David Lutterkort wrote:
On Wed, 2009-08-05 at 17:22 -0400, Scott Seago wrote:
Based on Bob's xml api examples and prior discussions with lutter and Hugh on the portal AR model, I've come up with an initial model specification. At this point I've only included those attributes that Bob has already identified.
Once we've nailed down the attributes, associations and validation rules for this stuff we can start integrating it into the controllers and UI bits.
Looks good.
What is the Flavor object used for ? Do we need to keep track of capacity by architecture ? And if that's the case, shouldn't the Flavor belong to the CloudPool rather than the Provider ?
Flavor is the the way of setting VM size. 'small' 'medium' 'large' etc. It's apparently what ec2 calls it, so the api that Bob is working on uses it as well. It doesn't belong to the CloudPool since that's purely a Proxy/Portal creation, and this belongs to the provider itself. i.e. on ec2, it's ec2 that defines what 'small' means, etc.
In terms of terminology, I would call CloudAccount just Account (or maybe Credentials ?) and PortalPool just Pool - if we need to handle cloud-side pools at some point, we can always call them something else like 'Partition' or some such.
I've got a more immediate reason to use PortalPool instead of Pool for the immediate term -- Pool exists in the oVirt model we're working out of, and I don't want to spend the time to rip it out right now. Lets stick with PortalPool now but we can discuss whether it should change later. The other reason I called it PortalPool was to make it clear that this isn't something that exists like this on the cloud side -- it only belongs to portal/proxy. Also, We have an Account object already -- that's the ldap construct in oVirt. In addition, CloudAccount makes it clear that these are external accounts that we're linking to internal (proxy/portal) Users. Should we call it ExternalAccount instead?
Since I enjoy drawing UML diagrams lately, attached a diagram for what's in the Ruby code, both as a png and dia file.
There's of course no end to the attributes that could be added/changed, but I think this is a good start.
Right. I'm sure we need more attributes -- the list below is based on Bob's API email from last Saturday.
Scott
David