On Thu, Sep 29, 2011 at 9:45 AM, Somik Behera <so...@nicira.com> wrote:
> > >> >> - When creating a VM, you should be able to specify the # of VIFs for that >> VM. Each VIF could optionally specify a quantum network to be connected to >> and a Melange subnet to get an IP from. This provides the flexibility to >> make interesting network topologies, because you no longer have the >> requirement that every VM for a project is connected to the same set of >> networks. >> >> > This is a little more interesting use case as we will have to see if we > want the Dashboard to leverage the OpenStackx API that allows one to specify > # of Vif for every VM being launched and then allows the user to specify > which networks those Vifs should attached with. > I now Troy and other folks have been thinking a lot about this as well. To me, having this capability in the API and Dashboard is fundamental to delivering on the promise of being able to build interesting network topologies with VMs. Its somewhat similar to how Amazon VPC let's you place a VM in a particular VPC and subnet (amazon only supports a single vNIC per VM currently, so it is somewhat simpler, but the same concept). Dan > > This flow is similar to what I prototyped with the "simple quantum >> orchestrator" here: http://wiki.openstack.org/QuantumOVSDemo >> >> One interesting point to discuss is whether L2 networks and subnets should >> be tightly coupled in a GUI or not. I can certainly think of cases where >> you might not want them to be coupled, but in the common case they are. >> > > Coupled or not, we should be able to create both(L2 network & subnet) from > a single interface( CLI, GUI, WS) or atleast create both separately and > associate them together. This will be needed to replace the functionality > Nova offers today. > > >> >> Dan >> >> >> On Wed, Sep 28, 2011 at 5:38 PM, Salvatore Orlando < >> salvatore.orla...@eu.citrix.com> wrote: >> >>> Hi Somik, >>> >>> >>> >>> These are exactly the kind of questions I would like to answer in the >>> session I have proposed. >>> >>> I don’t think we need to schedule a different session in the >>> unconference. >>> >>> >>> >>> I hope we can use this thread to precisely define the agenda of the >>> session. >>> >>> >>> >>> Salvatore >>> >>> >>> >>> *From:* netstack-bounces+salvatore.orlando= >>> eu.citrix....@lists.launchpad.net [mailto: >>> netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] *On >>> Behalf Of *Devin Carlen >>> *Sent:* 29 September 2011 01:19 >>> *To:* Somik Behera >>> *Cc:* netstack@lists.launchpad.net >>> *Subject:* Re: [Netstack] Pre-summit Quantum & Dashboard integration >>> discussions >>> >>> >>> >>> Hi all, >>> >>> >>> >>> I have some notes inline for you. >>> >>> >>> >>> On Sep 28, 2011, at 2:59 PM, Somik Behera wrote: >>> >>> >>> >>> Hi All, >>> >>> I just wanted to send few initial thoughts on enhancing our Dashboard >>> integration to better enable the end-user(tenant) to manage their >>> networking( L2, IPAM all together) as well as provide the Cloud Admin a >>> location, where they can interact with Quantum, and perform Quantum specific >>> functions( i.e. use cases specific to the Network Admin) I installed >>> Dashboard with Quantum,Keystone and Nova all working together, after >>> navigating few landmines, I got it running and had some early feedback and I >>> was hoping to collect what ideas other folks in the team had around >>> Dashboard. I know Arvind and Mark Voelker from Cisco have quite a few ideas >>> and I am hoping by the end of summit, we can all together crystallize all >>> the ideas into blueprints for Essex. >>> >>> >>> >>> Yes, we got bit by the Keystone bug a bit. They have committed to >>> dropping code by Friday so we should be able to release a Diablo stable >>> version of Dashboard by then. >>> >>> >>> >>> I am sure there are a lot of thoughts and ideas around how we should >>> integrate Quantum with various OpenStack services, and then how does >>> Dashboard orchestrate all these underlying OpenStack services in a cohesive >>> manner( from networking perspective.) I just wanted to get the discussion >>> started and hopefully, we can tackle the discussions around these flows in >>> the unconference area or together with Salvatore's Quantum integration >>> workflows session <http://summit.openstack.org/sessions/view/78> >>> >>> Quantum-Nova workflow today: >>> >>> 1. OpenStack cloud provider configures QuantumManager as the >>> NetworkManager and the appropriate IPAM service,Nova's IPAM or Melange. >>> 2. Using nova-manage, Cloud “admin” creates global shared networks in >>> nova with a priority & subnet >>> 3. Using nova-manage, Cloud “admin” or tenant “admin” creates tenant >>> specific networks with a priority & subnet >>> 4. Tenant spins up a VM, VM contains appropriate # of nics(multi-nic) >>> based on # of networks the VM is associated with, injected IP, and Vifs >>> plugged into the correct network. >>> >>> Quantum-Dashboard workflow today: >>> >>> 1. OpenStack cloud provider configures Quantum service integration. >>> 2. Tenant logs in with keystone credentials >>> 3. Tenant can view networks owned by the tenant >>> 4. Tenant can create, update, delete tenant owned network & ports >>> 5. Tenant can plug/unplug Vifs to/from networks. >>> >>> Workflow items not supported by dashboard today: >>> >>> 1. A SysPanel UI for "Quantum" only for Network-only admin functionality. >>> >>> 2. Networks created via dashboard are unknown to nova, the networks also >>> are not associated with Nova IPAM or Melange IPAM >>> - This requires that once a Quantum network has been created, user >>> still has to use nova-manage CLI to associate the quantum network within >>> Nova DB >>> and create an associated IP block with the network. >>> >>> >>> >>> >>> >>> 3. A mechanism for dashboard UI to support additional UI for various >>> extensions, in a pluggable manner. >>> >>> >>> >>> This is in progress now. We'll have the ability to register >>> functionality in the side and top bars as needed for top level >>> functionality. >>> >>> >>> >>> To enable functions at a more granular level (eg specifiying a network to >>> use when launching an instance?) you'll need to create code in the launch >>> instance template to pivot around settings.QUANTUM_ENABLED. Bit of a pain >>> but totally doable. >>> >>> >>> >>> >>> While we can discuss what the real workflow should be and what kind of UI >>> we should create, at the summit, I just wanted to open this thread to gather >>> some input ahead of the summit. >>> >>> >>> >>> Let me know when and where and I'll be there. :) >>> >>> >>> >>> >>> I am hoping we can merge this discussions with Salvatore's integration >>> workflow discussion or do a unconference session as having a robust UI will >>> definitely help Quantum's adoption as well as Demo's :) >>> >>> Thanks, >>> Somik >>> >>> -- >>> Somik Behera | Nicira Networks, Inc. | so...@nicira.com<sbeh...@nicira.com> >>> | >>> office: 650-390-6790 | cell: 512-577-6645 >>> -- >>> Mailing list: https://launchpad.net/~netstack >>> Post to : netstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~netstack >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> -- >>> 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, Inc. >> www.nicira.com | www.openvswitch.org >> Sr. Product Manager >> cell: 650-906-2650 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> > > > > -- > Somik Behera | Nicira Networks, Inc. | so...@nicira.com<sbeh...@nicira.com> | > office: 650-390-6790 | cell: 512-577-6645 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
