neutron

Code review comment for lp:~salvatore-orlando/neutron/quantum-api-alignment

quantum-api-alignment
Merge into diablo

Revision history for this message

dan wendlandt (danwent) wrote on 2011-08-09:

On Mon, Aug 8, 2011 at 3:13 PM, Salvatore Orlando <
<email address hidden>> wrote:

> > One other question for you: as part of nova + quantum integration, I'm
> > prototyping the "admin API" interfaces to communicate information like
> > interface-ownership (for authenticating attachments) and
> interface-bindings
> > (for knowing where a vif was deployed).
> >
> > My gut says that we should not hold up the 1.0 version while waiting to
> > include these items, but I wanted to get your thoughts there. We
> definitely
> > will need to document these eventually though, as there will be other
> > openstack services that want to integrate with Quantum.
>
> Good point. I guess the admin API has a different endpoint, as it should be
> exposed by nova, is that correct?
>

I think one could think of doing it in two ways:

1) exposing an endpoint on nova, with quantum as the client.
2) exposing an endpoints on quantum, with nova as the client.

My mental model had always been #2, but I'm not wedded to it.

#2 seemed natural to me as the "interface service" (e.g., nova) seemed to
need to be able to "push" an interface binding to quantum (e.g., in the case
where a VM migrates, changing the binding). Also, requring "interface
service" to make a JSON call (ideally with the help of the client lib)
seemed easier than requiring each interface service to expose and
authenticate a new API call. This would be particularly true if an interface
service was already acting as a quantum client for other reasons, which is
the case with nova.

One case where #2 is a bit funky is if quantum is deployed after an
interface service like nova is already running (and thus has already spun up
a set of VMs). It would seem that nova would need to support a method where
it "resends" all of its data. Seems possible, but kind of clunky.

Do you have a strong feeling on this one?

> In that case I'm not entirely sure this should be part of the Quantum API
> at all (for instance if it going to be an Openstack API extension, why
> should it be documented in Quantum API). I can't find a blueprint for
> tracking this piece of work, can you give me a pointer?
>

The original blueprint for this work is:
https://blueprints.launchpad.net/quantum/+spec/quantum-interface-binding-api

There's not a whole lot there. I'm hoping to do this as part of the Quantum
Manager work in nova:
https://blueprints.launchpad.net/nova/+spec/implement-network-api

Just last night I started stubbing out out a possible Controller for this
admin API. I've decided my first cut wasn't how I wanted it to work, so I'm
going to tweak it (hopefully tonight), then I will push the branch and see
what feedback people have. Main goals are:

1) transmit "vif ownership" info to quantum, so we can tell what tenant owns
a vif (and thus whether they are allowed to plug it in to one of their
ports).
2) for plugins that need it, have a channel to report interface bindings.

#2 is somewhat trickier (not clear if it should live in the network-manager,
in the vif-plug driver, somewhere else), but #1 seems pretty
straightforward.

>
> My plan to lock down the API for this week is motivated by the fact that we
> have to lock down features by Aug 25, and then do bug fixing and system
> testing until diablo release. If you think that we only have two weeks left,
> and given that code review process usually takes a week, this means that the
> best way to ensure a timely completion for the API blueprint is to start
> locking down the spec this week, and then work the week after on the code.
>
>
Agreed. If we wanted to we could have plugins expose these admin apis as
extensions for now, if we can't get them locked down in time.

>
>
> --
>
> https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api-alignment/+merge/70788
> You are reviewing the proposed merge of
> lp:~salvatore-orlando/quantum/quantum-api-alignment into lp:quantum.
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
Sr. Product Manager
cell: 650-906-2650
~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Mon, Aug 8, 2011 at 3:13 PM, Salvatore Orlando <
salvatore.orlando@eu.citrix.com> wrote:

> > One other question for you:  as part of nova + quantum integration, I'm
> > prototyping the "admin API" interfaces to communicate information like
> > interface-ownership (for authenticating attachments) and
> interface-bindings
> > (for knowing where a vif was deployed).
> >
> > My gut says that we should not hold up the 1.0 version while waiting to
> > include these items, but I wanted to get your thoughts there.  We
> definitely
> > will need to document these eventually though, as there will be other
> > openstack services that want to integrate with Quantum.
>
> Good point. I guess the admin API has a different endpoint, as it should be
> exposed by nova, is that correct?
>

I think one could think of doing it in two ways:

1) exposing an endpoint on nova, with quantum as the client.
2) exposing an endpoints on quantum, with nova as the client.

My mental model had always been #2, but I'm not wedded to it.

#2 seemed natural to me as the "interface service" (e.g., nova) seemed to
need to be able to "push" an interface binding to quantum (e.g., in the case
where a VM migrates, changing the binding).  Also, requring "interface
service" to make a JSON call (ideally with the help of the client lib)
seemed easier than requiring each interface service to expose and
authenticate a new API call. This would be particularly true if an interface
service was already acting as a quantum client for other reasons, which is
the case with nova.

One case where #2 is a bit funky is if quantum is deployed after an
interface service like nova is already running (and thus has already spun up
a set of VMs).  It would seem that nova would need to support a method where
it "resends" all of its data.  Seems possible, but kind of clunky.

Do you have a strong feeling on this one?

The original blueprint for this work is:
https://blueprints.launchpad.net/quantum/+spec/quantum-interface-binding-api

There's not a whole lot there.  I'm hoping to do this as part of the Quantum
Manager work in nova:
https://blueprints.launchpad.net/nova/+spec/implement-network-api

Just last night I started stubbing out out a possible Controller for this
admin API.  I've decided my first cut wasn't how I wanted it to work, so I'm
going to tweak it (hopefully tonight), then I will push the branch and see
what feedback people have.  Main goals are:

#2 is somewhat trickier (not clear if it should live in the network-manager,
in the vif-plug driver, somewhere else), but #1 seems pretty
straightforward.

>
> My plan to lock down the API for this week is motivated by the fact that we
> have to lock down features by Aug 25, and then do bug fixing and system
> testing until diablo release. If you think that we only have two weeks left,
> and given that code review process usually takes a week, this means that the
> best way to ensure a timely completion for the API blueprint is to start
> locking down the spec this week, and then work the week after on the code.
>
>
Agreed.  If we wanted to we could have plugins expose these admin apis as
extensions for now, if we can't get them locked down in time.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
Sr. Product Manager
cell: 650-906-2650
~~~~~~~~~~~~~~~~~~~~~~~~~~~

« Back to merge proposal