<div dir="ltr">Lots of open questions in here, because I think we need a long conversation on the subject.<br><br>On 23 January 2015 at 15:51, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>It seems like a change to using internal RPC interfaces would be pretty unstable at this point.</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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? <div></div></div></blockquote><div> <br>I think the protocol being used is a distraction from the actual shortcomings.<br><br>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.<br><br></div><div><br></div><div>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.)<br><br>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?</div></div></blockquote><div><br></div><div>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.<br></div><div><br>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?<br></div><div>-- <br></div><div>Ian.<br></div></div></div></div>