Open Stack

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.


>

>
>>
>>
> 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.


>
>>
>> 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.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130731/f5903edc/attachment.html>