cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: Functional Specification for the multiple IPs per NIC
Date Wed, 30 Jan 2013 04:21:34 GMT
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.Vittal@citrix.com>
wrote:

>
>
>On 1/29/13 8:23 AM, "Jayapal Reddy Uradi" <jayapalreddy.uradi@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.uradi@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.Vittal@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.Prateek@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.uradi@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.Vittal@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.uradi@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.Vittal@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.Xu@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.uradi@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:jlk@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.kannan@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:jlk@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.uradi@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.Vittal@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"
>>> > >>> >> >> > >>> <jlk@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.uradi@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
>>> > >>> >> >
>>> > >>> >
>>> > >>
>>> > >
>>
>


Mime
View raw message