[PATCH conductor 0/2] #786844 - Reporting on deleted instances (v2)

Jan Provaznik jprovazn at redhat.com
Tue Feb 14 10:13:37 UTC 2012


On 02/14/2012 11:02 AM, Martyn Taylor wrote:
> On 02/14/2012 09:09 AM, Jan Provaznik wrote:
>> On 02/13/2012 08:19 PM, Matt Wagner wrote:
>>> This is a resend to address a problem Martyn and I discovered
>>> occurring in certain conditions.
>>>
>>> The gist of the patch is this -- if an instance is removed from the
>>> cloud provider bypassing Conductor, we would just leave the instance
>>> in its existing state, which was about the worst thing we could do.
>>> This usually manifested itself as an instance that we claimed was
>>> running just fine when, in actuality, it had failed and been removed
>>> from the back-end provider.
>>>
>>> This resend fixes a logic flaw discovered in destroy_on_provider, and
>>> also skips running destroy_on_provider when an instance is in
>>> STATE_VANISHED, since it doesn't make a whole lot of sense to try to
>>> delete something that disappeared.
>>>
>>> Two possible idiosyncracies I welcome feedback on:
>>>
>>> - The event association is :dependent => :destroy, so we end up
>>> deleting the event when the instance is destroyed. I'm not sure this
>>> is catastrophic since deleting the instance is really more of a
>>> stopgap solution, and long-term we've talked about leaving it in
>>> 'vanished' state.
>>>
>>> - We delete the instance, but not its deployment. This permits a
>>> state where you can have no instances. I'm kind of weighing how much
>>> to do here -- we could destroy the deployment if all of its instances
>>> are destroyed, but, again, we don't plan on deleting instances
>>> long-term -- we plan on setting them to a special state. So for now
>>> I've left it as-is, but I could easily be swayed.
>>>
>>
>> When reading it now, one question I should have probably asked earlier:
>> since we support only stateless instances, wouldn't be better to
>> change state to 'stopped' instead of deleting a vanished instance?
>> This behaviour reflects EC2 state change better - if an instance is
>> stopped, it 'disappears', and RHEVM (or other stateful) instances
>> can't be started again anyway. Advantage of this is that a user has
>> access to the instance's events and he can track what happened.
> Jan,
>
> I think the issue with using stopped is that we need to distinguish
> between standard stopped and when DC can not find the instance.

That's the question. What is better? Destroy an instance or don't 
distinguish between stopped/vanished? I tend to think that 'stopped' is 
better than destroying it.

> Also we
> do have states that are not in the Deltacloud model. i.e. NEW and
> possibly CREATED_FAILED so we're not doing anything different with this
> patch.
>
> However, I'm thinking that we shouldn't use the state at all. We could
> just set a field on the instance (like contact_retries) once this hits
> say 5 then we delete it. We could do this on an after_save filter or
> something? For me this is cleaner than managing this from dbomatic?
>

Sure, agree with both points above.

>
>
>
>>
>>> -- Matt
>>
>

Jan



More information about the aeolus-devel mailing list