cc'ing Matt Ray from OpsCode, since he and I discussed related topics
this past Thursday during the bug squash day...
On 02/06/2012 06:35 PM, Monty Taylor wrote:
I think the thing you are discussing already exists.
devstack is currently part of and managed by all of the normal OpenStack
development infrastructure. The canonical repository for it is
https://review.openstack.org/p/openstack-dev/devstack which is mirrored
to https://github.com/openstack-dev/devstack. Every change to OpenStack
is not only gated on devstack properly functioning, every change to
devstack is gated on OpenStack properly functioning.
Additionally, branches match up, so there is a stable/diablo that works
with stable/diablo of all of the OpenStack branches and is a part of
their trunk gating.
This is a critical piece of the puzzle. If I want a Diablo install for
testing, all I need to do is:
cd $devstack_dir
git checkout stable/diablo
rm -rf /opt/stack
./stack.sh
And I get a Diablo installation of OpenStack. Likewise, if I want a
development (Essex currently) version of OpenStack, I just do:
cd $devstack_dir
git checkout master
rm -rf /opt/stack
./stack.sh
And I get a development installation of OpenStack.
Now, I'm not entirely sure I even need to do the rm -rf /opt/stack part,
but I do that for good measure, even if it does mean it takes a little
longer... ;)
This is not something I can do currently with the other deployment methods.
In that sense, it's actually the first "install OpenStack" method that
_is_ fully a part of OpenStack - even though there are also chef recipes
and puppet modules in OpenStack's gerrit as well. (although at some
point I wouldn't mind getting some installation testing and gating on
them as well)
Yes, and getting those projects aligned with the core projects' branch
layout would be good, too. Followup email on the Chef stuff coming
shortly, as Matt ray and I discussed this last Thursday at length and I
think there's a lot we can do to improve things.
-jay
So it's pretty official already.
However, as to becoming an "official project" - it's a developer tool,
same as git-review or gerrit or the openstack nose-plugin. It's
something that's useful for developers for developing and testing
OpenStack. It is not, nor is it meant to be, part of the software we
"ship" -- which is the current definition of what it means to be a
"core" project. i.e. - If I'm a deployer and I want to "install
OpenStack" - is this one of the things I install? With devstack - the
answer is no.
Is is MASSIVELY helpful and a part of everyday life for all of us?
ABSOLUTELY (this is why we have to be careful with changes to it and run
them through the same process everything else gets)
All of that to say - I agree with you, and it's already done. :)
Monty
On 02/06/2012 01:43 PM, Joshua Harlow wrote:
So the part that worries me about what u just said is the part about “it
is already some kind of official project”.
When you have to question whether a project is official or not, that
seems to pretty make the whole point for making it official ;)
Overall though I think what u are saying is correct, but the overhead I
don’t see as being a bad thing.
In my idea release management is good since it allows developers to be
able to setup a development environment for a given openstack release
(good for when you need to fix bugs against a given release as well as
good for providing a stable point for other distributions to know what
goes in a release and what configs need to be adjusted to make that
release work for all the different components). So I don’t see that as a
drawback (even though yes it does add work/overhead in, but I don’t see
that as a valid point, in any case).
Downstream distribution, I am not exactly sure what you mean here?
A technical lead I think is something good to have, as this
script/code/documentation is not as simple as you might think (and most
likely won’t get any simpler).
Maybe the correct wording isn’t that this is a core project, but it
seems like it is already a widely used project, so I don’t see the
difference, either way it should become official and follow some of the
same processes as the rest of openstack. Yes it might be developer
oriented but if that doesn’t fit a definition of a core project (or
whatever u want to call it), because of it being developer focused, then
maybe the core project definition needs to be updated?
As for:
An other point is that the official CI systems (and I think
everybody else, too) are using devstack.org and and that the script
is doing a well job.
That’s the whole point, a un-official script shouldn’t be doing these
tasks ;)
-Josh
On 2/6/12 12:36 PM, "Christian Berendt"<bere...@b1-systems.de> wrote:
Hello together.
> I was wondering if the community could elevate devstack to a
> "official" openstack project, instead of being a "unofficial
> project".
I think devstack.org is already some kind of official project (provided
by Rackspace Cloud Builders).
Where is the benefit of becoming a core project? At the moment I only
see a lot of overhead (release management, downstream distribution,
technical lead, feature frozen zones, ..) without any benefits.
Also it would take a lot of efforts (see [0] for details) to set up a
new core project.
Devstack is an instrument to help and improve the development. I think
a core component must have the opportunity to be used in a productive
environment and should not "only" be used to support the development.
Can you please describe in more detail what are the benefits of
becoming a core project?
An other point is that the official CI systems (and I think everybody
else, too) are using devstack.org and and that the script is doing a
well job.
You're starting two discussions in this mail: Should devstack become a
part of the core and should devstack be rewritten to Python. I think
the discussions should be splitted and I don't see any motivation of
the devstack.org developers to join the discussion of a Python rewrite
at the moment (maybe I'm wrong).
I don't find the definition and requirements of a core project at the
moment, but I'm pretty sure that there exist some documents.
Maybe it makes sense to define some kind of requirements about OpenStack
specific tools used by the official CI, but that's an other discussion.
[0] http://wiki.openstack.org/Governance/Approved/NewProjectProcess
Bye, Christian.
--
Christian Berendt
Linux / Unix Consultant& Developer
Mail: bere...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
