Open Stack

On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague <sean at dague.net> wrote:

> On 08/22/2014 01:30 AM, Michael Chapman wrote:
> >
> >
> >
> > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes <jaypipes at gmail.com
> > <mailto:jaypipes at gmail.com>> wrote:
> >
> >     On 08/19/2014 11:28 PM, Robert Collins wrote:
> >
> >         On 20 August 2014 02:37, Jay Pipes <jaypipes at gmail.com
> >         <mailto:jaypipes at gmail.com>> wrote:
> >         ...
> >
> >                 I'd like to see more unification of implementations in
> >                 TripleO - but I
> >                 still believe our basic principle of using OpenStack
> >                 technologies that
> >                 already exist in preference to third party ones is still
> >                 sound, and
> >                 offers substantial dogfood and virtuous circle benefits.
> >
> >
> >
> >             No doubt Triple-O serves a valuable dogfood and virtuous
> >             cycle purpose.
> >             However, I would move that the Deployment Program should
> >             welcome the many
> >             projects currently in the stackforge/ code namespace that do
> >             deployment of
> >             OpenStack using traditional configuration management tools
> >             like Chef,
> >             Puppet, and Ansible. It cannot be argued that these
> >             configuration management
> >             systems are the de-facto way that OpenStack is deployed
> >             outside of HP, and
> >             they belong in the Deployment Program, IMO.
> >
> >
> >         I think you mean it 'can be argued'... ;).
> >
> >
> >     No, I definitely mean "cannot be argued" :) HP is the only company I
> >     know of that is deploying OpenStack using Triple-O. The vast
> >     majority of deployers I know of are deploying OpenStack using
> >     configuration management platforms and various systems or glue code
> >     for baremetal provisioning.
> >
> >     Note that I am not saying that Triple-O is bad in any way! I'm only
> >     saying that it does not represent the way that the majority of
> >     real-world deployments are done.
> >
> >
> >     > And I'd be happy if folk in
> >
> >         those communities want to join in the deployment program and
> >         have code
> >         repositories in openstack/. To date, none have asked.
> >
> >
> >     My point in this thread has been and continues to be that by having
> >     the TC "bless" a certain project as The OpenStack Way of X, that we
> >     implicitly are saying to other valid alternatives "Sorry, no need to
> >     apply here.".
> >
> >
> >             As a TC member, I would welcome someone from the Chef
> >             community proposing
> >             the Chef cookbooks for inclusion in the Deployment program,
> >             to live under
> >             the openstack/ code namespace. Same for the Puppet modules.
> >
> >
> >     While you may personally welcome the Chef community to propose
> >     joining the deployment Program and living under the openstack/ code
> >     namespace, I'm just saying that the impression our governance model
> >     and policies create is one of exclusion, not inclusion. Hope that
> >     clarifies better what I've been getting at.
> >
> >
> >
> > (As one of the core reviewers for the Puppet modules)
> >
> > Without a standardised package build process it's quite difficult to
> > test trunk Puppet modules vs trunk official projects. This means we cut
> > release branches some time after the projects themselves to give people
> > a chance to test. Until this changes and the modules can be released
> > with the same cadence as the integrated release I believe they should
> > remain on Stackforge.
> >
> > In addition and perhaps as a consequence, there isn't any public
> > integration testing at this time for the modules, although I know some
> > parties have developed and maintain their own.
> >
> > The Chef modules may be in a different state, but it's hard for me to
> > recommend the Puppet modules become part of an official program at this
> > stage.
>
> Is the focus of the Puppet modules only stable releases with packages?
>


We try to target puppet module master at upstream OpenStack master, but
without CI/CD we fall behind. The missing piece is building packages and
creating a local repo before doing the puppet run, which I'm working on
slowly as I want a single system for both deb and rpm that doesn't make my
eyes bleed. fpm and pleaserun are the two key tools here.


> Puppet + git based deploys would be honestly a really handy thing
> (especially as lots of people end up having custom fixes for their
> site). The lack of CM tools for git based deploys is I think one of the
> reasons we seen people using DevStack as a generic installer.
>
>
It's possible but it's also straight up a poor thing to do in my opinion.
If you're going to install nova from source, maybe you also want libvirt
from source to test a new feature, then you want some of libvirt's deps and
so on. Puppet isn't equipped to deal with this effectively. It runs yum
install x, and that brings in the dependencies.

It's much better to automate the package building process and install
everything using that single method. Otherwise the operations team now has
to consider which dependencies have come from pip, and which have come from
deb/rpm.


>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140823/4b3cdb83/attachment-0001.html>