Also to go further into a little mini-retrospective we did during our
meeting. This got released and passed through the periodic jobs we run
before releasing in oslo due to primarily a timing glitch. When the
patch[0] was proposed to the release repo the nova periodic jobs were
fine and releasing looked ok, but what was noticed is that the commit
that got merged into oslo.context[1] was with-in the 24 hour period of
those periodic jobs[2] and hadn't been put through the 'wringer' just
yet, thus how it got released.
So to help that process going forward (and to make it more visible) I
made a 'oslobot' which has as one of its main commands the ability to
easily check the failed jobs and report them back into IRC (code and
review for this is at https://review.openstack.org/#/c/343857/).
That should help mitigate this kind of situation going forward although
I also agree with what ronald says below in that some of the tests being
performed are reaching a little to far into oslo.context to do that
testing (ie knowing what to_dict outputs starts to cross a API boundary
IMHO).
[0]: https://review.openstack.org/#/c/340578/
[1]: https://review.openstack.org/#/c/331916/
[2]: https://wiki.openstack.org/wiki/Oslo#Periodic
Ronald Bradford wrote:
Hi All,
For Oslo libraries we ensure that API's are backward compatible for 1+ releases.
When an Oslo API adds a new class attribute (as in this example of
is_admin_project and 4 other attributes) added to Oslo Context in
2.6.0, these are added to ensure this API is also forward compatible
with existing project code for any contract with the base class
instantiation or manipulation.
The issue seen is presently Nova specific (as other projects can
utilize 2.6.0) and it is related to projects that sub-class
oslo.context, and how unit tests are written for using class
parameters. Ideally, to implement using oslo.context correctly
OpenStack projects should:
* Not perform direct dictionary to dictionary comparisons with the
to_dict() method as this does not support when new attributes at
added. Two patches (one to nova) address this in offending projects
[5][6]
* Unit tests should focus on attributes specific to the sub-classed
signature, e.g. [7]. Oslo context provides an extensive set of unit
tests for base class functionality. This is a wish list item for
projects to implement.
The to_dict() method exists as a convenience method only and is not an
API contract. The resulting set of keys should be used accordingly.
This is why there is no major release version.
There is a note from our discussion in Oslo to improve our
documentation to describe the API use of to_dict() better and state we
will not remove to_dict() keys within a release, but that may happen
between releases.
There is a subsequent problem with how Nova performs a warning test
[8]. Additional reviews are looking at addressing this sub-class usage
of from_dict() and to_dict().
Regards
Ronald
[5] https://review.openstack.org/#/c/343694/,
[6] https://review.openstack.org/#/c/342367/
[7] https://review.openstack.org/#/c/342869/
[8]
http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144
On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
<mrie...@linux.vnet.ibm.com> wrote:
On 7/18/2016 9:42 AM, Matt Riedemann wrote:
On 7/18/2016 9:09 AM, Markus Zoeller wrote:
Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
Portland and won't be available for the next 2h or so.
If you can have a look at it and merge it, that would be great.
References:
[1]
https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
[2] https://review.openstack.org/#/c/342604/1
[3] https://bugs.launchpad.net/nova/+bug/1603979
[4] logstash: http://goo.gl/79yFb9
This is an API change for oslo.context, why wasn't it released as 3.0.0?
Seems we should revert the upper-constraints bump and blacklist 2.6.0,
then get that released as 3.0.0.
Here is the blacklist:
https://review.openstack.org/#/c/343683/
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
