cloud state requirements
David Lutterkort
lutter at redhat.com
Fri May 25 23:17:04 UTC 2012
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
More information about the aeolus-devel
mailing list