Hi Chiradeep and Anthony, Thanks for the feedback, that clarifies the scope of the 4.2 Security Groups work nicely, especially around pluggability and supported network models.
Thanks, Dave. On Fri, Mar 8, 2013 at 10:56 AM, Anthony Xu <xuefei...@citrix.com> wrote: > > >Lastly we wanted to understand timelines. The last comment on > > >CLOUDSTACK-737 shows the feature being reverted, so we were wondering > > >when it's aimed for master, and also to understand when Security > > >Groups on Advanced Isolated mode is scheduled to hit master. > > > > As I said, there's hypervisor-level issues being sorted out. I'll let > > Anthony reply on that one. > > > > CLOUDSTACK-737 have limited version, it only supports one shared SG > enabled network. > > I'll update FS to describe what we will do for 4.2. > > Below is summary in my mind, > - SG is an option in network offering, not a flag in Zone level, SG could > be added to existing zone. > - SG can only be added to shared network ( zone-wide, domain-wide..) > - SG will move to NIC level from VM level, a VM can have two NICs with two > shared networks, each NIC can be associated to different SGs. > - SG cannot be added to isolated network, or VPC network, firewall or ACL > could provide similar function. > - SG can coexist with external device in a shared network. > - support XS and KVM. > - for existing zone, if user wants to add SG in this zone, user needs to > change XS network mode from OVS mode to bridge mode because iptables > doesn't work with OVS. > > > > Thanks, > Anthony > > > > > > > > > > > -----Original Message----- > > From: Chiradeep Vittal > > Sent: Thursday, March 07, 2013 3:18 PM > > To: cloudstack-dev@incubator.apache.org > > Cc: Anthony Xu > > Subject: Re: Security Groups in Advanced Zone - Plugin Support > > > > > > > > On 3/7/13 12:22 AM, "Dave Cahill" <dcah...@midokura.com> wrote: > > > > >Hi Chiradeep, > > > > > >Thanks for jumping in, great to get feedback on this one. > > > > > >However, SecurityGroups are handled by SecurityGroupManagerImpl, which > > >simply sends a Command to the agent without checking for, or calling > > >into, a SecurityGroupsProvider. In other words, it's not pluggable. > > > > > >That's the background for why we're interested in pluggability for the > > >service. > > > > Yes, it should be pluggable, but it isn't currently. Patches welcome. > > > > > > > >Our second question was aimed at checking our understanding of > > >Anthony's response: "as for SG enabled shared network, current plan is > > >only support Virtual Router as service provider". It sounds like this > > >would make all of the other Providers (external ones like F5 as well > > >as virtual ones like Nicira) unusable in a SG-enabled Advanced Shared > > >network, but we wanted to double-check that. > > > > I don't see anything in the code that would preclude that. I think > > given > > the scope of testing with myriad providers, he was merely stating that > > he > > would vouch for it working with the virtual router. > > > > > > > >Lastly we wanted to understand timelines. The last comment on > > >CLOUDSTACK-737 shows the feature being reverted, so we were wondering > > >when it's aimed for master, and also to understand when Security > > >Groups on Advanced Isolated mode is scheduled to hit master. > > > > As I said, there's hypervisor-level issues being sorted out. I'll let > > Anthony reply on that one. > > > > > > >
