Jayapal, We should not create multiple APIs for diff outputs, when a param can give you control over output from an existing API.
-abhi On 30/01/13 12:58 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: > > >On 1/29/13 8:23 AM, "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com> >wrote: > >> >>listNicIps/listNicSecondaryIps API lists the only the secondary ip >>addresses . >>do we need to list the both primary and secondary ip addresses in the >>list API ? > >Yes. Why do we need a listNicSecondaryIps API? Why not just enhance >listNics? > >> >>The current load balancing 'assignToLoadBalancerRule' API takes list >>virtualmachineids argument and configures the LB for primary IP >>addresses. >> >>To configure the LB for secondary ip addresses adding an optional >>argument to API. >>The optional argument vmIpaddrs takes the list of ip addresses of the >>corresponding virtualmachineids vm list parameter. >>When vmipaddrs is not passed LB is configured for the VMs primary ip >>addreses. > >I think this can be handled with an enhancement separate from this >feature. Let us leave the API as is. > >> >> >>Thanks, >>Jayapal >> >> >> >>> -----Original Message----- >>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] >>> Sent: Monday, January 28, 2013 9:15 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: Functional Specification for the multiple IPs per NIC >>> >>> 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 >>> > >>> >> > >>> > >>> > >>> > >> >>> > > >> >
