deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <mtay...@redhat.com>
Subject Re: cloud state requirements
Date Sun, 27 May 2012 09:31:37 GMT
On 05/26/2012 09:03 AM, Michal Fojtik wrote:
> On May 26, 2012, at 1:17 AM, David Lutterkort wrote:
>
>>> So, I'd hope that you would return some indication of what has changed.
>>> a PUT with the changed resource in the body to the call back URL?
>> Any specific reason why this is a PUT ? POST seems more natural to me
>> here …
I guess it depends on how the client intends to handle callbacks.  In 
conductors case we actually want to update resources directly, so we'll 
supply a callback url that is the resource endpoint.  This means we 
don't have to create a new set of endpoints for listening to call backs.

Other clients might wish to represent call backs as separate resources 
(or use non REST style)  in which case POST would be a more fitting verb.

How about we support PUT for the first version with the possiblitity of 
making it configurable in next?
> Also PATCH method can be considered updating resource :-)
>
>    -- Michal
>
>>>>>>> TODO: how to handle credentials? will the stateful app keep credentails
>>>>>>> permanently for each instance being checked?
>>>>>> As much as this worries me from a security standpoint, I don't see
>>>>>> another way around this - cloud API's generally don't allow any
>>>>>> delegation of auth.
>>>>>>
>>>>>> There's a couple more TODO's connected to credentials:
>>>>>>
>>>>>> TODO: how are credentials changes handled (user revokes API Key and
>>>>>> generates a new one) ? [not for the first cut
>>>>>>
>>>>>> TODO: when are stored credentials purged ? We want to make sure we
get
>>>>>> rid of them as quickly as possible.
>>>>> Why not make this a feature.  Credentials could be stored via the API
>>>>> and managed via a single login (maybe OAuth)?
>>>>>
>>>>> Then to answer the previous question, we could add another callback on
>>>>> the credentials resource that is invoked when authentication fails.
>>>> I don't want to introduce an explicit credentials resource; because we
>>>> then need to safeguard that with credentials of its own. Rather, I'd
>>>> prefer that the state tracker just snoop the backend credentials out of
>>>> the ordinary DC requests.
>>> Fair point.
>>>
>>> Mainly my thinking was from aeolus perspective here.  Credentials get
>>> passed around a lot in aeolus from  "conductor ->  dc", "conductor ->
>>> image factory" and they only really make sense in the context of DC.  I
>>> always assumed that the login credentials to DC replicated the back end
>>> provider login simply due to the lack of state.  If you stored
>>> credentials in DC Stateful you could have a single consistent way to
>>> authenticate.
>> For the Tracker piece, I would want to continue to give users the
>> illusion that they are talking to a simple proxy, without hte need to
>> setup and manage credentials mappings.
>>
>>> Another thing of interest, if we did go down this route, is that you
>>> could do some cool things like aggregating clouds hiding all of the
>>> backend provider stuff from the user who just starts an instance
>>> "somewhere" and a list of all his instances in "The Cloud".
>> Yes, I think we should incorporate something like this into Deltacloud,
>> too, but that will be a much more complex piece than Tracker. For now,
>> let's just figure out Tracker and get that rolling - we'll do the broker
>> right after ;)
alrighty, that wfm
>>
>> David
>>
>>
Cheers

Martyn


Mime
View raw message