Open Stack

(I sincerely apologize for the length of this email. I have a lot to ask/say and I promise to be more concise in future mailings.)

Hey All,

I didn't get to talk to much of the Infrastructure team at the summit, but I'm pretty tired of not working closer with OpenStack CI.

For reference, I work at Rackspace to deploy OpenStack.

Long story short: I want to create environments, manage environments, and deploy code to environments under the auspices of the OpenStack Infrastructure team.

Now, I guess the first question I'd like answered is: Is this goal under the purview of OSCI (do you have a nickname/shortname?)? Is it reasonable? Perhaps you can't answer that without elaboration. Here is some.

The devstack-gate is great -- but it is devstack nonetheless. We should have a devstack gate. We also need other, more realistic gates. You know this, I'm pretty sure we agree on this at least but to be honest I can't remember with everything that's been happening the past week.

We seem to have already:

  *   devstack-gate
  *   a very nice, flexible gating system

What I/we would like to help with:

  *   more gating scenarios
  *   deployment tool(s) standardization

One issue is the vague term "more gating scenarios". Obviously I mean everything you've ever thought off. All permutations of $platform, $config_management, $packaging_method, $deployment_method, $use_cells I suppose. Since that's a lot, we'll choose the one we care about the most: XenServer, masterless puppet, venv, mcollective, 2 cells.

Woah, woah, woah, you say. Where did masterless puppet, venv, and mcollective come from?! Well, those are what we're using now. If they have to change because they're not the technologies chosen for the future then so be it. I'm not attached to technologies.

We use no puppet masters because puppet did not scale for us (even with many puppet masters behind LBs).
We use venv because it's more cross-platform and makes it easy to deploy multiple versions of software at the same time.
We use mcollective to orchestrate the deployment because PSSH is slow when dealing with a significantly large number of hosts.

However, if you ignore all of the above, a great first step is XenServer and forget all the other things (for now).

So the question again becomes how can we get XenServer into the gate. I imagine it going something like this:

1) Hardware is provided with XenServer 6.1 installed
2) Script for Jenkins will boot XenServer VM on hardware provided
3) VM will be configured using...devstack?
4) This script will be an unofficial gate (aka 3rd party gate) until it is considered stable
5) This script will be integrated into the official process either as a gate-gate or a periodic-gate

As you can see I'm pretty fuzzy on the details, which is where this list comes in. Heck, some of my team is on this list and will probably be shouting at their monitors that I'm doing it all wrong. It isn't the first time and won't be the last time.

Ending before this email rambles on more,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20130423/39ecde58/attachment.html>