Open Stack

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?
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.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140822/8a128876/attachment.pgp>