Had a chat with Murali about the semantics of adding external elements. I summarize here:
1. addProvider (virtualrouter and derivatives|physical external-service-provider|external-controller) 2. configureProvider 3. enableProvider The VR/VpcVR/InternalLBVm do these three steps but since they are template based systems one can enable the provider soon as it is configured. Because management server is responsible for start up of these appliances we consider them to be ready (isReady = true). OTOH, the external physical elements like the JuniperSRX, BigIP and NetScaler are not controlled by CloudStack and need to be externally configured. They need to signal to CS that they are ready for operation (isReady = false until a device is brought up) SDN Controllers like Midonet, Nicira take control of all aspects of routing and network traffic mgmt so they are always ready (isReady=true) since CS offloads all operations to these elements. Inflobox is similar to the external elements I think so it needs to signal to CS that it is indeed ready for operation. So I'm not sure if it should be in the default set of providers that are enabled. To handle the tests: deployDataCenter.py only optionally enables the provider and the device if they are available. We should keep that to be able to prepare a deployment with devices if and when they are provided in the marvin configuration. We can workaround: 1. enable the provider, add the device and remove it to keep the provider enabled for subsequent tests 2. attempt to enable the provider per-test (as you've done) I'm ok with 2. temporarily On Wed, Sep 04, 2013 at 05:25:24PM +0000, Sowmya Krishnan wrote: > So to get around this limitation, should we be looking at making > appropriate changes to deployDataCenter.py to not try to add NS > device if it's not supplied? The test would take care anyway of > adding the device and configuring the provider. > Thoughts? > > > -----Original Message----- > > From: Soheil Eizadi [mailto:seiz...@infoblox.com] > > Sent: Tuesday, September 03, 2013 11:48 AM > > To: dev@cloudstack.apache.org > > Subject: RE: NetworkElements: configure the provider to enable the provider? > > > > Hi Prasanna, > > The limitation you have highlighted "enable network service providers > > without > > actually adding the device" is not enforced by the NetworkManager but by the > > design of the NetworkElement. > > > > If you have not registered a device with the Netscaler NetworkElement it is > > rejecting the Enable. The NetworkManager calls the NetworkElement isReady() > > and that determines if it is ready to accept the call to Enable. I assume > > that > > NetScaler NetworkElement code can not handle subsequent calls to Prepare() > > etc. unless a device is configured. > > > > I assume those other NetworkElements you have highlighted, have chosen to > > return True on that call, and handle the subsequent calls e.g. Prepare(), > > when > > there is not a device, my NetworkElement behaves this way so that it can be > > enabled early when there is no device. > > > > There is a design pattern to enable some Network Elements that offer > > service to > > the Physical and Guest network in the call to createPhysicalNetwork() in > > NetworkServiceImpl: > > > > ....... > > > > // add VirtualRouter as the default network service provider > > addDefaultVirtualRouterToPhysicalNetwork(pNetwork.getId()); > > > > // add security group provider to the physical network > > > > addDefaultSecurityGroupProviderToPhysicalNetwork(pNetwork.getId()); > > > > // add VPCVirtualRouter as the defualt network service provider > > addDefaultVpcVirtualRouterToPhysicalNetwork(pNetwork.getId()); > > > > // add baremetal as the defualt network service provider > > addDefaultBaremetalProvidersToPhysicalNetwork(pNetwork.getId()); > > > > //Add Internal Load Balancer element as a default network > > service > > provider > > addDefaultInternalLbProviderToPhysicalNetwork(pNetwork.getId()); > > > > // add Infoblox as the default network service provider > > addDefaultInfobloxProvidersToPhysicalNetwork(pNetwork.getId()); > > > > -Soheil > > ________________________________________ > > From: Prasanna Santhanam [t...@apache.org] > > Sent: Saturday, August 31, 2013 1:36 AM > > To: CloudStack Dev > > Subject: NetworkElements: configure the provider to enable the provider? > > > > I'm looking to enable network service providers without actually adding the > > device but it appears as if the addition of the device is coupled with the > > enabling > > of the provider. While this is not the case with default providers like VR, > > VpcVR, > > security groups and the InternalLbVm? > > > > What is the reason for the restriction placed on External NetworkElements? > > In > > marvin integration tests [1] we want to be able to enable the provider > > whilst > > deployment and later add VPX Netscalers per test but this is not possible > > since > > the Netscaler provider cannot be enabled during the deployment of > > CloudStack. > > The problem exists with the implementation of other providers as well like > > JuniperSRX, F5BigIp. > > > > Nicira and Midonet however are always ready to be enabled. > > > > I tried the following via API: > > > > $add networkserviceprovider name=Netscaler physicalnetworkid=0d1a18d5- > > 837e-4973-8b06-ff1f3a8bdbfd > > > > The netscaler element is registered successfully but disabled: > > mysql> select id, state, provider_name, physical_network_id from > > physical_network_service_providers; > > +----+----------+-----------------------+---------------------+ > > | id | state | provider_name | physical_network_id | > > +----+----------+-----------------------+---------------------+ > > | 1 | Enabled | VirtualRouter | 200 | > > | 2 | Disabled | SecurityGroupProvider | 200 | > > | 3 | Enabled | VpcVirtualRouter | 200 | > > | 4 | Enabled | InternalLbVm | 200 | > > | 5 | Disabled | Netscaler | 200 | > > | 6 | Disabled | JuniperSRX | 200 | > > +----+----------+-----------------------+---------------------+ > > 6 rows in set (0.00 sec) > > > > So I enable it using: > > > > $update networkserviceprovider id=1a266697-838a-4322-b894-235bdc158da1 > > state=Enabled > > > > Async job d830d7aa-2a1e-44a4-a736-4885a668e8a6 failed Error 530, Provider is > > not ready, cannot Enable the provider, please configure the provider first > > accountid = e31a616a-1212-11e3-8a03-ef159ac306d1 > > cmd = > > org.apache.cloudstack.api.command.admin.network.UpdateNetworkServicePro > > viderCmd > > created = 2013-08-31T13:58:12+0530 > > jobid = d830d7aa-2a1e-44a4-a736-4885a668e8a6 > > jobprocstatus = 0 > > jobresult: > > errorcode = 530 > > errortext = Provider is not ready, cannot Enable the provider, please > > configure > > the provider first jobresultcode = 530 jobresulttype = object jobstatus = 2 > > userid > > = e31a7560-1212-11e3-8a03-ef159ac306d1 > > > > These steps feel counter-intuitive and the error message is a little > > confusing too. > > It says I need to configure the provider to enable the provider? > > > > [1] https://reviews.apache.org/r/13889/ > > -- > > Prasanna., > > > > ------------------------ > > Powered by BigRock.com -- Prasanna., ------------------------ Powered by BigRock.com
