On Wed, 2014-01-08 at 17:20 +1300, Robert Collins wrote: > On 8 January 2014 12:18, James Slagle <james.sla...@gmail.com> wrote: > > Sure, the crux of the problem was likely that versions in the distro > > were too old and they needed to be updated. But unless we take on > > building the whole OS from source/git/whatever every time, we're > > always going to have that issue. So, an additional benefit of > > packages is that you can install a known good version of an OpenStack > > component that is known to work with the versions of dependent > > software you already have installed. > > The problem is that OpenStack is building against newer stuff than is > in distros, so folk building on a packaging toolchain are going to > often be in catchup mode - I think we need to anticipate package based > environments running against releases rather than CD.
It's about matching the expectations of the end user (deployer). If they lean towards a CD model, then git based OpenStack deployments are clearly a necessity -- otherwise we'd need to maintain a set of package archives built (and tested!) for every project and every commit to master. If they lean towards a more traditional release model, then OpenStack packages maintained (and tested!) by the distros are a better fit for the end user. However... Both camps should be able to experience the benefits of having an OpenStack undercloud building an OpenStack overcloud, without forcing the end user to adopt a methodology they may not yet be comfortable with. As an aside, Fuel has an overcloud builder that uses Puppet to deploy OpenStack with packages [1]. I understand the Fuel dev team at Mirantis is keen to join forces with the Triple-O contributor community and reduce duplicative efforts. This may be the perfect place to pull some practices from Fuel to enable some flexibility in how tripleo-image-elements constructs things. If you want a good indication of how much overlap there is, just look at the list of puppet modules in Fuel [2] vs. the list of elements in t-i-e [3]. Sure, t-i-e is Bash scripts and Fuel is Puppet manifests, but they are trying to do the same fundamental thing: produce an Overcloud entirely through automation. There are definite advantages to both approaches. Would be great to put our heads together and get the best of both worlds. I think the end user would benefit. All the best, -jay [1] Just one example... here is the Glance installation by package: https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/glance/manifests/registry.pp#L76 [2] https://github.com/stackforge/fuel-library/tree/master/deployment/puppet [3] https://github.com/openstack/tripleo-image-elements/tree/master/elements _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev