On 20/11/2015 5:12 PM, Chris Dent wrote:
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_.
you can still do anything and add anything to notifications but you also
know that "attributeA/B/C are probably useful to consumerX;
attributeD/E/F are related and all the attributes can be used by anyone."
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.)
i actually view notifications different from 'well-formed HTTP APIs' as
the initiator is not the consumer but the producer but i agree with
"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.
agree, following this makes versioning pretty much moot. it's the major
version changes i'm thinking of. how does producer know not to remove
attributeX? how does consumer know attributeX is now attributeX.Y.Z if
the name/location is different?
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.
__________________________________________________________________________
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
--
gord
__________________________________________________________________________
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
