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 <openst...@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).

> 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.

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

-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to