On 17/10/12 10:42 PM, "Alena Prokharchyk" <alena.prokharc...@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" <murali.re...@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 >> >> > > >
