Hi Chiradeep. Thanks for the review comments.
I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal > -----Original Message----- > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > Sent: Monday, January 28, 2013 1:05 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Functional Specification for the multiple IPs per NIC > > I didn't notice the API specification before in the FS. > The verb 'associate' is used with the public ip (for static nat), so it will > introduce confusion. I prefer "add" or "assign" > Similarly, 'unassociate' doesn't make any sense > > Also, why insist on 'secondary' in the API? A nic cannot be created without > any ip addresses (at least currently), so I would leave out the 'secondary' > part > in the API as well. > > Last, the instance meta-data makes available the primary ip, the secondary > ips should be made available as well. > See > http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter- > instanceda > ta.html#instancedata-data-categories > > On 1/18/13 3:40 AM, "Abhinandan Prateek" > <abhinandan.prat...@citrix.com> > wrote: > > >Jayapal, > > > > The FS seems to be updated with the feedback received on the forum, > >I guess you can start implementation. > > > >-abhi > > > >On 18/01/13 4:33 PM, "Jayapal Reddy Uradi" > ><jayapalreddy.ur...@citrix.com> > >wrote: > > > >>Update the FS with the below discussions. > >> > >>Please find updated FS below. > >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a > dd > >>res > >>s > >>+per+NIC > >> > >>Thanks, > >>Jayapal > >> > >>> -----Original Message----- > >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > >>> Sent: Thursday, January 17, 2013 12:51 PM > >>> To: CloudStack DeveloperList > >>> Subject: Re: Functional Specification for the multiple IPs per NIC > >>> > >>> I hope we consider the case when the ip is removed from the nic > >>>while there is a PF rule to that ip. > >>> > >>> On 1/16/13 9:10 PM, "Jayapal Reddy Uradi" > >>><jayapalreddy.ur...@citrix.com> > >>> wrote: > >>> > >>> >Hi Chiradeep, > >>> > > >>> >Now the VM NIC will have multiple IPs so for creating PF for > >>> >secondary ip address we will pass VM id and (optional argument) VM > >>> >ip address > >>>to > >>> >the API. > >>> >When VM ip address is passed it checks the whether the ip belongs > >>> >to the VM or not and configures the PF for the VM IP address. > >>> > > >>> >When VM ip address argument is not passed to the API then it works > >>> >in older way. > >>> >When VM NIC has NO secondary ip address also we can pass VM id and > >>> >VM primary ip address to VM ipaddress argument to API to configure > PF. > >>> > > >>> >Thanks, > >>> >Jayapal > >>> > > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > >>> >> Sent: Thursday, January 17, 2013 1:45 AM > >>> >> To: CloudStack DeveloperList > >>> >> Subject: Re: Functional Specification for the multiple IPs per > >>> >> NIC > >>> >> > >>> >> Note also that the createPortForwardingRule API takes a vm id and > >>> >>network id, based on the assumption of a single ip per NIC. This > >>> >>may need an additional parameter of ip (or make the vm id optional). > >>> >> > >>> >> On 1/15/13 9:35 AM, "Anthony Xu" <xuefei...@citrix.com> wrote: > >>> >> > >>> >> >Thanks for bringing this up, > >>> >> > > >>> >> >For security group, we may need to handle following things, > >>> >> > > >>> >> >As you mentioned, > >>> >> >Anti-spoofing rules need to be updated, when secondary IP is > >>> >> >associate/dissociate to NIC. > >>> >> > > >>> >> >And > >>> >> >Security group rule can base on cidr and it can base on > >>> >> >account/security group, For example a security group rule can > >>> >> >allow all VMs in another account/security group to access VMs in > >>> >> >this security group. > >>> >> > > >>> >> >In this case, > >>> >> > > >>> >> >When secondary IP is associate/dissociate to NIC. The related > >>> >> >security group rule based on account/security group need to be > >>> >> >resent to reflect the IP change in this security group. > >>> >> > > >>> >> > > >>> >> > > >>> >> >Anthony > >>> >> > > >>> >> > > >>> >> > > >>> >> >> -----Original Message----- > >>> >> >> From: Jayapal Reddy Uradi > >>> >> >> [mailto:jayapalreddy.ur...@citrix.com] > >>> >> >> Sent: Tuesday, January 15, 2013 5:17 AM > >>> >> >> To: cloudstack-dev@incubator.apache.org > >>> >> >> Subject: RE: Functional Specification for the multiple IPs per > >>>NIC > >>> >> >> > >>> >> >> Please find the updated FS in below link. > >>> >> >> > >>> >> > >>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a > >>> d > >>> >> >> dr > >>> >> >> ess+per+NIC > >>> >> >> > >>> >> >> I want to discuss the MIPN case for shared networks. > >>> >> >> > >>> >> >> I observed VM specific security groups iptables rules in basic > >>> >> >> zone, in which we are allowing egress traffic from the guest > >>> >> >> VM primary > >>> >> >> (dhcp) address only. > >>> >> >> If we add another IP to the NIC we should update the security > >>> >> >> groups to allow the egress traffic from the new ip. > >>> >> >> > >>> >> >> Example Current rule: It allows traffic from the i-2-3 VM's > >>> >> >> 10.147.41.239 IP only. > >>> >> >> 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 > >>> >> >> 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 > >>>--physdev-is- > >>> >> >> bridged > >>> >> >> > >>> >> >> We should update security group rules each time we associate > >>> >> >> secondary IP to NIC. > >>> >> >> > >>> >> >> Please let me know if you have any comments or suggestion for > >>> >> >> the above . > >>> >> >> > >>> >> >> Thanks, > >>> >> >> Jayapal > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -----Original Message----- > >>> >> >> > From: John Kinsella [mailto:j...@stratosec.co] > >>> >> >> > Sent: Wednesday, December 19, 2012 10:59 PM > >>> >> >> > To: cloudstack-dev@incubator.apache.org > >>> >> >> > Subject: Re: Functional Specification for the multiple IPs > >>> >> >> > per NIC > >>> >> >> > > >>> >> >> > 'morning Hari. I can think of at least one use case where > >>> >> >> > allowing > >>> >> >> the "user" > >>> >> >> > to specify the IP would be required - when migrating an IP > >>> >> >> > from one > >>> >> >> CAP to > >>> >> >> > ACS or from one VM to another. > >>> >> >> > > >>> >> >> > Anyways - I think what the real answer to your question is > >>>would > >>> >> >> > be > >>> >> >> to have > >>> >> >> > a granular security model around the API calls. At that > >>> >> >> > point you > >>> >> >> could specify > >>> >> >> > what users/groups have the ability to assign specific IPs to > >>> >> >> > a > >>> >> >> specific instance. > >>> >> >> > So I'd vote to implement for now, and attack a granular api > >>> >> >> > security > >>> >> >> model > >>> >> >> > sooner rather than later. > >>> >> >> > > >>> >> >> > John > >>> >> >> > > >>> >> >> > On Dec 18, 2012, at 4:15 PM, Hari Kannan > >>> >> >> > <hari.kan...@citrix.com> > >>> >> >> > wrote: > >>> >> >> > > >>> >> >> > > Regarding " User can specify the IP address from the > >>> >> >> > > guest subnet > >>> >> >> if > >>> >> >> > > not CS picks the IP from the guest subnet " comment in the > >>> >> >> > > FS > >>> >> >> > > > >>> >> >> > > I don't see a need to do this - because, it is a shared > >>> >> >> > > network, > >>> >> >> how > >>> >> >> > > does he know what is used up and what is not? So, he could > >>> >> >> > > go > >>> >> >> through > >>> >> >> > > a sequence of steps only to get an error message back that > >>> >> >> > > it is > >>> >> >> not > >>> >> >> > > possible (and keep doing this until success) > >>> >> >> > > > >>> >> >> > > One possibility is telling him what is available - it may > >>> >> >> > > not be a > >>> >> >> big > >>> >> >> > > deal to reveal the used/unused IPs in isolated network > >>> >> >> > > (although it would be hard to show from a large CIDR what > >>> >> >> > > is used/available), > >>> >> >> but > >>> >> >> > > we wont even be able to tell him what is used/unused in a > >>> >> >> > > shared network - > >>> >> >> > > > >>> >> >> > > Any thoughts? > >>> >> >> > > > >>> >> >> > > Hari Kannan > >>> >> >> > > > >>> >> >> > > -----Original Message----- > >>> >> >> > > From: John Kinsella [mailto:j...@stratosec.co] > >>> >> >> > > Sent: Tuesday, December 18, 2012 10:36 AM > >>> >> >> > > To: cloudstack-dev@incubator.apache.org > >>> >> >> > > Subject: Re: Functional Specification for the multiple IPs > >>>per > >>> >> >> > > NIC > >>> >> >> > > > >>> >> >> > > Is there any logic behind 30? At some point, we're going > >>> >> >> > > to > >>>be > >>> >> >> asked, > >>> >> >> > > so I'd like to have a decent answer. :) > >>> >> >> > > > >>> >> >> > > On the rest of this, I'd like to get some level of > >>> >> >> > > consensus on the > >>> >> >> design. > >>> >> >> > What looks best to me: > >>> >> >> > > * Improve UserData/CloudInit support in CloudStack (I'm > >>> >> >> > > willing to work on this, consider it important) - allow > >>> >> >> > > expiration of data, > >>> >> >> wider > >>> >> >> > > variety of data supported > >>> >> >> > > * Create the multi-IPs-per-NIC code to get IPs via > >>> >> >> > > CloudInit (Need > >>> >> >> to > >>> >> >> > > think through Windows equivalent) > >>> >> >> > > * Update the password changing script to use CloudInit > >>> >> >> > > > >>> >> >> > > Thoughts? Or Jayapal have you already started work on the > >>> >> >> > > multi-IP > >>> >> >> > feature? > >>> >> >> > > > >>> >> >> > > On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi > >>> >> >> > <jayapalreddy.ur...@citrix.com> wrote: > >>> >> >> > > > >>> >> >> > >> Regarding IP limit, it can be made as configurable using > >>> >> >> > >> global > >>> >> >> settings and > >>> >> >> > default value will be 30. > >>> >> >> > >> > >>> >> >> > >> > >>> >> >> > >> Thanks, > >>> >> >> > >> Jayapal > >>> >> >> > >> > >>> >> >> > >>> -----Original Message----- > >>> >> >> > >>> From: Chiradeep Vittal > >>> >> >> > >>> [mailto:chiradeep.vit...@citrix.com] > >>> >> >> > >>> Sent: Monday, December 17, 2012 12:59 PM > >>> >> >> > >>> To: CloudStack DeveloperList > >>> >> >> > >>> Subject: Re: Functional Specification for the multiple > >>> >> >> > >>> IPs per > >>> >> >> NIC > >>> >> >> > >>> > >>> >> >> > >>> In basic/shared networks the allocation is bounded by > >>> >> >> > >>> what is already > >>> >> >> > >>> "used- up". To prevent tenants from hogging all the > >>> >> >> > >>> available ips, there needs to be limits. > >>> >> >> > >>> > >>> >> >> > >>> On 12/15/12 8:38 AM, "John Kinsella" <j...@stratosec.co> > >>>wrote: > >>> >> >> > >>> > >>> >> >> > >>>> I'd remove the limitation of having 30 IPs per interface. > >>> >> >> > >>>> Modern OSes can support way more. > >>> >> >> > >>>> > >>> >> >> > >>>> Why no support for basic networking? I can see a small > >>> >> >> > >>>> hosting provider with a basic setup wanting to manage > >>> >> >> > >>>> web > >>> servers... > >>> >> >> > >>>> > >>> >> >> > >>>> John > >>> >> >> > >>>> > >>> >> >> > >>>> On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi > >>> >> >> > >>>> <jayapalreddy.ur...@citrix.com> wrote: > >>> >> >> > >>>> > >>> >> >> > >>>>> Hi All, > >>> >> >> > >>>>> > >>> >> >> > >>>>> Current guest VM by default having one NIC and one IP > >>> >> >> > >>>>> address > >>> >> >> > assigned. > >>> >> >> > >>>>> If your wants extra IP for the guest VM, there no > >>> >> >> > >>>>> provision > >>> >> >> from > >>> >> >> > >>>>> the CS. > >>> >> >> > >>>>> > >>> >> >> > >>>>> Using multiple IP address per NIC feature CS can > >>>associate > >>> >> >> > >>>>> IP address for the NIC, user can take that IP and > >>> >> >> > >>>>> assign it to > >>> >> >> the VM. > >>> >> >> > >>>>> > >>> >> >> > >>>>> Please find the FS for the more details. > >>> >> >> > >>>>> > >>> >> >> > >>>>> > >>> >> >> > >>>>> > >>> >> >> > > >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+ > >>> >> >> > IP > >>> >> >> > >>>>> + > >>> >> >> > >>>>> a > >>> >> >> > >>> dd > >>> >> >> > >>>>> res > >>> >> >> > >>>>> s+per+NIC > >>> >> >> > >>>>> > >>> >> >> > >>>>> Please provide your comments on the FS. > >>> >> >> > >>>>> > >>> >> >> > >>>>> > >>> >> >> > >>>>> Thanks, > >>> >> >> > >>>>> jayapal > >>> >> >> > >>>> > >>> >> >> > >>>> Stratosec - Secure Infrastructure as a Service > >>> >> >> > >>>> o: 415.315.9385 > >>> >> >> > >>>> @johnlkinsella > >>> >> >> > >>>> > >>> >> >> > >> > >>> >> >> > >> > >>> >> >> > > > >>> >> >> > > Stratosec - Secure Infrastructure as a Service > >>> >> >> > > o: 415.315.9385 > >>> >> >> > > @johnlkinsella > >>> >> >> > > > >>> >> >> > > > >>> >> >> > > >>> >> >> > Stratosec - Secure Infrastructure as a Service > >>> >> >> > o: 415.315.9385 > >>> >> >> > @johnlkinsella > >>> >> > > >>> > > >> > >
