Somik is actually going to take the lead on this from our end. After talking a bit more, our thinking is to explore just doing the integration against keystone to start, since that is our thinking of what the right long-term approach is. Somik will send out an update once he's looked into this a bit more.
Dan On Tue, Aug 16, 2011 at 1:50 PM, Dan Wendlandt <d...@nicira.com> wrote: > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
