Open Stack

Hope this helps:

'Let's do away with' == 'remove it/no longer use it'

vs 'let's use RPC-over-AMQP' which means continue using it/use it more.

Flavio Percoco wrote:
> On 08/04/15 15:35 -0700, Min Pae wrote:
>> Uh sorry to nitpick, I think he said “let’s do away with” not “let’s use”
>> RPC-over-AMQP
>
> How is that different? I honestly don't see the difference but I'm
> surre I'm missing something in my translation.
>
>>
>> On Wed, Apr 8, 2015 at 10:56 AM, Flavio Percoco <flavio at redhat.com>
>> wrote:
>>
>> On 08/04/15 16:38 +0000, Sandy Walsh wrote:
>>
>> ________________________________________
>>
>> From: Clint Byrum <clint at fewbar.com>
>> Sent: Wednesday, April 8, 2015 1:15 PM
>>
>> There's this:
>>
>> https://wiki.openstack.org/wiki/Cue
>>
>>
>> Hmm, that looks interesting. Will read.
>>
>>
>> I also want to point out that what I'd actually rather see is that
>> all
>> of the services provide functionality like this. Users would be
>> served
>> by having an event stream from Nova telling them when their
>> instances
>> are active, deleted, stopped, started, error, etc.
>>
>> Also, I really liked Sandy's suggestion to use the notifications on
>> the
>> backend, and then funnel them into something that the user can
>> consume.
>> The project they have, yagi, for putting them into atom feeds is
>> pretty
>> interesting. If we could give people a simple API that says
>> "subscribe
>> to Nova/Cinder/Heat/etc. notifications for instance X, and put them
>> in an atom feed", that seems like something that would make sense
>> as
>> an under-the-cloud service that would be relatively low cost and
>> would
>> ultimately reduce load on API servers.
>>
>>
>> THIS!
>>
>> Yes. It would be so good to pull apart the state-machine that is Nova
>> and
>> just emit completed actions via notifications. Then, have something
>> like
>> TaskFlow externalize the orchestration. Do away with RPC-over-AMQP.
>>
>>
>> Sorry for being nitpicky but, saying "RPC-over-AMQP" is way too
>> generic. What AMQP version? On top of what technology?
>>
>> Considering all the issues OPs have with our current broker story, I
>> think considering implementing this on top of pure AMQP (which is how
>> that phrase reads) would not be good.
>>
>> If you meant "RPC-over-messaging" then I think you should just keep
>> using oslo.nmessaging, which abstracts the problem of picking one
>> broker.
>>
>> Unfortunately, this means users will need to consume this messages
>> from the "messaging source" using oslo.messaging as well. I say
>> "unfortunately" because I believe the API - or even the protocol - as
>> it is exposed through this library - or simply the broker - is not
>> something users should deal with. There are services that try to make
>> this interaction simpler - yes, Zaqar.
>>
>> Flavio
>>
>>
>>
>>
>> And, anyone that is interested in the transitions can eavesdrop on the
>> notifications.
>>
>> In our transition from StackTach.v2 to StackTach.v3 in production we
>> simply
>> cloned the notification feeds so the two systems can run in parallel*.
>> No
>> changes to OpenStack, no disruption of service. Later, we'll just kill
>> off
>> the v2 queues.
>>
>> -S
>>
>> * we did this in Yagi, since olso-messaging doesn't support multiple
>> queues
>> from one routing key.
>> __________________________________________________________________________
>>
>> 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
>>
>>
>> --
>> @flaper87
>> Flavio Percoco
>> __________________________________________________________________________
>>
>> 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
>>
>>
>>
>
>> __________________________________________________________________________
>>
>> 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
>
>
> __________________________________________________________________________
> 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