Open Stack

On 22 August 2015 at 11:50, Dave Walker <email at daviey.com> wrote:
> On 22 August 2015 at 00:04, Matthew Thode <prometheanfire at gentoo.org> wrote:
>> On 08/21/2015 05:59 PM, Robert Collins wrote:
>>> On 22 August 2015 at 10:57, Matthew Thode <prometheanfire at gentoo.org> wrote:
>>>> Packaging for us is fairly easy, but it is annoying to have to add 5-6
>>>> deps each release, (which means we are adding cruft over time).
>>>
>>> We're adding functionality by bringing in existing implementations.
>>> Surely thats better than reinventing *everything* ?
>>>
>>> -Rob
>>>
>> totally, more of a minor annoyance :P
>
> A strong reason that requirements was created was to give distros a
> voice and avoid incompatible versions, which was more of a problem for
> distros than it was for each different service at that point.

So, incompatible versions with which/what packages? We guarantee
co-installability within OpenStack, but if e.g. RHEL and Ubuntu are
mutually incompatible in their versions of some package, what should
OpenStack do? That seems like a problem that is intrinsically
unsolvable for OpenStack as its a consistency issue between a large
and growing number of independent groups - and inevitably, in that
situation, one loses. So they have to solve it locally - for Ubuntu
via click, for RHEL via software collections. So if its locally
solvable, why should OpenStack consider it?

On the voice: please do get more distributors reviewing requirements changes!

> I'm not sure that a requirement has ever been not included because it
> *wasn't* packaged, but perhaps because it *couldn't* be packaged.  Is
> there an example that has caused you to raise this?

I'm a new core there and trying to make sure what we document and what
we want to happen are the same thing. 'Apply caution' doesn't mean
much to me other than to feel scared! So I'm trying to elucidate what
should be there instead.

> The is-it-packaged-test was added at a time where large changes were
> happening in OpenStack right up to the (release) wire and cause scary
> changes for distros that were tracking the release.  Now, Feature
> development has become more mature with the scary stuff being front
> loaded, I'm not quite sure this is such a problem.
>
> The release schedule used to document a DepFreeze[0] to avoid nasty
> surprises for distros, which used to be at the same point of
> FeatureFreeze[1].  This reference seems to have been removed from the
> last few cycles, but I would suggest that it could be re-added.

As more components of OpenStack are moving away from big-bang
releases, DepFreeze would make less and less sense to me. The
integrated release is on the way out.

-Rob

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