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