RFC: Feature Planning - Design the model changes for support of stateful instances

Scott Seago sseago at redhat.com
Fri Apr 20 14:35:00 UTC 2012


On 04/20/2012 07:59 AM, Jan Provazník wrote:
> On 04/18/2012 03:57 PM, Jozef Zigmund wrote:
>> Hi,
>>
>> I wrote up current status of instance states, and described a 
>> proposal how we
>> could implement this feature.
>>
>> Rather than paste in the entire text, I'm just linking to the wiki
>> writeup.
>> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Design_the_model_changes_for_support_of_stateful_instances 
>>
>>
>> Any thoughts or improvement ideas are welcomed.
>>
>> -- 
>> Jozef
>
> Hi Jozef,
> I might be completely wrong but from the subject: "Design the model 
> changes for support of stateful instances" I think that the goal is 
> slightly different than what you describe on the wiki page. The thing 
> is that now, when a user stops an instance, there is no way how to 
> start the instance again later because till now we considered all 
> instances to be stateless (not re-launchable).
>
> Off the top of my head, to add stateful instances we will have to:
> - distinguish between stopped (re-launchable) and terminated state
The real "fun" here is that a lot of  this is provider-specific. 
Generally, the hope will be that something in the 'stopped' state can be 
started again, but that a 'terminated' instance can not start again. 
This may not be true for all providers, though. Deltacloud has a notion 
in the driver of the valid state transitions for an instance, so we can 
use that to determine whether a 'stopped' instance may be restarted. The 
other thing we'll need to decide is whether we'll continue to fully 
support stateless instances alongside stateful instances, or are we 
moving to stateful-only? In the former case, will the stateful/stateless 
decision be made in the image, the instance, the deployable, or the 
deployment? Is there a need to support deployments with both stateful 
and stateless components?
> - update method which compute uptimes
Uptime and run history. Really, we probably need to know each time an 
instance was started and stopped, as well as maintaining an accumulated 
uptime measurement.
> - update deployment/instance launch methods to be able to work with 
> existing objects (now we always create new instance/deployment)
So I would imagine that the "launch" sequence we have now will be mostly 
unchanged (except for, possibly, needing a stateful/stateless tab). 
Launch == "Create and Start", and the whole UI is based on choosing a 
set of images to create a new deployment. For starting a previously-run 
instance/deployable, we wouldn't need the launch sequence -- the user 
would see a 'start' action on the deployment details page, and there 
might be a 'start' action on the list view alongside the 'stop' action 
to allow restarting of more than one deployment at a time.
> - allow start action for stopped instances (and probably for whole 
> deployments?) in UI
>
Yeah, I'd think that the deployment level would be the main focus here 
-- 'stop deployment', then 'start deployment', etc. As it is we're 
limiting actions on individual instances within a deployment. If we 
allow individually stopping instances in a deployment, then restarting 
should also be allowed.
> Jan
Scott




More information about the aeolus-devel mailing list