openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

Heh. Of course.

I'm not really advocating puppet or chef. I think juju is pretty cool
too, actually... I think all I'm saying is that I'm VERY concerned that
if we expand the scope of devstack to be a tool people can use to deploy
operational OpenStack if they don't want to use puppet or chef or juju,
that we might undercut the original target audience - which are devs who
need to install openstack easily into a vm for local testing.

As long as we don't screw those people, I'm fine with whatever, and want
to do what I can to enable any of the choices people might make.

Monty

On 02/07/2012 03:23 PM, Joshua Harlow wrote:
> Just one problem.
> Some companies may not be wanting to use puppet or chef (at least in the
> short-term).
> I know of at least one ;)
> But maybe this can be worked on...
> 
> On 2/7/12 12:37 PM, "Monty Taylor" <mordred@xxxxxxxxxxxx> wrote:
> 
> 
> 
> 
>     On 02/07/2012 06:44 AM, Alan Pevec wrote:
>     > On Tue, Feb 7, 2012 at 6:51 AM, Maru Newby <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.
>     >
>     > In the meantime devstack's mission was expanded to gate all new
>     > commits as a part of Jenkins job e.g.
>     > https://jenkins.openstack.org/job/gate-integration-tests-devstack-vm/1130/
>     > It would be fair to provide the same check on all platforms which care
>     > to support Openstack.
>     > Devstack on Ubuntu could stay primary target and gating criteria but
>     > e.g. Red Hat provided Jenkins instance would add informational gerrit
>     > comments. Same for other platforms which are willing to contribute
>     > resources.
> 
>     ACTUALLY - I'd way prefer to get chef/puppet/cfengine/juju support for
>     expanding commit gating.
> 
>     The reason that we're using devstack for that purpose right now is that
>     a) it worked and b) came with actual instructions and c) had a team of
>     people willing to work with us to get it up and running consistently.
> 
>     It also had (and has) the benefit of being something that devs could use
>     it to duplicate locally what jenkins was doing - so that if their change
>     got rejected, there was a reasonable expectation that they could
>     troubleshoot why (this expectation is not as reasonable with
>     jenkins-based puppet and chef deployments)
> 
>     Once we get in to either chef/puppet deploys or multi-distro-targetted
>     devstack, that last point gets much more complex. We've developed a
>     feature that we haven't turned on yet to deal with it - which is the
>     ability to have Jenkins hand the cloud server where the failed test ran
>     to the developer whose change caused the test failure ... and honesty
>     we're going to have to get the go-ahead to turn that on if we intend on
>     starting to do either puppet/chef deployments or multi-distro targets -
>     as it is NOT reasonable to expect a developer to have Ubuntu, Fedora,
>     CentOS and Debian at the disposal and also to understand how to deploy
>     software on those targets using puppet, chef, juju, cfengine and
>     devstack2.
> 
>     That being said I fully intend to get chef and puppet-based testing up
>     and going - and we're also more than happy to work with folks on adding
>     more testing targets. How soon we can make those targets part of gating
>     largely depends on how well we can solve the issues surrounding devs
>     getting access to debug problems.
> 
> 
>     >> +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.
>     >
>     > Why is that, could you explain so non-apt distros can improve?
> 
>     I'm a huge Ubuntu fanboi and was a Debian fanboi before that - but I
>     have to strongly disagree with the above statement. Fedora is a fine
>     platform to develop for and to maintain support for, as is pretty much
>     any platform that's reasonably modern with sensible tooling.
> 
>     >> Mind you, I don't think anybody would complain if Redhat et al
>     wanted to
>     >> maintain their own targeted version of devstack.
>     >
>     > Fair enough, but I'd rather avoid fork and help DevstackPy which is
>     > designed to support multiple distros.
> 
>     Honestly - from the CI side of things, I'll run anything anybody hands
>     me, as long as it meets a few criteria:
> 
>     - scriptable
>     - consistently repeatable - we run this stuff 100s of times a day
>     - use is documented (does not mean "become a puppet expert first, then
>     follow these three simple instructions")
>     - external network resources must be cachable, or the process must be
>     able to be done in stages so that I can do all of the network access as
>     part of setting up the test environment _BEFORE_ we run the actual test
>     ... a devs code should not fail a test because github happens to be down
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>     Unsubscribe : https://launchpad.net/~openstack
>     More help   : https://help.launchpad.net/ListHelp
>