Open Stack

More comments on top of your comments!
And one more question: what are we going to do with 'orphaned' logical
instances? Can they be associated with another provider?

Salvatore


On 31 July 2013 09:23, Eugene Nikanorov <enikanorov at mirantis.com> wrote:

> My comments inline
>
>
> On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando <sorlando at nicira.com>wrote:
>
>>
>>
>> On 30 July 2013 23:24, Eugene Nikanorov <enikanorov at mirantis.com> wrote:
>>
>>> 2) Resources allocated by the provider must be cleaned up - that is done
>>> before neutron server is restarted with new configuration.
>>> I think it's a valid workflow.
>>>
>>
>> What kind of operations would the cleanup involve?
>>
>
> To me it basically means that resources need to be undeployed from
> corresponding devices/hosts.
> Being more specific: if for example cloud admin decides to remove lbaas
> reference provider for whatever reason, then he would expect haproxy
> processes to be shut down on all hosts.
>

If I get it right then, this would mean that all the resources (in your
case service pools) will have to be scanned at startup to see if their
provider has been removed.
I don't think this is the right time to get into performance and scale
discussions; on the implementation side, it would be good for me to
understand how neutron will be able to undeploy resources - for which it
should use a driver which unfortunately has been removed. Are we caching
drivers somewhere - or planning to store them back in the database?



>
>
>>
>
>>
>>>
>>>
>> Also, I'd be against such a check which would prevent neutron-server from
>>> starting if some resources reference unknown providers.
>>> Providers may be removed for various reasons, but that would be too
>>> disruptive to bring down whole networking service because of that.
>>> Another option may be to take such decision on per-service basis. At
>>> least I don't think having orphaned loadbalancer pools should prevent
>>> neutron to start.
>>>
>>
>> It might be ok to not prevent the service from starting.
>> Perhaps I am misunderstanding the workflow, which I barely know since the
>> original conversation happened outside of this thread.
>> From the perspective of the API user, I perceive the effect would be that
>> of a service instance which exists as a logical entity, but actually has
>> been de-implemented as its provider has been removed.
>> This is probably not very different from the case in which the host where
>> a port is deployed goes down - the status for the port will be DOWN. I hope
>> that the status for the corresponding services will go DOWN as well -
>> otherwise this might result a bit confusing to API users.
>>
>
> I think having resource in DOWN state is different from having resource
> with no provider. Why? Because from API perspective when you update
> resource from DOWN to UP state, you expect some deployment to happen, and
> it would not be a case if provider is not associated with the resource.
>
>
I am referring to the operational status. I've used the term
'administratevely down' incorrectly

>
>>
>>>
>>> The need for Noop driver is direct consequence of the case above.
>>> If we remove requirement (1) and just delete resources which reference
>>> removed provider, than we will not need Noop and unassociated resources.
>>>
>>
>> While a 'noop' driver - assuming this would be the right term - can be
>> used to describe service instances without a provider, I wonder if the best
>> way of describing an instance without a provider is literally a service
>> instance without a provider. Also, correct me if I'm wrong here, if one
>> assumes that such 'orphaned' instances should be in status 'DOWN' or
>> 'ERROR', then probably it does not matter which provider (if any) the
>> service instance is associated with.
>>
>
> In fact,  'Noop' is kind of 'internal' description, not visible to users.
> That's just a technical need to have such driver which will finish removal
> operations (I'm speaking about lbaas plugin now, which changes state of
> objects to PENDING_DELETE and lets drivers to do actual db removal) and
> will not do any additional stuff.
> Regarding DOWN and ERROR - see my comment above.
>

So the Noop driver will be able to undeploy the service instance?


>
> Thanks,
> Eugene.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130731/c0be74ab/attachment.html>