Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
gord

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/480cc3a6/attachment.html>