openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Wed, Feb 16, 2011 at 5:29 PM, Brian Waldon
<brian.waldon@xxxxxxxxxxxxx> wrote:
> -----Original Message-----
> From: "Jay Pipes" <jaypipes@xxxxxxxxx>
> Sent: Wednesday, February 16, 2011 5:09pm
> To: "Glen Campbell" <glen.campbell@xxxxxxxxxxxxx>
> Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
>
> On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
> <glen.campbell@xxxxxxxxxxxxx> wrote:
>> The proposed compute API 1.1 has a specification for server actions (Sec.
>> 4.4) with the endpoint:
>>
>>    /servers/{id}/action
>>
>> The actual action is specified as the body of the POST request, and the
>> implication is that the action is performed immediately, or as soon as
>> possible.
>
> Hmm, do you mean the GET request? The above URL implies the action is
> part of the GET URL...
>
> /servers/{id}/action only accepts POST requests with an action entity as the
> body, "action" is not a replaceable string

OK.

>> I'd like us to consider changing this "action" resource into a "calendar"
>> or
>> perhaps "schedule" resource:
>>
>>    /servers/{id}/schedule{/year{/month{/day{/hour{/minute}}}}}
>>
>> This would provide a generalized way of performing actions on a scheduled
>> basis.
>>
>> For example, instead of having to wake up at 2AM to reboot a server (for
>> whatever reason), the administrator could schedule that event:
>>
>>    /servers/{id}/schedule/2011/2/17/02/00
>>
>> By using the default resource (without the day or time specified), the
>> meaning would be synonymous with the proposed "/action" resource; i.e.,
>> perform it NOW, or as soon as possible.
>
> Why not /servers/{id}/{action}/schedule/2011/2/17/02/00 instead? That
> way no POST would be required.
>
> Changing a POST to a GET may seem convenient, but to me GET != POST and
> should never be used that way.

Hmm, I suppose, yes, you're right.

> Why not add a "schedule_at" property to the
> action entity and keep the url short?

++ that would work, too.

-jay