You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Murali Reddy <Mu...@citrix.com> on 2012/10/16 10:17:53 UTC
[4.1 feature RFC] Optional Public IP assignment for EIP with Basic
Zone
I am trying to change EIP semantics supported by CloudStack for 4.1 release. Today if some one deploys a basic zone with EIP service, then by default a public IP is allocated for the user VM along with private IP, and then a 1:1 NAT is established between the public IP and private IP of the user VM. In a deployment where public IP's are scarce this result in wastage of public IP. I am changing CloudStack behaviour so that cloud admin has the flexibility to enable or disable default public IP allocation for the user VM's in the basic zone with EIP service. I opened enhancement request [1] and the functional requirements are detailed at [2] please comment.
[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+IP+assignment+for+EIP+with+Basic+Zone
Re: [4.1 feature RFC] Optional Public IP assignment for EIP with
Basic Zone
Posted by Murali Reddy <Mu...@citrix.com>.
Swamy, please see inline comments
On 16/10/12 2:19 PM, "Venkata SwamyBabu Budumuru"
<ve...@citrix.com> wrote:
>Hi Murali,
>
>First of all spec is crystal clear and has all the details about what you
>are planning to do.
>
>I have the following few queries after reviewing your FS.
>
>(1) Is this enhancement made for enterprise clouds? because, I don't see
>a reason why on public clouds, tenant doesn't want public access while
>using EIP & ELB offering.
No assumptions made on enterprise cloud or public cloud for this
enhancement. This is just a mechanism to provide the flexibility to cloud
deployer. If a tenant want's public access to his VM's, he can still
acquire a public IP and can establish 1:1 NAT.
>
>(2) As per my understanding, opting for EIP/ELB is possible only at the
>time of zone creation which is in the hands of cloud admin who opts for
>this option only after deciding whether he want to conserve public IPs or
>not?
>
>Rather, Isn't it a good idea to provide the flexibility of associate or
>disassociate IP to the end user ? I mean how about adding logic to
>associate and disassociate (including the one with is_system=1) along
>with the above
>mentioned behavior?
IIUIC, your concern is user should still have the ability to acquire and
release public IP's in the basic zone? I am not changing this semantics,
user can still acquire a public IP and assign or re-assign the public IP
to any of the VM's he owns.
>
>(3) After zone creation, if admin wants to move from an offering that has
>eip_associate_public_ip=1 to eip_associate_public_ip=0 or vice versa then
>do we have that option?
No. Updating the network from offering with 'AssociatePublicIP' capability
to different offering without AssociatePublicIP is not permitted. I will
call that out in the specification.
>
>(4) how about masking this option (associatePubIP) OFF for Isolated by
>default in UI
Sure. Option to set 'associatePubIP' should only be seen in the UI only
for guest traffic type 'shared'.
>(5) As per my understanding, we don't have any impact on ec2 API calls
>due to this change. correct me if you see anything.
In general EC2 api calls should not be impacted. Not sure if it will break
any EC2 API integration due to EIP semantics change. Can anyone comment on
EC2 API use on basic zone with EIP service, are there any assumption made
that VM gets the public IP by default?
>
>Thanks,
>SWAMY
>
>-----Original Message-----
>From: Murali Reddy [mailto:Murali.Reddy@citrix.com]
>Sent: Tuesday, October 16, 2012 1:48 PM
>To: cloudstack-dev@incubator.apache.org
>Subject: [4.1 feature RFC] Optional Public IP assignment for EIP with
>Basic Zone
>
>I am trying to change EIP semantics supported by CloudStack for 4.1
>release. Today if some one deploys a basic zone with EIP service, then by
>default a public IP is allocated for the user VM along with private IP,
>and then a 1:1 NAT is established between the public IP and private IP of
>the user VM. In a deployment where public IP's are scarce this result in
>wastage of public IP. I am changing CloudStack behaviour so that cloud
>admin has the flexibility to enable or disable default public IP
>allocation for the user VM's in the basic zone with EIP service. I
>opened enhancement request [1] and the functional requirements are
>detailed at [2] please comment.
>
>[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
>[2]
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+IP+
>assignment+for+EIP+with+Basic+Zone
>
>
RE: [4.1 feature RFC] Optional Public IP assignment for EIP with
Basic Zone
Posted by Venkata SwamyBabu Budumuru <ve...@citrix.com>.
Hi Murali,
First of all spec is crystal clear and has all the details about what you are planning to do.
I have the following few queries after reviewing your FS.
(1) Is this enhancement made for enterprise clouds? because, I don't see a reason why on public clouds, tenant doesn't want public access while using EIP & ELB offering.
(2) As per my understanding, opting for EIP/ELB is possible only at the time of zone creation which is in the hands of cloud admin who opts for this option only after deciding whether he want to conserve public IPs or not?
Rather, Isn't it a good idea to provide the flexibility of associate or disassociate IP to the end user ? I mean how about adding logic to associate and disassociate (including the one with is_system=1) along with the above
mentioned behavior?
(3) After zone creation, if admin wants to move from an offering that has eip_associate_public_ip=1 to eip_associate_public_ip=0 or vice versa then do we have that option?
(4) how about masking this option (associatePubIP) OFF for Isolated by default in UI
(5) As per my understanding, we don't have any impact on ec2 API calls due to this change. correct me if you see anything.
Thanks,
SWAMY
-----Original Message-----
From: Murali Reddy [mailto:Murali.Reddy@citrix.com]
Sent: Tuesday, October 16, 2012 1:48 PM
To: cloudstack-dev@incubator.apache.org
Subject: [4.1 feature RFC] Optional Public IP assignment for EIP with Basic Zone
I am trying to change EIP semantics supported by CloudStack for 4.1 release. Today if some one deploys a basic zone with EIP service, then by default a public IP is allocated for the user VM along with private IP, and then a 1:1 NAT is established between the public IP and private IP of the user VM. In a deployment where public IP's are scarce this result in wastage of public IP. I am changing CloudStack behaviour so that cloud admin has the flexibility to enable or disable default public IP allocation for the user VM's in the basic zone with EIP service. I opened enhancement request [1] and the functional requirements are detailed at [2] please comment.
[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+IP+assignment+for+EIP+with+Basic+Zone
Re: [4.1 feature RFC] L4-L7 network services in shared network
Posted by Murali Reddy <Mu...@citrix.com>.
On 19/10/12 9:32 PM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>Ok, you want to just re-implement elements and rules w/o changing the
>network configuration. You should probably confirm with Alex, because
>initially Implemented/Setup state were reflecting network configuration
>state, not the state of the elements and rules in it. The network in Setup
>state was going through Prepare() phase, and during this phase network
>elements were implemented.
Alex,
Could you please help me understand the goal of having separate 'Setup'
and 'Implemented' states for the network? Is there a correlation between
the network state and if the network has the L4-L7 services implemented? I
see that for 'isolated networks' which has L4-L7 services by default,
network goes through the Allocated->Implementing->Implemented states,
where as 'shared networks' with out L4-L7 services is setup to be in
'Setup' state.
I am enhancing CloudStack to orchestrate full set of L4-L7 services for
'shared networks' in the advanced zone, for which I need network
operations like implement, shutdown to be called up by both 'Network
Guru'and 'Network Elements'. In my understanding, 'Implemented' state of
network reflects that network elements have implemented the network to
provide L4-L7 services. So, I am wondering if the 'shared network' with
L4-L7 services should go through the Implementing->Implemented states
rather than being in 'Setup' state.
>
>Murali, could you also tell why we need Shared network to go through
>Shutdown/Implementing/Implemented phase? What is the use case for it? For
>isolated network we just needed it in order to GC the network, so the
>guest Vlan can be released if there are no user vms in the network.
Alena,
Admin can provision and de-provision 'shared networks' in the advanced
zone. When shared network with L4-L7 is provisioned, then backend network
elements which provide the services to the network need to implement
network or shutdown the network (typical operation in implement phase on
the back end provider in this case SRX, NetScaler, F5, Brocade etc would
be to set up the VLAN and assign a subnet IP or gateway IP of the shared
network on the device). Similarly when network is shutdown the VLAN and
the IP's need to be removed from the device.
Thanks,
Murali
>
>Thank you,
>Alena.
>
>On 10/19/12 6:24 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>
>>
>>
>>
>>On 19/10/12 5:46 AM, "Alena Prokharchyk" <Al...@citrix.com>
>>wrote:
>>
>>>On 10/18/12 4:59 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>>>
>>>>On 17/10/12 10:42 PM, "Alena Prokharchyk"
>>>><Al...@citrix.com>
>>>>wrote:
>>>>
>>>>>Murali, some comments:
>>>>>
>>>>>1) "During network design phase of network creation, 'Direct network
>>>>>Guru' which designs the shared networks shall setup the network to be
>>>>>in
>>>>> Network.State.Allocated if shared network is being created in
>>>>>advanced
>>>>>zone and with L4-L7 services enabled"
>>>>>
>>>>>Can you explain why? Allocated state means that the Vlan and CIDR for
>>>>>the
>>>>>network will be re-calculated on every network imeplement. Setup state
>>>>>means that the Vlan will stay with the network for its lifecycle, as
>>>>>well
>>>>>as the network CIDR. If you are not planning to recalculate the CIDR
>>>>>on
>>>>>each network re-implement, then Setup is your initial and the only one
>>>>>state.
>>>>>
>>>>>If the only one thing you want to do during this face - prepare your
>>>>>external devices - then you should use prepare() instead (we call it
>>>>>when
>>>>>setup the network)
>>>>
>>>>
>>>>I agree that 'Allocated' state is wrong here. I don¹t want CIDR to be
>>>>recalculated. I just want to force the 'shared network' in the advanced
>>>>zone to go through the complete implement phase. Right now, shared
>>>>network
>>>>are set to be in 'Setup' state by direct network guru. Implement
>>>>network
>>>>phase skips the back end implementation (i.e. implement operation on
>>>>network elements) when network state is 'Setup'. I want to model life
>>>>cycle of 'shared network' with L4-L7 service just as isolated network.
>>>>Except for the fact that network is shared by multiple accounts, shared
>>>>network with L4-L7 services is really same as isolated network w.r.t
>>>>life
>>>>cycle of the network and how the rules are applied.
>>>>
>>>>I can set the state to be 'Setup' but want the shared network with
>>>>L4-L7
>>>>service to go through implement phase. Does having state transition
>>>>from
>>>>State.Setup to State.Implemented on Event.ImplementNetwork make sense?
>>>
>>>Murali, could you please give more details on what exactly you want to
>>>introduce in Implement phase for Shared networks? Because looking at the
>>>code right now, I see that in
>>>
>>>* DirectNetworkGuru (responsible for Shared networks)- does nothing in
>>>implement()
>>>* ExternalGuestNetworkGuru (responsible for Isolated network), -
>>>recalculate vlan and cidr for the network in implement()
>>>
>>>
>>>I assume all you want to do - re-implement the elements and network
>>>rules
>>>w/o changing the network configuration? That's something that
>>>RestartNetwork does (re-implements all the network elements and the
>>>rules
>>>w/o changing the network state and config; both Isolated and Shared
>>>networks can be restarted)
>>>
>>>-Alena.
>>
>>Ok. Let me elaborate a bit. So the network in CloudStack is handled by
>>two
>>entities. Network design (L2-L3) is handled by 'Network Guru' and network
>>services (L4-L7) are handled by 'Network element'. Network operations
>>like
>>implement, shutdown, restart, destroy should go through operations on
>>both
>>network guru and network element as well. Since the 'shared network' did
>>not have any L4-L7 services, network operations were implemented for
>>shared network to go through corresponding operation on network guru
>>only.
>>Now if we have L4-L7 services in the 'shared network', network operations
>>like implement, shutdown, restart etc should go through corresponding
>>actions on network guru, and network element as well. For e.g. I see that
>>implementNetwork() operation in the network manager, does NOT end up
>>invoking implementNetworkElementsAndResources() for the 'shared networks'
>>as the direct network guru says network is setup. Implement phase skips
>>the implementNetworkElementsAndResources() as network is setup.
>>
>>So, my thinking is, 'shared network' with L4-L7 services should go
>>through
>>'Implementing' and 'Implemented' sates as well.
>>
>>
>>
>>
>
>
>
Re: [4.1 feature RFC] L4-L7 network services in shared network
Posted by Alena Prokharchyk <Al...@citrix.com>.
Ok, you want to just re-implement elements and rules w/o changing the
network configuration. You should probably confirm with Alex, because
initially Implemented/Setup state were reflecting network configuration
state, not the state of the elements and rules in it. The network in Setup
state was going through Prepare() phase, and during this phase network
elements were implemented.
Murali, could you also tell why we need Shared network to go through
Shutdown/Implementing/Implemented phase? What is the use case for it? For
isolated network we just needed it in order to GC the network, so the
guest Vlan can be released if there are no user vms in the network.
Thank you,
Alena.
On 10/19/12 6:24 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>
>
>
>On 19/10/12 5:46 AM, "Alena Prokharchyk" <Al...@citrix.com>
>wrote:
>
>>On 10/18/12 4:59 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>>
>>>On 17/10/12 10:42 PM, "Alena Prokharchyk" <Al...@citrix.com>
>>>wrote:
>>>
>>>>Murali, some comments:
>>>>
>>>>1) "During network design phase of network creation, 'Direct network
>>>>Guru' which designs the shared networks shall setup the network to be
>>>>in
>>>> Network.State.Allocated if shared network is being created in advanced
>>>>zone and with L4-L7 services enabled"
>>>>
>>>>Can you explain why? Allocated state means that the Vlan and CIDR for
>>>>the
>>>>network will be re-calculated on every network imeplement. Setup state
>>>>means that the Vlan will stay with the network for its lifecycle, as
>>>>well
>>>>as the network CIDR. If you are not planning to recalculate the CIDR on
>>>>each network re-implement, then Setup is your initial and the only one
>>>>state.
>>>>
>>>>If the only one thing you want to do during this face - prepare your
>>>>external devices - then you should use prepare() instead (we call it
>>>>when
>>>>setup the network)
>>>
>>>
>>>I agree that 'Allocated' state is wrong here. I don¹t want CIDR to be
>>>recalculated. I just want to force the 'shared network' in the advanced
>>>zone to go through the complete implement phase. Right now, shared
>>>network
>>>are set to be in 'Setup' state by direct network guru. Implement network
>>>phase skips the back end implementation (i.e. implement operation on
>>>network elements) when network state is 'Setup'. I want to model life
>>>cycle of 'shared network' with L4-L7 service just as isolated network.
>>>Except for the fact that network is shared by multiple accounts, shared
>>>network with L4-L7 services is really same as isolated network w.r.t
>>>life
>>>cycle of the network and how the rules are applied.
>>>
>>>I can set the state to be 'Setup' but want the shared network with L4-L7
>>>service to go through implement phase. Does having state transition from
>>>State.Setup to State.Implemented on Event.ImplementNetwork make sense?
>>
>>Murali, could you please give more details on what exactly you want to
>>introduce in Implement phase for Shared networks? Because looking at the
>>code right now, I see that in
>>
>>* DirectNetworkGuru (responsible for Shared networks)- does nothing in
>>implement()
>>* ExternalGuestNetworkGuru (responsible for Isolated network), -
>>recalculate vlan and cidr for the network in implement()
>>
>>
>>I assume all you want to do - re-implement the elements and network rules
>>w/o changing the network configuration? That's something that
>>RestartNetwork does (re-implements all the network elements and the rules
>>w/o changing the network state and config; both Isolated and Shared
>>networks can be restarted)
>>
>>-Alena.
>
>Ok. Let me elaborate a bit. So the network in CloudStack is handled by two
>entities. Network design (L2-L3) is handled by 'Network Guru' and network
>services (L4-L7) are handled by 'Network element'. Network operations like
>implement, shutdown, restart, destroy should go through operations on both
>network guru and network element as well. Since the 'shared network' did
>not have any L4-L7 services, network operations were implemented for
>shared network to go through corresponding operation on network guru only.
>Now if we have L4-L7 services in the 'shared network', network operations
>like implement, shutdown, restart etc should go through corresponding
>actions on network guru, and network element as well. For e.g. I see that
>implementNetwork() operation in the network manager, does NOT end up
>invoking implementNetworkElementsAndResources() for the 'shared networks'
>as the direct network guru says network is setup. Implement phase skips
>the implementNetworkElementsAndResources() as network is setup.
>
>So, my thinking is, 'shared network' with L4-L7 services should go through
>'Implementing' and 'Implemented' sates as well.
>
>
>
>
Re: [4.1 feature RFC] L4-L7 network services in shared network
Posted by Murali Reddy <Mu...@citrix.com>.
On 19/10/12 5:46 AM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>On 10/18/12 4:59 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>
>>On 17/10/12 10:42 PM, "Alena Prokharchyk" <Al...@citrix.com>
>>wrote:
>>
>>>Murali, some comments:
>>>
>>>1) "During network design phase of network creation, 'Direct network
>>>Guru' which designs the shared networks shall setup the network to be in
>>> Network.State.Allocated if shared network is being created in advanced
>>>zone and with L4-L7 services enabled"
>>>
>>>Can you explain why? Allocated state means that the Vlan and CIDR for
>>>the
>>>network will be re-calculated on every network imeplement. Setup state
>>>means that the Vlan will stay with the network for its lifecycle, as
>>>well
>>>as the network CIDR. If you are not planning to recalculate the CIDR on
>>>each network re-implement, then Setup is your initial and the only one
>>>state.
>>>
>>>If the only one thing you want to do during this face - prepare your
>>>external devices - then you should use prepare() instead (we call it
>>>when
>>>setup the network)
>>
>>
>>I agree that 'Allocated' state is wrong here. I don¹t want CIDR to be
>>recalculated. I just want to force the 'shared network' in the advanced
>>zone to go through the complete implement phase. Right now, shared
>>network
>>are set to be in 'Setup' state by direct network guru. Implement network
>>phase skips the back end implementation (i.e. implement operation on
>>network elements) when network state is 'Setup'. I want to model life
>>cycle of 'shared network' with L4-L7 service just as isolated network.
>>Except for the fact that network is shared by multiple accounts, shared
>>network with L4-L7 services is really same as isolated network w.r.t life
>>cycle of the network and how the rules are applied.
>>
>>I can set the state to be 'Setup' but want the shared network with L4-L7
>>service to go through implement phase. Does having state transition from
>>State.Setup to State.Implemented on Event.ImplementNetwork make sense?
>
>Murali, could you please give more details on what exactly you want to
>introduce in Implement phase for Shared networks? Because looking at the
>code right now, I see that in
>
>* DirectNetworkGuru (responsible for Shared networks)- does nothing in
>implement()
>* ExternalGuestNetworkGuru (responsible for Isolated network), -
>recalculate vlan and cidr for the network in implement()
>
>
>I assume all you want to do - re-implement the elements and network rules
>w/o changing the network configuration? That's something that
>RestartNetwork does (re-implements all the network elements and the rules
>w/o changing the network state and config; both Isolated and Shared
>networks can be restarted)
>
>-Alena.
Ok. Let me elaborate a bit. So the network in CloudStack is handled by two
entities. Network design (L2-L3) is handled by 'Network Guru' and network
services (L4-L7) are handled by 'Network element'. Network operations like
implement, shutdown, restart, destroy should go through operations on both
network guru and network element as well. Since the 'shared network' did
not have any L4-L7 services, network operations were implemented for
shared network to go through corresponding operation on network guru only.
Now if we have L4-L7 services in the 'shared network', network operations
like implement, shutdown, restart etc should go through corresponding
actions on network guru, and network element as well. For e.g. I see that
implementNetwork() operation in the network manager, does NOT end up
invoking implementNetworkElementsAndResources() for the 'shared networks'
as the direct network guru says network is setup. Implement phase skips
the implementNetworkElementsAndResources() as network is setup.
So, my thinking is, 'shared network' with L4-L7 services should go through
'Implementing' and 'Implemented' sates as well.
Re: [4.1 feature RFC] Optional Public IP assignment for EIP with
Basic Zone
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 10/18/12 4:59 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>On 17/10/12 10:42 PM, "Alena Prokharchyk" <Al...@citrix.com>
>wrote:
>
>>Murali, some comments:
>>
>>1) "During network design phase of network creation, 'Direct network
>>Guru' which designs the shared networks shall setup the network to be in
>> Network.State.Allocated if shared network is being created in advanced
>>zone and with L4-L7 services enabled"
>>
>>Can you explain why? Allocated state means that the Vlan and CIDR for the
>>network will be re-calculated on every network imeplement. Setup state
>>means that the Vlan will stay with the network for its lifecycle, as well
>>as the network CIDR. If you are not planning to recalculate the CIDR on
>>each network re-implement, then Setup is your initial and the only one
>>state.
>>
>>If the only one thing you want to do during this face - prepare your
>>external devices - then you should use prepare() instead (we call it when
>>setup the network)
>
>
>I agree that 'Allocated' state is wrong here. I don¹t want CIDR to be
>recalculated. I just want to force the 'shared network' in the advanced
>zone to go through the complete implement phase. Right now, shared network
>are set to be in 'Setup' state by direct network guru. Implement network
>phase skips the back end implementation (i.e. implement operation on
>network elements) when network state is 'Setup'. I want to model life
>cycle of 'shared network' with L4-L7 service just as isolated network.
>Except for the fact that network is shared by multiple accounts, shared
>network with L4-L7 services is really same as isolated network w.r.t life
>cycle of the network and how the rules are applied.
>
>I can set the state to be 'Setup' but want the shared network with L4-L7
>service to go through implement phase. Does having state transition from
>State.Setup to State.Implemented on Event.ImplementNetwork make sense?
Murali, could you please give more details on what exactly you want to
introduce in Implement phase for Shared networks? Because looking at the
code right now, I see that in
* DirectNetworkGuru (responsible for Shared networks)- does nothing in
implement()
* ExternalGuestNetworkGuru (responsible for Isolated network), -
recalculate vlan and cidr for the network in implement()
I assume all you want to do - re-implement the elements and network rules
w/o changing the network configuration? That's something that
RestartNetwork does (re-implements all the network elements and the rules
w/o changing the network state and config; both Isolated and Shared
networks can be restarted)
-Alena.
>
>>
>>2) associateIpAddress
>>
>>With the current logic we always check if the owner of the guest network
>>and the owner of ip are the same. It should be relaxed for Shared
>>networks
>>case.
>>
>>
>>3) listPublicIpAddresses API shall be enhanced to take network ID
>>corresponding to the shared network in the advanced zone. When listAll
>>API parameter is set to true, API shall return list of the public IP's
>>associated with the network which caller is authorised to see.
>>When listAll API parameter is set to false then API shall return the
>>list of public IP's owned by the caller and associated with the network.
>>
>>We already have "associatedNetworkId" parameter in listPublicIpAddresses
>>call. Just make sure it accepts Shared networkId.
>>
>>
>>
>>-Alena.
>>
>>
>>
>>On 10/16/12 1:17 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>>
>>>I am trying to change EIP semantics supported by CloudStack for 4.1
>>>release. Today if some one deploys a basic zone with EIP service, then
>>>by
>>>default a public IP is allocated for the user VM along with private IP,
>>>and then a 1:1 NAT is established between the public IP and private IP
>>>of
>>>the user VM. In a deployment where public IP's are scarce this result in
>>>wastage of public IP. I am changing CloudStack behaviour so that cloud
>>>admin has the flexibility to enable or disable default public IP
>>>allocation for the user VM's in the basic zone with EIP service. I
>>>opened enhancement request [1] and the functional requirements are
>>>detailed at [2] please comment.
>>>
>>>[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
>>>[2]
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+I
>>>P
>>>+
>>>assignment+for+EIP+with+Basic+Zone
>>>
>>>
>>
>>
>>
>
>
>
Re: [4.1 feature RFC] Optional Public IP assignment for EIP with
Basic Zone
Posted by Murali Reddy <Mu...@citrix.com>.
On 17/10/12 10:42 PM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>Murali, some comments:
>
>1) "During network design phase of network creation, 'Direct network
>Guru' which designs the shared networks shall setup the network to be in
> Network.State.Allocated if shared network is being created in advanced
>zone and with L4-L7 services enabled"
>
>Can you explain why? Allocated state means that the Vlan and CIDR for the
>network will be re-calculated on every network imeplement. Setup state
>means that the Vlan will stay with the network for its lifecycle, as well
>as the network CIDR. If you are not planning to recalculate the CIDR on
>each network re-implement, then Setup is your initial and the only one
>state.
>
>If the only one thing you want to do during this face - prepare your
>external devices - then you should use prepare() instead (we call it when
>setup the network)
I agree that 'Allocated' state is wrong here. I don¹t want CIDR to be
recalculated. I just want to force the 'shared network' in the advanced
zone to go through the complete implement phase. Right now, shared network
are set to be in 'Setup' state by direct network guru. Implement network
phase skips the back end implementation (i.e. implement operation on
network elements) when network state is 'Setup'. I want to model life
cycle of 'shared network' with L4-L7 service just as isolated network.
Except for the fact that network is shared by multiple accounts, shared
network with L4-L7 services is really same as isolated network w.r.t life
cycle of the network and how the rules are applied.
I can set the state to be 'Setup' but want the shared network with L4-L7
service to go through implement phase. Does having state transition from
State.Setup to State.Implemented on Event.ImplementNetwork make sense?
>
>2) associateIpAddress
>
>With the current logic we always check if the owner of the guest network
>and the owner of ip are the same. It should be relaxed for Shared networks
>case.
>
>
>3) listPublicIpAddresses API shall be enhanced to take network ID
>corresponding to the shared network in the advanced zone. When listAll
>API parameter is set to true, API shall return list of the public IP's
>associated with the network which caller is authorised to see.
>When listAll API parameter is set to false then API shall return the
>list of public IP's owned by the caller and associated with the network.
>
>We already have "associatedNetworkId" parameter in listPublicIpAddresses
>call. Just make sure it accepts Shared networkId.
>
>
>
>-Alena.
>
>
>
>On 10/16/12 1:17 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>
>>I am trying to change EIP semantics supported by CloudStack for 4.1
>>release. Today if some one deploys a basic zone with EIP service, then by
>>default a public IP is allocated for the user VM along with private IP,
>>and then a 1:1 NAT is established between the public IP and private IP of
>>the user VM. In a deployment where public IP's are scarce this result in
>>wastage of public IP. I am changing CloudStack behaviour so that cloud
>>admin has the flexibility to enable or disable default public IP
>>allocation for the user VM's in the basic zone with EIP service. I
>>opened enhancement request [1] and the functional requirements are
>>detailed at [2] please comment.
>>
>>[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
>>[2]
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+IP
>>+
>>assignment+for+EIP+with+Basic+Zone
>>
>>
>
>
>
Re: [4.1 feature RFC] Optional Public IP assignment for EIP with
Basic Zone
Posted by Alena Prokharchyk <Al...@citrix.com>.
Murali, some comments:
1) "During network design phase of network creation, 'Direct network
Guru' which designs the shared networks shall setup the network to be in
Network.State.Allocated if shared network is being created in advanced
zone and with L4-L7 services enabled"
Can you explain why? Allocated state means that the Vlan and CIDR for the
network will be re-calculated on every network imeplement. Setup state
means that the Vlan will stay with the network for its lifecycle, as well
as the network CIDR. If you are not planning to recalculate the CIDR on
each network re-implement, then Setup is your initial and the only one
state.
If the only one thing you want to do during this face - prepare your
external devices - then you should use prepare() instead (we call it when
setup the network)
2) associateIpAddress
With the current logic we always check if the owner of the guest network
and the owner of ip are the same. It should be relaxed for Shared networks
case.
3) listPublicIpAddresses API shall be enhanced to take network ID
corresponding to the shared network in the advanced zone. When listAll
API parameter is set to true, API shall return list of the public IP's
associated with the network which caller is authorised to see.
When listAll API parameter is set to false then API shall return the
list of public IP's owned by the caller and associated with the network.
We already have "associatedNetworkId" parameter in listPublicIpAddresses
call. Just make sure it accepts Shared networkId.
-Alena.
On 10/16/12 1:17 AM, "Murali Reddy" <Mu...@citrix.com> wrote:
>I am trying to change EIP semantics supported by CloudStack for 4.1
>release. Today if some one deploys a basic zone with EIP service, then by
>default a public IP is allocated for the user VM along with private IP,
>and then a 1:1 NAT is established between the public IP and private IP of
>the user VM. In a deployment where public IP's are scarce this result in
>wastage of public IP. I am changing CloudStack behaviour so that cloud
>admin has the flexibility to enable or disable default public IP
>allocation for the user VM's in the basic zone with EIP service. I
>opened enhancement request [1] and the functional requirements are
>detailed at [2] please comment.
>
>[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
>[2]
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Optional+Public+IP+
>assignment+for+EIP+with+Basic+Zone
>
>