Re: [openstack-dev] [nova][neutron] VIF event callbacks implementation
On 7 May 2014 13:04, Mike Kolesnik mkole...@redhat.com wrote: - Original Message - Yeah, we've already got plans in place to get Cinder to use the interface to provide us more detailed information and eliminate some polling. We also have a very purpose-built notification scheme between nova and cinder that facilitates a callback for a very specific scenario. I'd like to get that converted to use this mechanism as well, so that it becomes the way you tell nova that things it's waiting for have happened. Not sure how you consider this mechanism something generic since it's facilitating only Nova while there might be a number of different services interested in this information. Now Neutron needs to be aware of VIF and Nova's expectations of Neutron in regards to that VIF, which is highly tightly coupled. Using a notification scheme where any subscriber can receive the event from Neutron/Cinder/etc and handle it how it needs instead would be much more decoupled, IMHO. Nothing is merged on the cinder side yet, and won't be merging until after the summit. Making an interface that is generic enough for any entity that may wish to receive event notification from cinder is my concern. The fact nova has already merged something that works for neutron really isn't much of a concern for me - getting the right interface into cinder is. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] VIF event callbacks implementation
I have additional concern that API is something that's user facing so basically now Nova is exposing some internal synchronization detail to the outside world. We have lots of admin-only APIs. Does it make sense that the user would now be able to send messages to this API? Potentially. Right now you can ask for a refresh of their network info if things are stale, and some RAX people mentioned that they would like to be able to trigger network resets and some other sorts of things through that mechanism. Not sure why RPC is more coupled than API. Maybe you could explain? Because we change our RPC APIs all the time. If an external component has to consume our RPC messages reliably, that means either we have to make sure that component tracks the changes, or we avoid making them. On the other hand, our REST APIs are specifically designed and carefully monitored to maintain compatibility with external things. Currently it's a very specific API putting a burden on Neutron to now know what is VIF and what state is necessary for this VIF to be working, instead of having these calculations in Nova (which is of course aware of VIF, and of Port). It's optional, and for better integration with Neutron and Nova. I don't really think that it's as nova-specific as you're implying. IIRC, the neutron side just fires a notification any time a port changes state right now. I wasn't suggesting touching Nova's RPC but rather utilize the existing notifications sent from Neutron to achieve the same logic. So not sure what changes you believe are to be coordinated from Nova's POV. Neutron consuming Nova's RPC or Nova consuming Neutron's RPC.. either way, it's not how I'd choose to go about it. It could similarly be a queue with some defined message format. I think that's what we've implemented, no? It's a well-defined format that describes an event. It has nothing nova-specific in it. We could alternatively provide a callback functionality that allows various clients to receive notifications from Neutron, specifying an address to send these details to. Sure, if you want to go extend this mechanism to remove the static configuration and allow for dynamic registration of who receives these messages, I would expect that would be fine. We'd need to figure out how a single Nova deployment will manage registering with Neutron in an efficient way, but I'm sure that could be done. Not sure how you consider this mechanism something generic since it's facilitating only Nova while there might be a number of different services interested in this information. Now Neutron needs to be aware of VIF and Nova's expectations of Neutron in regards to that VIF, which is highly tightly coupled. Using a notification scheme where any subscriber can receive the event from Neutron/Cinder/etc and handle it how it needs instead would be much more decoupled, IMHO. Well, I'm not sure why Cinder would need to receive notifications from Neutron, but I understand what you mean. Like I said, nothing about how it's currently architected prevents this from happening, AFAIK, other than the fact that it's currently managed by static configuration. If you want to add a subscription interface to register for these so that neutron can supply notifications to multiple entities dynamically, then that seems like a natural next step. I'm sure Cinder would prefer that as well. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] VIF event callbacks implementation
On Tue, Apr 29, 2014 at 12:23 PM, Dan Smith d...@danplanet.com wrote: Yeah, we've already got plans in place to get Cinder to use the interface to provide us more detailed information and eliminate some polling. We also have a very purpose-built notification scheme between nova and cinder that facilitates a callback for a very specific scenario. I'd like to get that converted to use this mechanism as well, so that it becomes the way you tell nova that things it's waiting for have happened. --Dan We actually need something *very* similar in Ironic right now to address many of the same issues that os-external-events solves for Nova - Neutron coordination. I've been looking at implementing an almost identical thing in Ironic and was hoping to file a BP to get some discussion going in Atlanta. There are a few places currently where the same mechanism would fix bugs or be a general improvement, and more stuff coming in Juno where this will be required. I would love to find out if parts of what is currently in Nova that can be factored out and shared across projects to make this easier, and to provide all projects with a way you tell some other service that things it's waiting for have happened Cheers, Adam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] VIF event callbacks implementation
On 29 April 2014 20:23, Dan Smith d...@danplanet.com wrote: Yeah, we've already got plans in place to get Cinder to use the interface to provide us more detailed information and eliminate some polling. We also have a very purpose-built notification scheme between nova and cinder that facilitates a callback for a very specific scenario. I'd like to get that converted to use this mechanism as well, so that it becomes the way you tell nova that things it's waiting for have happened. I'm gently but firmly pushing for the cinder event interface to be made rather more generic than what is currently being looked at - nova is not the only project that could benefit from better status updates than polling. Dashboards and even the CLI could also potentially benefit -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] VIF event callbacks implementation
Aside from creating a sort of cyclic dependency between the two, it is my understanding that Neutron is meant to be a stand alone service capable of being consumed by other compute managers (i.e. oVirt). This breaks that paradigm. snip So my question is: Why use API and not RPC? I saw that there is already a notification system in Neutron that notifies on each port update (among other things) which are currently consumed by Ceilometer. Why not have Nova use those notifications to decide that a VIF got plugged correctly, floating IPs changed, and so on? To your point above, having either service sit on the other's RPC bus ties them together far closer than having them consume each other's REST API, IMHO. Further, Nova's internal RPC mechanics are controlled pretty tightly for upgrade compatibility and I don't think I'd want another service sitting on that bus that we have to worry about when we're coordinating a change across releases (which we do quite often). We consume Neutron's services via the REST API because that's what is exposed externally and guaranteed to be stable -- the same goes for Neutron consuming anything from Nova. I believe the rationale here was that nova's API interface is only currently exposed via a rest API over http so leveraging this existing framework seemed like a good place to do it. In addition, there didn't seem to be an obvious advantage to using RPC rather than the rest interface. Lastly, this new interface that nova exposes is generic and not neutron specific as it can be used for other type of notifications that things want to send nova. I added Dan Smith to CC to keep me honest here as I believe this was the rationale. Yeah, we've already got plans in place to get Cinder to use the interface to provide us more detailed information and eliminate some polling. We also have a very purpose-built notification scheme between nova and cinder that facilitates a callback for a very specific scenario. I'd like to get that converted to use this mechanism as well, so that it becomes the way you tell nova that things it's waiting for have happened. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][neutron] VIF event callbacks implementation
Hi, I came across the implementation of https://blueprints.launchpad.net/neutron/+spec/nova-event-callback and have a question about the way it was implemented. I notice that now Neutron has a dependency on Nova and needs to be configured to have nova details (API endpoint, user, password, tenant, etc). Aside from creating a sort of cyclic dependency between the two, it is my understanding that Neutron is meant to be a stand alone service capable of being consumed by other compute managers (i.e. oVirt). This breaks that paradigm. So my question is: Why use API and not RPC? I saw that there is already a notification system in Neutron that notifies on each port update (among other things) which are currently consumed by Ceilometer. Why not have Nova use those notifications to decide that a VIF got plugged correctly, floating IPs changed, and so on? I am willing to make the necessary changes to decouple Neutron from Nova, but want to understand the rationale behind the original decision of using API and not RPC notifications. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
