Open Stack

On 8 January 2014 12:26, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> One of the major features using a distro over upstream gives is integration.
> rhel6 behaves differently then ubuntu 13.10. Sometimes it takes a while to fix upstream for a given distro, and even then it may not even be accepted because "the distro's too old, go away". Packages allow a distro to make sure all the pieces can work together properly. And quickly patch things when needed. Its kind of a fork but not quite the same thing. The distro integrates not just OpenStack, but all its dependencies and their dependencies all the way up. For example there can be subtle issues if neutron, open vswitch and the kernel are out of sync. It is the integration that folks like about distro's. "I can trust that since it came from X, all the pieces should work together, or I know who to call".
>
> The only way I can think of to get the same stability out of just source is for Triple-O to provide a whole source distro and test it, itself. More work then it probably wants to do. Or pick just one distro and support source only on that. Though if you pick the wrong distro, then you get into trust issues and religious wars. :/

It is precisely that integration tested confidence that inspired the
TripleO design: we don't know if a given combination of components
work unless we've tested it. So TripleO is about the lifecycle:

code -> image -> test -> deploy.

What is deployed is what was tested.

Where we source what was tested - packages or pypi or git - is
irrelevant to the test results.

I think we need to support everything that someone wants to offer up
patches to make work (and ongoing support for whatever approach that
is) because there are many use cases for users: if they get OpenStack
using TripleO from e.g. Mirantis, or RedHat, or upstream, they will
want to be using the install mechanism preferred by their service
provider - and for TripleO to be widely applicable, we need to permit
service providers to dial their own story.

We're at the top of a waterfall of
pull-and-build-and-test-and-distribute - we don't get to pick Chef vs
Puppet vs nothing, or packages vs git vs pypi, or RHEL vs Ubuntu or
Xen vs Kvm or Ceph vs GlusterFS.

We do need to start with one thing and then add more backends -
balance generalising everything with the cost ofa dding plug points
after things are in use.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud