openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott <
brian.schott@xxxxxxxxxxxxxxxxxx> wrote:

> Doug,
>
> Do we mirror the table structure of nova, etc. and add created/modified
> columns?
>

> Or do we flatten into an instance event record with everything?
>

I lean towards flattening the data as it is recorded and making a second
pass during the bill calculation. You need to record instance modifications
separately from the creation, especially if the modification changes the
billing rate. So you might have records for:

created instance, with UUID, name, size, timestamp, ownership information,
etc.
resized instance, with UUID, name, new size, timestamp, ownership
information, etc.
deleted instance, with UUID, name, size, timestamp, ownership information,
etc.

Maybe some of those values don't need to be reported in some cases, but if
you record a complete picture of the state of the instance then the code
that aggregates the event records to produce billing information can use it
to make decisions about how to record the charges.

There is also the case where an instance is still no longer running but
nova thinks it is (or the reverse), so some sort of auditing sweep needs to
be included (I think that's what Dough called the "farmer" but I don't have
my notes in front of me).


>
> Bran
>
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott@xxxxxxxxxxxxxxxxxx
> ph: 443-274-6064  fx: 443-274-6060
>
>
>
> On Apr 23, 2012, at 3:23 PM, Doug Hellmann wrote:
>
>
>
> On Mon, Apr 23, 2012 at 1:50 PM, Brian Schott <
> brian.schott@xxxxxxxxxxxxxxxxxx> wrote:
>
>> So, we could build on this. No reason to reinvent, but we might want to
>> expand the number of events.  I'm concerned about things like what happens
>> when flavors change over time.  Maybe the answer is, always append to the
>> flavor/instance-type table.  The code I remember and the admin interface
>> that Ken wrote allowed you to modify flavors.  That would break billing
>> unless you also track flavor modifications.
>>
>
> That seems like a situation where you would want to denormalize the
> billing database and record the flavor details along with the rest of the
> creation event data.
>
> Doug
>
>
>