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" <mord...@inaugust.com> wrote: > > > > > On 02/07/2012 06:44 AM, Alan Pevec wrote: > > On Tue, Feb 7, 2012 at 6:51 AM, Maru Newby <mne...@internap.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
