Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-28 Thread Brent Eagles

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 blak...@gmail.com 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 

Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-28 Thread Robert Collins
On 26 January 2015 at 15:30, Ian Wells ijw.ubu...@cack.org.uk 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 blak...@gmail.com 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 for any service that
 binds to 

Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-28 Thread Ian Wells
On 28 January 2015 at 17:32, Robert Collins robe...@robertcollins.net
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

2015-01-28 Thread Mark Voelker
-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 beag...@redhat.com 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 blak...@gmail.com 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 

Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-25 Thread Ian Wells
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 blak...@gmail.com 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

2015-01-23 Thread Russell Bryant
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

2015-01-23 Thread Kevin Benton
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 gkot...@vmware.com 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 rbry...@redhat.com 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

2015-01-23 Thread Gary Kotton
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 rbry...@redhat.com 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

2015-01-22 Thread Sean Dague
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


Re: [openstack-dev] [Nova][Neutron] Thoughts on the nova-neutron interface

2015-01-22 Thread Salvatore Orlando
On 22 January 2015 at 17:09, Sean Dague s...@dague.net 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

2015-01-22 Thread Kevin Benton
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 akilesh1...@gmail.com 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 s...@dague.net 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

2015-01-22 Thread Akilesh K
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 s...@dague.net 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