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 > >
