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

Martyn Taylor mtaylor at redhat.com
Tue Feb 14 10:02:35 UTC 2012


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




>
>> -- Matt
>




More information about the aeolus-devel mailing list