Adding netstack list, as this originally started out as a discussion on a merge prop.
Salvatore, I think we have a lot of the same concerns and goals here. I would actually love for Keystone obviate the need for this direct path all together, with the model being that any service that can leverage Quantum grants a "role/capability" of quantum-iface-attach:<iface-id> to a particular set of identifies, then all Quantum does is check that a tenant plugging an interface with id = "foo" has the role/capability quantum-iface-attach:foo . This way, Quantum does not actually have to store any of the ownership state, nor worry about details like having stale ownership info if a user is removed from keystone, etc. Keystone is still just coming together though, and my sense if that such fine-grained capabilities are not yet something they are targeting, so I'm not sure how this would scale. If we're using a cloud platform other than nova, either that service either also needs to talk with Keystone, or make sure that Quantum can talk to whatever it uses for identity (hand wave, hand wave). If we think this is the right long-term path, I would vote for a model with the same "directionality", even if we are not yet talking to keystone (i.e., one where nova calls out to a remote entity to report ownership info). In the short-term, the call that it makes could just be a Quantum Admin API. I've gone back and forth on whether this should happen in the vif-plugging "driver" or in the network manager. For now, I think it seems most straight-forward to implement this in the Quantum-aware NetworkManager, as this requires changing only one entity (as opposed to everyone's vif drivers) but I can definitely see arguments either way. I think I'll at least prototype this in the network manager, then we can see what we think about it. Ideally we can soon revisit this and compare it against using keystone. Dan On Fri, Aug 12, 2011 at 1:14 PM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > Hi Dan, **** > > ** ** > > Thanks for resending me this. Your previous email ended up in the junk > folder. **** > > I’m changing the subject to avoid this happens again.**** > > ** ** > > My replies are inline. **** > > The bottom line is that I don’t have any specific preference; my only goal > is to keep Quantum and nova enough loosely coupled, in order to fulfil one > the principles behind the whole NetStack project, which is the ability of > working with IaaS software stacks different from Openstack. **** > > ** ** > > Cheers,**** > > Salvatore**** > > ** ** > > *From:* Dan Wendlandt [mailto:d...@nicira.com] > *Sent:* 12 August 2011 08:03 > *To:* Salvatore Orlando > *Subject:* Fwd: [Merge] > lp:~salvatore-orlando/quantum/quantum-api-alignment into lp:quantum**** > > ** ** > > Hi Salvatore,**** > > ** ** > > I've had to be helping with customer deployments all week and haven't > gotten to this yet, but since you'll be out next week I wanted to check and > see if you had any thoughts on this, as I'll try to do a first cut of this > over the weekend. **** > > ** ** > > Also, is your thinking that the API itself would store this data, or that > the plugin would store it. Long term I think we agree that ownership info > should be managed by keystone, so hopefully either decision will just be > temporary. I think when we last talked, we had planned on having the API > store the data directly.**** > > ** ** > > I think you are referring to ownership information here. Looking at the > plugin interface, ownership information are implicitly stored when you > create the network. For the simple model we are implementing for Quantum, I > think this is good enough for ports and networks. As concerns interfaces, > this really depends on how we design the Admin API. See other comments.*** > * > > ** ** > > When we will move to a full RBAC model, we can do two things:**** > > **· **Provide data storage in the quantum service layer; we will > probably have to devise a solution with strict scalability and reliability > requirements, and I’m pretty sure you guys can help a lot here. **** > > **· **Have the Quantum service layer use a database model, with > the implementation of the database API provided a 3rd party (which could > be the plugin implementor or somebody else). In this way if a particular > service provider has a super-scalable, super-fast, super-reliable database, > such database can be used to store Quantum data. **** > > ** ** > > Dan**** > > ** ** > > ---------- Forwarded message ---------- > From: *Dan Wendlandt* <d...@nicira.com> > Date: Mon, Aug 8, 2011 at 6:23 PM > Subject: Re: [Merge] lp:~salvatore-orlando/quantum/quantum-api-alignment > into lp:quantum > To: mp+70...@code.launchpad.net > > > > **** > > On Mon, Aug 8, 2011 at 3:13 PM, Salvatore Orlando < > salvatore.orla...@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. **** > > ** ** > > I think both models somehow increase the degree of coupling between Quantum > and nova. In case #1 nova is “passive”, as Quantum asks for interface > ownership information; where in case #2 nova has an active role, as it > pushes out interface information to Quantum. **** > > ** ** > > ** ** > > #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. **** > > ** ** > > I agree that a “push” mechanisms for interface information is a rather > natural solution; we also agreed that these notifications would happen > through standardized APIs, without “plugin black magic”.**** > > On the minus side, I see this as something which increases quite a lot the > degree of coupling between Quantum and nova, as nova should be aware of the > fact that it needs to push the interface information to Quantum; I expect a > rather uncool “if network_manager==’Quantum’:” to be somewhere in the code. > Another comment I have on approach #2, is that it would be quite hard to > integrate Quantum with other IaaS stack unless we have the same degree of > influence that we have with nova. **** > > ** ** > > For this reason I think maybe we should consider the first approach as > well. Required APIs on nova could be implemented as an API extension; I > think this will also keep nova and Quantum rather loose. However, the big > cons here is that you wouldn’t have “real-time” notifications for events > regarding interfaces; not sure how that is important, though.**** > > ** ** > > So let’s say that I slightly lean towards approach #1, but my position is > rather soft, especially considering the fact that it seems you’ve already > done a lot of work around approach #2, and the last thing I want is to > hinder progress.**** > > ** ** > > 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? **** > > ** ** > > IMHO in this scenario, “resending” all the data would only one of the > problems to be faced. Assuming that this is a use case we aim to support, I > think what we need here is a migration procedure, which, among the other > things, will include interfaces as well.**** > > ** ** > > **** > > 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). **** > > I guess this is information is supposed to be transmitted when the VIF is > created, is that correct?**** > > ** ** > > **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. **** > > I need to understand a little bit better what you guys are doing in nova; > unfortunately I did not have enough spare cycles to have a look at it is. > I’m particularly intrigued by the “network-manager”: is that a > network-manager for nova-network which actually turns out to be a proxy for > Quantum? Or is it something different? **** > > ** ** > > Anyway I think that the most natural point where plugins should do this is > the vif-plug driver. **** > > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks, Inc. > www.nicira.com | www.openvswitch.org > Sr. Product Manager > cell: 650-906-2650 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
