incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Waterhouse <Simon.Waterho...@eu.citrix.com>
Subject RE: [jira] [Created] (CLOUDSTACK-1043) Add AWS Style NIC support
Date Wed, 23 Jan 2013 18:19:31 GMT
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.Xu@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:jira@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
Mime
View raw message