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