Open Stack

On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> On Oct 17, 2016 7:27 PM, "Thomas Goirand" <zigo at debian.org
> <mailto:zigo at debian.org>> wrote:
>>
>> On 10/17/2016 08:43 PM, Adam Harwell wrote:
>> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
>> > aware is to maintain interoperability between project dependencies for
>> > openstack deploys, and since our amphora image is totally separate, it
>> > should not be restricted to g-r requirements.
>>
>> The fact that we have a unified version number of a given lib in all of
>> OpenStack is also because that's a requirement of downstream distros.
>>
>> Imagine that someone would like to build the Octavia image using
>> exclusively packages from <your-favorite-distro-here>...
>>
>> > I brought this up, but
>> > others thought it would be prudent to go the g-r route anyway.
>>
>> It is, and IMO you should go this route.
> 
> I'm not convinced by your arguments here, Thomas. If the distributor
> were packaging Octavia for X but the image is using some other operating
> system, say Y, why are X's packages relevant?

What if operating systems would be the same?

As a Debian package maintainer, I really prefer if the underlying images
can also be Debian (and preferably Debian stable everywhere).

> I would think that if this
> is something inside an image going to be launched by Octavia that
> co-installibilty wouldn't really be an issue.

The issue isn't co-instability, but the fact that downstream
distribution vendors will only package *ONE* version of a given python
module. If we have Octavia with version X, and another component of
OpenStack with version Y, then we're stuck with Octavia not being
packageable in downstream distros.

> I don't lean either way right now, so I'd really like to understand your
> point of view, especially since right now it isn't making much sense to me.

Do you understand now? :)

Cheers,

Thomas