Concur with Kelcey. Why is this a concern of MIPN? As long as the metadata includes all ips assigned to the nic, cloud-init can be modified at any point in time to take advantage of this metadata. It is like saying AWS maintains cloud-init and changes it in lockstep to any new thing they add to the instance metadata.
> -----Original Message----- > From: Kelcey Damage (BT) [mailto:kel...@backbonetechnology.com] > Sent: Tuesday, December 18, 2012 11:17 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Functional Specification for the multiple IPs per NIC > > OK, > > I must have missed something, or made an invalid assumption. I thought the > MIPN could be handled by metadata and not need to be re-written. > > I also figured guest management could be handled separate and make use of > the metadata. > > If it requires a re-write down the road for what we are actively discussing > now, then it seems inefficient. Could we not find some sort of hybrid > solution, that would allow MIPN to move forward, but not potentially hinder > plans for CloudInit/guest management? > > Thanks > > >-----Original Message----- > >From: John Kinsella [mailto:j...@stratosec.co] > >Sent: Tuesday, December 18, 2012 11:05 AM > >To: cloudstack-dev@incubator.apache.org > >Subject: Re: Functional Specification for the multiple IPs per NIC > > > >Well, not quite. The question I might be clearly asking is: Do we build > MIPN > >now with intention to rewrite, or do we update the metadata/user-data > >code first? > > > >On Dec 18, 2012, at 10:58 AM, "Kelcey Damage (BT)" > ><kel...@backbonetechnology.com> > > wrote: > > > >> I guess we are all in agreement them :) > >> > >>> -----Original Message----- > >>> From: John Kinsella [mailto:j...@stratosec.co] > >>> Sent: Tuesday, December 18, 2012 10:56 AM > >>> To: cloudstack-dev@incubator.apache.org > >>> Subject: Re: Functional Specification for the multiple IPs per NIC > >>> > >>> cloud-init's (more specifically, user-data) being mentioned because > >>> I see > >> an > >>> ongoing need of wanting to get instance-specific data into an instance. > >>> > >>> So, we can tweak meta-data to add support for multi-IP per NIC > >>> (MIPN), or we can take a step back and talk through how the metadata > >>> side of things could be beefed up before implementing MIPN to > >>> minimize > >future rewriting. > >>> > >>> The result is better compatibility with AWS, better security, and > >>> more standardized functionality going forward. > >>> > >>> Yes, this is a separate feature than the MIPN by itself. I meant to > >>> call > >> that out > >>> in my first bullet, apologies. > >>> > >>> John > >>> > >>> On Dec 18, 2012, at 10:39 AM, Chiradeep Vittal > >>> <chiradeep.vit...@citrix.com> > >>> wrote: > >>> > >>>> Sorry, not sure why cloud-init is being clubbed into this feature. > >>>> > >>>> The secondary ips can be made available through the usual metadata > >>> scheme. > >>>> > >>>> On 12/18/12 10:36 AM, "John Kinsella" <j...@stratosec.co> wrote: > >>>> > >>>>> 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 > >>>>>>>>> +I > >>>>>>>>> P+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 > >> > >> > >> > > > >Stratosec - Secure Infrastructure as a Service > >o: 415.315.9385 > >@johnlkinsella >