settingsLogin | Registersettings

Re: [openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors

0 votes

On 2 May 2015 at 04:17, Doug Hellmann doug@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).

Two number of projects had backslid since the audit I did last year on
their setup.cfg's: tempest and rally. These have all been trivially
fixed by removal. tempest's caused issues in many different projects
test runs though, which let to some confused reports - generally any
patch hitting that issue should be fine on a recheck.
http://logs.openstack.org/85/179285/1/check/check-tempest-dsvm-full/1c5fec4/logs/devstacklog.txt.gz#_2015-04-30_23_47_08_277
and the following error show this.

Nova had a unit test that mocked out only part of the API it was
using, and when the internals of pbr changed, the mocking stopped
being effective. It was using VersionInfo.version_string, but mocking
VersionInfo.version. https://review.openstack.org/179307 and the
associated backports fix this. I think we should move the vendor
functionality into pbr itself (you'd give pbr a callback to get the
vendor info) rather than having multiple copies of it one per server,
all potentially different.

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.

-Rob

--
Robert Collins rbtcollins@hp.com
Distinguished Technologist
HP Converged Cloud


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 1, 2015 in openstack-dev by Robert_Collins (27,200 points)   4 6 12

2 Responses

0 votes

On 02/05/15 07:06, Robert Collins wrote:
On 2 May 2015 at 04:17, Doug Hellmann doug@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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 3, 2015 by Steve_Baker (7,380 points)   1 3 6
0 votes

On 4 May 2015 at 08:59, Steve Baker sbaker@redhat.com wrote:
On 02/05/15 07:06, Robert Collins wrote:

On 2 May 2015 at 04:17, Doug Hellmann doug@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@hp.com
Distinguished Technologist
HP Converged Cloud


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 3, 2015 by Robert_Collins (27,200 points)   4 6 12
...