On Fri, Jun 29 2012, Doug Hellmann wrote: Hi Doug,
Sorry for the late reply. > I don't think I've made the problem clear. > > I'm not talking about wanting to calculate the different usage for CPU, > RAM, etc. The different counters are calculated separately, so we can keep > the amounts for CPU and RAM completely separate, and the API allows the > outside user to ask for the amounts for each counter for a resource (or > globally for a user/project). The problem is in deciding how the metadata > associated with a meter event might cause the provider to change the rate > they want to charge for that usage. It's not metadata of a counter that cause the provider to change the rate. It's a meter of a resource that can do that. > That only solves part of the problem, though. As a provider I may want to > charge different flat rates for the amount of RAM being used. For example, > 1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the size > of the VM changes, we need to produce multiple totals (the length of time > that the VM had 1024 MB RAM and then the length of time it had 4096 MB RAM). Yeah, like I said, for the meter 'RAM' of resource 'instance' you can't request a total amount used, because the type of this meter (I don't know how to call it, it's the kind I named if-i-change-you-need-to-split-the-resource-in-several-stuff in my latest email) don't have this semantic. > I might also want to change the rate I bill when a VM is migrated between > hosts or availability zones (I think we said migration caused a new > instance to be created, but bear with me). The availability zone for an > instance is clearly metadata and not something we can track via a counter. Again, that's also a meter that has the same type of 'RAM' for a resource 'instance'. > That's an interesting idea, and it might solve the problem. At this point > in the Folsom schedule though, I would much rather implement a pared down > API that handles the simple cases but makes the caller do a bit more data > manipulation for complex cases, in favor of focusing on counting more > things than we do now. Is that a reasonable approach? Problem is that we might break the API a bit with this. This would not be the first time an OpenStack API is broken, but if we can avoid it, it'd be better. I am not sure you can really bill anything if you're not able to handle a simple thing such a VM resize. So currently, it seems that the API is not designed correctly to handle such a case, and since it's not yet implemented, maybe it's still time to fix it? -- /* Julien Danjou ╭ Free Software hacker & freelance ╰ http://julien.danjou.info */
pgpBtQSHifQMF.pgp
Description: PGP signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
