Now that we have a demo UI put together Scott and I wanted to start serious discussion around what to implement next for the dloud portal. Here's a list of things to discuss, please comment in-line.
deltacloud-portal-design-points ===============================
Date: 2009-08-25 16:47:26 EDT
1 What's missing in the models ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Storage (and the whole boatload of issues around image management) + Custom attributes + Actions
2 Polling and updating ~~~~~~~~~~~~~~~~~~~~~~ + Lots to do here figuring out how we're going to poll the different driver/providers for updates. + Also we need to work out a parallel monitoring API -- do we need separate monitoring drivers?
3 Permissions model ~~~~~~~~~~~~~~~~~~~ + We know portal users will need and be granted permissions on pools + Do we need single-user ownership of pools as well? + Do we need to track images and realms on the cloud providers and relate them back to our users, or is the user->pool->account mapping sufficient for this?
4 Validation infrastructure, going down to the drivers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Names (validity, length, uniqueness)
5 Explicit mods to "Flavor" ~~~~~~~~~~~~~~~~~~~~~~~~~~~ + RAM + CPU + Storage
6 oVirt driver ~~~~~~~~~~~~~~ + dcloud pool would map to a single VM pool in oVirt
7 Quotas ~~~~~~~~ + We need to be aware of cloud-side quotas + We need to manage portal-side quotas on pools
8 Proxy vs. Portal ~~~~~~~~~~~~~~~~~~ + Is the proxy API the same as the deltacloud API, or is there more going on there
9 What additional non-REST APIs if any do we support ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + QMF? + Web services (SOAP)?
10 Monitoring/stats display ~~~~~~~~~~~~~~~~~~~~~~~~~~~ How do we fit the widget in?