Project

Profile

Help

Issue #2342

closed

Vagrant setup does not allow to checkout the code in anywhere except $HOME/devel

Added by ipanova@redhat.com over 7 years ago. Updated almost 5 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

following docs https://github.com/pulp/pulp/blob/master/docs/dev-guide/contributing/dev_setup.rst#creating-the-vagrant-environment

There are a lot of permission errors in case you specify any other directory other then ~/devel

Actions #1

Updated by semyers over 7 years ago

I think this is by design. You really should use ~/devel.

Actions #2

Updated by semyers over 7 years ago

semyers wrote:

I think this is by design. You really should use ~/devel.

I misinterpreted this as referring to ~/devel in the vagrant guest machine, but in talking about it the code needed to be in ~/devel on the host. That is not okay.

Actions #3

Updated by amacdona@redhat.com over 7 years ago

  • Triaged changed from No to Yes
Actions #4

Updated by semyers about 7 years ago

I haven't been able to reproduce this, but it might be fixed for 3.0. I definitely had this in mind when converting all the 3.0 vagrant stuff to ansible, and tested installing from code in locations other than ~/devel on both the host and the vagrant box while developing the playbook.

Actions #5

Updated by bmbouter about 7 years ago

Here is some more info on what we observed. When bizhang and I experienced the issue I believe the checkouts were located on the host system at ~/pulp/ or ~/devel/pulp/pulp/ (one extra 'pulp' dir). This was with a Pulp 2.y setup. IIRC, the Vagrant completed and Pulp was installed, but most of the pulp bits that you expected to be from your checkouts actually came from rpms. This led to a strange "my changes are not taking effect" problem.

Actions #6

Updated by bmbouter about 7 years ago

Could the issue be here[0]? If the path is different it doesn't recognize a code checkout is present and you end up with a system installed version. I'm not certain, but that line could be running on the host system.

[0]: https://github.com/pulp/devel/blob/c3640dcc58d36cd92b9f9822f85b5f584dec3a0c/ansible/library/pulp_facts.py#L38

Actions #7

Updated by semyers about 7 years ago

bmbouter wrote:

Could the issue be here[0]? If the path is different it doesn't recognize a code checkout is present and you end up with a system installed version. I'm not certain, but that line could be running on the host system.

[0]: https://github.com/pulp/devel/blob/c3640dcc58d36cd92b9f9822f85b5f584dec3a0c/ansible/library/pulp_facts.py#L38

That file should be run on the remote machine.

Actions #8

Updated by bmbouter about 7 years ago

@smyers: after reading the vagrantfile I agree it is run on the remote machine.

I'm not sure what is setting the host_path variable here[0]. Perhaps that is related.

[0]: https://github.com/pulp/devel/blob/9c5a1904c23ad2538ada7776cd94bded7d03e161/Vagrantfile.example#L58

Actions #9

Updated by bmbouter about 7 years ago

The description claims that permission errors are the problem, but I've observed the issue without permission errors occurring. This is from memory but roughly:

1. Check out platform to ~/notdevel/pulp/ and pulp_rpm to ~/notdevel/pulp_rpm/
2. vagrant up
3. SSH to the vagrant env and cd /tmp
4. Create a python shell and run:

>>> from pulp import server
>>> 
>>> server
<module 'pulp.server' from '/home/vagrant/devel/pulp/server/pulp/server/__init__.pyc'>

The above is a healthy environment. A broken environment would show pulp.server being provided from /usr/lib/python2.7/site-packages/pulp/

Actions #10

Updated by amacdona@redhat.com over 6 years ago

  • Status changed from NEW to CLOSED - CURRENTRELEASE
Actions #11

Updated by bmbouter almost 5 years ago

  • Tags Pulp 2 added

Also available in: Atom PDF