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
