rnal IP Address
>Providers or use internal database to provide allocation.
>
>I hope I captured the essence of where we are with this?
>-Soheil
>
>
>From: Murali Reddy [murali.re...@citrix.com]
>Sent: Wednesday, August 07, 2013 7:43 AM
>
with this?
-Soheil
From: Murali Reddy [murali.re...@citrix.com]
Sent: Wednesday, August 07, 2013 7:43 AM
To: dev@cloudstack.apache.org
Subject: Re: IP Address Allocation
On 07/08/13 1:40 AM, "Alex Huang" wrote:
>I'll say it's a bad
; -----Original Message-
>> From: Soheil Eizadi [mailto:seiz...@infoblox.com]
>> Sent: Tuesday, August 6, 2013 11:54 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: IP Address Allocation
>>
>> Agree that the IP Address allocation is differ
to plug into: orchestration and actual provisioning. So the NetworkGuru
> forms the URI for isolation and then it has code at the hypervisor side to
> resolve the URI to something that the hypervisor can understand.
>
> --Alex
>
>> -Original Message-
>> Fro
6, 2013 11:54 AM
> To: dev@cloudstack.apache.org
> Subject: RE: IP Address Allocation
>
> Agree that the IP Address allocation is different than the DHCP and DNS
> service offered by the NetworkElements.
>
> The third party NetworkGurus just reference the standard
@cloudstack.apache.org
Subject: RE: IP Address Allocation
Can this be done on system VMs as well? I see that its targeted for the guests,
if there is a way to abstract and apply ip address on any component - it would
certainly make ACS much more flexible than it is now.
> -Original Mess
ation) without implementing new code to support
them.
-Soheil
From: Alex Huang [alex.hu...@citrix.com]
Sent: Tuesday, August 06, 2013 11:27 AM
To: Chiradeep Vittal; dev@cloudstack.apache.org
Subject: RE: IP Address Allocation
We can either break NetworkManager
ox.com]
> Sent: Tuesday, August 06, 2013 2:29 PM
> To: dev@cloudstack.apache.org
> Subject: RE: IP Address Allocation
>
> We can define a third type of element for IP Address Allocation, let me look
> at the code and see is there is standard base class that it can extend or we
>
Vittal [chiradeep.vit...@citrix.com]
Sent: Tuesday, August 06, 2013 11:14 AM
To: dev@cloudstack.apache.org
Cc: Alex Huang
Subject: Re: IP Address Allocation
The way the gurus are consulted for network design and reservation makes
it difficult to put this inside a guru.
However it does seem odd to put
tal
> Sent: Tuesday, August 6, 2013 11:14 AM
> To: dev@cloudstack.apache.org
> Cc: Alex Huang
> Subject: Re: IP Address Allocation
>
> The way the gurus are consulted for network design and reservation makes it
> difficult to put this inside a guru.
> However it does see
m]
>Sent: Tuesday, August 06, 2013 3:24 AM
>To: dev@cloudstack.apache.org
>Subject: Re: IP Address Allocation
>
>On 06/08/13 8:59 AM, "Soheil Eizadi" wrote:
>
>>One way to achieve this behavior is to have a call out in prepareNic() to
>>the NetworkEleme
, August 06, 2013 3:24 AM
To: dev@cloudstack.apache.org
Subject: Re: IP Address Allocation
On 06/08/13 8:59 AM, "Soheil Eizadi" wrote:
>One way to achieve this behavior is to have a call out in prepareNic() to
>the NetworkElements before the call to the NetworkGuru allowing the
&g
On 06/08/13 8:59 AM, "Soheil Eizadi" wrote:
>One way to achieve this behavior is to have a call out in prepareNic() to
>the NetworkElements before the call to the NetworkGuru allowing the
>NetworkElement to update the Nic Profile. In this use case the Network
>Element would suggest an IP Address.
One way to achieve this behavior is to have a call out in prepareNic() to the
NetworkElements before the call to the NetworkGuru allowing the NetworkElement
to update the Nic Profile. In this use case the Network Element would suggest
an IP Address. In the use case below the IP Address would be
14 matches
Mail list logo
