On Fri, 2012-05-25 at 08:42 +0100, Martyn Taylor wrote:
On 05/24/2012 11:41 PM, David Lutterkort wrote:
> On Thu, 2012-05-24 at 13:26 +0100, Martyn Taylor wrote:
>> Had a chat with Jan this morning about some of your questions. I've
>> replied to qs with what we talked about plus a few thoughts of my own.
>>
>>
>> On 05/24/2012 01:36 AM, David Lutterkort wrote:
>>> We need to define in detail for each of these resources what needs to be
>>> tracked, and what status changes constitute an 'event', but as a
general
>>> requirement this is fine.
>>>
>>> I suggest though that we start with something very basic, like tracking
>>> only instance state changes, and expand from there gradually.
>> I'd suggest that this is what ever changes from a->b, probably let the
>> driver to decide what to return since it should know what changes from
>> say Pending -> Running.
> The state changes should all be on the level of DC instance states; we
> do not want to expose driver-specific state ... I assume that's what you
> are saying.
No.
So, I assumed each provider would have a different set of changes moving
from one state to another. For example. When EC2 instance is started
it's assigned public/private ip addresses and state is set to
"Running". I imagine that another providers (Provider B) might have
different set of changes when moving to state running, maybe only
private ip address is set.
I agree the changes should be on the DC Level, i.e. DC resource fields,
nothing specific to the driver/provider. But chosing which of these
resource fields to look out for, would probably be best suited to live
in the driver, since the driver knows that Provider B only changes
private ip addresses when moving to running state.
Alternatively, and probably more appropriately. We could just inspect
the resource before and after the change and return the diff of the two
Yes, that's what I was thinking; and make sure we only report changes
for fields that we know are interesting.
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 ...
>
>>>> 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