Hi Dan,
Thanks for your response. > ** 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. Yes, I checked the Cisco driver and the portprofile extension. The Cisco driver seems to pass and retrieve the plugin-specific data with PUT method. I just thought that this kind of vif-plugging could be a general model for plugins that work without "agent". I agree with you that we should minimize churn in the Nova codebase. But, I still feel that the "agent" model, especially polling, is not so good. Although there are many topics on the summit, I hope that we could have discussion about vif-plugging changes. > 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. It could be mixed. I think that a cloud user specifies vNIC option like "physical NIC mapping" as a VM flavor, then a service provider determines a hypervisor node and it's available physical NIC. It is not suitable that the cloud user specifies physical NIC itself. But this though is not clear enough to having a session on the summit, I hope that we discuss this issue on vif-plugging session or somewhere in the summit. > 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). > I found it. I'll join the sessions. Thanks! > 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. > Thanks, Ryota MIBU -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
