Open Stack

-1 on multi-distribution devstack.  Being cross-platform is arguably a place where chef/puppet/cfengine automation comes into play, and that's not where devstack's self-declared mission lies.

+1 to continuing to have Ubuntu be the reference devstack target.  Maintaining support for an apt-based distribution is much easier than the alternatives from a developer perspective.

Mind you, I don't think anybody would complain if Redhat et al wanted to maintain their own targeted version of devstack.

Thanks,


Maru

On 2012-02-06, at 5:22 PM, Joshua Harlow wrote:

> + There needs to be a way to install on multiple distributions (without saying go figure out the deps yourself).
> 
> I know everyone is ubuntu, ubuntu, ubuntu, but this really needs to be fixed (process wise as well).
> 
> :-/
> 
> On 2/6/12 5:12 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
> 
> 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"<berendt at 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: berendt at 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 at lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120206/0d43c492/attachment.html>