Hi,
I've implemented all operations that I could map between DC and FGCP and
am ready to submit a patch again.
Below I'm listing the issues I've found. I think each of them would
require changes in the DC API to resolve.
I invite you to try the driver out on the FGCP and see what you think.
https://issues.apache.org/jira/browse/DTACLOUD-176
These are the collections I've covered in my driver:
DEFAULT_COLLECTIONS + [ :addresses, :load_balancers, :firewalls ]
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
could consider implementing images(opts[:name]) so the user does have a
fairly unique url to poll for it. (The FGCP driver would still need to
retrieve the whole image list so it's more of a convenience method than
a performance improvement.)
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.
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?
4. Instance creation in realm
As mentioned in 2., would be nice if only the relevant realms (i.e. the
network segments) where listed.
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?
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)?
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 :)
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?
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.
11. Address creation requires realm id
In the FGCP address are created into a particular realm. How is it for
other providers?
My driver currently just picks the first realm (VSYS) that the API
returns if :realm_id is not specified.
Suggestion: Make it a feature so that we can extend the GUI to allow the
user to select the realm from a list as is done for instance creation.
12. Address creation does not return new IP straight away
The FGCP address creation operation does not return an id/ip straight
away. The only way to find out the new ip is to keep listing the
addresses until a new entry appears.
-> Suggestion: Make the id optional?
13. Address association
For performance reasons the addresses my driver returns for addresses()
does not include the instance_id's they are assigned to.
I do include this when a single address is queried. The GUI lists all
addresses as 'Free'. How can we implement a third state ('not
checked-drill down for details') for attributes like this? Use an empty
string?
14. Address lifecycle mapping to DC
Addresses in FGCP require more steps until they can be used compared to
what DC expects:
FGCP:
1. Create address in realm (VSYS)
2. Enable address
3. Attach address to instance
4. Detach from instance
5. Disable address
6. Destroy
DC:
1. Create address
2. Attach
3. Detach
4. Destroy
As each of the operations are asynchronous, I can't easily merge three
into two (two into one) unless I introduce sleeps and polling.
Any advice on how to resolve this?
I currently combine the enable with the attach and the disable with the
destroy. This means the first time you do an associate it fails with an
error, but works if you try again after a while.
-> Suggestion: Introduce enable & disable action/feature either on all
providers, implemented as NOP where not relevant, or FGCP feature?
15. Firewalls mapped to instances and VSYS
In the FGCP a firewall is automatically created as part of the creation
of a VSYS. The FW needs to be started (it is actually implemented as a
special VM in your VSYS) before you can register any rules. The driver
therefore includes it in the instances list so you can start and stop
it.
Can we make it a feature that some providers allow FW creation and rule
creation in one operation, which FGCP won't support?
In FGCP, when creating a VSYS, you have to specify a VSYS descriptor.
The VSYS descriptor defines whether the VSYS is a 1, 2 or 3 tier network
and can include server instance descriptions (i.e. you could have a LAMP
VSYS descriptor that would allow you to create a 2 server - one in DMZ
and one in SECURE zone - system created in one operation).
So I've mapped FW creation to VSYS creation using the FW description as
descriptor. Should we introduce a separate feature/attribute instead?
The FGCP FW rules also don't map well in all cases to DC's. I'll save
that for a separate e-mail. (Or maybe you can have a look yourself on
the FGCP portal?)
16. Load balancers mapped to instances and VSYS
The load balancer on FGCP needs to be started (it is actually
implemented as a special VM in your network segment) before you can
register any rules. The driver therefore includes it in the instances
list so you can start and stop it.
Can we make it a feature that some providers allow load balancer
creation and rule creation in one operation, which FGCP won't support?
The FGCP load balancer rules also don't map well at all to DC's
listeners. I'll save that for a separate e-mail.
That's it for now.
Cheers,
Dies Koper
