deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject RE: outstanding issues with FGCP driver
Date Fri, 11 May 2012 22:08:46 GMT
On Fri, 2012-05-11 at 18:36 +1000, Koper, Dies wrote:
> > The behavior is either an oversight in the API, or will require us to
> > maintain state on the server to map DC assigned id's to FGCP id's.
> 
> Or both :)
> So the driver could look up the image by name if not formatted as an id.

The way I am thinking about this is that we return /machines/$name as
the URL for image creation - clients will use this URL for quite some
time, and we will therefore have to translate name -> id to make
requests into FGPC.

In theory, we'd have to maintain that mapping for the entire lifetime of
the machine - unless we have a _cheap_ way to look up by name (which I
gather does not exist)

Though, since names are unique, what's the point of having a separate id
on top of that ?

> > My sense here is that the crucial thing issue is finding out what
> > operations can be performed on a given realm - e.g., can I create a LB
> > in that realm ? Can I create a VM in that realm etc.
> 
> Correct.
> 
> > We should add <actions/> to realms; I haven't figured out how to do
> that
> > in a backwards compatible way, but since only users of the FGPC driver
> > will be affected by this, it's not that much of a headache, I hope.
> 
> That's an interesting idea.
> How would that work for creating an instance? Does the <actions> list
> for a realm include a url to create action for each available image?
> And for storage volumes, how would it include the volume name and
> capacity?
> Or are the urls not supposed to be actioned as is?

Yeah, I realized that little wrinkle after I wrote that about <actions/>
- that various create actions take parameters, and we'd not want to blow
them out in each realms (as with images as you mentioned) We have
precedents for that: e.g., with load balancers, the 'register' link does
not contain an instance_id. The <link/> indicates to the client that a
certain action can be performed, and where to go for that, but it still
assumes the client knows the contract for that action.

So I don't see a problem with using <actions/> to indicate what can be
created; the important thing is that we have a well-known list of
create_XXX tags for the rel of the <link/>s

> The fact that virtual systems have one to three network segments (the
> parent-child relationship) is not relevant for the actions, so not
> expressing this relationship may not cause an issue.

Ok .. if just the <actions/> thing would take care of what users need to
know about realms, I'd be much happier with that. But if there are other
things they need to know, we might have to reconsider.

> > > > 4. Instance creation in realm
> > > >
> > > > As mentioned in 2., would be nice if only the relevant realms
> (i.e. the
> > > > network segments) where listed.
> > 
> > I think we should cover that with actions; like
> > 
> >         <realm>
> >                 <name>netw-seg1</name>
> >                 <actions>
> >                   <link rel="create_instance" href="http://..."/>
> >                 </actions>
> >         </realm>
> 
> Although this solution looks nice, how would this work in the DC GUI?
> Currently you go to an image page, click launch, get a list of all
> realms and specify name and hwp.
> Instead of listing all realms, can we retrieve realms(opts[:action =>
> 'create_instance']) so that in FGCP's case only the network segment
> realms are returned?
> That sounds like it would work nicely and have no impact on existing
> providers.

Yes, I think we'd need to allow filtering realms by the permissible
actions, i.e. GET /realms?action=create_instance

> > > > Both types of volume can be backed up and restored. Restoring
> means
> > > > overwriting whatever you have on it now, no flexibility to use it
> for
> > > > cloning.
> > > > My driver's storage_volumes operation is returning both. What does
> > the
> > > > undocumented ':kind' attribute mean? Shall I use it to specify the
> type
> > > > of storage (system|additional)?
> > 
> > Right now, I see kind only used in the rhevm_driver, where it just
> spews
> > back whatever rhevm gave it. We should probably figure out what
> possible
> > values we want in there, and make sure we only return those.
> 
> I tried googling it but no luck. Maybe you know people more familiar
> with rhevm who can answer that?

mfojtik is probably the best person to ask.

David



Mime
View raw message