Done, thank you, Murali
https://issues.apache.org/jira/browse/CLOUDSTACK-6420
On 4/15/14, 2:13 AM, "Murali Reddy" <murali.re...@citrix.com> wrote:
>On 15/04/14 3:08 AM, "Alena Prokharchyk" <alena.prokharc...@citrix.com>
>wrote:
>
>>Murali,
>>
>>I have a question to you. In NetworkOrchestrator, implementNetwork code,
>>when we update the state for the network, why don¹t we use state machine
>>for Shared networks, but instead update it directly in the DB?
>>
>>
>>if (isSharedNetworkWithServices(network)) {
>> network.setState(Network.State.Implementing);
>> } else {
>> stateTransitTo(network, Event.ImplementNetwork);
>> }
>>
>>
>>That doesn¹t seem right to me as there should be no exception when it
>>comes to state update - the state machine should always be used once its
>>implemented for the object. If your code needs additional state
>>transitions for the Setup state, why can¹t you add it?
>
>Initially network just had states and states were set explicitly. Actually
>I happened to add state changes to explicitly happen through the state
>machine for resource state change events for EventBus. But the problem I
>had with
>shared networks was, it had different life cycle (before cloudstack
>supported L4-L7 services in shared networks) and shared network with L4-L7
>service has life cycle similar to that of isolated network. For the
>network in 'Setup' state, ImplementNetwork event shall succeed only for
>shared network with services but should fail for shared network without
>L4-L7 services. Similarly an implemented network in 'Implemented' state on
>'ShutdownNetwork' event can go to 'Allocated' or 'Setup' state depending
>on the network type (isolate/shared). I needed some sort of conditional
>state transition in the state machine which is not there.
>
>Due to time constraint I added minimal disruptive changes. Doing it
>cleaner way means revamping the network states and transitions to avoid
>conflicting transitions. Please do open a bug to fix it.
>
>
>>
>>Thanks,
>>Alena.
>>
>>
>
>
