Open Stack

On 08/04/15 20:23 -0700, Joshua Harlow wrote:
>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.

a-ha... That explains it. My, obviously, non-native english
translation failed to parse that. Thanks for explaining :)

Feel free to ignore my last 2 emails :P

Cheers,
Flavio

>
>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
>
>__________________________________________________________________________
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/6d15818c/attachment.pgp>