Re: [Openstack] [ceilometer] Potential New Use Cases
Yes, I see a general need to be able to represent meta data the identifies associations between monitored systems and between usage stored in the datastore. There could be a variety of ways that we need to relate event data, so the mechanism should be relatively generic. In addition to your use case, we would want to be able to map instances to other tenants, group VM's together to represent some kind of shared identity or behavior, map instances to some kind of special service type. I think there are big advantages to keeping the collection and storage of this data separate: 1. It does not require Nova to be aware of the details of the VM internals. 2.It allows for deferral of processing until later in the rating process, which helps on scalability 3. makes it easier to extract and report on this data for other use cases besides the base billing 4. it more extensible in the sense that you can add arbitrary metadata without affecting the core usage data generation. We use this information as part of our rating process to determine the correct charges to apply, so we will need to be able to query for it. Dan On 11/5/2012 5:04 AM, Doug Hellmann wrote: On Fri, Nov 2, 2012 at 4:42 PM, Dan Dyer dan.dye...@gmail.com mailto:dan.dye...@gmail.com wrote: Yes, I am assuming the service controller provides a different stream of data from the lower level VM events. So the question is how to represent and store this additional meta data in ceilometer. Note that there doesn't necessarily need to be a linkage/grouping between the resources since the association is what is actually contained in the metadata that is provided by the service controller. As a summary Nova provides its normal events for usage Service controller provides a mapping of nova instances to service type and actual end user So the problem isn't necessarily that you want to measure something different, but that the ownership in the existing data is not correct from the perspective of the billing system. We have a similar issue at DreamHost. Our existing user database has account ids that need to be mapped to tenant ids from keystone. Rather than putting that information in keystone, or ceilometer, we decided to store it in our system and have the DreamHost billing system drive the ceilometer API. Does it make sense to do something similar here? If we definitely want ceilometer to hold the metadata, then I could also see adding an API to let an outside system add metadata to a resource. That would let the PaaS code, which knows about each VM, store extra data that would be returned with the VM metadata when a caller visits /resources/resourceid. Would you expect to be able to query using the metadata? For example, provide the total instance hours for all instances with paas_tag=foo? Doug Dan On 11/1/2012 11:25 AM, Doug Hellmann wrote: On Thu, Nov 1, 2012 at 10:21 AM, Dan Dyer dan.dye...@gmail.com mailto:dan.dye...@gmail.com wrote: In some cases, the service controller is actually running inside a VM. It would not have access to the internals of the VM's. It maintains its metadata separately from the Nova infrastructure. It doesn't need internal access to the VM, but something has to share the metadata with ceilometer (or join it to the data ceilometer has) at some point. If it would be too difficult to get the data into the events, then it could be done by the app that uses the ceilometer API to query for usage. For example, the app that loads data from ceilometer to your real billing system could be driven by data saved by the service controller in whatever database it uses. Doug DD On 10/25/2012 2:25 AM, Nick Barcet wrote: Let's imagine that the service that launch instances can tag the instance with: a) a common service identifier (constant) b) a uuid unique for each Unit of the service such as constant:uuid If that tag is passed onto the events which ceilometer stores in its entirety as meta, I do not see what the difficulty would be for the rating engine to be able to reconcile the information to handle your 2 use cases. Am I missing something? Nick On 10/25/2012 12:03 AM, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper
Re: [Openstack] [ceilometer] Potential New Use Cases
On Fri, Nov 2, 2012 at 4:42 PM, Dan Dyer dan.dye...@gmail.com wrote: Yes, I am assuming the service controller provides a different stream of data from the lower level VM events. So the question is how to represent and store this additional meta data in ceilometer. Note that there doesn't necessarily need to be a linkage/grouping between the resources since the association is what is actually contained in the metadata that is provided by the service controller. As a summary Nova provides its normal events for usage Service controller provides a mapping of nova instances to service type and actual end user So the problem isn't necessarily that you want to measure something different, but that the ownership in the existing data is not correct from the perspective of the billing system. We have a similar issue at DreamHost. Our existing user database has account ids that need to be mapped to tenant ids from keystone. Rather than putting that information in keystone, or ceilometer, we decided to store it in our system and have the DreamHost billing system drive the ceilometer API. Does it make sense to do something similar here? If we definitely want ceilometer to hold the metadata, then I could also see adding an API to let an outside system add metadata to a resource. That would let the PaaS code, which knows about each VM, store extra data that would be returned with the VM metadata when a caller visits /resources/resourceid. Would you expect to be able to query using the metadata? For example, provide the total instance hours for all instances with paas_tag=foo? Doug Dan On 11/1/2012 11:25 AM, Doug Hellmann wrote: On Thu, Nov 1, 2012 at 10:21 AM, Dan Dyer dan.dye...@gmail.com wrote: In some cases, the service controller is actually running inside a VM. It would not have access to the internals of the VM's. It maintains its metadata separately from the Nova infrastructure. It doesn't need internal access to the VM, but something has to share the metadata with ceilometer (or join it to the data ceilometer has) at some point. If it would be too difficult to get the data into the events, then it could be done by the app that uses the ceilometer API to query for usage. For example, the app that loads data from ceilometer to your real billing system could be driven by data saved by the service controller in whatever database it uses. Doug DD On 10/25/2012 2:25 AM, Nick Barcet wrote: Let's imagine that the service that launch instances can tag the instance with: a) a common service identifier (constant) b) a uuid unique for each Unit of the service such as constant:uuid If that tag is passed onto the events which ceilometer stores in its entirety as meta, I do not see what the difficulty would be for the rating engine to be able to reconcile the information to handle your 2 use cases. Am I missing something? Nick On 10/25/2012 12:03 AM, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Dan On 10/24/2012 3:35 PM, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that
Re: [Openstack] [ceilometer] Potential New Use Cases
Yes, I am assuming the service controller provides a different stream of data from the lower level VM events. So the question is how to represent and store this additional meta data in ceilometer. Note that there doesn't necessarily need to be a linkage/grouping between the resources since the association is what is actually contained in the metadata that is provided by the service controller. As a summary Nova provides its normal events for usage Service controller provides a mapping of nova instances to service type and actual end user Dan On 11/1/2012 11:25 AM, Doug Hellmann wrote: On Thu, Nov 1, 2012 at 10:21 AM, Dan Dyer dan.dye...@gmail.com mailto:dan.dye...@gmail.com wrote: In some cases, the service controller is actually running inside a VM. It would not have access to the internals of the VM's. It maintains its metadata separately from the Nova infrastructure. It doesn't need internal access to the VM, but something has to share the metadata with ceilometer (or join it to the data ceilometer has) at some point. If it would be too difficult to get the data into the events, then it could be done by the app that uses the ceilometer API to query for usage. For example, the app that loads data from ceilometer to your real billing system could be driven by data saved by the service controller in whatever database it uses. Doug DD On 10/25/2012 2:25 AM, Nick Barcet wrote: Let's imagine that the service that launch instances can tag the instance with: a) a common service identifier (constant) b) a uuid unique for each Unit of the service such as constant:uuid If that tag is passed onto the events which ceilometer stores in its entirety as meta, I do not see what the difficulty would be for the rating engine to be able to reconcile the information to handle your 2 use cases. Am I missing something? Nick On 10/25/2012 12:03 AM, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Dan On 10/24/2012 3:35 PM, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just
Re: [Openstack] [ceilometer] Potential New Use Cases
In some cases, the service controller is actually running inside a VM. It would not have access to the internals of the VM's. It maintains its metadata separately from the Nova infrastructure. DD On 10/25/2012 2:25 AM, Nick Barcet wrote: Let's imagine that the service that launch instances can tag the instance with: a) a common service identifier (constant) b) a uuid unique for each Unit of the service such as constant:uuid If that tag is passed onto the events which ceilometer stores in its entirety as meta, I do not see what the difficulty would be for the rating engine to be able to reconcile the information to handle your 2 use cases. Am I missing something? Nick On 10/25/2012 12:03 AM, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Dan On 10/24/2012 3:35 PM, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? ___ 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] [ceilometer] Potential New Use Cases
On Thu, Nov 1, 2012 at 10:21 AM, Dan Dyer dan.dye...@gmail.com wrote: In some cases, the service controller is actually running inside a VM. It would not have access to the internals of the VM's. It maintains its metadata separately from the Nova infrastructure. It doesn't need internal access to the VM, but something has to share the metadata with ceilometer (or join it to the data ceilometer has) at some point. If it would be too difficult to get the data into the events, then it could be done by the app that uses the ceilometer API to query for usage. For example, the app that loads data from ceilometer to your real billing system could be driven by data saved by the service controller in whatever database it uses. Doug DD On 10/25/2012 2:25 AM, Nick Barcet wrote: Let's imagine that the service that launch instances can tag the instance with: a) a common service identifier (constant) b) a uuid unique for each Unit of the service such as constant:uuid If that tag is passed onto the events which ceilometer stores in its entirety as meta, I do not see what the difficulty would be for the rating engine to be able to reconcile the information to handle your 2 use cases. Am I missing something? Nick On 10/25/2012 12:03 AM, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Dan On 10/24/2012 3:35 PM, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? ___ 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 :
Re: [Openstack] [ceilometer] Potential New Use Cases
On Thu, Oct 25 2012, Doug Hellmann wrote: IIUC, what's need here is a GROUP BY operator in the API. Correct me if I'm wrong, but this is still doable via the API if you request /users/user/meters/instance and treats the events in the client, no? It is possible, but very very inefficient. Oh, sure it is. But adding feature and making things more efficient are different things. :) Querying against arbitrary metadata fields is easy in the MongoDB driver, but not in the SQLAlchemy driver. Adding explicit handling for dimensions would let us implement it in SQL and improve performance with indexes in Mongo. Ah, thanks to remind me how ORM are bad and that we now have to fight against it. :) I wish we could use JSON native type from PostgreSQL directly and be efficient! -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgplhhIAVMIOb.pgp Description: PGP 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] [ceilometer] Potential New Use Cases
On Oct 25, 2012, at 6:05 PM, Angus Salkeld asalk...@redhat.com wrote: On 25/10/12 17:04 -0400, Doug Hellmann wrote: On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Oct 25 2012, Doug Hellmann wrote: That would be one way, but adding dimensions to the meters also makes sense because it reduces the need to collect the data more than once. In case of group, the other problem is how to emit instance counter with group metadata (assuming this group implementation is not part of Nova but Heat). Good point. I was assuming the values would be available as metadata of the underlying resource, but that may not always be the case. Yea, we need a consistent way of doing this. That should work on different resource types. We could use the tags or a similar mechanism. Tags would be available as part of an objects normal metadata, right? Doug -A For instance, if flavor was a dimension of the instance meter I wouldn't need the separate meter instance:flavor. These sorts of use cases were part of the original motivation for collecting all of the metadata about a resource, but what we have now isn't structured enough to let the API user query into it. IIUC, what's need here is a GROUP BY operator in the API. Correct me if I'm wrong, but this is still doable via the API if you request /users/user/meters/instance and treats the events in the client, no? It is possible, but very very inefficient. How, then, do we define the dimensions for a given meter in a more structured way? Some built-in values (like flavor) can be pulled automatically based on the resource type, but what about settings controlled by the deployer and end-user (for purposes other than billing)? Do we have to define dimensions explicitely, or isn't what's needed just ways to filter and/or group events by metadata fields? Querying against arbitrary metadata fields is easy in the MongoDB driver, but not in the SQLAlchemy driver. Adding explicit handling for dimensions would let us implement it in SQL and improve performance with indexes in Mongo. Doug -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info g ___ 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] [ceilometer] Potential New Use Cases
On Oct 26, 2012, at 4:29 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Oct 25 2012, Doug Hellmann wrote: IIUC, what's need here is a GROUP BY operator in the API. Correct me if I'm wrong, but this is still doable via the API if you request /users/user/meters/instance and treats the events in the client, no? It is possible, but very very inefficient. Oh, sure it is. But adding feature and making things more efficient are different things. :) Querying against arbitrary metadata fields is easy in the MongoDB driver, but not in the SQLAlchemy driver. Adding explicit handling for dimensions would let us implement it in SQL and improve performance with indexes in Mongo. Ah, thanks to remind me how ORM are bad and that we now have to fight against it. :) I wish we could use JSON native type from PostgreSQL directly and be efficient! You could write a different storage driver. ;) Doug -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info ___ 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] [ceilometer] Potential New Use Cases
On Thu, Oct 25 2012, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Sure, I am not stating you don't need to specify the relationship. I'm just saying I don't see why existing counter in ceilometer should be modified to store the relationship and why it should be aware of it. Maybe I don't understand properly what you want to do, so I'll try to give a concrete example. Please correct me and amend the example if it doesn't match what you've in mind. Let's say you have a PaaS platform built on instances. This PaaS platform has a user P in keystone and launches instances with that user. Now you have to spawn the platform, or a new instance of it, doesn't matter, and launch let's 3 VM instances X, Y and Z. Ceilometer records that 3 VMs instances are running for user P the entire lifetime of the platform. At this point, what I'm saying is that your PaaS platform also needs to send meters too like: Customer C is using the platform running on VM X, Y and Z. The VM the platform is using can be stored in the metadata of the meter the platform emits. You don't need to modify the existing meters. With that, it's possible when billing customer C to request all meters concerning the PaaS platform (you filter by counter name and/or source) and bill the PaaS platform to C. If you want detail usage, or charge back your platform owner, you also can bill the platform using the meter on the VM (and here bill the IaaS part). So the relationship is stored in Ceilometer (via metadata) and you can exploit it to build a more complex billing system with more layers. How does that sound? -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgp8irt5IFg7F.pgp Description: PGP 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] [ceilometer] Potential New Use Cases
On Thu, Oct 25 2012, Angus Salkeld wrote: If you do auto scaling you will have a similar problem. Here you want to monitor the group (with instances comming and going) as a logical unit. One way would be to tag the instances and then extract the tag and send it with the metadata associated with the meter. Then you could query the ceilometer db for that group. What about sending meters where the resource is the group and not the instances? (What do you meter exactly on such a group? I'm not really familiar with CW yet) -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgp5ZEGys3WWJ.pgp Description: PGP 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] [ceilometer] Potential New Use Cases
Let's imagine that the service that launch instances can tag the instance with: a) a common service identifier (constant) b) a uuid unique for each Unit of the service such as constant:uuid If that tag is passed onto the events which ceilometer stores in its entirety as meta, I do not see what the difficulty would be for the rating engine to be able to reconcile the information to handle your 2 use cases. Am I missing something? Nick On 10/25/2012 12:03 AM, Dan Dyer wrote: I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Dan On 10/24/2012 3:35 PM, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? ___ 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] [ceilometer] Potential New Use Cases
That would be one way, but adding dimensions to the meters also makes sense because it reduces the need to collect the data more than once. For instance, if flavor was a dimension of the instance meter I wouldn't need the separate meter instance:flavor. These sorts of use cases were part of the original motivation for collecting all of the metadata about a resource, but what we have now isn't structured enough to let the API user query into it. How, then, do we define the dimensions for a given meter in a more structured way? Some built-in values (like flavor) can be pulled automatically based on the resource type, but what about settings controlled by the deployer and end-user (for purposes other than billing)? Doug On Thu, Oct 25, 2012 at 7:11 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Oct 25 2012, Angus Salkeld wrote: So we need normal stuff like cpu/mem usage but aggregated over the instances in the group. So this is not easy to do externally. Interesting use case. I think for such a thing, a way would be to have a component listening to meters (e.g. on the bus directly or via PubSubHubbub-like) to re-emit consolidated meters. -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ ___ 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] [ceilometer] Potential New Use Cases
On Thu, Oct 25 2012, Doug Hellmann wrote: That would be one way, but adding dimensions to the meters also makes sense because it reduces the need to collect the data more than once. In case of group, the other problem is how to emit instance counter with group metadata (assuming this group implementation is not part of Nova but Heat). For instance, if flavor was a dimension of the instance meter I wouldn't need the separate meter instance:flavor. These sorts of use cases were part of the original motivation for collecting all of the metadata about a resource, but what we have now isn't structured enough to let the API user query into it. IIUC, what's need here is a GROUP BY operator in the API. Correct me if I'm wrong, but this is still doable via the API if you request /users/user/meters/instance and treats the events in the client, no? How, then, do we define the dimensions for a given meter in a more structured way? Some built-in values (like flavor) can be pulled automatically based on the resource type, but what about settings controlled by the deployer and end-user (for purposes other than billing)? Do we have to define dimensions explicitely, or isn't what's needed just ways to filter and/or group events by metadata fields? -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info g pgpVFTwjNG7i6.pgp Description: PGP 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] [ceilometer] Potential New Use Cases
On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Oct 25 2012, Doug Hellmann wrote: That would be one way, but adding dimensions to the meters also makes sense because it reduces the need to collect the data more than once. In case of group, the other problem is how to emit instance counter with group metadata (assuming this group implementation is not part of Nova but Heat). Good point. I was assuming the values would be available as metadata of the underlying resource, but that may not always be the case. For instance, if flavor was a dimension of the instance meter I wouldn't need the separate meter instance:flavor. These sorts of use cases were part of the original motivation for collecting all of the metadata about a resource, but what we have now isn't structured enough to let the API user query into it. IIUC, what's need here is a GROUP BY operator in the API. Correct me if I'm wrong, but this is still doable via the API if you request /users/user/meters/instance and treats the events in the client, no? It is possible, but very very inefficient. How, then, do we define the dimensions for a given meter in a more structured way? Some built-in values (like flavor) can be pulled automatically based on the resource type, but what about settings controlled by the deployer and end-user (for purposes other than billing)? Do we have to define dimensions explicitely, or isn't what's needed just ways to filter and/or group events by metadata fields? Querying against arbitrary metadata fields is easy in the MongoDB driver, but not in the SQLAlchemy driver. Adding explicit handling for dimensions would let us implement it in SQL and improve performance with indexes in Mongo. Doug -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info g ___ 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] [ceilometer] Potential New Use Cases
On 25/10/12 17:04 -0400, Doug Hellmann wrote: On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Oct 25 2012, Doug Hellmann wrote: That would be one way, but adding dimensions to the meters also makes sense because it reduces the need to collect the data more than once. In case of group, the other problem is how to emit instance counter with group metadata (assuming this group implementation is not part of Nova but Heat). Good point. I was assuming the values would be available as metadata of the underlying resource, but that may not always be the case. Yea, we need a consistent way of doing this. That should work on different resource types. We could use the tags or a similar mechanism. -A For instance, if flavor was a dimension of the instance meter I wouldn't need the separate meter instance:flavor. These sorts of use cases were part of the original motivation for collecting all of the metadata about a resource, but what we have now isn't structured enough to let the API user query into it. IIUC, what's need here is a GROUP BY operator in the API. Correct me if I'm wrong, but this is still doable via the API if you request /users/user/meters/instance and treats the events in the client, no? It is possible, but very very inefficient. How, then, do we define the dimensions for a given meter in a more structured way? Some built-in values (like flavor) can be pulled automatically based on the resource type, but what about settings controlled by the deployer and end-user (for purposes other than billing)? Do we have to define dimensions explicitely, or isn't what's needed just ways to filter and/or group events by metadata fields? Querying against arbitrary metadata fields is easy in the MongoDB driver, but not in the SQLAlchemy driver. Adding explicit handling for dimensions would let us implement it in SQL and improve performance with indexes in Mongo. Doug -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info g ___ 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
[Openstack] [ceilometer] Potential New Use Cases
Based on a discussion with Doug at the Summit, I would like to propose a couple of new use cases for Ceilometer. As background, up until now, the usage data that Ceilometer collects could be considered atomic in the sense that everything needed to understand/process the information could be contained in a single generated event. We have identified some use cases that will require additional meta data about the source and/or type of the event so that later processing can be performed. Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time.Note that in theory you could do this in the agent as part of collection, but we have found that this is very expensive and scales best if the actual substitution is delayed until the latest point possible (which at that point potentially means there are less records to process or can be better handled with parallel processing using something like MapReduce.From a billing perspective these instances will have unique pricing (i.e. premium on top of the base VM cost). Part of the aggregation process is to substitute the billable account for the service account and identify the service type so that proper billing can be applied. We would like to see the Ceilometer data model expanded to store this kind of metadata. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Both of these use cases point to a general need to be able to store meta-data that will allow the usage processing logic to identify relationships between VM's and provide additional context for determining billing policy. Dan Dyer HP Cloud Services aka: DanD ___ 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] [ceilometer] Potential New Use Cases
On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpJ98Zivjt7G.pgp Description: PGP 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] [ceilometer] Potential New Use Cases
I think a good deal of ceilometer's messaging and event tracking could additionally be used for event audit logging. -Matt On Wed, Oct 24, 2012 at 2:35 PM, Julien Danjou jul...@danjou.info wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info ___ 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] [ceilometer] Potential New Use Cases
+1 for both of these use cases On Oct 24, 2012 5:06 PM, Dan Dyer dan.dye...@gmail.com wrote: Based on a discussion with Doug at the Summit, I would like to propose a couple of new use cases for Ceilometer. As background, up until now, the usage data that Ceilometer collects could be considered atomic in the sense that everything needed to understand/process the information could be contained in a single generated event. We have identified some use cases that will require additional meta data about the source and/or type of the event so that later processing can be performed. Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system. This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. Note that in theory you could do this in the agent as part of collection, but we have found that this is very expensive and scales best if the actual substitution is delayed until the latest point possible (which at that point potentially means there are less records to process or can be better handled with parallel processing using something like MapReduce. From a billing perspective these instances will have unique pricing (i.e. premium on top of the base VM cost). Part of the aggregation process is to substitute the billable account for the service account and identify the service type so that proper billing can be applied. We would like to see the Ceilometer data model expanded to store this kind of metadata. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Both of these use cases point to a general need to be able to store meta-data that will allow the usage processing logic to identify relationships between VM's and provide additional context for determining billing policy. Dan Dyer HP Cloud Services aka: DanD ___ 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] [ceilometer] Potential New Use Cases
I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly. Dan On 10/24/2012 3:35 PM, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? ___ 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] [ceilometer] Potential New Use Cases
On 24/10/12 23:35 +0200, Julien Danjou wrote: On Wed, Oct 24 2012, Dan Dyer wrote: Use Case 1 Service Owned Instances There are a set of use cases where a service is acting on behalf of a user, the service is the owner of the VM but billing needs to be attributed to the end user of the system.This scenario drives two requirements: 1. Pricing is similar to base VM's but with a premium. So the type of service for a VM needs to be identifiable so that the appropriate pricing can be applied. 2. The actual end user of the VM needs to be identified so usage can be properly attributed I think that for this, you just need to add more meters on top of the existing one with your own user and project id information. As an example, in some of our PAAS use cases, there is a service controller running on top of the base VM that maintains the control and and manages the customer experience. The idea is to expose the service and not have the customer have to (or even be able to) manipulate the virtual machine directly. So in this case, from a Nova perspective, the PAAS service owns the VM and it's tenantID is what is reported back in events. The way we resolve this is to query the service controller for meta data about that instances they own. This is stored off in a separate table and used to determine the real user at aggregation time. This is probably where you should emit the meters you need. Use Case 2 Multple Instances combine to make a billable product/service In this use case, a service might consist of several VM's, but the actual number does not directly drive the billing. An example of this might be a redundant service that has a primary and two backup VM's that make up a deployment. The customer is charged for the service, not the fact that there are 3 VM's running. Once again, we need meta data that is able to describe this relationship so that when the billing records are processed, this relationship can be identified and billed properly. Kind of the same here, if you don't want to really bill the vm, just don't meter them (or ignore the meters) and emit your own meter via your PaaS platform to bill your customer. Or is there a limitation I miss? If you do auto scaling you will have a similar problem. Here you want to monitor the group (with instances comming and going) as a logical unit. One way would be to tag the instances and then extract the tag and send it with the metadata associated with the meter. Then you could query the ceilometer db for that group. (In CloudWatch this is just another Dimension). -Angus -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info ___ 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
