openstack team mailing list archive

[Maru Newby <mnewby@xxxxxxxxxxxx>]

Hi Josh,

Your perspective is certainly valid, no argument from me.

Devstack advertises being written in bash instead of Chef/Puppet/etc to be able to provide a documented install and avoid alienating the unchosen CM communities.  Is the functionality of DevstackPy similiarly constrained by not being allowed to be implemented with an existing CM tool?  If so, my line of argument is entirely moot and I apologize.

Cheers,


Maru


On 2012-02-07, at 1:39 PM, Joshua Harlow wrote:

> Aren’t the problems u just stated really just things that need to be “watched” and “controlled” by technical leadership?
> Ie, its the leads job to make sure it doesn’t grow out of control. I don’t see how the excuse that something could go out of control as a reason to not do it in the first place.
> Everything can go out of control and blow-up and become a new CM/puppet when it shouldn’t be, but only if u let it. General life principle :-)
> 
> On 2/7/12 1:36 PM, "Maru Newby" <mnewby@xxxxxxxxxxxx> wrote:
> 
> Hi Josh,
> 
> Devstack in bash will only get more complicated and harder to maintain as time goes on.  Supporting multiple distros would add to that complexity, and increase the resources required to support devstack.
> 
> As far as DevstackPy goes, I have mixed feelings.  It's easier to write testable functionality in Python, and OpenStack's reliance on the language means there is lots of capability in the community.  But at what point does DevstackPy start to approach the functionality of a Chef or Puppet?  If the goal is flexibility and multi-platform, why wouldn't DevstackPy end up re-implementing much of what existing CM tools do?
> 
> Personally, I would love to see a Chef equivalent written in Python.  But is the answer to not wanting to officially support a CM tool to write our own?  No project has unlimited resources, and I'm wondering if it doesn't make more sense to just choose between Chef or Puppet.
> 
> Cheers,
> 
> 
> Maru 
> 
> 
> On 2012-02-07, at 12:59 PM, Joshua Harlow wrote:
> 
> Re: [Openstack] [DEVSTACK] officialize it! 
> Hmmm, that seems odd, and I guess I don’t understand your reasoning there.
> 
> There are other developers that develop on more than just ubuntu X (where X is the latest ubuntu). Ie yahoo is on rhel, I’m pretty sure red hat is running rhel/fedora so the idea that because a “self-declared mission lies”  is enough of a reason to not do something correctly seems pretty wrong. Rewrite the mission then imho. Having a separate devstack by rhel also seems wrong (yet another implementation).  I know its possible to do this right, even if the “mission” was different before since me and my pep’s at yahoo + others have been writing https://github.com/yahoo/Openstack-DevstackPy
> Which guess what, has most of the features of devstack, written in python, but also can run in rhel 6.2, ubuntu 11 and work is being done for fedora 16.
> 
> Josh
> 
> On 2/6/12 9:51 PM, "Maru Newby" <mnewby@xxxxxxxxxxxx <x-msg://211/mnewby@xxxxxxxxxxxx> > wrote:
> 
> -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:
> 
> Re: [Openstack] [DEVSTACK] officialize it! 
> + 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@xxxxxxxxx <x-msg://211/jaypipes@xxxxxxxxx>  <x-msg://92/jaypipes@xxxxxxxxx <x-msg://92/jaypipes@xxxxxxxxx> > > 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 <http://devstack.org>  <http://devstack.org <http://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@xxxxxxxxxxxxx <x-msg://211/berendt@xxxxxxxxxxxxx>  <x-msg://92/berendt@xxxxxxxxxxxxx <x-msg://92/berendt@xxxxxxxxxxxxx> > >  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 <http://devstack.org>  <http://devstack.org <http://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 <http://devstack.org>  <http://devstack.org <http://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 <http://devstack.org>  <http://devstack.org <http://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@xxxxxxxxxxxxx <x-msg://211/berendt@xxxxxxxxxxxxx>  <x-msg://92/berendt@xxxxxxxxxxxxx <x-msg://92/berendt@xxxxxxxxxxxxx> > 
> >>
> >>      B1 Systems GmbH
> >>      Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de <http://www.b1-systems.de/>  <http://www.b1-systems.de/> 
> >>      GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> >>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx <x-msg://211/openstack@xxxxxxxxxxxxxxxxxxx>  <x-msg://92/openstack@xxxxxxxxxxxxxxxxxxx <x-msg://92/openstack@xxxxxxxxxxxxxxxxxxx> > 
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx <x-msg://211/openstack@xxxxxxxxxxxxxxxxxxx>  <x-msg://92/openstack@xxxxxxxxxxxxxxxxxxx <x-msg://92/openstack@xxxxxxxxxxxxxxxxxxx> > 
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx <x-msg://211/openstack@xxxxxxxxxxxxxxxxxxx>  <x-msg://92/openstack@xxxxxxxxxxxxxxxxxxx <x-msg://92/openstack@xxxxxxxxxxxxxxxxxxx> > 
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx <x-msg://211/openstack@xxxxxxxxxxxxxxxxxxx> 
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
>