deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject Re: feedback request regarding FGCP driver patch
Date Thu, 12 Apr 2012 01:39:25 GMT
Hi Dies,

great to see this much progress on the driver - from glancing at it, it
looks very promising.

On Thu, 2012-04-12 at 00:15 +1000, Koper, Dies wrote:
> 1. The default storage paths for the user and CA certificates and the
> environment variables to override them with.

I wouldn't store the certs in a path relative to __FILE__ - in a lot of
cases that will be under /usr, and writing there from code is pretty
unfriendly. If FGCP_CERT_DIR is not set, I would try looking either for
something in $HOME/.deltacloud or in /var/tmp/deltacloud/fgcp ... since
these are certs, I wonder if the latter is really that great. Since
deltacloudd often runs as a system daemon, I don't really like storing
in $HOME either.

Maybe it is time that we assume the existence of /var/lib/deltacloud and
store everything there ? This would require that we at the very least
also change the mock driver and have it store its data
in /var/lib/deltacloud/mock

> 2. Instance :username is hardcoded to 'root' in some drivers. In FGCP it
> depends on the image's OS: 'root' for Linux and 'Administrator' for
> Windows. There is no API to get the username but I could check the OS
> from the instance's image and return the right username that way. I
> couldn't find any other drivers doing this. What would you recommend?
> Add the call or just not set :username?

I think mapping from OS to username is icky, but should be fine.

> 3. 'feature :instances, :hardware_profiles', what does it do?

It allows overriding HWP propeties on instance creation - that only
makes sense with HWP that use ranges or enums for some of their
parameters. E.g., if a HWP says 'memory must be between 2GB and 8GB with
a default of 4GB', the presence of this feature allows users to pass in
hwp_memory=3 when they create an instance.

> 4. hardware_profiles.storage: storage is defined as part of the image in
> FGCP, not the hwp. Should I just not set this variable, or set it to a
> particular value (like 'N/A')?

Good question - omitting it would be cleaner to me, though API users
might trip over themselves; would be good to check at least the Ruby
client to see if it will be happy with HWP w/o storage.

Otherwise, we could also set it to 0.

> 5. Is there an easy way to sort the hardware_profiles before returning
> them? Especially if hwp setting is optional when creating a new instance
> I'd like to default to the lowest spec one, but that is currently not
> the first one returned by hardware_profiles. So I'd like to sort its
> profiles by memory and cpu before returning them.

No, there's nothing built in; you'll get to have some fun with
Array#sort - don't be shy to implement a '<=>' in
Deltacloud::HardwareProfile to make that simple. I think sorting
ascending by [cpu, memory] is very sane.

> 6. FGCP's create image from instance API does not return the new image
> id straight away. In fact, it is not known until the creation process
> completes. What do you think of my solution to return a dummy id? Shall
> I add a check for that ID in create_instance to raise an error?

You can't just return a dummy id, since that will become part of the URL
for the image (it will be /images/:id) - and that URL needs to stay
fixed for as long as the image stays around.

How does the FGCP API deal with somebody creating 5 images from 5
different instances ? How would a user know which image comes from what
instance ?

> 8. I had browser timeouts with the instances method so I reduced the
> amount of detail given when no :id is specified. What do you think of
> the rules I use decide whether to add detail? OK like that or make it
> more predictable and return more detail only for the case where id is
> given?

It's fine to return only some detail about instances for /instances (as
long as each instance has a URL from which you can retrieve all details)

> 10. Images' hardware profiles: In FGCP images can be used with any
> hardware profile, so I'm saving a call (to retrieve the hardware profile
> list) and return an empty array. Should I return the hwps anyway?

How often can HWP change in FGPC ? If they don't change, just retrieve
them once and then stick them into a class variable.

> Storage is defined by the image so I could return the list of profiles
> with the storage specified too.

Hmmm ... I am not sure what the effect would be if the same HWP
sometimes has storage=0 and sometimes storage=200. I wouldn't return
anything different for the HWP's on an image.

> 11. valid_credentials?: I only noticed about this method when I was
> looking at some of the other drivers' unit tests. It's not in the online
> API documentation. How/why would a client use it?

It's meant to allow quickly checking that you have the right
credentials, before you do actual work.

David



Mime
View raw message