[openstack-dev] [nova] Versioned notifications... who cares about the version?

John Garbutt john at johngarbutt.com
Mon Nov 23 11:33:34 UTC 2015


On 20 November 2015 at 09:37, Balázs Gibizer
<balazs.gibizer at ericsson.com> wrote:
>> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
>> Sent: November 19, 2015 23:29
>> On 11/19/2015 4:05 PM, Ryan Rossiter wrote:
>> > Reading through [1] I started getting worries in the back of my head
>> > about versioning these notifications. The main concern being how can
>> > the consumer know about the versions and what's different between
>> them?
>> > Because these versioned notification payloads hold live nova objects,
>> > there can be a lot of rug-pulling going on underneath these
>> > notifications. If the payload doesn't pin itself to a certain level of
>> > the object, a consumer can never be guaranteed the version of the
>> > payload's object they will be receiving. I ran through a few of the
>> > scenarios about irregular versions in the notifications subteam
>> > meeting on Tuesday [2].
>> >
>> > My question is.... do we care about the consumer? Or is it a case of
>> > "the consumer is always right" so we need to make sure we hand them
>> > super consistent, well-defined blobs across the wire? Consumers will
>> > have no idea of nova object internals, unless they feel like `python
>> > -c import nova`. I do think we get one piece of help from o.vo though.
>> > When the object is serialized, it hands the version with the object.
>> > So consumers can look at the object and say "oh, I got 1.4 I know what
>> > to do with this". But... they will have to implement their own compat
>> > logic. Everyone will have to implement their own compat logic.
>> >
>> > We could expose a new API for getting the schema for a specific
>> > version of a notification, so a consumer will know what they're
>> > getting with their notifications. But I think that made mriedem
>> > nauseous. We could make an oslo library that stuffs a shim in between
>> > o.vo and nova's notifications to help out with compat/versioning, but
>> > that sounds like a lot of work, especially because the end goal is still not
>> clearly defined.
>>
>> The term is 'nauseated'. To be nauseous, you nauseate others. Which I might
>> do from time to time.
>>
>> Sorry, I'm channeling one of my wives' pet peeves because I say the same
>> thing. Sometimes just to annoy her.
>>
>> But yeah, I was made physically ill from that idea.
>>
>> >
>> > Thoughts?
>> >
>> > [1] https://review.openstack.org/#/c/247024
>> > [2]
>> > http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-
>> alt/%23ope
>> > nstack-meeting-alt.2015-11-17.log.html#t2015-11-17T20:22:29
>> >
>> >
>>
>> One idea I had was (and maybe this would be in a separate library like you're
>> talking about, i.e. nova-notifications), but if nova emits the notification with
>> the version and the consumer calls into the library that translates it into a
>> version they want, then get that transformed thing back.
>>
>> However, how does the consumer know what they want or what they can
>> handle? Do they pin a version in configuration somewhere? I could see
>> something like how we have upgrade levels pinned in nova so newer
>> conductor can backlevel things for older computes.
>>
>> I was also thinking about microversions and novaclient, but in that case
>> novaclient knows what max microversion it can handle and only requests up
>> to that version, and then nova-api handles the compat work. In the case of
>> notifications, nova is just broadcasting those so it's not doing any compat
>> work, but it's the only thing that knows *how* to do the compat work...
>>
>> So yeah, I'm lost.
>
> Minor version change shall not cause any problem for the consumer as the payload is backward compatible between minor versions. So if the consumer does not need the new field then he/she does not need to change anything in his/her parser. As far as I know we had a single major object version in nova so far so this is not a frequent event.  In case of major change I think we can offer version pinning from nova via configuration as a future step.
>
> The library idea has the problem that it would be python lib and consumers can be in any language. For me lib would be used for compat code but as I mentioned above incompatibility is not that frequent. In the other hand discoverability of notifications are more important for me. For that I can suggest providing notification samples as a first step so the consumer can see in the source tree what notifications are provided by the nova. As a natural next step would be to provide not just samples but schemas for the notifications. I haven't looked it too deep but I feel if we provide json schema for the notifications then the consumer can generate an object model from that schema without too much effort. It might not help directly with backporting the payload but at least automate things around it. The json schema has the benefit that it is language independent too.
>

So, on re-reading, I think we are missing some of the context from the
summit session in this spec:
http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/versioned-notification-api.html

The aim of notifications is to focus more on structured logging, for
the operator.

It is not trying to provide an end-user async API, such as:
https://etherpad.openstack.org/p/liberty-cross-project-user-notifications

As Gibi mentions, the idea was to add a version, so you can tell when
the content has changed, generally in a backwards compatible way. The
other big parts, like properly testing the notifications to ensure
they stay compatible.

It uses o.vo, with the intent we avoid a major version bump. Should we
need one, its likely to end up with a similar transition phase to the
current un-versioned->versioned transition phase (effectively the
deployer decides which major versions will be emitted at any one
time).

The interface is a stable JSON structure, with some handy version and
identification metadata. It happens to use o.vo to generate that
format, and we happen to have python code to read that format, but
thats not the aim.

There is a bit I am conflicted/worried about, and thats when we start
including verbatim, DB objects into the notifications. At least you
can now quickly detect if that blob is something compatible with your
current parsing code. My preference is really to keep the
Notifications as a totally separate object tree, but I am sure there
are many cases where that ends up being seemingly stupid duplicate
work. I am not expressing this well in text form :(

Thanks,
John

> Cheers,
> Gibi
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list