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 03:00:29 GMT
On Thu, 2012-05-03 at 13:28 +0300, marios@redhat.com wrote:
> On 30/04/12 16:45, Koper, Dies wrote:
> 
> 8<---snip---8<
> > 
> > 1. FGCP API's image creation API does not return ID straight away
> > 
> > I mentioned this before, FGCP's image creation API does not return the
> > image id straight away (same for public IPs and storage snapshots,
> > covered below). Once the image creation has completed, it will be
> > returned by the image list API, including the new id. The FGCP Portal
> > has an Image Manager screen which shows the image creation progress but
> > there is no API for it.
> > -> Suggestion: Make the image id variable optional. Additionally, we
> 
> I don't see how this would help though. It would only allow you to ommit
> 'pending' from the Image you return from 'create_image' but still
> wouldn't give the user indication of the status. An immediate thought is
> to consider adding some kind of 'Job' entity to deltacloud but even this
> wouldn't be much use, since FGCP doesn't provide API access to the image
> 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 ? If I create two images almost simultaneously, how can I
distinguish them ?

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.

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

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.

For the parent-child relationship: do we really need it ? And rather
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')

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

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

> > 5. Instance hwp change
> > 
> > The FGCP, and I suppose other clouds, allow a user to change the
> > hardware profile of an instance (e.g. increasing memory/cpu) when the
> > instance is not running. I believe DC does not support this yet. Have
> > you had no requests for that yet?
> > 
> 
> 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.

> > 6. Storage volumes in realm
> > 
> > As mentioned in 2., would be nice if only the relevant realms (i.e.
> > VSYS) where listed. Instead of only the first one as the UI does.
> > 
> > 7. Storage volume types and snapshots
> > 
> > FGCP API returns two types of volumes, system volumes (which are the
> > volumes instances boot from, created from the disk images) and
> > additional storage (additional, detachable volumes). The latter are
> > always empty at creation and cannot currently be cloned.
> > 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.

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

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

> > 10. Storage snapshot creation does not return an id straight away
> > 
> > The FGCP storage volume backup operation does not return an id straight
> > away. On the FGCP Portal it does, with details of the progress of the
> > snapshot creation process, but no API equivalent.
> > The only way to find out the id is to keep listing the backups of a
> > volume until the new entry appears.
> > 
> > -> 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.

... the rest of your issues, I need to come back to ...

David



Mime
View raw message