Hi Debo, Happy holidays. Thanks for putting together the write-up on cloudpipe + Quantum. A couple comments/questions below.
Dan I agree that the generalization of the cloudpipe capability is a generic VM service insertion capability. This actually maps to some of the work Edgar has been doing with respect to a generic framework for service insertion (that will be the subject of a subsequent email). My original thinking on this topic had been to do some simple tweaks to Nova to make sure someone could use the existing nova-manage to spin up cloudpipe VPNs, but on a specific quantum network. I think this essentially maps to what you describe at the bottom of the wiki page (second half of "Design Notes" section). The Nova code already supporting specifying the network to be used when creating a VM. We'll probably need to update the IP allocation logic within the IPAM libraries of the QuantumManager to be aware of the VPN range, and to allocate the correct VPN-private-address IP to the cloudpipe VM when it is spun up. Where you thinking of making these changes for Melange as well as the Nova IPAM? Ultimately, I think Melange is what we will use when inserting generic services, so doing this work now would help flush things out for general service insertion, at the cost of making things a bit more complex up front. Can you be a bit more detailed in what you're proposing in the "Changes to Quantum" section?: "API changes to Quantum would include adding attributes to a network upon creation for the cloudpipe. An alternative is to specify it separately (not during creation)." I hadn't been thinking that Quantum API changes would be required. This may depend on how much you were thinking of improving on the base cloudpipe capabilities. This gets back to the discussion of generic services insertion, but I would probably view that as something that belong more with a "VPN service" than with the core Quantum L2/L3 APIs. Are we still comfortable targeting this for essex-3? As I mentioned, we won't be able to make any significant changes to nova beyond essex-3, so we may need to trim our ambitions here. For me, parity with the existing mechanism is the more important bar. A more flexible VPN service could instead be implemented as part of a more generic services insertion mechanism. On Mon, Dec 12, 2011 at 11:33 PM, Debo Dutta (dedutta) <dedu...@cisco.com>wrote: > Folks **** > > ** ** > > Feedback solicited for this BP http://wiki.openstack.org/QuantumCloudpipe* > *** > > ** ** > > Regards**** > > debo**** > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
