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

Chris Dent cdent+os at anticdent.org
Fri Nov 20 22:12:07 UTC 2015


On Fri, 20 Nov 2015, gord chung wrote:

> i think a lot of the complexity we have in versioning is that the projects 
> are too silo'd. i think some of the versioning issues would be irrelevant if 
> the producer knew it's consumers before sending rather than producers just 
> tossing out a chunk of data (versioned schema or not) and considering their 
> job complete once it leaves it's own walls. the producer doesn't necessarily 
> have to be the individual project teams but whoever the producer of 
> notifications is, it should know it's audience.

To me this is entirely contrary to the point of having notifications
as a generic concept in the OpenStack environment. To me the point is
to ensure that it is possible for the audience to be and do _anything_.

We've become so accustomed to some of the misfeatures in the messaging
architecture that we've lost track of the fact that it could be an
event pool on which we have diverse listeners that the producers have
no requirement to know anything about. We could have nova-compute spinning
along shouting "I made a VM. I made another VM. Hey, I made another
VM" and "This VM is hot. Halp, I am oversubscribed." All sorts of
tools and devices need to be able to hear that stuff and choose for
themselves what they might do with it.

(This is similar to the reason we have well-formed HTTP APIs: It is so
we can have unexpected clients that do unexpected things.)

It is certainly the case that if we're going to have schematized
and versioned notifications it is critical that the schema are
discoverable in a language independent fashion.

Sometimes it is hard, though, to be convinced that such formalisms are
quite what we really need. From the consumers end the concern is "do
you have these several keys that I care about?" and, as has been said,
the rest is noise. It sounds like microversioned notifications which
almost never version on the major axis might be able to provide this.

We can't allow the introduction of either the formalisms or
discoverability thereof to grant license to change stuff willy nilly.
Nor should we be building formalisms that are defenses against an
architecture that's sub-optimal. We need to evolve the formalisms and
the architecture toward the ideal.

-- 
Chris Dent               (¨s¡ã¡õ¡ã)¨s¦à©ß©¥©ß            http://anticdent.org/
freenode: cdent                                         tw: @anticdent


More information about the OpenStack-dev mailing list