Open Stack

On 08/10/2012 12:25 AM, Dan Wendlandt wrote:
>
>
> On Thu, Aug 9, 2012 at 1:13 PM, Mark McClain 
> <mark.mcclain at dreamhost.com <mailto:mark.mcclain at dreamhost.com>> wrote:
>
>     All-
>
>     I wanted to widen the discussion that we've been having on
>     https://review.openstack.org/#/c/10997/
>
>     Basically the DHCP Agent needs to be notified about certain
>     Quantum events.  There are two ways of accomplishing this:
>
>     1) Turn on Quantum notifications and have the agent consume the
>     general notifications.  Moving forward this would require that
>     rabbit_notifications always be enabled in quantum.conf.
>
>     Pro: This functionality already exists in Quantum.
>     Con: These messages are more general, so the agent typically has
>     to collect some data in response to the calls.
>
>
> This is my preference, as I think it leads to a cleaner design and 
> avoid a bunch of specific notifications within Quantum.  I'd really 
> like something like DHCP to be implemented in a way that is basically 
> agnostic to the plugin that is running (i.e., consuming standard 
> notifications, and interacting via the main Quantum API).   This let's 
> people build additional such services (e.g., integrating quantum IPAM 
> with DNS) without modifying the core code.
>
> We actually had a substantial thread on this topic a few weeks ago in 
> the context of plugin-agents, and the concern was that there currently 
> wasn't a channel other than RPC to pass some information (e.g., the 
> VLAN a network maps to), so we said that for F-3 plugins could create 
> their own RPC mechanisms if needed.  That said, I'd still like to see 
> things more toward a model where we use "standard" notifications.

I agree that the standard notification would be better. I nonetheless 
have a number of reservations regarding the existing notifications 
mechanism. This may be due to my misunderstanding of things or not being 
familiar enough with the implementation and use cases. My gut feeling is 
that the current notification mechanism from openstack common can be 
used for monitoring and billing. I do not think that this suited for 
what we would like to do and achieve. Say for example that the user 
updates a subnet name. This means that a start and end message will be 
sent to the agent. More specifically the agent may only be interested in 
receiving an update if a specific field of the subnet has changed.

I think that we can certainly find a good solution in the long run and 
would be happy to discuss and work on this for Grizzly. Needless to say 
we need a short term solution for F-3. I personally am in favor of a 
simple fanout cast without using the notification mechanism (option #2). 
In addition to the notification mechanism may not have have support for 
the extensions or require authorization for extensions. This infomation 
can be added by the self managed messaging...

Thanks
Gary

>
> Dan
>
>
>
>     Note: The rabbit_notifier actually works will all of the messaging
>     backends, i.e. qpid.)  These messages are more general in nature
>     and just provide the data returned from the plugin.
>
>     2) Create specific RPC calls that q-svc fans out to the DHCP agent(s).
>
>     Pro: This approach means that the Quantum server can send messages
>     that are specifically tailored for the DHCP agent to act upon.
>     Con: Essentially implements a subset of the notification API in a
>     specific way.
>
>     I'm open to either approach, but would like the community's input.
>     Thoughts?
>
>     mark
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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