> 2. Realms mapping > -> 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.
We spoke about realms before I implemented all the operations that depend on it. The original idea hasn't changed, it would fit well for FGCP, re-usable by other providers and not affect existing DC users. The tree structure is mostly useful to show the hierarchy in the GUI that is inherently there. As most driver operations show little detail when listing all and much detail when listing one, I think the relationship between realms and sub-realms would be better managed on the sub-realm side, i.e. a realm has a parent_id attribute, not a list of sub-realms. The type/scope/purpose(/limit?) is mostly for filtering when you need a realm for a particular purpose (such as creating an instance or a storage volume). Maybe we can re-use the collection names, e.g.: Realm A name: myVSYS id: dkoper-myVSYS scope: storage_volumes, addresses Realm B name: myVSYS [DMZ] id: dkoper-myVSYS-DMZ scope: instances parent_id: dkoper-myVSYS Realm C name: myVSYS [SECURE1] id: dkoper-myVSYS-SECURE1 scope: instances, load_balancer parent_id: dkoper-myVSYS So when we create an instance through the DC GUI, it could show a list of available realms filtered by scope:instance. What do you think? Cheers, Dies Koper > -----Original Message----- > From: Koper, Dies [mailto:[email protected]] > Sent: Monday, 30 April 2012 11:46 PM > To: [email protected] > Subject: outstanding issues with FGCP driver > > 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 >
