Open Stack

Excerpts from James Slagle's message of 2014-01-08 07:03:39 -0800:
> On Tue, Jan 7, 2014 at 11:20 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > On 8 January 2014 12:18, James Slagle <james.slagle at 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.
> 
> I just don't see anyone not building on a packaging toolchain, given
> that we're all running the distro of our choice and pip/virtualenv/etc
> are installed from distro packages.  Trying to isolate the building of
> components with pip installed virtualenvs was still a problem.  Short
> of uninstalling the build tools packages from the cloud image and then
> wget'ing the pip tarball, I don't think there would have been a good
> way around this particular problem.  Which, that approach may
> certainly make some sense for a CD scenario.
> 

I will definitely concede that we find problems at a high rate during
image builds, and that we would not if we just waited for others to solve
those problems. However, when we do solve those problems, we solve them
for everyone downstream from us. That is one reason it is so desirable
to keep our work in TripleO as far upstream as possible. Package work is
inherently downstream.

Also it is worth noting that problems at image build time are much simpler
to handle, because they happen on a single machine generally. That is
one reason I down play those issues. For anyone not interested in running
CD, we have the release process to handle such problems and they should
_never_ see any of these issues, whether running from packages or on
stable branches in the git repos.