Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ? l...@enovance.com ? +33 1 49 70 99 82 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.comhttp://labs.enovance.com/ // ✉ l...@enovance.commailto:l...@enovance.com ☎ +33 1 49 70 99 82
Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other
Re: [Openstack] Monitoring / Billing Architecture proposed
Probably an extra audit system is required. I'm searching for solutions in the IT market. Regards On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote: ** On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in
Re: [Openstack] Monitoring / Billing Architecture proposed
Hi Monsyne,
I have set the notification_driver param, but no notification.* queues
created. I'm using devstack stable/essex.
stack@ubuntu:/$ sudo rabbitmqctl list_queues
Listing queues ...
volume_fanout_e0923a8bbb9f45dc9e63d382796a4c8f 0
cert.ubuntu 0
consoleauth.ubuntu 0
compute 0
compute.ubuntu 0
scheduler.ubuntu0
network_fanout_1a3d6d9e946b46d1bf64fc38be5a38aa 0
volume.ubuntu 0
compute_fanout_b29d53b516bb4acc9f8fb1bd4a9fc7f1 0
cert0
scheduler 0
consoleauth_fanout_d0fad95fbd0749929a84830a56551420 0
scheduler_fanout_0d320a2d79404d1d833ac248a8ff3dfc 0
network 0
volume 0
network.ubuntu 0
consoleauth 0
...done.
stack@ubuntu:/$
stack@ubuntu:/$ sudo rabbitmqctl list_exchanges
Listing exchanges ...
consoleauth_fanout fanout
compute_fanout fanout
amq.rabbitmq.trace topic
network_fanout fanout
amq.rabbitmq.logtopic
amq.match headers
amq.headers headers
scheduler_fanoutfanout
volume_fanout fanout
amq.topic topic
amq.direct direct
amq.fanout fanout
novatopic
direct
...done.
stack@ubuntu:/$
On Tue, Apr 24, 2012 at 2:25 AM, Monsyne Dragon mdra...@rackspace.comwrote:
This looks like just the standard RPC traffic.
You need to turn notifications on
(set:
notification_driver=nova.notifier.rabbit_notifier
in nova's config file)
and listen on the notification.* queues
On Apr 23, 2012, at 2:26 PM, Luis Gervaso wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method:
get_floating_ips_by_project, _context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {request_spec: {num_instances:
1, block_device_mapping: [], image: {status: active, name:
cirros-0.3.0-x86_64-uec, deleted: false, container_format: ami,
created_at: 2012-03-20 17:37:08, disk_format: ami, updated_at:
2012-03-20 17:37:08, properties: {kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted:
false, created_at: null, ephemeral_gb: 0, updated_at: null,
memory_mb: 512, vcpus: 1, flavorid: 1, swap: 0, rxtx_factor:
1.0, extra_specs: {}, deleted_at: null, vcpu_weight: null, id: 2},
instance_properties: {vm_state: building, ephemeral_gb: 0,
access_ip_v6: null, access_ip_v4: null, kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, key_name: testssh,
ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977, instance_type_id:
2, user_data:
Re: [Openstack] Monitoring / Billing Architecture proposed
I take it that the instance manager doesn't generate any kind of heartbeat, so whatever monitoring/archiving service we do should internally poll the status over MQ? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote: Probably an extra audit system is required. I'm searching for solutions in the IT market. Regards On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote: On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova
Re: [Openstack] Monitoring / Billing Architecture proposed
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of
heartbeat, so whatever monitoring/archiving service we do should internally
poll the status over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in
the IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote:
**
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance
The event has the somewhat generic name of 'compute.instance.exists' and is
emitted on an periodic basis, currently by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook
is implemented for the kvm, etc drivers, it will be picked up automatically
for them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent
should collect this data from the nova queue instead of extracting it from
the system (interface, disk stats etc.) ? And for other openstack
components ( as Nick Barcet suggests below ) the metering agent will have
to find another way. Or do you have something else in mind ?
If it's something we have access to, we should emit it in those usage
events. As far as the other components, glance is already using the same
notification system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about
making sure all messages related to a billable event are accounted for. I
mean, for instance, what if the event that says an instance is deleted is
lost ? How is the billing software supposed to cope with that ? If it
checks the status of all VM on a regular basis to deal with this, how can
it figure out when the missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give
me a hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com
brian.sch...@nimbisservices.com 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).
When I wrote [1], one of the things that I never assumed was how agents
would collect their information. I imagined that the system should allow
for multiple implementation of agents that would collect the same
counters, assuming that 2 implementations for the same counter should
never be running at once.
That said, I
Re: [Openstack] Monitoring / Billing Architecture proposed
Yeah, but does that mean the instance is alive and billable :-)? I guess that
counts! I thought they were only in response to external API/admin requests.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 3:42 PM, Luis Gervaso wrote:
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of heartbeat,
so whatever monitoring/archiving service we do should internally poll the
status over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in
the IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote:
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each
instance The event has the somewhat generic name of
'compute.instance.exists' and is emitted on an periodic basis, currently
by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the
hook is implemented for the kvm, etc drivers, it will be picked up
automatically for them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent
should collect this data from the nova queue instead of extracting it from
the system (interface, disk stats etc.) ? And for other openstack
components ( as Nick Barcet suggests below ) the metering agent will have
to find another way. Or do you have something else in mind ?
If it's something we have access to, we should emit it in those usage
events. As far as the other components, glance is already using the same
notification system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about
making sure all messages related to a billable event are accounted for. I
mean, for instance, what if the event that says an instance is deleted is
lost ? How is the billing software supposed to cope with that ? If it checks
the status of all VM on a regular basis to deal with this, how can it figure
out when the missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a
hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.com
mailto:brian.sch...@nimbisservices.com 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
Re: [Openstack] Monitoring / Billing Architecture proposed
I think so.
If it is in response or not, it's a truly heartbeat
On Tue, Apr 24, 2012 at 9:46 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
Yeah, but does that mean the instance is alive and billable :-)? I guess
that counts! I thought they were only in response to external API/admin
requests.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 3:42 PM, Luis Gervaso wrote:
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of
heartbeat, so whatever monitoring/archiving service we do should internally
poll the status over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions
in the IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote:
**
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each
instance The event has the somewhat generic name of
'compute.instance.exists' and is emitted on an periodic basis, currently
by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook
is implemented for the kvm, etc drivers, it will be picked up
automatically for them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent
should collect this data from the nova queue instead of extracting it from
the system (interface, disk stats etc.) ? And for other openstack
components ( as Nick Barcet suggests below ) the metering agent will have
to find another way. Or do you have something else in mind ?
If it's something we have access to, we should emit it in those usage
events. As far as the other components, glance is already using the same
notification system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageDataabout
making sure all messages related to a billable event are accounted
for. I mean, for instance, what if the event that says an instance is
deleted is lost ? How is the billing software supposed to cope with that ?
If it checks the status of all VM on a regular basis to deal with this, how
can it figure out when the missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give
me a hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com
brian.sch...@nimbisservices.com 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
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 11:00 AM, Loic Dachary wrote: On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? FIrst, we use a reliable queueing mechanism to prevent that. Secondly there are periodic audit events that act as a check (and also contain data for usage over a time period, like bandwidth). It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com 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). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 2:31 PM, Brian Schott wrote:
I take it that the instance manager doesn't generate any kind of heartbeat, so
whatever monitoring/archiving service we do should internally poll the status
over MQ?
Actually, it generates periodic 'heartbeat' events ('exists' events) for each
instance that existed during a given audit period.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in the
IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary
l...@enovance.commailto:l...@enovance.com wrote:
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance
The event has the somewhat generic name of 'compute.instance.exists' and is
emitted on an periodic basis, currently by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook is
implemented for the kvm, etc drivers, it will be picked up automatically for
them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent should
collect this data from the nova queue instead of extracting it from the system
(interface, disk stats etc.) ? And for other openstack components ( as Nick
Barcet suggests below ) the metering agent will have to find another way. Or do
you have something else in mind ?
If it's something we have access to, we should emit it in those usage events.
As far as the other components, glance is already using the same notification
system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about making
sure all messages related to a billable event are accounted for. I mean, for
instance, what if the event that says an instance is deleted is lost ? How is
the billing software supposed to cope with that ? If it checks the status of
all VM on a regular basis to deal with this, how can it figure out when the
missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a
hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
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).
When I wrote [1], one of the things that I never assumed was how agents
would collect their information. I imagined that the system should allow
for multiple implementation of agents that would collect the same
counters, assuming that 2 implementations for the same counter should
never be running at once.
That said, I am not sure an event based collection of what nova is
notifying would satisfy the requirements I have heard from many cloud
providers:
- how do we ensure that event are not forged or lost in the current nova
system?
- how can I be sure that an instance has not simply crashed and never
started?
- how can I collect information which is not captured by nova events?
Hence the proposal to use a dedicated event queue for billing, allowing
for agents to collect and eventually validate data from different
sources, including, but
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 2:46 PM, Brian Schott wrote:
Yeah, but does that mean the instance is alive and billable :-)? I guess that
counts! I thought they were only in response to external API/admin requests.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
Actually, that is simply an rpc call message. Unrelated to notifications.
On Apr 24, 2012, at 3:42 PM, Luis Gervaso wrote:
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of heartbeat, so
whatever monitoring/archiving service we do should internally poll the status
over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in the
IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary
l...@enovance.commailto:l...@enovance.com wrote:
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance
The event has the somewhat generic name of 'compute.instance.exists' and is
emitted on an periodic basis, currently by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook is
implemented for the kvm, etc drivers, it will be picked up automatically for
them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent should
collect this data from the nova queue instead of extracting it from the system
(interface, disk stats etc.) ? And for other openstack components ( as Nick
Barcet suggests below ) the metering agent will have to find another way. Or do
you have something else in mind ?
If it's something we have access to, we should emit it in those usage events.
As far as the other components, glance is already using the same notification
system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about making
sure all messages related to a billable event are accounted for. I mean, for
instance, what if the event that says an instance is deleted is lost ? How is
the billing software supposed to cope with that ? If it checks the status of
all VM on a regular basis to deal with this, how can it figure out when the
missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a
hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
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
Re: [Openstack] Monitoring / Billing Architecture proposed
Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Hi, Although metering and billing always comes together for the deployment, for the sake of clarity, I also think metering should be a separate project from the billing, especially in openstack. (As you mentioned it, billing is complex and has too many different requirements per provider) Anyway, I am really interested in weekly meeting you mentioned in the email. How can I join the meeting? Is it irc-meeting?, mailing-list?, or else? -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community Apr 23, 2012, 4:09 PM, Nick Barcet 작성: Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/23/2012 11:17 AM, Ahn, Jaesuk wrote: Hi, Although metering and billing always comes together for the deployment, for the sake of clarity, I also think metering should be a separate project from the billing, especially in openstack. (As you mentioned it, billing is complex and has too many different requirements per provider) Anyway, I am really interested in weekly meeting you mentioned in the email. How can I join the meeting? Is it irc-meeting?, mailing-list?, or else? Of course you can join. It will be a weekly irc meeting and I am about to send a doodle with multiple time choices to everyone that mentioned being interested in joining this project at the summit, and have included your email now. The first meeting will have for objective to finalize a project name and validate a road-map of decisions that need to be made. Thanks a lot, Nick -- *Jaesuk Ahn*, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) *T. +82-10-9888-0328 | F. +82-303-0993-5340* *Active member on **OpenStack Korea Community* http://www.openstack.or.kr/ Apr 23, 2012, 4:09 PM, Nick Barcet 작성: Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Hi! We have developed Nova Billing v2. Its documentation is currently available at http://aababilov.github.com/nova-billing-doc.github.com/. The documentation includes a glossary and architecture and API descriptions. Nova Billing v2 is a totally new solution. Its API and architecture were rewritten from scratch. The new Nova Billing introduces extensible modularized system with separate components. Nova Billing v2 can charge arbitrary resources according to custom billing schemas and, naturally, with different tariffs. Nova Billing v2 does not depend on any UI for OpenStack Cloud (neither OpenStack Dashboard nor any other solution). It does not require a particular OpenStack release. Provided components allow integration with diablo and essex and this list can be extended. Nova Billing v2 is event-driven and does not consumes system resources for periodical polling. Nova Billing v2 uses a RESTful protocol, so it is easy to integrate it with miscellaneous user clients and to add third-party components notifying about arbitrary events. Alessio Ababilov, Software Engineer Grid Dynamics ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/23/2012 04:39 PM, Alexey Ababilov wrote: Hi! We have developed Nova Billing v2. Its documentation is currently available at http://aababilov.github.com/nova-billing-doc.github.com/. The documentation includes a glossary and architecture and API descriptions. Nova Billing v2 is a totally new solution. Its API and architecture were rewritten from scratch. The new Nova Billing introduces extensible modularized system with separate components. Nova Billing v2 can charge arbitrary resources according to custom billing schemas and, naturally, with different tariffs. Nova Billing v2 does not depend on any UI for OpenStack Cloud (neither OpenStack Dashboard nor any other solution). It does not require a particular OpenStack release. Provided components allow integration with diablo and essex and this list can be extended. Nova Billing v2 is event-driven and does not consumes system resources for periodical polling. Nova Billing v2 uses a RESTful protocol, so it is easy to integrate it with miscellaneous user clients and to add third-party components notifying about arbitrary events. Alessio Ababilov, Software Engineer Grid Dynamics Excellent! It sounds from the architecture that your work will easily be integrated into a the generic OpenStack metering solution that we are currently defining. The main goal of our design is to dissociate the metering from the billing part and to offer extensibility to all current and future components of OpenStack. Would you care to help us define this architecture? Thanks, Nick signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On Sun, 2012-04-22 at 20:50 +0200, Luis Gervaso wrote: I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) Except for the use of MongoDB, the above seems to me to be almost identical to the notifications system already in Nova, which Yagi consumes. Have you looked at our existing notifications? Yagi? One or both might solve at least parts of your problem… -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Nick, I want contribute in the discussion group. I have seen yagi implementation, and i like it. I like the protocol. But I think that it's a protocol that fits very well when no sensible data is involved (content feeds). When money, resources, companies are involved i think we need to use a more elaborated schema. I don't like the 3rd parties have to pull, my proporsal here is that 3rd parties can be entities externalized outside of the datacenter. 1. i don't want to make the accounting public accessible for security reasons. 2. 3rd parties can't be coupled to openstack, i want to feed them. I think this is the key. What i realized is that the listener needs to feed the billing system following the rules/api of the selected billing system. Scenario: 1. A company has an account on a billing provider 2. A company should define the pricing model in the billing system, outside openstack (i.e: inside zuora, jbilling, recurly, dough) 3. When a message arrives to the listener the listener has to perform the following actions: 3a: transform and store the message in a accounting system (restful api) 3b (optional): transform and store the message in a billing system (restful api) example: [ http://knowledgecenter.zuora.com/C_Zuora_User_Guides/A_Billing_and_Payments/A_Z-Billing ] 3c (optional): perform monitoring (currently evaluating sigar functionality) 3a: is openstack related 3b, 3c, ...: are hooks 4a. A company can query the billing system to gather the bills (no openstack dependencies) 4b. A company can query the monitoring system (no openstack dependencies) Regarding MongoDB, I recommend a document oriented database where we can query with criteria. Redis is key-value oriented. Cheers! On Mon, Apr 23, 2012 at 4:51 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Sun, 2012-04-22 at 20:50 +0200, Luis Gervaso wrote: I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) Except for the use of MongoDB, the above seems to me to be almost identical to the notifications system already in Nova, which Yagi consumes. Have you looked at our existing notifications? Yagi? One or both might solve at least parts of your problem… -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On Sun, Apr 22, 2012 at 5:29 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Dough is a proposed billing service. There was a session at Folsom design summit. This is a practical project for an OpenStack provider with test code on github. http://summit.openstack.org/sessions/view/37 The billing system consists of three components. 1) API Server, which receives subscribe/unsubscribe and usage query requests. 2) Farmer, which periodically checks all subscriptions and requests billing to the collector. 3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly. Kanyun is an OpenStack monitoring tool, but I don't see documentation in the code tree (but I've just pulled it to see). https://github.com/lzyeval Dough had mixed reviews during the session, but that I think was because it came across as a billing system triggered solely by Horizon requests and was a polled architecture. I also had some reservations about Dough because it seemed brittle. For example, it was my impression that if an instance creation operation failed for some reason, the operator had to manually correct the billing data. Given what we have today, I'd implement my own billing/metering system exactly the same way. In fact, I have. Our own e-commerce system at Nimbis works this way with EC2 and OpenStack presently because the only option available is polling periodically and logging the usage data. The fact that it only worked through Horizon was the biggest issue for us. That means if we expose the API to our users, instances created via the API but not the Horizon dashboard would not be billed. I understood the decision to be a proof-of-concept, but an event-based model for collecting the data seems much more robust and flexible. Where I'd like to see OpenStack go is metering service that is fully asynchronous and event driven so that I only need to hit the API service when I'm generating an invoice, rather than once per minute because I don't know when an instance was terminated by the user or just crashed. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote: What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.comwrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34)
Re: [Openstack] Monitoring / Billing Architecture proposed
Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi ( https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
If you wanted to use Yagi, it would be trivial to add a JSON only notifier to Yagi. If you're interested and need a hand, feel free to hit Dragon or I for assistance. From: Monsyne Dragon mdra...@rackspace.commailto:mdra...@rackspace.com Date: Mon, 23 Apr 2012 16:39:08 + To: Luis Gervaso l...@woorea.esmailto:l...@woorea.es Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
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. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/23/2012 07:06 PM, Luis Gervaso wrote: Nick, I want contribute in the discussion group. Luis, I just sent your an invite to the doodle to pick the best time for this irc meeting. Once the date will have been finalized (I'll close the poll tomorrow EOD), I'll announce the date, time and place on this list as well as to everyone that entered the poll. Anyone else wanting to participate in the poll for the meeting time may follow this link: http://doodle.com/zi6b6vxxkiuxyuqk Thanks, Nick signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Brian, Dough isn't dependent on Horizon. Dough has a client that can be inserted anywhere to notify the start/end of using a resource. We inserted the client in horizon just to try out the many ways our billing system could be integrated with our existing deployment. We are planning to make a Nova notifier to listen on the AMQP to automate the subscription process. However, we still have to devise a way to integrate Swift that would be symmetric with the things done in Nova. Also fail recovery is a feature we are working on right now. Separate the log and execution to cross-reference the logs and DB periodically. We plan to finish the first release this month and use it on our deployment. Let me know if you have other suggestions. Cheers, LZY On Tue, Apr 24, 2012 at 1:06 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Sun, Apr 22, 2012 at 5:29 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Dough is a proposed billing service. There was a session at Folsom design summit. This is a practical project for an OpenStack provider with test code on github. http://summit.openstack.org/sessions/view/37 The billing system consists of three components. 1) API Server, which receives subscribe/unsubscribe and usage query requests. 2) Farmer, which periodically checks all subscriptions and requests billing to the collector. 3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly. Kanyun is an OpenStack monitoring tool, but I don't see documentation in the code tree (but I've just pulled it to see). https://github.com/lzyeval Dough had mixed reviews during the session, but that I think was because it came across as a billing system triggered solely by Horizon requests and was a polled architecture. I also had some reservations about Dough because it seemed brittle. For example, it was my impression that if an instance creation operation failed for some reason, the operator had to manually correct the billing data. Given what we have today, I'd implement my own billing/metering system exactly the same way. In fact, I have. Our own e-commerce system at Nimbis works this way with EC2 and OpenStack presently because the only option available is polling periodically and logging the usage data. The fact that it only worked through Horizon was the biggest issue for us. That means if we expose the API to our users, instances created via the API but not the Horizon dashboard would not be billed. I understood the decision to be a proof-of-concept, but an event-based model for collecting the data seems much more robust and flexible. Where I'd like to see OpenStack go is metering service that is fully asynchronous and event driven so that I only need to hit the API service when I'm generating an invoice, rather than once per minute because I don't know when an instance was terminated by the user or just crashed. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote: What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough
Re: [Openstack] Monitoring / Billing Architecture proposed
I like http://wiki.openstack.org/SystemUsageData I just wonder if there should be offical formats for the data sent across the wire. Or at least high level formats that define the data, maybe in a simple python map style layout. With examples would be awesome. On 4/23/12 10:40 AM, Luis Gervaso l...@woorea.es wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 tel:443-274-6064 fx: 443-274-6060 tel:443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method:
get_floating_ips_by_project, _context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {request_spec: {num_instances:
1, block_device_mapping: [], image: {status: active, name:
cirros-0.3.0-x86_64-uec, deleted: false, container_format: ami,
created_at: 2012-03-20 17:37:08, disk_format: ami, updated_at:
2012-03-20 17:37:08, properties: {kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted:
false, created_at: null, ephemeral_gb: 0, updated_at: null,
memory_mb: 512, vcpus: 1, flavorid: 1, swap: 0, rxtx_factor:
1.0, extra_specs: {}, deleted_at: null, vcpu_weight: null, id: 2},
instance_properties: {vm_state: building, ephemeral_gb: 0,
access_ip_v6: null, access_ip_v4: null, kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, key_name: testssh,
ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977, instance_type_id:
2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=, vm_mode: null,
display_name: eureka, config_drive_id: , reservation_id:
r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id:
abe21eb7e6884547810f0a43c216e6a6, uuid:
40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z,
metadata: {}, display_description: eureka, memory_mb: 512,
launch_index: 0, vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null,
power_state: 0, auto_disk_config: null, progress: 0, os_type: null,
project_id: df3827f76f714b1e8f31675caf84ae9d, config_drive: },
security_group: [default]}, is_first_time: true, filter_properties:
{scheduler_hints: {}}, topic: compute, admin_password:
SKohh79r956J, injected_files: [], requested_networks: null},
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:52.089383, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method: run_instance,
_context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {instance_uuid:
40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, requested_networks:
Re: [Openstack] Monitoring / Billing Architecture proposed
The following links to work from OGF in the usage accounting and tracking area might be useful. First of all, we have the UsageRecord format (UR), which has been used in a variety of distributed computing environments for tracking usage. It defines an XML-based format for exchange of usage records. The format is general enough to describe a variety of distributed computing environments, but specific enough to allow practical usage and has served as the basis for usage accounting in grids, for example, for some time. http://ogf.org/documents/GFD.98.pdf We also have the following storage accounting work in process and nearly complete: https://forge.gridforum.org/sf/go/artf6532?nav=1 and http://www.ogf.org/Public_Comment_Docs/Documents/2012-02/EMI-StAR-OGF-info-doc-v2.pdf This document has just come out of public comment and is moving toward publication shortly. Between the UR work on traditional cpu accounting and the above storage accounting publication, I hope this provides some input into this topic from OGF. Alan On Apr 23, 2012, at 12:50 PM, Brian Schott 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. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es
Re: [Openstack] Monitoring / Billing Architecture proposed
Flavor information is copied to the Instance table on creation so the Flavors can change and still be tracked in the Instance. It may just need to be sent in the notification payload. The current events in the system are documented here: http://wiki.openstack.org/SystemUsageData -Sandy On 04/23/2012 02:50 PM, Brian Schott 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. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 tel:443-274-6064 fx: 443-274-6060 tel:443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 tel:%28%2B34%29%20627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 tel:210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe :
Re: [Openstack] Monitoring / Billing Architecture proposed
Great,
Now we just need to officialize those as a first step to making a real
interchange format that can be versioned, documented... and all the other
goodies u would normally expect.
On 4/23/12 12:26 PM, Luis Gervaso l...@woorea.es wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a, _context_is_admin:
false, _context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method: get_floating_ips_by_project,
_context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin], _context_request_id:
req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5, _context_read_deleted: no,
args: {request_spec: {num_instances: 1, block_device_mapping: [],
image: {status: active, name: cirros-0.3.0-x86_64-uec, deleted:
false, container_format: ami, created_at: 2012-03-20 17:37:08,
disk_format: ami, updated_at: 2012-03-20 17:37:08, properties:
{kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted: false,
created_at: null, ephemeral_gb: 0, updated_at: null, memory_mb: 512,
vcpus: 1, flavorid: 1, swap: 0, rxtx_factor: 1.0, extra_specs: {},
deleted_at: null, vcpu_weight: null, id: 2}, instance_properties:
{vm_state: building, ephemeral_gb: 0, access_ip_v6: null,
access_ip_v4: null, kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a,
key_name: testssh, ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977,
instance_type_id: 2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=, vm_mode:
null, display_name: eureka, config_drive_id: , reservation_id:
r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id: abe21eb7e6884547810f0a43c216e6a6,
uuid: 40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z, metadata:
{}, display_description: eureka, memory_mb: 512, launch_index: 0,
vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null, power_state: 0,
auto_disk_config: null, progress: 0, os_type: null, project_id:
df3827f76f714b1e8f31675caf84ae9d, config_drive: }, security_group:
[default]}, is_first_time: true, filter_properties: {scheduler_hints:
{}}, topic: compute, admin_password: SKohh79r956J, injected_files:
[], requested_networks: null}, _context_auth_token:
deb477655fba448e85199f7e559da77a, _context_is_admin: false,
_context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:52.089383, _context_user_id:
Re: [Openstack] Monitoring / Billing Architecture proposed
StackTach is a Django-based web interface for capturing, displaying and
navigating OpenStack notifications
https://github.com/rackspace/stacktach
-S
On 04/23/2012 04:26 PM, Luis Gervaso wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7, host: ubuntu, project_id:
c290118b14564257be26a2cb901721a2, rxtx_factor: 1.0},
_context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7, host: ubuntu, project_id:
c290118b14564257be26a2cb901721a2, rxtx_factor: 1.0},
_context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7, host: ubuntu, project_id:
c290118b14564257be26a2cb901721a2, rxtx_factor: 1.0},
_context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method:
get_floating_ips_by_project, _context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {request_spec:
{num_instances: 1, block_device_mapping: [], image: {status:
active, name: cirros-0.3.0-x86_64-uec, deleted: false,
container_format: ami, created_at: 2012-03-20 17:37:08,
disk_format: ami, updated_at: 2012-03-20 17:37:08, properties:
{kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525,
size: 25165824}, instance_type: {root_gb: 0, name: m1.tiny,
deleted: false, created_at: null, ephemeral_gb: 0, updated_at:
null, memory_mb: 512, vcpus: 1, flavorid: 1, swap: 0,
rxtx_factor: 1.0, extra_specs: {}, deleted_at: null,
vcpu_weight: null, id: 2}, instance_properties: {vm_state:
building, ephemeral_gb: 0, access_ip_v6: null, access_ip_v4:
null, kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, key_name:
testssh, ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977,
instance_type_id: 2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=,
vm_mode: null, display_name: eureka, config_drive_id: ,
reservation_id: r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id:
abe21eb7e6884547810f0a43c216e6a6, uuid:
40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z,
metadata: {}, display_description: eureka, memory_mb: 512,
launch_index: 0, vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null,
power_state: 0, auto_disk_config: null, progress: 0, os_type:
null, project_id: df3827f76f714b1e8f31675caf84ae9d, config_drive:
}, security_group: [default]}, is_first_time: true,
filter_properties: {scheduler_hints: {}}, topic: compute,
admin_password: SKohh79r956J, injected_files: [],
requested_networks: null}, _context_auth_token:
deb477655fba448e85199f7e559da77a, _context_is_admin: false,
_context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:52.089383, _context_user_id:
Re: [Openstack] Monitoring / Billing Architecture proposed
This looks like just the standard RPC traffic.
You need to turn notifications on
(set:
notification_driver=nova.notifier.rabbit_notifier
in nova's config file)
and listen on the notification.* queues
On Apr 23, 2012, at 2:26 PM, Luis Gervaso wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a, _context_is_admin:
false, _context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method: get_floating_ips_by_project,
_context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin], _context_request_id:
req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5, _context_read_deleted: no,
args: {request_spec: {num_instances: 1, block_device_mapping: [],
image: {status: active, name: cirros-0.3.0-x86_64-uec, deleted:
false, container_format: ami, created_at: 2012-03-20 17:37:08,
disk_format: ami, updated_at: 2012-03-20 17:37:08, properties:
{kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted: false,
created_at: null, ephemeral_gb: 0, updated_at: null, memory_mb: 512,
vcpus: 1, flavorid: 1, swap: 0, rxtx_factor: 1.0, extra_specs: {},
deleted_at: null, vcpu_weight: null, id: 2}, instance_properties:
{vm_state: building, ephemeral_gb: 0, access_ip_v6: null,
access_ip_v4: null, kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a,
key_name: testssh, ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977,
instance_type_id: 2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=, vm_mode:
null, display_name: eureka, config_drive_id: , reservation_id:
r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id: abe21eb7e6884547810f0a43c216e6a6,
uuid: 40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z, metadata:
{}, display_description: eureka, memory_mb: 512, launch_index: 0,
vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null, power_state: 0,
auto_disk_config: null, progress: 0, os_type: null, project_id:
df3827f76f714b1e8f31675caf84ae9d, config_drive: }, security_group:
[default]}, is_first_time: true, filter_properties: {scheduler_hints:
{}}, topic: compute, admin_password: SKohh79r956J, injected_files:
[], requested_networks: null}, _context_auth_token:
deb477655fba448e85199f7e559da77a, _context_is_admin: false,
_context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:52.089383,
Re: [Openstack] Monitoring / Billing Architecture proposed
On 04/23/2012 10:09 PM, Sandy Walsh wrote: Flavor information is copied to the Instance table on creation so the Flavors can change and still be tracked in the Instance. It may just need to be sent in the notification payload. The current events in the system are documented here: http://wiki.openstack.org/SystemUsageData Hi, Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. Cheers -Sandy On 04/23/2012 02:50 PM, Brian Schott 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. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 tel:443-274-6064 fx: 443-274-6060 tel:443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 tel:%28%2B34%29%20627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 tel:210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
[Openstack] Monitoring / Billing Architecture proposed
Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.comwrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Correct me if I am wrong but mongo has not been used in openstack previously? What is the benefit here that justifies bringing in new technology? Also are you planning an active polling process over AMPQ or passive listening for the monitor? It seems to me that most of the main components today can provide billing data via their API, there's no need to write anything new. Maybe we should just standardize billing related API queries across the board? -Matt On Sun, Apr 22, 2012 at 12:36 PM, Luis Gervaso l...@woorea.es wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On Sun, Apr 22, 2012 at 9:57 PM, Matt Joyce m...@nycresistor.com wrote: Correct me if I am wrong but mongo has not been used in openstack previously? What is the benefit here that justifies bringing in new technology? Mongo is document oriented, which i consider fits perfectly with the needs. It allows to query a huge json documents set. In older version of OpenStack the NoSQL used was Redis, this is key oriented Also are you planning an active polling process over AMPQ or passive listening for the monitor? Listen: The Message Listener will feed MongoDB It seems to me that most of the main components today can provide billing data via their API, You are right, the mediation has to transform the OpenStack specific data to the billing priovider. Then using the billing provider API we can feed it. there's no need to write anything new. We need to provider a driver for each billing provider Maybe we should just standardize billing related API queries across the board? I see this option outbound of OpenStack project (actually, this a rougth estimation ;) Cheers! -Matt On Sun, Apr 22, 2012 at 12:36 PM, Luis Gervaso l...@woorea.es wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Have you started a blueprint and/or Etherpad? We should do that. Couple of comments: 1. I had an idea for naming the metering service after Nipper, the famous RCA dog :-) http://en.wikipedia.org/wiki/Nipper 2. A common metering service that listens on Rabbit/ZeroMQ bus for registering events is a good idea, but we need to document some use case scenarios to really nail down the architecture. Who signals the metering service? The API service or nova, quantum, swift, glance, volume? I'd argue that the individual services need to hook into the metering service and that you can't just monitor the message bus for calls from the API service. - A user launches a flavor A instance of image X through the API service. When nova receives a run_instances request, nova signals nipper with the instance details, the flavor details, and image details. As the instance transitions through its states (pending, starting, running), nova signals nipper on each state change. Nipper will need to have an immutable copy of the current flavor, image, and instance information in case an administrator changes/deletes this information in the future. You want a bill to reflect what resources were consumed, not what the flavor describes when when the bill is generated. - From within the instance, a user issues a shutdown -h command. Nova signals nipper that the state has changed to shutting down, and then to stopped or terminated depending on nova's config. - A user creates a volume of flavor X of size N. (won't the volume service have different flavor of volumes like SSD, sparse, raid-x, ...?). The volume service signals nipper that the volume has been created. Nipper needs to have an immutable copy of the current volume flavor, utilization, and size. - A user allocates a public IP address. Quantum 2. A separate billing service should have a pricing plugin similar to nova's scheduler. This should handle generating quotes for a given flavor, image, volume, network, combination and generate invoices as you describe. 3. I'd steer away from mandating implementation technologies in the architecture. MongoDB is fine, but others here would prefer to make their own deployment choices. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 2:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.comwrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
my comments below On Sun, Apr 22, 2012 at 10:32 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Have you started a blueprint and/or Etherpad? We should do that. Couple of comments: 1. I had an idea for naming the metering service after Nipper, the famous RCA dog :-) http://en.wikipedia.org/wiki/Nipper 2. A common metering service that listens on Rabbit/ZeroMQ bus for registering events is a good idea, but we need to document some use case scenarios to really nail down the architecture. Who signals the metering service? The API service or nova, quantum, swift, glance, volume? I'd argue that the individual services need to hook into the metering service and that you can't just monitor the message bus for calls from the API service. Each service should signal the bus, these are the different exchanges/queues The metering service should subscribe to whatever it wants to be notified, then react with custom implementation for each event. I identify a template here: 1. persist the event (useful for accounting) 2. mediate and notify the monitoring tool 3. mediate and notify the billing tool 4. ... (whatever) Consider than extra billable services like platformlayer (from Justin) should feed the bus, and the metering should be aware of them in the same fashion. - A user launches a flavor A instance of image X through the API service. When nova receives a run_instances request, nova signals nipper with the instance details, the flavor details, and image details. As the instance transitions through its states (pending, starting, running), nova signals nipper on each state change. Nipper will need to have an immutable copy of the current flavor, image, and instance information in case an administrator changes/deletes this information in the future. You want a bill to reflect what resources were consumed, not what the flavor describes when when the bill is generated. My vision is that billable systems knows nothing about cloud, they only know how to bill items. So extra info is for accounting and monitoring. - From within the instance, a user issues a shutdown -h command. Nova signals nipper that the state has changed to shutting down, and then to stopped or terminated depending on nova's config. OK - A user creates a volume of flavor X of size N. (won't the volume service have different flavor of volumes like SSD, sparse, raid-x, ...?). The volume service signals nipper that the volume has been created. Nipper needs to have an immutable copy of the current volume flavor, utilization, and size. I think metering service, is only a dispatcher of asynchronous events to the specific systems. I mean metering is behind the firewall and billing, accounting, monitoring should not. - A user allocates a public IP address. Quantum 2. A separate billing service should have a pricing plugin similar to nova's scheduler. This should handle generating quotes for a given flavor, image, volume, network, combination and generate invoices as you describe. Totally agree, this is part of the billing system: for example Dough. Zuora, whatever 3. I'd steer away from mandating implementation technologies in the architecture. MongoDB is fine, but others here would prefer to make their own deployment choices. Agree, I have put them because I am working on a POC using these technologies Brian Thanks Brian! I like your vision! - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 2:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list:
Re: [Openstack] Monitoring / Billing Architecture proposed
Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net [openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of Endre Karlson [endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp http://www.csscorp.com/common/email-disclaimer.php ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On Sun, Apr 22, 2012 at 11:18 PM, Luis Gervaso l...@woorea.es wrote: I think Dough takes care about pricing and billing. I have proposed an arch and technologies to fill the gap between openstack and whatever billing system / monitoring system. On Sun, Apr 22, 2012 at 10:57 PM, Endre Karlson endre.karl...@gmail.comwrote: What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
Dough is a proposed billing service. There was a session at Folsom design summit. This is a practical project for an OpenStack provider with test code on github. http://summit.openstack.org/sessions/view/37 The billing system consists of three components. 1) API Server, which receives subscribe/unsubscribe and usage query requests. 2) Farmer, which periodically checks all subscriptions and requests billing to the collector. 3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly. Kanyun is an OpenStack monitoring tool, but I don't see documentation in the code tree (but I've just pulled it to see). https://github.com/lzyeval Dough had mixed reviews during the session, but that I think was because it came across as a billing system triggered solely by Horizon requests and was a polled architecture. Given what we have today, I'd implement my own billing/metering system exactly the same way. In fact, I have. Our own e-commerce system at Nimbis works this way with EC2 and OpenStack presently because the only option available is polling periodically and logging the usage data. Where I'd like to see OpenStack go is metering service that is fully asynchronous and event driven so that I only need to hit the API service when I'm generating an invoice, rather than once per minute because I don't know when an instance was terminated by the user or just crashed. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote: What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L
Re: [Openstack] Monitoring / Billing Architecture proposed
I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net[openstack-bounces+atul.jha= csscorp@lists.launchpad.net] on behalf of Endre Karlson [ endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto: brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com mailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp http://www.csscorp.com/common/email-disclaimer.php ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net
Re: [Openstack] Monitoring / Billing Architecture proposed
The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net [openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of Endre Karlson [endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post
Re: [Openstack] Monitoring / Billing Architecture proposed
Monitoring and billing seem to be two VERY different beasts. Should we be separating the two efforts? On Sun, Apr 22, 2012 at 3:08 PM, Brian Schott brian.sch...@nimbisservices.com wrote: The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net [openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of Endre Karlson [endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp
Re: [Openstack] Monitoring / Billing Architecture proposed
Why can't Dough / Kanyun be used for this? Endre. 2012/4/23 Brian Schott brian.sch...@nimbisservices.com The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net[openstack-bounces+atul.jha= csscorp@lists.launchpad.net] on behalf of Endre Karlson [ endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto: brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com mailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list
Re: [Openstack] Monitoring / Billing Architecture proposed
You are right. OpenStack should do only cloudcomputing. Others should manage better monitor and billing So we have to focus the effort to define the piece/component that orchestates the two/three/four ... beasts around OpenStack in a loosely coupled way. That is, other *should not* know OpenStack internals to do their work. On Mon, Apr 23, 2012 at 12:22 AM, Matt Joyce m...@nycresistor.com wrote: Monitoring and billing seem to be two VERY different beasts. Should we be separating the two efforts? On Sun, Apr 22, 2012 at 3:08 PM, Brian Schott brian.sch...@nimbisservices.com wrote: The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net [openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of Endre Karlson [endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net
Re: [Openstack] Monitoring / Billing Architecture proposed
Agreed. Not to mention all of those web commerce systems (Ubercart, Sachmo, Mezzanine/Cartridge, and many wordpress and rails commerce platforms I don't know). We don't need to reinvent selling stuff on the Internet. So, what's really missing? 1) The ability to query historical cloud resource utilization over a given time period for usage reports, graphs, and invoice generation. The alternative is polling the status interfaces frequently and caching externally. Many applications could use this with no need of billing semantics. Horizon can show you current instances, volumes, cores, memory, disk, etc. but no way it could give you a graph over time given that it doesn't store any historical data. It shouldn't store historical data, another OpenStack service should. 2) Maybe, the ability to register an external web hook for resource so I don't have to poll for state changes. This might be purely RESTful, so maybe this Nipper service returns 304 and lets the client cache? Does the OpenStack API support 304 not modified? I bet it doesn't because it doesn't have historical data. 3) Maybe, the ability to register an billing approval hook into keystone? Could be modeled like oauth style transaction. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 6:54 PM, Luis Gervaso wrote: You can, but there are more billing providers, i want to provider a point where you can choose your provider. I propose 4 possibilities as example: Scenario1 (this can be the reference implementation): OpenStack + Dough Scenario2: OpenStack + Zoura Scenario3: OpenStack + JBilling Scenario4: OpenStack + Recurly On Mon, Apr 23, 2012 at 12:26 AM, Endre Karlson endre.karl...@gmail.com wrote: Why can't Dough / Kanyun be used for this? Endre. 2012/4/23 Brian Schott brian.sch...@nimbisservices.com The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net [openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of Endre Karlson [endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22
Re: [Openstack] Monitoring / Billing Architecture proposed
On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott brian.sch...@nimbisservices.com wrote: Agreed. Not to mention all of those web commerce systems (Ubercart, Sachmo, Mezzanine/Cartridge, and many wordpress and rails commerce platforms I don't know). We don't need to reinvent selling stuff on the Internet. So, what's really missing? 1) The ability to query historical cloud resource utilization over a given time period for usage reports, graphs, and invoice generation. The alternative is polling the status interfaces frequently and caching externally. Many applications could use this with no need of billing semantics. Horizon can show you current instances, volumes, cores, memory, disk, etc. but no way it could give you a graph over time given that it doesn't store any historical data. It shouldn't store historical data, another OpenStack service should. Exactly. I'm evaluating such systems, actually I want to transform events from openstack into billable items on a billing system. So I store event for historical queries (accounting service) and send billable info to billing system to avoid a billing system has to pull openstack. 2) Maybe, the ability to register an external web hook for resource so I don't have to poll for state changes. This might be purely RESTful, so maybe this Nipper service returns 304 and lets the client cache? Does the OpenStack API support 304 not modified? I bet it doesn't because it doesn't have historical data. I have not found any 304 in the API 3) Maybe, the ability to register an billing approval hook into keystone? Could be modeled like oauth style transaction. I think we can use the existing X-Auth-Token with a billing system role as the first approach (i have to look closer) - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 6:54 PM, Luis Gervaso wrote: You can, but there are more billing providers, i want to provider a point where you can choose your provider. I propose 4 possibilities as example: Scenario1 (this can be the reference implementation): OpenStack + Dough Scenario2: OpenStack + Zoura Scenario3: OpenStack + JBilling Scenario4: OpenStack + Recurly On Mon, Apr 23, 2012 at 12:26 AM, Endre Karlson endre.karl...@gmail.comwrote: Why can't Dough / Kanyun be used for this? Endre. 2012/4/23 Brian Schott brian.sch...@nimbisservices.com The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net[openstack-bounces+atul.jha= csscorp@lists.launchpad.net] on behalf of Endre Karlson [ endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto: brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough
Re: [Openstack] Monitoring / Billing Architecture proposed
Hi, I'm the person who presented Dough. After my presentation there were lots of feedback from many people. The conclusion was that no matter how generic I tried to design Dough, the billing requirements of each company will vary if they have different metering specifications. Therefore a few companies have agreed to first work on a metering system together as described in http://wiki.openstack.org/EfficientMetering and http://etherpad.openstack.org/EfficientMetering They plan to officially launch a metering project and incubate the project in Folsom if possible. What I plan to do with Dough is to first use it in production and present how it worked out in our beta service at the next summit. Kanyun will be replaced with the new metering system. I'll work on the documentation of Dough once I finish testing it with our closed beta production environment. Cheers, LZY On Sun, Apr 22, 2012 at 5:43 PM, Luis Gervaso l...@woorea.es wrote: On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott brian.sch...@nimbisservices.com wrote: Agreed. Not to mention all of those web commerce systems (Ubercart, Sachmo, Mezzanine/Cartridge, and many wordpress and rails commerce platforms I don't know). We don't need to reinvent selling stuff on the Internet. So, what's really missing? 1) The ability to query historical cloud resource utilization over a given time period for usage reports, graphs, and invoice generation. The alternative is polling the status interfaces frequently and caching externally. Many applications could use this with no need of billing semantics. Horizon can show you current instances, volumes, cores, memory, disk, etc. but no way it could give you a graph over time given that it doesn't store any historical data. It shouldn't store historical data, another OpenStack service should. Exactly. I'm evaluating such systems, actually I want to transform events from openstack into billable items on a billing system. So I store event for historical queries (accounting service) and send billable info to billing system to avoid a billing system has to pull openstack. 2) Maybe, the ability to register an external web hook for resource so I don't have to poll for state changes. This might be purely RESTful, so maybe this Nipper service returns 304 and lets the client cache? Does the OpenStack API support 304 not modified? I bet it doesn't because it doesn't have historical data. I have not found any 304 in the API 3) Maybe, the ability to register an billing approval hook into keystone? Could be modeled like oauth style transaction. I think we can use the existing X-Auth-Token with a billing system role as the first approach (i have to look closer) - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 6:54 PM, Luis Gervaso wrote: You can, but there are more billing providers, i want to provider a point where you can choose your provider. I propose 4 possibilities as example: Scenario1 (this can be the reference implementation): OpenStack + Dough Scenario2: OpenStack + Zoura Scenario3: OpenStack + JBilling Scenario4: OpenStack + Recurly On Mon, Apr 23, 2012 at 12:26 AM, Endre Karlson endre.karl...@gmail.comwrote: Why can't Dough / Kanyun be used for this? Endre. 2012/4/23 Brian Schott brian.sch...@nimbisservices.com The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost. Not clear at my first review where/how these costs are set. Brian - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote: I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ... I'm proposing the way the events should be orchestated Please, correct me, if i'm wrong Luis On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha atul@csscorp.comwrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net[openstack-bounces+atul.jha= csscorp@lists.launchpad.net] on behalf of Endre Karlson [ endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto: brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org
Re: [Openstack] Monitoring / Billing Architecture proposed
: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto: brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto: brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto: endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp http://www.csscorp.com/common/email-disclaimer.php ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net
Re: [Openstack] Monitoring / Billing Architecture proposed
atul@csscorp.com wrote: Hi, Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net [openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of Endre Karlson [endre.karl...@gmail.com] Sent: Monday, April 23, 2012 2:27 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.esmailto:l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344tel:%28%2B34%29%20627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp http://www.csscorp.com/common/email-disclaimer.php ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es
