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
