Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
On 28 January 2015 at 17:32, Robert Collins wrote: > E.g. its a call (not cast) out to Neutron, and Neutron returns when > the VIF(s) are ready to use, at which point Nova brings the VM up. If > the call times out, we error. > I don't think this model really works with distributed systems, and it really doesn't work when you have a limited number of threads to play with - because they get consumed by anything that has to wait a long time for a thing to happen, and eventually you can't service requests any more. Also, it's entirely opposite to what Nova does. Does it return when the VM is running? No, it returns when the VM is requested, saying 'I note your request and will act on it in my own time'. What does Neutron have to do to complete a call? That's entirely dependent on the driver, but it could be talking to one, ten or a thousand devices, any of which might be slow to respond: there is no upper bound on how long it takes to bind a port, for instance. So any REST call to Neutron should change its DB and return, and leave an asynchronous process to deal with making the network state change. Neutron should notify Nova when it has changed, and Nova can go on with its life doing other things till the notification comes in. Right now we have this mix of synchronous and async code, and its > causing us to overlook things and have bugs. I'd be equally happy if > we went all in with an async event driven approach, but we should > decide if we're fish or fowl, not pick bits of both and hope reviewers > can remember every little detail. > On this much we agree, I just happen to like fowl. > > One other problem, not yet raised, is that Nova doesn't express its needs > > when it asks for a port to be bound [...] +1, OTOH I don't think this is a structural problem - it doesn't > matter what protocol or calling style we use, this is just the > parameters in the call :). > Agreed. We just need to make it a proper negotiation, and that's it done. No-one seems to have a problem with this, so I'll have a play with the idea (out of tree for now, given the time of the cycle). > I think your desire and Salvatore's are compatible: an interface that > is excellent for Nova can also be excellent for other users. > Agreed. But if there's one interface for everything it doesn't really need to be a plugin. The question is whether one interface is enough. > Notifications aren't a complete solution to the orphaning issue unless > the notification system is guaranteed non-lossy. Something like Kafka > would be an excellent substrate for such a system, or we could look at > per-service journalling (on either side of the integration point). > I prefer lossy notification systems. RabbitMQ is non-lossy, and that means it will sit on messages for days and then deliver them long past the point at which they're useful, plus its queue depth is unbounded. It's not a great way to run an eventually consistent system, in my opinion. The pattern I like is where you are notified (via an unreliable channel) when your operation has completed, but you must also have a background checking task that goes to see if the notification has gone missing by checking the datamodel. The task doesn't have to trigger very often, and in fact you could hold it off indefinitely with a heartbeat providing the communications channel remains functioning - but it does have to exist. You don't have the problem of having to provide an infinite queue, and it's not a crisis when your messaging system loses a message. -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
On 26 January 2015 at 15:30, Ian Wells wrote: > Lots of open questions in here, because I think we need a long conversation > on the subject. > > On 23 January 2015 at 15:51, Kevin Benton wrote: >> >> It seems like a change to using internal RPC interfaces would be pretty >> unstable at this point. > > >> >> Can we start by identifying the shortcomings of the HTTP interface and see >> if we can address them before making the jump to using an interface which >> has been internal to Neutron so far? > > > I think the protocol being used is a distraction from the actual > shortcomings. > > Firstly, you'd have to explain to me why HTTP is so much slower than RPC. > If HTTP is incredibly slow, can be be sped up? If RPC is moving the data > around using the same calls, what changes? Secondly, the problem seems more > that we make too many roundtrips - which would be the same over RPC - and if > that's true, perhaps we should be doing bulk operations - which is not > transport-specific. There's nothing intrinsic to HTTP that makes it higher latency than RPC-over-AMQP (in fact, it should be lower latency for established connections); however we have lots of room to improve the performance of our stack here. Joe Gordon has some specific numbers. That said, we're talking what - one API call (plug this vif please), so we've probably got a realistic time budget in the high tenths of a second before folk would notice. The tromboning involved in our current use of HTTP is a concern for me - more moving parts, more ways things can break, more synchronisation needed. Our coding style is very synchronous : we're not writing with signals and events, rather straight forward single-threaded worker code. I'd like to see us have some mechanism that fits with that. E.g. its a call (not cast) out to Neutron, and Neutron returns when the VIF(s) are ready to use, at which point Nova brings the VM up. If the call times out, we error. Right now we have this mix of synchronous and async code, and its causing us to overlook things and have bugs. I'd be equally happy if we went all in with an async event driven approach, but we should decide if we're fish or fowl, not pick bits of both and hope reviewers can remember every little detail. > I absolutely do agree that Neutron should be doing more of the work, and > Nova less, when it comes to port binding. (And, in fact, I'd like that we > stopped considering it 'Nova-Neutron' port binding, since in theory another > service attaching stuff to the network could request a port be bound; it > just happens at the moment that it's always Nova.) E.g. Ironic, which does port updates today using Neutron directly. > One other problem, not yet raised, is that Nova doesn't express its needs > when it asks for a port to be bound, and this is actually becoming a problem > for me right now. At the moment, Neutron knows, almost psychically, what > binding type Nova will accept, and hands it over; Nova then deals with > whatever binding type it receives (optimisitically expecting it's one it > will support, and getting shirty if it isn't). The problem I'm seeing at > the moment, and other people have mentioned, is that certain forwarders can > only bind a vhostuser port to a VM if the VM itself has hugepages enabled. > They could fall back to another binding type but at the moment that isn't an > option: Nova doesn't tell Neutron anything about what it supports, so > there's no data on which to choose. It should be saying 'I will take these > binding types in this preference order'. I think, in fact, that asking > Neutron for bindings of a certain preference type order, would give us much > more flexibility - like, for instance, not having to know exactly which > binding type to deliver to which compute node in multi-hypervisor > environments, where at the moment the choice is made in Neutron. +1, OTOH I don't think this is a structural problem - it doesn't matter what protocol or calling style we use, this is just the parameters in the call :). >> I scanned through the etherpad and I really like Salvatore's idea of >> adding a service plugin to Neutron that is designed specifically for >> interacting with Nova. All of the Nova notification interactions can be >> handled there and we can add new API components designed for Nova's use >> (e.g. syncing data, etc). Does anyone have any objections to that approach? > > > I think we should be leaning the other way, actually - working out what a > generic service - think a container management service, or an edge network > service - would want to ask when it wanted to connect to a virtual network, > and making an Neutron interface that supports that properly *without* being > tailored to Nova. The requirements are similar in all cases, so it's not > clear that a generic interface would be any more complex. > > Notifications on data changes in Neutron to prevent orphaning is another > example of a repeating pattern. It's probably the same fo
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If the problem is too many round trips our the interaction being too chatty This is a good point: is the main issue that we feel the interaction is too chatty, or that it’s too slow? I seem to hear people gravitating toward one or the other when this topic comes up, and the two issues may have somewhat different solutions. After all: in my experience, two Italians talking about football can say an awful lot in a very small window of time. =) If the problem is chattiness, we may look at bulk ops, intent-based metadata, pipelining, etc. If it’s slowness, then we probably want a deeper look at what bits of the operation are slow. Mark McClain and Ian and I were chatting about this the other day and suspect something like offline token validation or token windowing (e.g. attempting to prune out roundtrips to keystone) could go a long way on that front. At Your Service, Mark T. Voelker On Jan 28, 2015, at 12:52 AM, Brent Eagles wrote: On 25/01/2015 11:00 PM, Ian Wells wrote: Lots of open questions in here, because I think we need a long conversation on the subject. On 23 January 2015 at 15:51, Kevin Benton wrote: It seems like a change to using internal RPC interfaces would be pretty unstable at this point. Can we start by identifying the shortcomings of the HTTP interface and see if we can address them before making the jump to using an interface which has been internal to Neutron so far? I think the protocol being used is a distraction from the actual shortcomings. Firstly, you'd have to explain to me why HTTP is so much slower than RPC. If HTTP is incredibly slow, can be be sped up? If RPC is moving the data around using the same calls, what changes? Secondly, the problem seems more that we make too many roundtrips - which would be the same over RPC - and if that's true, perhaps we should be doing bulk operations - which is not transport-specific. I agree. If the problem is too many round trips our the interaction being too chatty, I would expect moving towards more service oriented APIs - where HTTP tends to be appropriate. I think we should focus on better separation of concerns, and approaches such as bulk operations using notifications where cross process synchronization for a task is required. Exploring transport alternatives seems premature until after we are satisfied that our house is in order architecture-wise. Furthermore, I have some "off-the-cuff" concerns over claims that HTTP is slower than RPC in our case. I'm actually used to arguing that RPC is faster than HTTP but based on how our RPCs work, I find such an argument counter-intuitive. Our REST API calls are direct client->server requests with GET's returning results immediately. Our RPC calls involve AMQP and a messaging queue server, with requests and replies encapsulated in separate messages. If no reply is required, then the RPC *might* be dispatched more quickly from the client side as it is simply a message being queued. The actual servicing of the request (server side dispatch or "upcall" in broker-parlance) happens "some time later", meaning possibly never. If the RPC has a return value, then the client must wait for the return reply message, which again involves an AMQP message being constructed, published and queued, then finally consumed. At the very least, this implies latency for dependent on the relative location and availability of the queue server. As an aside (meaning you might want to skip this part), one way our RPC mechanism might be "better" than REST over HTTP calls is in the cost of constructing and encoding of requests and replies. However, this is more of a function of how requests are encoded and less how the are sent. Changing how request payloads are constructed would close that gap. Again reducing the number of requests required to "do something" would reduce the significance of any differences here. Unless the difference between the two methods were enormous (like double or an order of magnitude) then reducing the number of calls to perform a task still has more gain than switching methods. Another difference might be in how well the "transport" implementation scales. I would consider disastrous scaling characteristics a pretty compelling argument. I absolutely do agree that Neutron should be doing more of the work, and Nova less, when it comes to port binding. (And, in fact, I'd like that we stopped considering it 'Nova-Neutron' port binding, since in theory another service attaching stuff to the network could request a port be bound; it just happens at the moment that it's always Nova.) One other problem, not yet raised, is that Nova doesn't express its needs when it asks for a port to be bound, and this is actually becoming a problem for me right now. At the moment, Neutron knows, almost psychically, what binding type Nova will accept, and hands it over; Nova then deals with whatever binding type
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
On 25/01/2015 11:00 PM, Ian Wells wrote: Lots of open questions in here, because I think we need a long conversation on the subject. On 23 January 2015 at 15:51, Kevin Benton wrote: It seems like a change to using internal RPC interfaces would be pretty unstable at this point. Can we start by identifying the shortcomings of the HTTP interface and see if we can address them before making the jump to using an interface which has been internal to Neutron so far? I think the protocol being used is a distraction from the actual shortcomings. Firstly, you'd have to explain to me why HTTP is so much slower than RPC. If HTTP is incredibly slow, can be be sped up? If RPC is moving the data around using the same calls, what changes? Secondly, the problem seems more that we make too many roundtrips - which would be the same over RPC - and if that's true, perhaps we should be doing bulk operations - which is not transport-specific. I agree. If the problem is too many round trips our the interaction being too chatty, I would expect moving towards more service oriented APIs - where HTTP tends to be appropriate. I think we should focus on better separation of concerns, and approaches such as bulk operations using notifications where cross process synchronization for a task is required. Exploring transport alternatives seems premature until after we are satisfied that our house is in order architecture-wise. Furthermore, I have some "off-the-cuff" concerns over claims that HTTP is slower than RPC in our case. I'm actually used to arguing that RPC is faster than HTTP but based on how our RPCs work, I find such an argument counter-intuitive. Our REST API calls are direct client->server requests with GET's returning results immediately. Our RPC calls involve AMQP and a messaging queue server, with requests and replies encapsulated in separate messages. If no reply is required, then the RPC *might* be dispatched more quickly from the client side as it is simply a message being queued. The actual servicing of the request (server side dispatch or "upcall" in broker-parlance) happens "some time later", meaning possibly never. If the RPC has a return value, then the client must wait for the return reply message, which again involves an AMQP message being constructed, published and queued, then finally consumed. At the very least, this implies latency for dependent on the relative location and availability of the queue server. As an aside (meaning you might want to skip this part), one way our RPC mechanism might be "better" than REST over HTTP calls is in the cost of constructing and encoding of requests and replies. However, this is more of a function of how requests are encoded and less how the are sent. Changing how request payloads are constructed would close that gap. Again reducing the number of requests required to "do something" would reduce the significance of any differences here. Unless the difference between the two methods were enormous (like double or an order of magnitude) then reducing the number of calls to perform a task still has more gain than switching methods. Another difference might be in how well the "transport" implementation scales. I would consider disastrous scaling characteristics a pretty compelling argument. I absolutely do agree that Neutron should be doing more of the work, and Nova less, when it comes to port binding. (And, in fact, I'd like that we stopped considering it 'Nova-Neutron' port binding, since in theory another service attaching stuff to the network could request a port be bound; it just happens at the moment that it's always Nova.) One other problem, not yet raised, is that Nova doesn't express its needs when it asks for a port to be bound, and this is actually becoming a problem for me right now. At the moment, Neutron knows, almost psychically, what binding type Nova will accept, and hands it over; Nova then deals with whatever binding type it receives (optimisitically expecting it's one it will support, and getting shirty if it isn't). The problem I'm seeing at the moment, and other people have mentioned, is that certain forwarders can only bind a vhostuser port to a VM if the VM itself has hugepages enabled. They could fall back to another binding type but at the moment that isn't an option: Nova doesn't tell Neutron anything about what it supports, so there's no data on which to choose. It should be saying 'I will take these binding types in this preference order'. I think, in fact, that asking Neutron for bindings of a certain preference type order, would give us much more flexibility - like, for instance, not having to know exactly which binding type to deliver to which compute node in multi-hypervisor environments, where at the moment the choice is made in Neutron. I scanned through the etherpad and I really like Salvatore's idea of adding a service plugin to Neutron that is designed specifically for interactin
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
Lots of open questions in here, because I think we need a long conversation on the subject. On 23 January 2015 at 15:51, Kevin Benton wrote: > It seems like a change to using internal RPC interfaces would be pretty > unstable at this point. > > Can we start by identifying the shortcomings of the HTTP interface and see > if we can address them before making the jump to using an interface which > has been internal to Neutron so far? > I think the protocol being used is a distraction from the actual shortcomings. Firstly, you'd have to explain to me why HTTP is so much slower than RPC. If HTTP is incredibly slow, can be be sped up? If RPC is moving the data around using the same calls, what changes? Secondly, the problem seems more that we make too many roundtrips - which would be the same over RPC - and if that's true, perhaps we should be doing bulk operations - which is not transport-specific. I absolutely do agree that Neutron should be doing more of the work, and Nova less, when it comes to port binding. (And, in fact, I'd like that we stopped considering it 'Nova-Neutron' port binding, since in theory another service attaching stuff to the network could request a port be bound; it just happens at the moment that it's always Nova.) One other problem, not yet raised, is that Nova doesn't express its needs when it asks for a port to be bound, and this is actually becoming a problem for me right now. At the moment, Neutron knows, almost psychically, what binding type Nova will accept, and hands it over; Nova then deals with whatever binding type it receives (optimisitically expecting it's one it will support, and getting shirty if it isn't). The problem I'm seeing at the moment, and other people have mentioned, is that certain forwarders can only bind a vhostuser port to a VM if the VM itself has hugepages enabled. They could fall back to another binding type but at the moment that isn't an option: Nova doesn't tell Neutron anything about what it supports, so there's no data on which to choose. It should be saying 'I will take these binding types in this preference order'. I think, in fact, that asking Neutron for bindings of a certain preference type order, would give us much more flexibility - like, for instance, not having to know exactly which binding type to deliver to which compute node in multi-hypervisor environments, where at the moment the choice is made in Neutron. I scanned through the etherpad and I really like Salvatore's idea of adding > a service plugin to Neutron that is designed specifically for interacting > with Nova. All of the Nova notification interactions can be handled there > and we can add new API components designed for Nova's use (e.g. syncing > data, etc). Does anyone have any objections to that approach? > I think we should be leaning the other way, actually - working out what a generic service - think a container management service, or an edge network service - would want to ask when it wanted to connect to a virtual network, and making an Neutron interface that supports that properly *without* being tailored to Nova. The requirements are similar in all cases, so it's not clear that a generic interface would be any more complex. Notifications on data changes in Neutron to prevent orphaning is another example of a repeating pattern. It's probably the same for any service that binds to Neutron, but right now Neutron has Nova-specific code in it. Broadening the scope, it's also likely the same in Cinder, and in fact it's also pretty similar to the problem you get when you delete a project in Keystone and all your resources get orphaned. Is a Nova-Neutron specific solution the right thing to do? -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
It seems like a change to using internal RPC interfaces would be pretty unstable at this point. Can we start by identifying the shortcomings of the HTTP interface and see if we can address them before making the jump to using an interface which has been internal to Neutron so far? I scanned through the etherpad and I really like Salvatore's idea of adding a service plugin to Neutron that is designed specifically for interacting with Nova. All of the Nova notification interactions can be handled there and we can add new API components designed for Nova's use (e.g. syncing data, etc). Does anyone have any objections to that approach? On Fri, Jan 23, 2015 at 7:04 AM, Gary Kotton wrote: > Hi, > As Salvatore mentioned this was one of the things that we discussed at the > San Diego summit many years ago. I like the idea of using an RPC interface > to speak with Neutron (we could do a similar thing with Cinder, glance > etc). This would certainly address a number of issues with the interfaces > that we use at the moment. It is certainly something worthwhile discussing > next week. > We would need to understand how to define versioned API¹s, how to deal > with extensions etc. > Thanks > Gary > > On 1/23/15, 2:59 PM, "Russell Bryant" wrote: > > >On 01/22/2015 06:40 PM, Salvatore Orlando wrote: > >> I also like the idea of considering the RPC interface. What kind of > >> stability / versioning exists on the Neutron RPC interface? > >> > >> > >> Even if Neutron does not have fancy things such as objects with > >> remotable method, I think its RPC interfaces are versioned exactly in > >> the same way as Nova. On REST vs AMQP I do not have a strong opinion. > >> This topic comes up quite often; on the one hand REST provides a cleaner > >> separation of concerns between the two projects; on the other hand RPC > >> will enable us to design an optimised interface specific to Nova. While > >> REST over HTTP is not as bandwidth-efficient as RPC over AMQP it however > >> allow deployers to use off-the-shelf tools for HTTP optimisation, such > >> as load balancing, or caching. > > > >Neutron uses rpc versioning, but there are some problems with it (that I > >have been working to clean up). The first one is that the interfaces > >are quite tangled together. There are interfaces that appear separate, > >but are used with a bunch of mixin classes and actually presented as a > >single API over rpc. That means they have to be versioned together, > >which is not really happening consistently in practice. I'm aiming to > >have all of this cleared up by the end of Kilo, though. > > > >The other issue is related to the "fancy things such as objects with > >remotable methods". :-) The key with this is versioning the data sent > >over these interfaces. Even with rpc interface versioning clear and > >consistently used, I still wouldn't consider these as stable interfaces > >until the data is versioned, as well. > > > >-- > >Russell Bryant > > > >__ > >OpenStack Development Mailing List (not for usage questions) > >Unsubscribe: > openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
Hi, As Salvatore mentioned this was one of the things that we discussed at the San Diego summit many years ago. I like the idea of using an RPC interface to speak with Neutron (we could do a similar thing with Cinder, glance etc). This would certainly address a number of issues with the interfaces that we use at the moment. It is certainly something worthwhile discussing next week. We would need to understand how to define versioned API¹s, how to deal with extensions etc. Thanks Gary On 1/23/15, 2:59 PM, "Russell Bryant" wrote: >On 01/22/2015 06:40 PM, Salvatore Orlando wrote: >> I also like the idea of considering the RPC interface. What kind of >> stability / versioning exists on the Neutron RPC interface? >> >> >> Even if Neutron does not have fancy things such as objects with >> remotable method, I think its RPC interfaces are versioned exactly in >> the same way as Nova. On REST vs AMQP I do not have a strong opinion. >> This topic comes up quite often; on the one hand REST provides a cleaner >> separation of concerns between the two projects; on the other hand RPC >> will enable us to design an optimised interface specific to Nova. While >> REST over HTTP is not as bandwidth-efficient as RPC over AMQP it however >> allow deployers to use off-the-shelf tools for HTTP optimisation, such >> as load balancing, or caching. > >Neutron uses rpc versioning, but there are some problems with it (that I >have been working to clean up). The first one is that the interfaces >are quite tangled together. There are interfaces that appear separate, >but are used with a bunch of mixin classes and actually presented as a >single API over rpc. That means they have to be versioned together, >which is not really happening consistently in practice. I'm aiming to >have all of this cleared up by the end of Kilo, though. > >The other issue is related to the "fancy things such as objects with >remotable methods". :-) The key with this is versioning the data sent >over these interfaces. Even with rpc interface versioning clear and >consistently used, I still wouldn't consider these as stable interfaces >until the data is versioned, as well. > >-- >Russell Bryant > >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
On 01/22/2015 06:40 PM, Salvatore Orlando wrote: > I also like the idea of considering the RPC interface. What kind of > stability / versioning exists on the Neutron RPC interface? > > > Even if Neutron does not have fancy things such as objects with > remotable method, I think its RPC interfaces are versioned exactly in > the same way as Nova. On REST vs AMQP I do not have a strong opinion. > This topic comes up quite often; on the one hand REST provides a cleaner > separation of concerns between the two projects; on the other hand RPC > will enable us to design an optimised interface specific to Nova. While > REST over HTTP is not as bandwidth-efficient as RPC over AMQP it however > allow deployers to use off-the-shelf tools for HTTP optimisation, such > as load balancing, or caching. Neutron uses rpc versioning, but there are some problems with it (that I have been working to clean up). The first one is that the interfaces are quite tangled together. There are interfaces that appear separate, but are used with a bunch of mixin classes and actually presented as a single API over rpc. That means they have to be versioned together, which is not really happening consistently in practice. I'm aiming to have all of this cleared up by the end of Kilo, though. The other issue is related to the "fancy things such as objects with remotable methods". :-) The key with this is versioning the data sent over these interfaces. Even with rpc interface versioning clear and consistently used, I still wouldn't consider these as stable interfaces until the data is versioned, as well. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
I can't imagine how MPLS/RSVP is suitable for the communications between Nova and Neutron. Can you elaborate on what you meant? On Thu, Jan 22, 2015 at 9:36 AM, Akilesh K wrote: > I had always wanted this to happen. It is really frustrating when nova > throws wierd python exceptions and difficult to comprehend log messages. > > If the developers do agree to clean up the interface I would suggest they > make use of some well knows protocol (mpls/rsvp) to do this, instead of > relying on custom south-bound api calls. > > regards, > Ageeleshwar K > > On Thu, Jan 22, 2015 at 9:39 PM, Sean Dague wrote: > >> On 01/22/2015 10:28 AM, Salvatore Orlando wrote: >> > Hi, >> > >> > We have attempted several times to start a conversation around the >> > interface between nova and neutron and its problems, starting with the >> > fact that it's chatter than two Italians arguing about football (*). >> > Indeed the first attempt at fixing these problems goes back to the Fall >> > 2012 summit [1]. While we probably don't want to introduce yet another >> > service to this aim, it might be worth giving another shot at having >> > these two project communicate in a decent way. I know that other >> > developers are interested in this and are probably even already actively >> > working on this topic. >> > >> > In my opinion it might not be such a bad idea to start this conversation >> > at the upcoming nova meetup, if there will be enough interest from the >> > participants. I have started the etherpad [2] for discussing issues of >> > the current implementation, goals, architecture, and design. >> > >> > As for timelines, it is very likely already too late for shipping this >> > in Kilo, but we're probably still on time for completing this work by >> > the "L" release. >> > >> > Salvatore >> > >> > (*) being Italian I am entitled to make jokes about Italians without >> > offending anyone, I hope. >> > >> > [1] https://etherpad.openstack.org/p/grizzly-newtonian >> > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework >> >> Interesting stuff. I conceptually like the idea of nova-compute doing >> the leg work for sub resources (like the network) as it feels like error >> handling is simpler given it's closeness to the actual VMs that are >> running. >> >> I also like the idea of considering the RPC interface. What kind of >> stability / versioning exists on the Neutron RPC interface? >> >> -Sean >> >> -- >> Sean Dague >> http://dague.net >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
On 22 January 2015 at 17:09, Sean Dague wrote: > On 01/22/2015 10:28 AM, Salvatore Orlando wrote: > > Hi, > > > > We have attempted several times to start a conversation around the > > interface between nova and neutron and its problems, starting with the > > fact that it's chatter than two Italians arguing about football (*). > > Indeed the first attempt at fixing these problems goes back to the Fall > > 2012 summit [1]. While we probably don't want to introduce yet another > > service to this aim, it might be worth giving another shot at having > > these two project communicate in a decent way. I know that other > > developers are interested in this and are probably even already actively > > working on this topic. > > > > In my opinion it might not be such a bad idea to start this conversation > > at the upcoming nova meetup, if there will be enough interest from the > > participants. I have started the etherpad [2] for discussing issues of > > the current implementation, goals, architecture, and design. > > > > As for timelines, it is very likely already too late for shipping this > > in Kilo, but we're probably still on time for completing this work by > > the "L" release. > > > > Salvatore > > > > (*) being Italian I am entitled to make jokes about Italians without > > offending anyone, I hope. > > > > [1] https://etherpad.openstack.org/p/grizzly-newtonian > > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework > > Interesting stuff. I conceptually like the idea of nova-compute doing > the leg work for sub resources (like the network) as it feels like error > handling is simpler given it's closeness to the actual VMs that are > running. > That's true for the nova-network use case. In the neutron case instead nova-compute ends up calling the neutron server which then operates on the host through its agent. So we probably have different workflows, and the one currently performed when using neutron is a bit "erratic" since it goes from nova-api to nova-compute where the instance is built; then it calls into neutron-server whose network configuration is picked up by the agent which configures networking on the same host where nova-compute is running! > > I also like the idea of considering the RPC interface. What kind of > stability / versioning exists on the Neutron RPC interface? > Even if Neutron does not have fancy things such as objects with remotable method, I think its RPC interfaces are versioned exactly in the same way as Nova. On REST vs AMQP I do not have a strong opinion. This topic comes up quite often; on the one hand REST provides a cleaner separation of concerns between the two projects; on the other hand RPC will enable us to design an optimised interface specific to Nova. While REST over HTTP is not as bandwidth-efficient as RPC over AMQP it however allow deployers to use off-the-shelf tools for HTTP optimisation, such as load balancing, or caching. > -Sean > > -- > Sean Dague > http://dague.net > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
I had always wanted this to happen. It is really frustrating when nova throws wierd python exceptions and difficult to comprehend log messages. If the developers do agree to clean up the interface I would suggest they make use of some well knows protocol (mpls/rsvp) to do this, instead of relying on custom south-bound api calls. regards, Ageeleshwar K On Thu, Jan 22, 2015 at 9:39 PM, Sean Dague wrote: > On 01/22/2015 10:28 AM, Salvatore Orlando wrote: > > Hi, > > > > We have attempted several times to start a conversation around the > > interface between nova and neutron and its problems, starting with the > > fact that it's chatter than two Italians arguing about football (*). > > Indeed the first attempt at fixing these problems goes back to the Fall > > 2012 summit [1]. While we probably don't want to introduce yet another > > service to this aim, it might be worth giving another shot at having > > these two project communicate in a decent way. I know that other > > developers are interested in this and are probably even already actively > > working on this topic. > > > > In my opinion it might not be such a bad idea to start this conversation > > at the upcoming nova meetup, if there will be enough interest from the > > participants. I have started the etherpad [2] for discussing issues of > > the current implementation, goals, architecture, and design. > > > > As for timelines, it is very likely already too late for shipping this > > in Kilo, but we're probably still on time for completing this work by > > the "L" release. > > > > Salvatore > > > > (*) being Italian I am entitled to make jokes about Italians without > > offending anyone, I hope. > > > > [1] https://etherpad.openstack.org/p/grizzly-newtonian > > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework > > Interesting stuff. I conceptually like the idea of nova-compute doing > the leg work for sub resources (like the network) as it feels like error > handling is simpler given it's closeness to the actual VMs that are > running. > > I also like the idea of considering the RPC interface. What kind of > stability / versioning exists on the Neutron RPC interface? > > -Sean > > -- > Sean Dague > http://dague.net > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova<->neutron interface
On 01/22/2015 10:28 AM, Salvatore Orlando wrote: > Hi, > > We have attempted several times to start a conversation around the > interface between nova and neutron and its problems, starting with the > fact that it's chatter than two Italians arguing about football (*). > Indeed the first attempt at fixing these problems goes back to the Fall > 2012 summit [1]. While we probably don't want to introduce yet another > service to this aim, it might be worth giving another shot at having > these two project communicate in a decent way. I know that other > developers are interested in this and are probably even already actively > working on this topic. > > In my opinion it might not be such a bad idea to start this conversation > at the upcoming nova meetup, if there will be enough interest from the > participants. I have started the etherpad [2] for discussing issues of > the current implementation, goals, architecture, and design. > > As for timelines, it is very likely already too late for shipping this > in Kilo, but we're probably still on time for completing this work by > the "L" release. > > Salvatore > > (*) being Italian I am entitled to make jokes about Italians without > offending anyone, I hope. > > [1] https://etherpad.openstack.org/p/grizzly-newtonian > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework Interesting stuff. I conceptually like the idea of nova-compute doing the leg work for sub resources (like the network) as it feels like error handling is simpler given it's closeness to the actual VMs that are running. I also like the idea of considering the RPC interface. What kind of stability / versioning exists on the Neutron RPC interface? -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
