openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

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