On Tue, Aug 25, 2009 at 05:28:36PM -0400, Scott Seago wrote:
Bryan Kearney wrote:
5 Explicit mods to "Flavor"
+ RAM + CPU + Storage
i.e. per-Instance flavor mods -- since RHEV-m, oVirt both allow these to be customized on a per-instance basis.
6 oVirt driver
+ dcloud pool would map to a single VM pool in oVirt
ovirt as hte backend?
Not "the" backend but another driver in parallel to RHEV-M and ec2. I understood this point a bit different in the earlier discussion with Hugh though. When we built the model for dcloud we explicitly avoided the ovirt-like notion of separate resource pools for a single account (i.e. what oVirt calls VM Pools) since these didn't exist in RHEV-M and ec2. To support an oVirt driver as I understand we are doing now, they need to be accounted for somewhere. However, the dcloud portal pools are internal to the portal and not exposed to the driver. In addition, drivers handle resource limitations on an account basis, whereas oVirt handles them on a VM pool basis.
To get around this I was thinking for the ovirt driver we'd scope accounts around VM pools. We would add an optional "context ID" to the portal account object and make accounts unique on the (username, context_id) pair rather than just unique on username. For oVirt the context ID would be the VM pool. This would mean for an oVirt user with access to two VM pools there would be two Account objects in the portal.
Providers for VMWare ESX and Rackspace are a higher priority, BTW. I left this out of my notes originally.
10 Monitoring/stats display
How do we fit the widget in?
- Support for creating items based on realms.
I think we've got this already.
- I would get another driver so that other issues can be found.
i.e. oVirt driver.
- Do we talk about provisioning into the cloud?
So far the only provisioning we've done is image selection -- do we need more than this for version "1.0" ?
Yeah, I think we do, but I'm not sure what. Certainly we need a local image library and a way to move those images around.
--Hugh