Thanks,
Jayapal
-Original Message-
From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
Sent: Friday, February 15, 2013 9:12 AM
To: cloudstack-dev@incubator.apache.org
Cc: Anthony Xu
Subject: Re: Functional Specification for the multiple IPs per NIC
Jayapal,
Vmops
: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
Sent: Wednesday, January 30, 2013 9:52 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Functional Specification for the multiple IPs per NIC
Jayapal,
We should not create multiple APIs for diff outputs, when a param can give
you
@incubator.apache.org
Subject: Re: Functional Specification for the multiple IPs per NIC
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
addreses.
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
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
: 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
: 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
: 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
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
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
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
: 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
-
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
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
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
: 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
[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
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
Replies inline
-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
-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Tuesday, December 18, 2012 10:39 AM
To: CloudStack DeveloperList
Subject: Re: Functional Specification for the multiple IPs per NIC
Sorry, not sure why cloud-init is being clubbed into this feature.
I
...@backbonetechnology.com
wrote:
-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Tuesday, December 18, 2012 10:39 AM
To: CloudStack DeveloperList
Subject: Re: Functional Specification for the multiple IPs per NIC
Sorry, not sure why cloud-init is being clubbed
-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Tuesday, December 18, 2012 10:50 AM
To: CloudStack DeveloperList
Subject: Re: Functional Specification for the multiple IPs per NIC
Yes, that is a mere matter of updating the metadata. How the vm wishes
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
:)
-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
, 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
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
: 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
-
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
)
The workflow is similar for shared net
Does it make sense?
Hari
-Original Message-
From: Kelcey Damage (BT) [mailto:kel...@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
...@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
-Original Message-
From: Hari Kannan [mailto:hari.kan...@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
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
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
This is a prime example where guest scripts make sense for automating the
interface alias creation. I still think I'm missing something however, does
this include a new fetch IP API?
Also the 30 IP limit seems out of place, when I can go in right now and give
any guest VM 256+ interface
I forgot to add...
I second the notion that Basic Networking should be supported. I think this
feature targets basic more so anyways. With basics single network, direct
public IPs, managing aliases would allow far more flexibility to the platform.
Especially any one trying to host an SSL
Good point, there…maybe what we need here is to beef up the password server
idea to provide a standardized conduit to get info down to a VM. Similar to
EC2's user-data.
Data I could see this framework providing:
* System passwords
* Additional IPs (so need to be able to return data sets,
Agreed, this sounds like a good direction to go, and would also fill the role
of 'guest agents(VMware tools, etc) as this would handle the standard use cases.
+1
I hope more people get in on this discussion.
Sent from my iPhone
On Dec 15, 2012, at 12:55 PM, John Kinsella j...@stratosec.co
On Sat, Dec 15, 2012 at 3:55 PM, John Kinsella j...@stratosec.co wrote:
Good point, there…maybe what we need here is to beef up the password server
idea to provide a standardized conduit to get info down to a VM. Similar to
EC2's user-data.
Data I could see this framework providing:
*
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
Just to be clear, this feature is to simply track multiple IPs in the ui/db
correct?
There is no mechanism to prevent an existing tenant from creating up aliases on
their subnet. So currently users can manually setup all the IPs they want in
guest VMs.
Sent from my iPhone
On Dec 14, 2012, at
40 matches
Mail list logo
