Open Stack

Yes, thanks Tom for connecting the dots.

I would be happy to speak about the work that I have been doing with
omnibus-openstack.  (In fact, I will be at ChefConf this year)

While this is not a Chef-specific tool, the Opscode folks already had a
rich and widely-used platform for doing such things, so I decided to take
advantage of it.  Seems like it may be similar to Anvil in some ways,
though probably quite different in many others.  The basic philosophy is to
build any of the openstack components and their dependencies (both Python
and system dependencies) into a sandbox that lives under /opt/<whatever
youd like>. This is all driven from an extraordinarily simple configuration
file that both instructs the tool what to build and where to get it.  The
build currently runs in Vagrant, but I am in the process of adding
Heat/Nova support now.  The output is a package specific to the flavor it
was built on - rpms, debs now, and conceivably other types (though this is
not tested).

My tool takes no stance on configuring OpenStack. In fact, there is already
a Chef cookbook that will work with these packages (and that cookbook has
no direct dependencies on the Stackforge cookbooks), and Ansible support
will be happening in the next few weeks.  Would also be great to get some
Puppet/Salt/whatever support as well.  I believe this to be an important
tenant: there are already very rich toolsets for config management, and
packaging should not attempt to duplicate this work.  Anyone standing up
OpenStack will already have one of these in-house (and probably the
expertise to support it).

But yeah, I'm definitely down for a hangout on the subject :)

https://github.com/craigtracey/omnibus-openstack
https://github.com/craigtracey/omnibus-openstack-build
https://github.com/craigtracey/cookbook-openstack-omnibus


On Wed, Mar 12, 2014 at 1:22 AM, Allamaraju, Subbu <subbu at subbu.org> wrote:

> Thanks Tom for adding the details from the summit last week. I missed this
> thread. This topic deserves to be a key project in OpenStack :)
>
> Josh - let us know if you're interested in additional details. At work we
> spend some cycles doing this activity.
>
> Regards,
> Subbu
>
> On Mar 11, 2014, at 10:06 PM, Tom Fifield <tom at openstack.org> wrote:
>
> > Hi all,
> >
> > Thanks for starting the thread Josh - you're too fast ;)
> >
> > Just to fill in some more information from the day...
> >
> > Recently, we got about 50 people together who are all running OpenStack
> clouds to have a bit of a rant session. The very first thing that came up
> was: packaging.
> >
> > It turns out that:
> > 1) the majority of people in that room (who are running production
> clouds) are making their own custom packages for at least some components
> >
> > 2) People package for different reasons, eg they:
> > * need isolation of virtual environments - different versions of
> openstack services on the one machine
> > * want to incorporate features from a newer version
> > * need to fix bugs
> > * find the lag time between bug fix and fix appearing in upstream distro
> repo is too long, so patch locally carry it in-house until then
> > * need vendor-fixed drivers that are not yet part of upstream
> > * don't find the quality or consistency of upstream packages to be
> sufficient
> > * find that upstream dependencies break things
> > * discovered that some packages assume internet access is available,
> when it is not
> > * have their own custom additions
> > * are doing continuous deployment
> >
> >
> > 3) People are using either upstream source or distro packages as a
> source for their custom packages
> >
> > 4) Most people are not packaging other software, just OpenStack
> >
> > 5) Many people believe that OpenStack will not get the the stage (at
> least for a long time) where they can just use upstream packages, because
> OpenStack has a high level of innovation and change and it's a complicated,
> distributed service.
> >
> > Throughout all of this, quite a few different toolchains have been
> developed for packaging OpenStack in various environments. So, I think,
> given that so many people are packaging...
> >
> >
> > ==> we need to form a community around making it really easy to make
> custom packages of OpenStack bits
> >
> >
> > If you agree, it would be great if we could get you and others together
> to have a chat about what's out there right now, potentially improve them,
> and leave some brilliantly coloured flags (possibly in the form of
> docs/tutorials/rants) for the ops guys that follow us :) On the day we had
> a couple of people volunteer to kick this effort of, so I'll let them jump
> in and take control!
> >
> >
> > Regards,
> >
> >
> > Tom
> >
> >
> > On 06/03/14 04:54, Joshua Harlow wrote:
> >> Hi all,
> >>
> >> At the operators summit etherpad[1] I saw some discussion about
> packaging.
> >>
> >> Since I'm currently hosting
> >> https://etherpad.openstack.org/p/tripleo-icehouse-sprint I wasn't able
> to
> >> attend (sorry).
> >>
> >> But I did leave some comments about what anvil[2] is doing related to
> >> packaging.
> >>
> >> I was wondering if there is enough interest to hear more about what its
> >> doing in more depth (and have a Q/A...)?
> >>
> >> Potentially something on hangouts or elsewhere?
> >>
> >> Let me know :-)
> >>
> >> -Josh
> >>
> >> [1] https://etherpad.openstack.org/p/operators-feedback-mar14
> >> [2] http://anvil.readthedocs.org/en/latest/
> >>
> >>
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140313/9f2716eb/attachment.html>