As for Security Groups, CS has a table "security_group_vm_map" to track which VM is in which SGs, since SG will be changed to NIC level, this table might be changed to "security_group_nic_map", and upgrade needs to be handled, listVM API lists SGs on which this VM is in as well, listVMresponse might need to represent which SGs is on which NIC.
As for VPC, I found below links, https://cwiki.apache.org/confluence/display/CLOUDSTACK/Inter-VLAN+Routing https://cwiki.apache.org/confluence/display/CLOUDSTACK/Amazon+vs+CloudStack+APIs+for+VPC http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+spec --Anthony > -----Original Message----- > From: Simon Waterhouse [mailto:simon.waterho...@eu.citrix.com] > Sent: Wednesday, January 23, 2013 10:20 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: [jira] [Created] (CLOUDSTACK-1043) Add AWS Style NIC > support > > Anthony, > > We should just use standard CloudStack resource quotas to limit how > many NICs and/or IP addresses any given account should be able to > create (I need to look into how these work...) > > The NIC is attached to a network when it is created and this action > will be subject to "standard" access control checks. After my default > position would be that in can be attached to any VM (again subject to > standard access control). However, if we want the VPC model in CS to > follow the AWS pattern, we should also be putting restrictions in place > so you cannot wire up a VM to span VPCs or route from a VPC to a non- > VPC network. I would welcome some input from the VPC folk on the list, > and if possible some reference to the information model for CS VPC. > > As part of the attachment of a NIC to a VM, the implementation will be > responsible for ensuring the relevant security groups are applied > before the NIC is activated. > > Your comment on superfluous virtualmachineid on detach is a good one: I > put the parameter in for consistency with the other CloudStack "detach" > methods (e.g. detachVolume). But we could do without it - I would be > interested in opinions on this... > > On detachNic the relevant security group rules will need to be "de- > applied" > > I missed an API change for "listSecurityGroups" - i.e. add an optional > parameter "nicid" to allow a query for the set of NICs associated with > a given NIC. Other than that I don't think the Security Group Platform > API needs to change, unless I am missing something. > > I will update the spec. with clarifications. > > Thanks for the feedback. > Simon > > > > -----Original Message----- > From: Anthony Xu [mailto:xuefei...@citrix.com] > Sent: 23 January 2013 17:28 > To: cloudstack-dev@incubator.apache.org > Subject: RE: [jira] [Created] (CLOUDSTACK-1043) Add AWS Style NIC > support > > Hi Simon, > > I'm glad to see ENI feature in CloudStack, I do have some questions, > > createNic, > it actually allocates IP, should CS limit the number of NIC an > account can create to avoid one account use too many IP? > > attachNic, > can a NIC be attached to any VM, or only VM in the same network with > NIC? > Will this api apply Security group rules for this NIC? > > detachNic, > since a NIC can only be attached to one VM, I don't think parameter > virtualmachineid is necessary. > Will this api remove security group rules for this NIC? > > Since the feature moves SG to NIC level from VM level, it might be nice > to add content about SG API behavior changes, and upgrade in this FS. > > > --Anthony > > > > > -----Original Message----- > > From: Simon Waterhouse (JIRA) [mailto:j...@apache.org] > > Sent: Wednesday, January 23, 2013 4:38 AM > > To: cloudstack-dev@incubator.apache.org > > Subject: [jira] [Created] (CLOUDSTACK-1043) Add AWS Style NIC support > > > > Simon Waterhouse created CLOUDSTACK-1043: > > -------------------------------------------- > > > > Summary: Add AWS Style NIC support > > Key: CLOUDSTACK-1043 > > URL: > > https://issues.apache.org/jira/browse/CLOUDSTACK- > > 1043 > > Project: CloudStack > > Issue Type: New Feature > > Security Level: Public (Anyone can view this level - this is > the > > default.) > > Components: Management Server > > Affects Versions: Future > > Reporter: Simon Waterhouse > > > > > > The issue is to expose a virtual network interface card (NIC) as a > > standalone entity in the CloudStack API that may be explicitly > > created/deleted and attached/detached from a virtual machine. The > > intention is to follow the pattern pioneered by Amazon with their > > Elastic Network Interface. > > > > A desgin document may be found at > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS+Style+NIC+s > > u > > pport > > > > -- > > This message is automatically generated by JIRA. > > If you think it was sent incorrectly, please contact your JIRA > > administrators For more information on JIRA, see: > > http://www.atlassian.com/software/jira
