Open Stack

On 2014-02-24 14:51, Sean Dague wrote:
> On 02/24/2014 03:10 PM, Ben Nemec wrote:
>> On 2014-02-21 17:09, Sean Dague wrote:
>>> On 02/21/2014 05:28 PM, Clark Boylan wrote:
>>>> On Fri, Feb 21, 2014 at 1:00 PM, Ben Nemec <openstack at nemebean.com>
>>>> wrote:
>>>>> On 2014-02-21 13:01, Mike Spreitzer wrote:
>>>>> 
>>>>> https://bugs.launchpad.net/devstack/+bug/1203680 is literally about
>>>>> Glance
>>>>> but Nova has the same problem.  There is a fix released, but just
>>>>> merging
>>>>> that fix accomplishes nothing --- we need people who run DevStack 
>>>>> to
>>>>> set the
>>>>> new variable (INSTALL_TESTONLY_PACKAGES).  This is something that
>>>>> needs to
>>>>> be documented (in http://devstack.org/configuration.html and all 
>>>>> the
>>>>> places
>>>>> that tell people how to do unit testing, for examples), so that
>>>>> people know
>>>>> to do it, right?
>>>>> 
>>>>> 
>>>>> 
>>>>> IMHO, that should be enabled by default.  Every developer using
>>>>> devstack is
>>>>> going to want to run unit tests at some point (or should 
>>>>> anyway...),
>>>>> and if
>>>>> the gate doesn't want the extra install time for something like
>>>>> tempest that
>>>>> probably doesn't need these packages, then it's much simpler to
>>>>> disable it
>>>>> in that one config instead of every separate config used by every
>>>>> developer.
>>>>> 
>>>>> -Ben
>>>>> 
>>>> 
>>>> I would be wary of relying on devstack to configure your unittest
>>>> environments. Just like it takes over the node you run it on, 
>>>> devstack
>>>> takes full ownership of the repos it clones and will do potentially
>>>> lossy things like `git reset --hard` when you don't expect it to. +1
>>>> to documenting the requirements for unittesting, not sure I would
>>>> include devstack in that documentation.
>>> 
>>> Agreed, I never run unit tests in the devstack tree. I run them on my
>>> laptop or other non dedicated computers. That's why we do unit tests 
>>> in
>>> virtual envs, they don't need a full environment.
>>> 
>>> Also many of the unit tests can't be run when openstack services are
>>> actually running, because they try to bind to ports that openstack
>>> services use.
>>> 
>>> It's one of the reasons I've never considered that path a priority in
>>> devstack.
>>> 
>>>     -Sean
>>> 
>> 
>> What is the point of devstack if we can't use it for development?
> 
> I builds you a consistent cloud.
> 
>> Are
>> we really telling people that they shouldn't be altering the code in
>> /opt/stack because it's owned by devstack, and devstack reserves the
>> right to blow it away any time it feels the urge?
> 
> Actually, I tell people that all that time. Most of them don't listen 
> to
> me. :)
> 
> Devstack defaults to RECLONE=False, but that tends to break people in
> other ways (like having month old trees they are building against). But
> the reality is I've watched tons of people have their work reset on 
> them
> because they were developing in /opt/stack, so I tell people don't do
> that (and if they do it anyway, at least they realize it's dangerous).

How would you feel about doing a git stash before doing reclones?  
Granted, that still requires people to know that the changes were 
stashed, but at least if someone reclones, loses their changes, and 
freaks out on #openstack-dev or something we can tell them how to get 
the changes back. :-)

> 
>> And if that's not
>> what we're saying, aren't they going to want to run unit tests before
>> they push their changes from /opt/stack?  I don't think it's 
>> reasonable
>> to tell them that they have to copy their code to another system to 
>> run
>> unit tests on it.
> 
> Devstack can clone from alternate sources, and that's my approach on
> anything long running. For instance, keeping trees in ~/code/ and 
> adjust
> localrc to use those trees/branches that I'm using (with the added
> benefit of being able to easily reclone the rest of the tree).
> 
> Lots of people use devstack + vagrant, and do basically the same thing
> with their laptop repos being mounted up into the guest.

So is there some git magic that also keeps the repos in sync, or do you 
have to commit/pull/restart service every time you make changes?  I ask 
because experience tells me I would inevitably forget one of those steps 
at some point and be stymied by old code still running in my devstack.  
Heck, I occasionally forget just the "restart service" step. ;-)

> 
> And some people do it the way you are suggesting above.
> 
> The point is, for better or worse, what we have is a set of tools from
> which you can assemble a workflow that suits your needs. We don't have 
> a
> prescribed "this is the one way to develop" approach. There is some
> assumption that you'll pull together something from the tools provided.
> 
> 	-Sean