Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Tue, 18 Dec 2012 17:56:15 -0800
Subject: Re: Functional Specification for the multiple IPs per NIC
Thread-Topic: Functional Specification for the multiple IPs per NIC
Thread-Index: Ac3djAgYvs18ELBfTMepdl6HQ99sdA==
Message-ID: <CCF65CA1.3C70E%chiradeep.vittal@citrix.com>
In-Reply-To: <030601cddd82$15db6840$419238c0$@backbonetechnology.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I would actually propose that the feature is more on parity with AWS's
'private' ip feature.
The relevant APIs are:
$API_DOCS_URL-AssignPrivateIpAddresses.html
$API_DOCS_URL-UnassignPrivateIpAddresses.html
$API_DOCS_URL-DescribeNetworkInterfaces.html
$API_DOCS_URL-CreateNetworkInterface.html

This kind of ties into [1] and [2] and [3]
As for Hari's question below, you could always modify the listNetwork API
to return the list of available ip addresses. Of course this list is
ephemeral, so you may still fail after choosing one of these addresses.


[1] http://markmail.org/thread/vqoso6p7ttvh7z4c
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-645
[3] http://markmail.org/thread/66b4wzbofggeozgl

On 12/18/12 4:45 PM, "Kelcey Damage (BT)" <kelcey@backbonetechnology.com>
wrote:

>Kind of yes. In advanced networking the user owns the whole subnet of the
>isolated network... so this does not matter.
>
>In shared you are correc its more tricky. The goal I would envision is a
>dynamically provided IP that has infinite DHCP lease.
>
>Now we are in the realm of what John was discussing.
>
>The basic spec for MIPN is only to get CS to track the request for
>additional private IP, nothing more.
>
>-kd
>
>
>
>>-----Original Message-----
>>From: Hari Kannan [mailto:hari.kannan@citrix.com]
>>Sent: Tuesday, December 18, 2012 4:32 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: RE: Functional Specification for the multiple IPs per NIC
>>
>>Hi Kelcey,
>>
>>The question is not whether CS knows this or not - the question is how
>>does
>a
>>"user" know it..
>>
>>Here is the workflow I envision -
>>
>>User requests a VM
>>                As part of this, he requests one or more isolated
>>networks
>User
>>optionally could add more networks for the VM (multiple nics feature in
>>Campo) User "acquires guest IPs" (new feature)
>>                Specifies the network he wants
>>                Optionally specifies the ip address (or we automatically
>assign from
>>the CIDR) <--------- not sure if we need to let him provide an IP - this
>>is
>the
>>question Out of band (manual) he ifconfigs the acquired guest IP on a
>>{VM,NIC} User can "acquire IP" (public ip) like he does today
>>                Associate the public IP with the guest IP (CS does the
>>NAT)
>"release"
>>public IP, if acquired "release" guest IP, if acquired (cannot release if
>still
>>mapped to a public IP)
>>
>>The workflow is similar for shared net
>>
>>Does it make sense?
>>
>>Hari
>>-----Original Message-----
>>From: Kelcey Damage (BT) [mailto:kelcey@backbonetechnology.com]
>>Sent: Tuesday, December 18, 2012 4:22 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: RE: Functional Specification for the multiple IPs per NIC
>>
>>All networks in CS shared, isolated, basic track assigned IPs in the
>database, so
>>yes, we can know what is in use if provisioned by CS. The key here is to
>use the
>>same tables to assign auxiliary IPs at the users request to individual
>instances.
>>
>>The responsibility is still on the  VM administrator to take the new IP
>provided
>>by CS and configure it in the correct VM.
>>
>>This is a start, and John and I have been discussing using
>>CloudInit/Guest
>>management to further automate this process.
>>
>>-kd
>>
>>>-----Original Message-----
>>>From: Hari Kannan [mailto:hari.kannan@citrix.com]
>>>Sent: Tuesday, December 18, 2012 4:15 PM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: Functional Specification for the multiple IPs per NIC
>>>
>>>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
>>
>
>