<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 20/11/2015 5:12 PM, Chris Dent
      wrote:<br>
    </div>
    <blockquote
      cite="mid:alpine.OSX.2.20.1511202156380.87350@crank.local"
      type="cite">On Fri, 20 Nov 2015, gord chung wrote:
      <br>
      <br>
      <blockquote type="cite">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.
        <br>
      </blockquote>
      <br>
      To me this is entirely contrary to the point of having
      notifications
      <br>
      as a generic concept in the OpenStack environment. To me the point
      is
      <br>
      to ensure that it is possible for the audience to be and do
      _anything_.
      <br>
    </blockquote>
    <br>
    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."<br>
    <br>
    <blockquote
      cite="mid:alpine.OSX.2.20.1511202156380.87350@crank.local"
      type="cite">
      <br>
      We've become so accustomed to some of the misfeatures in the
      messaging
      <br>
      architecture that we've lost track of the fact that it could be an
      <br>
      event pool on which we have diverse listeners that the producers
      have
      <br>
      no requirement to know anything about. We could have nova-compute
      spinning
      <br>
      along shouting "I made a VM. I made another VM. Hey, I made
      another
      <br>
      VM" and "This VM is hot. Halp, I am oversubscribed." All sorts of
      <br>
      tools and devices need to be able to hear that stuff and choose
      for
      <br>
      themselves what they might do with it.
      <br>
      <br>
      (This is similar to the reason we have well-formed HTTP APIs: It
      is so
      <br>
      we can have unexpected clients that do unexpected things.)
      <br>
    </blockquote>
    <br>
    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."<br>
    <br>
    <blockquote
      cite="mid:alpine.OSX.2.20.1511202156380.87350@crank.local"
      type="cite">
      <br>
      It is certainly the case that if we're going to have schematized
      <br>
      and versioned notifications it is critical that the schema are
      <br>
      discoverable in a language independent fashion.
      <br>
      <br>
      Sometimes it is hard, though, to be convinced that such formalisms
      are
      <br>
      quite what we really need. From the consumers end the concern is
      "do
      <br>
      you have these several keys that I care about?" and, as has been
      said,
      <br>
      the rest is noise. It sounds like microversioned notifications
      which
      <br>
      almost never version on the major axis might be able to provide
      this.
      <br>
      <br>
      We can't allow the introduction of either the formalisms or
      <br>
      discoverability thereof to grant license to change stuff willy
      nilly.
      <br>
    </blockquote>
    <br>
    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?<br>
    <br>
    <blockquote
      cite="mid:alpine.OSX.2.20.1511202156380.87350@crank.local"
      type="cite">Nor should we be building formalisms that are defenses
      against an
      <br>
      architecture that's sub-optimal. We need to evolve the formalisms
      and
      <br>
      the architecture toward the ideal.
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
gord</pre>
  </body>
</html>