Thanks for the thoughts Ryota, I have responded inline. Dan
On Fri, Mar 30, 2012 at 12:19 AM, Ryota MIBU <r-m...@cq.jp.nec.com> wrote: > Hi all, > > > I have some ideas about vif-plugging and Security Group. > I added a sub topic to vif-plugging. > > ** vif port parameter handling (or portprofile) > VIF Driver should be available to handle plugin-specific port parameters > and/or helper functions. > This is required in just some plugins now, but necessary to be designed in > Quantum Community. > In my experience of implementing NEC OpenFlow Plugin, I think it is tough > to create Nova drivers and Quantum extension APIs. > To help those who wants to write a new Quantum plugin without "agent", we > should design a common (or just sample) Nova driver and > Quantum extension APIs for passing or retrieving plugin-specific > information. > I believe the Cisco driver actually does something like this already, you might want to look at it as an example. However, I think the goal should be that code that is in Nova is not specific to the plugin. As we talked about earlier in the thread, you may need different types of vif-plugging to attach to different types of switching technologies (e.g., OVS vs. bridge vs. VEPA/VNTAG), but I think that different plugins that use the same switching technology should be able to use the same vif-plugging (for example, there are several plugins that all use the OVS vif-plugging). Our goal here should be to minimize churn in the Nova codebase. > I think there is another sub topic, but I am not sure yet. > I agree that a configurable VIF driver is much better. > For designing the configuration of vif-plugging, it is required that we > discuss the granularity of selecting VIF Driver. > Should The granularity of selecting VIF Driver be per node, VM, or VIF? > Currently, VIF Driver would be configured in nova-compute.conf. > This means that the granularity is per Hypervisor Node. > To be more flexible, we might consider the case where VIF1 of VM1 connects > to bridge and VIF2 of VM1 maps to a physical NIC > directly. > If so, it may raise another issue; how to determine connection type of VIF. > That's an interesting use case, and something that we haven't tried to deal with yet. In your use case, who would determine how a VIF was mapped? Would it be a policy described by the service provider? Would it be part of the VM flavor? Adding this kind of flexibility is certainly possible, though you are the first person who has expressed a need for this type of flexibility. > > Is there any blueprint of Security Group in NetStack? > I have a primitive proposal for an firewall model and API, and a firewall > implementation on Quantum OpenFlow Plugin. > That is just a prototype based on Quantum L2 API. > But, this proposal shows how firewalling API should be. > I think the first point in designing firewalling models is to which entity > each rule is associated. > Is the entity network or port? > I hope that we will have discussions for firewalling leads much more > functionalities and APIs than security group has currently. > Dave Lapsley (on netstack list) is doing a session on this at the summit. Feel free to join as a driver. My thinking on the topic is that each Quantum port could be assigned one or more security groups. There is also scope, I believe, for more advanced ACLs that could be associated with each port, essentially consisting of inbound/outbound lists of rules that each have a "match" and an "action" (allow/deny). There is also the topic of NAT, which in my mind makes the most sense to think about in terms of our "L3 forwarding" discussion (see etherpad). > > Finally, I would like to suggest that the Security Group session would be > suitable to be held after Quantum L3 session. > I think the Security Group is a cross layer function and its design should > better be coupled with L3 design. > I think our first task needs to be properly scoping each of these discussions, particularly on the many topics loosely call "L3". I've sent another email to the list with thoughts on breaking up those discussions. > > > Regards, > > Ryota MIBU > > >-----Original Message----- > >From: netstack-bounces+r-mibu=cq.jp.nec....@lists.launchpad.net > >[mailto:netstack-bounces+r-mibu=cq.jp.nec....@lists.launchpad.net] On > Behalf Of Dan Wendlandt > >Sent: Wednesday, March 28, 2012 6:58 AM > >To: netstack@lists.launchpad.net > >Subject: Re: [Netstack] quantum community projects & folsom summit plans > > > >Hi folks, > > > >Thanks for all of the great responses to the thread. I've gone through > the thread and tried to summarize the key > >topics here: http://etherpad.openstack.org/quantum-folsom > > > >I think an etherpad will be a better format for being able to collect > input on who wants to be able to be a "driver" > >on any given topic (we can definitely have more than one per topic). It > will also help us identify topics that we > >agree are important, but that don't yet have drivers. > > > >Note: > >- You don't have to be a driver to participate in the discussion on the > topic. Someone who is a driver is expected > >to come to the summit with a fairly detailed proposal on the topic, and > to help organize discussion. Everyone then > >helps refine the proposal. > >- Some of these topics are still quite broad, and may end up being broken > into multiple sessions, but the key first > >step is identifying the parties who want to be involved in defining the > topic. > > > >I want to make sure we spend summit time discussing topics that are the > most critical items for the project. If > >there are any topics on the ML that I missed, or topics topics that we > think are as or more important than other > >items on the list, let me sure we add them soon. > > > >We need to have sessions filed on the summit website by end of week, so > please update the etherpad today/tomorrow, > >and we'll start filing sessions thursday/friday. > > > >Thanks! > > > >Dan > > > > > > > >On Mon, Mar 12, 2012 at 4:10 PM, Dan Wendlandt <d...@nicira.com> wrote: > > > > > > Hi team, > > > > As we start to look forward to Folsom, I know there will be a lot > of excitement around shiny new directions > >we can take Quantum (L3, VPN/DCI, etc.). This is great, and we will be > moving in this direction during Folsom. I > >know many people are looking to participate here. > > > > But I also want to stress the importance of also focusing on less > shiny tasks that are central to building > >a solid and usable platform. To this end, I wanted to highlight a link I > sent out during last weeks meeting: > >http://wiki.openstack.org/QuantumStarterBugs > > > > This page has a pointer to low-hanging fruit bugs as well as a > list of "community projects" that are not > >necessarily shiny, but are critical to the progress of the project. This > includes things like improving the CLI, > >integrating with Horizon/Keystone, building a system test infrastructure, > updating documentation, multi-host devstack, > >etc. > > > > In many cases, these are items that we targeted for Essex, but > didn't have sufficient core dev resources > >to tackle. With Quantum becoming core in Folsom, we can't afford to have > that happen again, as expectations around > >Quantums usability, robustness and integration with other projects will > be much higher in Folsom than it was for > >Essex. > > > > I encourage others to add items to this page as well. My general > rule is that something is a community project > >if its unlikely that someone is doing the work to enable something for > their platform/company. As a hint, if a bunch > >of people who express interesting in working on something, its probably > not a community project. If people have > >been saying "hey, someone should really fix/improve X" for a while, the > fix would help just about everyone, but no > >one has yet stepped forward, its probably a community project :) > > > > > > So in sum, as an open source project, we must make sure everyone > is encouraged and rewarded for working on > >core community projects. I also want to make sure sufficient time at the > summit is dedicated to how we will progress > >on both community projects. > > > > > > Since we will soon be able to register sessions for the Folsom > summits, I'd like people to chime in on the > >list for what they think are the most important "community projects", as > well as "shiny objects" for us to discuss > >at the summit. Hopefully this will make the process of designing > sessions more collaborative and community-driver, > >rather than a game of "I better try and register the session on X before > someone else does". > > > > Here are some initial thoughts: > > > > community projects: > > - improve system test / devstack / tempest > > - quantum authn + authz (yes, we still do not have basic API auth) > > - better integration with openstack CI team (we want automated > smoketests to run on each check-in) > > - quantum CLI / client improvements. (many changes needed to be > more inline with other core projects) > > - reworking of quantum / nova integration (remove dependence on > nova db, etc.) > > - better model for learning what extensions are supported by the > currently running plugin. > > - quantum + horizon GUI flow (and framework for widgets that use > API extensions). > > - melange / quantum integration > > - DHCP API / service > > > > shiny objects: > > - L3 API > > - VPN / data-center-interconnect > > - firewalling / security groups. > > > > Please reply with your own input. Thanks, > > > > Dan > > > > > > > > > > > > > > > >-- > >~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >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 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
