deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Fojtik>
Subject Re: cloud state requirements
Date Sat, 26 May 2012 08:03:58 GMT

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 …

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 ;)
> David

View raw message