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 <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).
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
