Open Stack

On 4 May 2015 at 08:59, Steve Baker <sbaker at redhat.com> wrote:
> On 02/05/15 07:06, Robert Collins wrote:
>>
>> On 2 May 2015 at 04:17, Doug Hellmann <doug at doughellmann.com> wrote:
>>>
>>> Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:
>>>>
>>>> pbr 0.11 is finally released (now that Kilo is out :).
>>>>
>>>> This brings in more support to ensure that our version numbers are
>>>> monotonically increasing.
>>>>
>>>> Mostly this should be unintrusive (but please do read the docs -
>>>> http://docs.openstack.org/developer/pbr/#version).
>>
>> ...
>>
>>> It would be good to make sure this is in the pbr documentation, too.
>>
>> It is, at the link I gave. If its not clear enough, please do help me
>> understand how, since having clear docs is kindof important :)
>>
>> I'd also like to do a little postmortem - here's the fallout I've
>> heard of from pbr's 0.11 release (which is > 1yr of inventory, so
>> kindof a big deal).
>>
> ...
>>
>>
>> Lastly, and still unresolved, heat's contrib plugin versions
>> (introduced in March) are deliberately different to the git history,
>> and thats a use case that pbr hasn't ever supported (multiple version
>> timelines in one git tree). https://review.openstack.org/#/c/162311/
>> introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733
>> is the bug for this.
>
> Our contrib plugins are not distributed with the heat release and are come
> with a very limited notion of being supported. Operators who want to install
> any are expected to git-clone to the desired revision and either cp -r to
> /usr/lib/heat (our original plugin mechanism) or pip-install (so the plugin
> can be picked up by stevedore).
>
> Specifying the version in setup.cfg was added to stop pbr complaining about
> the lack of version, and to give operators some way of managing what version
> of what they have installed.
>
> We would prefer to keep the contrib plugins in-tree since it lets us run
> their unit tests in the standard gate job, and allows them to evolve with
> internal API additions. I fully realize that having mini packages in
> sub-directories is ... unique.
>
> What I think I would like is a way to tell pbr to ignore git and take the
> overridden version from setup.cfg. Having declarative setup is nice, but
> another option would be to just switch to plain setuptools - these are not
> complicated packages.

So, we've got a design requirements mismatch here, and should give
this the same care we do other decisions - I've set up
https://etherpad.openstack.org/p/heat-plugin-pbr to start capturing
your desires, and also to summarise the pbr constraints that led to
where we are today, from there we can work forward.

-Rob

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