deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Koper, Dies" <di...@fast.au.fujitsu.com>
Subject RE: outstanding issues with FGCP driver
Date Fri, 11 May 2012 08:36:04 GMT
Hi David,

Thank you for your comments!

> > creation status/progress. For now, "PENDING#{opts[:name]}" for
example
> > is the best we could do, and document this behaviour...
> 
> The problem with this is that the id of the instance will change over
> time - we really need a stable id (and a stable URL) for the image.
> 
> How are users supposed to keep track of images while they are being
> created ?

By name. Image names are unique.

> If I create two images almost simultaneously, how can I
> distinguish them ?

You can't, you can create only one image at a time within a contract.

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

> > > 2. Realms mapping
> > >
> > > I'm currently using the following mapping, which helped me map all
> > > relevant operations:
> > >
> > > DC		FGCP			Used by collection
> > > Realm		network segment	Instances, load balancers
> > > Realm		VSYS			Storage, public IPs,
image
> > > creation
> > > Firewall	VSYS			Firewall creation
> > >
> > > The only issue with mapping two FGCP concepts to Realms is that
when
> > > creating an instance from an image through the UI, it displays
both
> > > network segment realms and VSYS realms, but only the former work.
> > > Similarly, when creating a new volume or IP address, both are
displayed
> > > (but I made the driver accept both as I can determine the VSYS
from the
> > > network segment).
> > >
> > > -> Suggestion: Introduce parent-child hierarchy (sub-realms) and
list
> > > them in a tree structure in the UI. Also introduce a
> > > type/scope/purpose(/limit?) that can be filtered on so that the
> > > instance, IP address and storage creation operations can list only
the
> > > realms that are applicable.
> >
> > This could work - I can't think of a way using the current API
entities
> > (e.g. Provider --> Vsys won't work). However this is a big issue and
I'd
> > advise starting a separate thread for this one - an initial proposal
> > would be helpful (e.g. you mention a 'type' attribute above)
> 
> 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?

> For the parent-child relationship: do we really need it ? And rather

Maybe not.
All I thought is when you obtain the full realms list it would be nice
to see them grouped.
JClouds introduced a parent-child relationships. I'll try looking up
why.

> than doing that, we should probably express the actual relationship
that
> users care about (not sure if this applies for FGPC, but I am
imagining
> something like 'load balancers for instances in this realm go into
that
> other realm')

That example doesn't apply to FGCP so I may be missing your point.
Load balancers go into network segments.
Storage volumes go into virtual systems.
So resources go into realms of a certain type.
That's why I suggested Realms#type/scope/etc. = [load_balancers,
instances]
and Realms#type/scope/etc. = [storage_volumes]
so that we can filter on it.

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.

> > > 3. Instances details
> > >
> > > The FGCP driver needs to make multiple backend calls to retrieve
all
> > > instance details per instance and can't complete before the
browser
> > > times out when the number of instances grows. My driver therefore
> > > retrieves only minimal detail for the instances operation and full
> > > detail for the instance (or instances with :id specified)
operation.
> > > How can a client determine whether the instances operation has
> returned
> > > all available details or whether it's worth invoking instance() to
> > > possibly get more details?
> >
> > I think this is a good compromise. We do something similar with
Buckets
> > collection in that GET single bucket will give you details about the
> > Blobs it contains, but GET index gives you only name and size. I
think
> > we could just document this in the API (i.e. that index operations
may
> > not return all details of the given resource)
> 
> Yes, I agree - I thought we were already doing that in some places;
> essentially index does best effort to get all details, but a client
> might have to query individual instances. We could also introduce an
> 'expand' param so the client can control the level of detail
> (shamelessly copying from CIMI)

We'll call it promoting elements of CIMI ;)

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

> > haven't heard of any requests yet. Looking at the current API, POST
> > /api/instances creates an instance, POST /api/instances/:id/:action
> > invokes a start/stop/etc action. We *could* consider adding a POST
> > /api/instances/:id/:update action with POST body for the updated hwp
> 
> If we actually update instance attributes, a PUT /api/instances/:id
> might be cleaner - with all the headaches around what exactly goes
into
> that request.

Let's wait for a user request :)

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

> > > 8. Storage volume attached
> > >
> > > Even if my driver specifies that the volume is not attached (i.e.
> > > :instance_id => nil), the UI says it is attached to 'unknown'.
Why?
> > > -> Suggestion: Raise bug and fix UI :)
> 
> Yeah, most likely.

I'll raise it.

> > > 9. Storage volume device name
> > >
> > > FGCP doesn't allow the user to specify the device name, nor can it
be
> > > retrieved.
> > > -> Suggestion: Make device attribute optional?
> 
> Ugh .. we need some sort of negative feature to indicate that in the
> API.

I believe this is not a blocker (at least not with the GUI) so we can
leave it for later.

> > > -> Suggestion: Make the snapshot id variable optional.
Additionally, we
> > > could consider implementing
storage_snapshots(opts[:created(_since)])
> so
> > > the user has a unique url to poll for it. Snapshots of a
particular
> > > volume cannot be created simultaneously so it should be accurate.
> 
> Same question as for image creation. Hopefully the same solution.

Unfortunately not: with the image we specify a unique name at creation
that we can search on later.
With the snapshot creation operation we can't specify any attributes
that we can search on later.

Cheers,
Dies


Mime
View raw message