You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by Ladislav Martincik <lm...@redhat.com> on 2010/10/07 11:27:28 UTC
Question about instance states
Hey guys,
I have already asked the question on ICQ channel, but I think it deserves it's own thread on this mailing list.
At the moment I'm working on Linode driver for Deltacloud Core project and I'm having problem map all Linode instance states to our Deltacloud default states. Currently we have PENDING, RUNNING, SHUTTING_DOWN, STOPPED. Linode has 3 other states from which 2 can be mapped to our standard PENDING state but 1 called "Boot failed" cannot be.
There seems to be 2 obvious ways to go:
1) Create one more state which we can call UNKNOWN and pull all the other states into this status.
pros: It's simple solution and easy to handle.
cons: Some of the states could be important to outside world and we will just dump them into one unknown state
2) Let each driver populate different as strings to our API
pros: Transparent for outside world.
cons: Can be problematic for different clients as they could rely on predefined states for their apps.
I would really appreciate your elaboration on this.
Thank you, Ladislav
Re: Question about instance states
Posted by "marios@redhat.com" <ma...@redhat.com>.
> You're right. It makes sense so I could define it as STOPPED. :)
Woah there! I don't know about that, it was just one possible suggestion
- again I don't know anything about Linode and it might still be tricky
to map the 'failed' to stopped - e.g. what's the trigger?
eg:
Stopped to running on start
stopped to stopped on? (error?) not sure.
In any case, it should become clearer once we (via you :) ) have a
better understanding of all the possible states and their triggers
marios
>
> But...
>
> What about states that you cannot map directly Deltacloud states?
>
> -- Ladislav
Re: Question about instance states
Posted by Ladislav Martincik <lm...@redhat.com>.
> What does the Linode state machine look like? It would be helpful if
> you
> could list all the Linode states?
I don't have the state machine yet, but will work on it today.
> RE 'boot failed', can that not be 'stopped'? I mean, you try to start
> an
> instance and it doesn't start (due to whatever error), so it ends up
> as
> 'stopped'?
You're right. It makes sense so I could define it as STOPPED. :)
But...
What about states that you cannot map directly Deltacloud states?
-- Ladislav
Re: Question about instance states
Posted by "marios@redhat.com" <ma...@redhat.com>.
What does the Linode state machine look like? It would be helpful if you
could list all the Linode states?
RE 'boot failed', can that not be 'stopped'? I mean, you try to start an
instance and it doesn't start (due to whatever error), so it ends up as
'stopped'?
marios
On 07/10/10 12:27, Ladislav Martincik wrote:
> Hey guys,
>
> I have already asked the question on ICQ channel, but I think it deserves it's own thread on this mailing list.
>
> At the moment I'm working on Linode driver for Deltacloud Core project and I'm having problem map all Linode instance states to our Deltacloud default states. Currently we have PENDING, RUNNING, SHUTTING_DOWN, STOPPED. Linode has 3 other states from which 2 can be mapped to our standard PENDING state but 1 called "Boot failed" cannot be.
>
> There seems to be 2 obvious ways to go:
>
> 1) Create one more state which we can call UNKNOWN and pull all the other states into this status.
> pros: It's simple solution and easy to handle.
> cons: Some of the states could be important to outside world and we will just dump them into one unknown state
>
> 2) Let each driver populate different as strings to our API
> pros: Transparent for outside world.
> cons: Can be problematic for different clients as they could rely on predefined states for their apps.
>
>
> I would really appreciate your elaboration on this.
>
> Thank you, Ladislav
Re: Question about instance states
Posted by Chris Lalancette <cl...@redhat.com>.
On 10/22/10 - 03:57:15PM, Ed Bradford wrote:
> I noted Chris Lalancette's email on Oct 7 saying there are only three
> states defined.
> However, many of the drivers still reference "shutting_down". I have a
Yes, I did not cleanup the state machines. So the API can no longer return
a state of SHUTTING_DOWN, but these things are still listed in the files.
Note, however, that these are orthogonal issues, really; it's possible that the
backend state machine could go through a "SHUTTING_DOWN" state, but we just
never expose that to the API user.
> suggestion. Would it be
> possible to include in the source code of each file the date on which it
> was
> last modified? That would be very helpful finding why something is missing
> or present.
This is trivial with git:
git blame <filename>
>
> [I could be wrong on this. I downloaded the source code Oct 22, 2010 from
> git clone git://git.apache.org/deltacloud.git core]
>
> Also, on the "states".
>
> What is the current thinking? Specifically, :pending is so vague that it
> will always
> beg for more information. Pending what? If I am writing software to talk to
> Deltacloud
> and my instance is "pending" what can I extract from that information? I'm
> thinking
> that :booting, :shutting, :suspending [or :pausing] and maybe
> even :snapshotting
> give much more information to the user than :pending.
Yes, I agree that pending is vague. But I'm not sure that we have a good
way to tell some of these states; EC2, for instance, does not give us any
additional information except PENDING, and then RUNNING, once it is up.
That being said, I'm not at all opposed to adding new states. But it needs
to be done in a consistent way across the drivers, otherwise it is impossible
to use the API in a cloud-independent way.
--
Chris Lalancette
Re: Question about instance states
Posted by Ed Bradford <eg...@us.ibm.com>.
I noted Chris Lalancette's email on Oct 7 saying there are only three
states defined.
However, many of the drivers still reference "shutting_down". I have a
suggestion. Would it be
possible to include in the source code of each file the date on which it
was
last modified? That would be very helpful finding why something is missing
or present.
[I could be wrong on this. I downloaded the source code Oct 22, 2010 from
git clone git://git.apache.org/deltacloud.git core]
Also, on the "states".
What is the current thinking? Specifically, :pending is so vague that it
will always
beg for more information. Pending what? If I am writing software to talk to
Deltacloud
and my instance is "pending" what can I extract from that information? I'm
thinking
that :booting, :shutting, :suspending [or :pausing] and maybe
even :snapshotting
give much more information to the user than :pending.
Ed Bradford
Re: Question about instance states
Posted by Chris Lalancette <cl...@redhat.com>.
On 10/07/10 - 05:27:28AM, Ladislav Martincik wrote:
> Hey guys,
>
> I have already asked the question on ICQ channel, but I think it deserves it's own thread on this mailing list.
>
> At the moment I'm working on Linode driver for Deltacloud Core project and I'm having problem map all Linode instance states to our Deltacloud default states. Currently we have PENDING, RUNNING, SHUTTING_DOWN, STOPPED. Linode has 3 other states from which 2 can be mapped to our standard PENDING state but 1 called "Boot failed" cannot be.
>
> There seems to be 2 obvious ways to go:
>
> 1) Create one more state which we can call UNKNOWN and pull all the other states into this status.
> pros: It's simple solution and easy to handle.
> cons: Some of the states could be important to outside world and we will just dump them into one unknown state
>
> 2) Let each driver populate different as strings to our API
> pros: Transparent for outside world.
> cons: Can be problematic for different clients as they could rely on predefined states for their apps.
There is another downside to 2), in that if each individual driver specifies
it's own set of states, then you cannot write a generic client; your client
needs to know whether it is using EC2, or Linode, or Rackspace, etc. That
defeats the whole purpose of deltacloud. In my opinion, option 1 is the only
reasonable choice; define it as a state that all drivers could use, and then
just define it for the ones that can actually get there.
FYI: recently we removed the "SHUTTING_DOWN" state, since it was poorly
defined. Therefore, the only valid states at present are PENDING, RUNNING,
and STOPPED.
--
Chris Lalancette