Re: [Openstack] IMPORTANT: Openstack List Migration (Please read)
On Fri, Jul 26 2013, Tom Fifield wrote: Pro Tip: ensure your email client filters are updated for the new list, if necessary. There's already mail going on this new list btw. Could it be configured correctly? The footer seems buggy and there's no List-Id header. Thanks! -- Julien Danjou // Free Software hacker / freelance consultant // http://julien.danjou.info signature.asc 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] swift proxys and dedecated ceilometer
On Wed, Jul 24 2013, Axel Christiansen wrote: Hi Axel, If you want to only meter Swift, you just need: ceilometer-agent-central ceilometer-collector And to retrieve your data: ceilometer-api -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc 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] swift proxys and dedecated ceilometer
On Wed, Jul 24 2013, Axel Christiansen wrote: To be sure, the ceilometer-agent-central and ceilometer-collector do go on the proxys. And just the ceilometer-api ist for the dedecated ceilometer-host? No, they all can go to your dedicated host. Ceilometer agent central access Swift via its API (so via swift-proxies). -- Julien Danjou // Free Software hacker / freelance consultant // http://julien.danjou.info signature.asc 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] Problem with nova resize events
On Wed, Jul 24 2013, Jay Lau wrote: Hi Alex, Not sure if it is a bug, but you are right, ceiloemeter did not send the notification that you required. Perhaps you can log a bug or else you can patch your cluster directly to enable this. class ComputeInstanceNotificationBase(ComputeNotificationBase): Convert compute.instance.* notifications into Counters @staticmethod def get_event_types(): return ['compute.instance.create.start', 'compute.instance.create.end', 'compute.instance.exists', 'compute.instance.update', 'compute.instance.delete.start', 'compute.instance.delete.end', 'compute.instance.finish_resize.end', 'compute.instance.resize.revert.end'] Thanks, Not really a bug, but we know we could do better. I've just cooked a patch that should improve that: https://review.openstack.org/38485 -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info signature.asc 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] Problems with query fields in filters
On Fri, Jul 12 2013, Alessandro Barabesi wrote:
I have the following problems with query fields in filters.
1) Filtering by metadata.size in v2/meters/image apparently is not working.
The following request returns also samples with metadata.size=0.
GET http://10.10.10.10:8777/v2/meters/image
{
q: [{
field: project_id,
op: eq,
value: 77b461539c8542909f67b29939ec87dd
},
{
field: timestamp,
op: ge,
value: 2013-07-11T13:36:00
},
{
field: timestamp,
op: lt,
value: 2013-07-11T13:39:00
},
{
field: metadata.size,
op: gt,
value: 0
}]
}
I am probably doing something wrong but I can't figure out what.
That seems correct from the top of my head. If that really doesn't work,
feel free to open a bug.
2) Filtering by counter_volume returns the folloving error message:
error_message={debuginfo: null, faultcode: Client, faultstring:
Unknown argument: \counter_volume\: unrecognized query field}
Is this a bug or filtering by counter-volume is not allowed?
Try `volume' instead of `counter_volume'. But I am not sure it's
currently allowed -- in that case opening a bug can be good idea too.
--
Julien Danjou
// Free Software hacker / freelance consultant
// http://julien.danjou.info
signature.asc
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] volume.exists events collected after volume is deleted
On Fri, Jul 12 2013, Alessandro Barabesi wrote: ceilometer collects samples for a volume even after the volume has been deleted, reporting event volume.exists (see below). Does it dependend on ceilometer or on cinder? Is there a way to stop this? If the volume has been deleted, it's more likely a bug in Cinder notification system. Fortunately you are now familiar with Launchpad. ;) -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc 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] email notification in openstack
On Wed, Jul 10 2013, val john wrote: Im new to openstack , i have setuped the cloud setup with two compute and one controller nodes , is there any way to send e-mail notification to project admin , when users launching a instance . There's no such feature, but you could rely on Nova notifications sent to build such a tool. -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc 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 getting a Connection refused from
On Tue, Jul 02 2013, Jobin Raju George wrote: Please feel free to ask for clarification. Could you paste the content of your configuration file? -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc 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 getting a Connection refused from
On Tue, Jul 02 2013, Jobin Raju George wrote: Here is my /etc/ceilometer/ceilometer.conf: http://pastebin.ubuntu.com/5835612/ So the problem is that you configured it to use mongodb at mongodb://10.112.107.107:27017/ceilometer but mongodb doesn't seem to answer on this IP/port considering the error. I really dont'get what you don't get, it seems pretty obvious to me you should install MongoDB where you configured Ceilometer to look, right? -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info signature.asc 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][Healthnmon] Dealing with Performance/Monitoring Metrics
On Sat, Jun 22 2013, Bruno Oliveira ~lychinus wrote: So, long story short, is technically possible for me to create metrics to make the API show up system_usage_metrics instead of simply system_allocated_metrics ? (I guess I misunderstood, right?) Could you please enlight the path for me ? If you know how to retrieve the actual memory or disk used (rather than allocated) by a VM by measuring from outside the VM, please enlighten us. We (Ceilometer) don't know how to do that, that's why we don't do it actually. -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info signature.asc 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-agent-central
On Tue, Jun 18 2013, Claudio Marques wrote: Does anyone have some issue like this? What's your Glance endpoint like in Keystone? If it ends with a version number like /v1, remove it. -- Julien Danjou // Free Software hacker / freelance consultant // http://julien.danjou.info signature.asc 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-agent-central
On Tue, Jun 18 2013, Claudio Marques wrote: Thank you for your response. Do you mean removing the keystone endpoint for glance and creating a new one without the /v2 number? http://10.0.1.167:9292/v2|http://10.10.10.51:9292/v2 |http://10.10.10.51:9292/v2| Yes, this is wrong, it shouldn't contain the /v2. -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info signature.asc 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] volume usage from ceilometer and cinder
On Mon, Jun 10 2013, Anshul Gangwar wrote: I am trying ceilometer to get volume usage. But in statistics, I am getting volume usage duration only after deleting the volume. But before deleting I am not getting any duration of usage. It is always 0 if volume is not deleted. I have triedvolume and volume.size meters. You need to enable audit events into Cinder. -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc 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] volume usage from ceilometer and cinder
On Mon, Jun 10 2013, Anshul Gangwar wrote: In my cinder.conf I have added below configuration. cinder_volume_usage_audit=True cinder_volume_usage_audit_period=hour notification_driver=cinder.openstack.common.notifier.rpc_notifier control_exchange=cinder Does above settings not enabling audit events? If not what else I need to add in cinder.conf? You need to run cinder-volume-usage-audit yourself in a cron or something IIRC. Cinder lacks behind other projects in this regard. -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info signature.asc 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] [HyperV][Ceilometer] Performance statistics from Hyper-V with Ceilometer and libvirt
On Thu, Jun 06 2013, Peter Pouliot wrote: The hyper-v driver uses WMI. Libvirt is not used. There is currently no support for celometer, however we should have havana blueprints meaning it is one of the things we are trying to deliver. We'd be glad to have this support indeed. I don't think I saw any blueprint about this on Ceilometer, did you already create them somewhere? -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info signature.asc 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] [HyperV][Ceilometer] Performance statistics from Hyper-V with Ceilometer and libvirt
On Wed, Jun 05 2013, Bruno Oliveira wrote: So far, in the irc channel #openstack-ceilometer, I got to know that ceilometer, just like collectd, uses libvirt to query the hypervisors for data (thanks dhellmann !). BUT if check in the libvirt.org site, it's being said that there's support for Hyper-V: http://libvirt.org/drvhyperv.html (given a uri to connect to it). First question is, is Hyper-V driver for Nova used via libvirt? If yes, then libvirt should be patched to provide information to Ceilometer. If not, then Ceilometer should be patched to learn how to poll Hyper-V. -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info signature.asc 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] configure devstack to get cinder volume events/meters from ceilometer
On Tue, Jun 04 2013, Anshul Gangwar wrote: I want to receive cinder volume meters from ceilometer. What changes shall i make in localrc file of devstack to acheive this? You need: notification_driver=cinder.openstack.common.notifier.rpc_notifier and usage audit enabled and running. -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info signature.asc 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] configure devstack to get cinder volume events/meters from ceilometer
On Tue, Jun 04 2013, Swann Croiset wrote: the exchange used to send notifications need to match between Cinder and Ceilometer configurations. since ceilometer has 'cinder' as default and cinder has 'openstack' as default try to set in cinder.conf: control_exchange=cinder This is bug in Cinder. One should check if it's reported already, it would be trivial to fix… -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc 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] support for older versions of ceilometer
On Thu, May 30 2013, Tim Bell wrote: I hope that ceilometer can also include this within the Havana timeframe as it becomes a key component of production, large scale clouds. I think we all agree in principle. We'd be happy to enhance Ceilometer and fix potential bugs in this direction, but we'll require some help testing the upgrade path *before* Havana is released. -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info signature.asc 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] how to enable cpu meter?
On Tue, May 28 2013, alexander barakin wrote: i use fresh devstack without local modifications on ubuntu 12.04 i have run the example image cirros-0.3.1-x86_64-uec and see the following meters in output of ceilometer meter-list: You need to run `ceilometer-agent-compute'. -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info signature.asc 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] [metering] Ceilometer plugin for VM provisioning metrics
On Thu, May 16 2013, Ruslan Kiianchuk wrote: There were issues with versioning (I have to run Ceilometer with Folsom OpenStack version) so few lines of code had to be changed for successful porting. Now everything works. Yet, another question arose, weather I can ignore some events from the RPC bus in process_notification() method or any other way? Yes, you can ignore whatever you want in process_notification. You don't have to return/yield counters if there's no need. -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info signature.asc 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] [metering] Ceilometer plugin for VM provisioning metrics
On Tue, May 14 2013, Ruslan Kiianchuk wrote: Could you please help on how the listener plugin is supposed to be created? There are good chances I have some misunderstandings in the concept of Ceilometer plugins. No, you got everything right! You should start by checking if your plugin is loaded by running ceilometer-collector with -v option I guess. Then I'd try to see if nova is really sending those messages on the RPC bus. -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info signature.asc 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] How to purge old meter data of Ceilometer
On Thu, Apr 04 2013, Harri Pyy wrote: With the default 1 minute interval, Ceilometer collects quite large amounts of meter data. Does Ceilometer provide a TTL configuration option for the meter data, or some other functionality or API for purging old meter data? Not yet unfortunately. -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info pgp1Idj4d32BF.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
[Openstack] Ceilometer 2013.1 released
Hello, Ceilometer 2013.1 has been released, ending the Grizzly development cycle where we were an incubated project, and became an integrated one for the Havana cycle. The tarball can be found with the list of features and bugfixes here: https://launchpad.net/ceilometer/grizzly/2013.1 Congratulations to everyone for this! -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info pgpGYgEau09B1.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
[Openstack] [Ceilometer] Grizzly RC1 released
Hi, We're pleased to announce that the RC1 version for the Grizzly release of Ceilometer is available! https://launchpad.net/ceilometer/grizzly/grizzly-rc1 Unless release-critical issues are found that warrant a release candidate respin, this version will be formally released as the Ceilometer 2013.1 version on April 4. You are therefore strongly encouraged to test and validate this tarball. If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer/+filebug Note that the master branch for Ceilometer is now open for Havana development, and feature freeze restriction no longer apply. -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info pgpzk9vLkH8Up.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
[Openstack] Announcing Climate, OpenStack Capacity Leasing project
Hi there, I'd like to announce a new project named Climate. The project aims to provide a capacity leasing service inside OpenStack cloud platforms, via the reservation of various resources in a calendar based view. The project is still as its early draft stage, but anyone with ideas and interest is welcome! Homepage: https://launchpad.net/climate Cheers, -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info pgpyh7KqjhFjA.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] [openstack] [ceilometer] API /v1/meters/ return '404 Not Found'
On Mon, Feb 04 2013, Qinglong.Meng wrote: Hi all, I have deployed ceilometer with openstack F. Version: ceilometer: stable/folsom openstack: folsom nova: 2012.2.3 The ceilometer services here: nova 6750 5522 0 17:16 pts/0 00:00:04 /usr/bin/python /usr/local/bin/ceilometer-collector nova 6762 5522 0 17:17 pts/0 00:00:04 /usr/bin/python /usr/local/bin/ceilometer-agent-central nova 6771 5522 0 17:17 pts/0 00:00:03 /usr/bin/python /usr/local/bin/ceilometer-agent-compute nova 7271 5522 0 17:23 pts/0 00:00:00 /usr/bin/python /usr/local/bin/ceilometer-api I try this api: http://docs.openstack.org/developer/ceilometer/webapi/v1.html * GET /v1/resources OK * GET /v1/projects OK * GET /v1/meters: I got the 404 not Found response. and I don't get the WARNNING and TRACE by ceilometer-api. Is the API correct or not implement? Any good idea? Which version of Ceilometer did you deploy? Indeed, not everything is implemented in the API, but /meters is implemented in current development version as far as I can see. -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpJwDH_j2bTw.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] Ganglia Ceilometer integration
On Tue, Jan 08 2013, shengjie_...@dell.com wrote: Just out of curiosity, Have we ever had any previous threads discussing about possibility of integrating Ceilometer with ganglia as a monitoring approach? Didn't manage to find any from the mailing list archive. Doesn't ring a bell, indeed. -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpWaR3KSFLqz.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
[Openstack] [Ceilometer] Bug squash day on 4th January 2013
Hi fellow OpenStackers, The Ceilometer team is pleased to announce that it organizes a bug squashing day on the Friday 4th January 2013. You can find more information about the Ceilometer project on its wiki page¹. The organization details for this day are available on its own page² also. If you're already curious about how to contribute to Ceilometer, you can read the associated page³. This event will mainly happen on IRC (#openstack-metering on Freenode), and all participants are encoured to join. People will be there to welcome and help new comers to contribute to Ceilometer! ¹ http://wiki.openstack.org/Ceilometer ² http://wiki.openstack.org/Ceilometer/BugSquashingDay/20130104 ³ http://wiki.openstack.org/Ceilometer/Contributing -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgpMPQ5br08qV.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] How does ceilometer work with multi-DC scenario
On Fri, Nov 23 2012, shengjie_...@dell.com wrote: Two regions case: If you want to get the meters for TenantA from 'swift-cluster-1' specifically. According to the API design we have now, there is no API can do that directly unless you do some complex API calls combination. I think you can use: GET /v1/sources/swift-cluster-1/projects/project/meters/meter in that case, no? I actually didn't see this API you mentioned above defined anywhere. We can probably add that in the API anyway. :) -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpLWvbNocQJb.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] How does ceilometer work with multi-DC scenario
On Thu, Nov 22 2012, shengjie_...@dell.com wrote: Let's say if you deploy one ceilometer instance for two swift clusters swift-cluster-1' and 'swift-cluster-2'. According to the design, if we use source' field for region/cluster to tell what cluster the meters come from. The Ceilometer API doesn't seem being well thought through yet. A single region case: If you want to get the meters for TenantA, this API will simply do the job: GET /v1/projects/(project)/meters/(meter) Two regions case: If you want to get the meters for TenantA from 'swift-cluster-1' specifically. According to the API design we have now, there is no API can do that directly unless you do some complex API calls combination. I think you can use: GET /v1/sources/swift-cluster-1/projects/project/meters/meter in that case, no? -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgpXLk9LHdkzJ.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] How does ceilometer work with multi-DC scenario
On Tue, Nov 20 2012, shengjie_...@dell.com wrote: Has anybody come across the scenario you need to deploy two or more openstack swift or nova clusters for whatever DR or HA reasons. How Ceilometer is going to cope with that? Just wondering is there any plans or blueprints addressing the usage data replication/distinguish/isolation among multi-DCs? You can deploy several ceilometer and use several databases, or just one and use a different 'source' field for each of your region/cluster to differentiate where meters come from. -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgpAMx4Vs8WRp.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] Essex
On Tue, Nov 13 2012, Joe Warren-Meeks wrote: Hi Joe, When I use a floating IP in the 10.0.40.0/24 range, it is fine to speak to that network and traffic goes out and back on the vlan40 interface, but for all other networks it is routed out the 10.0.0.250 eth0 interface, rather than vlan40. The replys are coming back on vlan40 to the correct address, but nova seems to ignore them. You need to create another routing table on your compute hosts, and set up some ip routing rules based on source, using `ip rule'. So that traffic coming from your tenants VLAN goes out by vlan40. -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgpfb6MYi1sDc.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] Hbase storage backend for Ceilometer - blueprint?
On Thu, Nov 15 2012, shengjie_...@dell.com wrote: The blueprint is registered : https://blueprints.launchpad.net/ceilometer/+spec/hbase-storage-backend, Any idea what's the next step ? :) Implementing? :) And eventually adding more blueprint to depends on if you can't implement this one directly because of some missing stuff. -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgp8jDsQh0QEc.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] Hbase storage backend for Ceilometer - blueprint?
On Thu, Nov 15 2012, shengjie_...@dell.com wrote: 1. Does it need to be approved first, what's the process to get it approved/assigned to a release? Btw, I was trying to add Julien in the approver list as well, didn't manage to do that. I don't think we've been anything formal so far about that. The storage part has been abstracted so everybody can come up with a new storage engine. So you're planning to work a new one, I don't see any reason not to approve such a blueprint. But I've set this blueprint to approved anyway. :) More discussion is likely to be needed if you need to do modifications to the abstraction layer itself. 2. The community meeting normally is the place to have this kind of tech discussion or it's for something else? It its, so I suggest you bring this today (in 2 minutes) in the open discussion at the end of the meeting, or add it the agenda for next meeting next week. -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpcjsYblpraH.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] [metering][ceilometer] Ceilometer and Keystone regions
On Thu, Nov 08 2012, Aguiar, Glaucimar (Brazil RD-ECL) wrote: Can Ceilometer collect data about instances in different keystone regions? Is this a valid/possible configuration? Scenario 1: I have two regions defined in my keystone service, each one has a nova service in it. Can Ceilometer collect metering information from both regions? In a single database? Yes, you'll just have to deploy at least one ceilometer-collector in each region on Nova and connect them to the same database. Plus ceilometer-agent-compute on each nova-compute. Scenario 2: I have two nova services in my keystone service region. Can Ceilometer support this configuration? Yes, same answer as scenario 1, deploy at least a ceilometer-collector for each Nova, plus ceilometer-agent-compute. If you want to easily identify the region your meter stored in Ceilometer come from, you can use the 'source' field of the meters to a string that helps you recognize which region the meter come from (see counter_source option in Ceilometer). -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpowwb8kk0eo.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] Hbase storage backend for Ceilometer - blueprint?
On Wed, Nov 07 2012, shengjie_...@dell.com wrote: Hi Shengjie, I am looking for a way to propose a blueprint to the ceilometer team - Adding Hbase storage backend for ceilometer. Currently we have only MongoDB and SQLalchemy as the possible ceilometer storage backend. Given the storage interface is clearly designed and allows us to have different backend, it would be nice to have more options which make Ceilometer more adoptive to some providers' existing architectures. As a cloud IAAS provider, Ceilometer might not be just considered as a usage db, also it's being seen as a centralized place to store all the usage data cross platforms. Additionally, all the historical usage data stored can be used for historical usage analysis as well, this is where MapReduce comes into play. With Hadoop Hbase, it allows usage data to be stored in HDFS, also it gives us the ability to run large scale massive MapRed analysis jobs in the future. This is indeed a good idea, and as you pointed out, Ceilometer collector has been designed so this is being possible. I think you can create a blueprint here: https://blueprints.launchpad.net/ceilometer And write in what should be done. -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgp0Y6makV0xI.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] Monitoring physical devices
On Tue, Nov 06 2012, Graf Lucas (graflu0) wrote: I'm a little confused now... ;) Is the bare metal run by the platform operator the physical machine? What do you mean with the bare metal run to replace virtual instances for any project? AFAIU, bare-metal provisionning is about using hardware (bare-metal) rather than virtual instances as a flavor in Nova. For such case, we won't be able to poll anything about the hardware. For hardware ran by the operator, this will be doable. -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgpDsJxrCp10y.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] Monitoring physical devices
On Mon, Nov 05 2012, Doug Hellmann wrote: If we make the current compute agent take an option telling it which pollster namespace to use, then the same framework can load different pollsters. However, there is a fundamental security issue with communicating from an agent running inside a tenant's OS image using the RPC stack. At DreamHost, and I suspect at other providers, that RPC network is completely isolated from any tenant networks. We would not want a tenant to be able to listen to the message bus, and definitely would not want it to be able to write anything to the message bus. What makes you think an agent would run inside an instance? I mean, this is not what this is about, we're talking about hardware running OS. -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgp7Pk0gZAZEV.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] Monitoring physical devices
On Mon, Nov 05 2012, Doug Hellmann wrote: When an image is deployed to bare metal, there is no container, right? Ah, I see the confusion. There's 2 bare metal, I think, the ones run by the the platform operator and the ones run to replace virtual instances for any project. I was actually talking about the former in this thread so far. :) For the latter, there's indeed this kind of problem, but I don't think we really want to meter resources on that. Well, at least I don't see the point and how it can be safe anyway. -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgpnuRPSMxHAW.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] meter data volume
On Wed, Oct 31 2012, Eoghan Glynn wrote: Yep the sum of local maxima is not lossy as long as the requested duration completely encapsulates the compute agent outage (and the instance doesn't restart during the outage). Actually, if there's one restart, it still _can_ be safe in certain cirumstances such as in a case like: Time | Value 0| 1000 1| 3000 (agent down) 2| 0(agent down) 3| 80 4| 100 If in this particular case, with the case where your agent was down at t1 and t2. The API will detect the counter reseted while the agent was down. With cumulative model, the loss is again less than the computed delta model. OTOH, both models fails to get some data with a case like: Time | Value 0| 1000 1| 3000 (agent down) 2| 0(agent down) 3| 8000 4| 1 However I was more thinking of the scenario where the duration requested via the API is say t1..t4 in your example above. In any case, do we need a new measurement type, in addition to the existing CUMULATIVE type, that captures the non-monotonic nature of the measure and alerts the API that special handling is required to compute say max-min? Something like TRANSIENT_CUMULATIVE, if that's not too much of a mouthful. We discussed it already with Doug, and came to conclusion that we didn't, because the monotonic case is just a special case of the non monotonic one. So applying the computing method to the non-monotonic case will solve all problem. -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpFZzJXgNfiW.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] meter data volume
On Thu, Nov 01 2012, 吴亚伟 wrote: Is the API capable to deal with that at present? If not, when? Not yet. When someone will write with the code! Is the Web API in the document going to be updated recently? We hope so! -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpRKrwXhvbAn.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] meter data volume
On Thu, Nov 01 2012, 吴亚伟 wrote: Cumulative type is apparent, while even with descriptions gauge and delta type confuse me. Could you explain them through examples or by sharing an use case? Gauge is an absolute value, like a temperature or the number of people in a room. Delta is a counter where each value is the difference between the current and the previous value. Each value represents how many things were consumed since last time a value has been sent. It's always compared to a counter that resets to 0 once you read it. -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpsqx8oaQ2Qf.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] Monitoring physical devices
On Thu, Nov 01 2012, Zehnder Toni (zehndton) wrote: On every physical compute node is the Ceilometer compute agent installed, right?! Yes. 1) Does the compute agent collect data of the physical machine as well or is it just collecting data of the virtual machines? Only virtual machines. 2) Could it be useful to enhance the Ceilometer agent to collect data from the physical servers? Why not. What do you have in mind exactly? -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpOmfnhSmJUB.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] Monitoring physical devices
On Thu, Nov 01 2012, Zehnder Toni (zehndton) wrote: My goal is to offer monitored data to the admin and customers. The admin is interested in the utilization of the physical components and the virtual machines and the customer is interested to know what his VMs do or can do. It would be nice to get the data from a single point. I thought I can enhance the Ceilometer compute agent to get this data out. Does this make sense or is it better to use another monitoring tool for the physical components? I think the pollster implementation can be done. I wouldn't implement this in the compute agent, but probably in some hardware agent, because it's likely it would be used in different kinds of environment and not only on compute node, i.e. you may also want to meter hardware usage for you cinder or glance node anyway. About the 10 minutes polling interval Doug mentionned, this can be a problem indeed, but it's still solvable later and would be easy to solve if this in a different agent, since you could change the periodic interval for pollster runs to something like 1 or 5 minutes. -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpDAWYZn0Ulm.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] meter data volume
On Thu, Nov 01 2012, Eoghan Glynn wrote: What would be the best way to achieve this? A small sqlite DB per-agent, or even simpler just a pickled dict? The latter would avoid the complexity of DB versioning and migration. At the risk of repeating myself, can I stress again how much we don't need to transform cumulative into delta, and certainly not in the pollster/agents/notifications code? -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgpUMOnj02Wdh.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] meter data volume
On Thu, Nov 01 2012, Eoghan Glynn wrote: Well local persistence of the prev times would still be of use I think for the in-pollster CPU util % calculation (as discussed here[1]). Allright, so that may be needed, but not in the pollster. It'll be needed in the CW publisher that will compute that, because CW don't offer any other mean (I imagine) to handle cumulative value like Ceilometer does. :) (But I know that currently we don't have multi-publisher, and that's why it's done that way in #14921 :) -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpGXlGjlMQCY.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] meter data volume
On Wed, Oct 31 2012, 吴亚伟 wrote: 1) '12389000' nanoseconds means '123.89' seconds or two minutes,it seem like to be 1238.9 seconds actually, is there something wrong ? Why do you think it's 1238.9 seconds? 2) If I never reboot or suspend vm_1, will the 'counter_volume' of cpu usage record increase all the time ? Just like '8 minutes' - '18 minutes' - '28 minutes' ? It's a CPU time, not an uptime. http://en.wikipedia.org/wiki/CPU_time 3) If I reboot or suspend vm_1, I find that the 'counter_volume' of cpu usage record will count from zero. Just like '8 minutes' - '18 minutes' - '28 minutes' [- '0 minutes'] -'5 minutes' - '15 minutes'. Does it mean that 'counter_volume' just represents how long has vm_1 been booted up ? Not at all. It means the CPU time consumed is reset to 0, but that's not an issue in itself, the API should be capable to deal with that if you ask for the total usage. 4) This one is about Web API. I find that GET /v1/resources/(resource)/meters/(meter)/volume/sum just return the sum value of all the cpu 'counter_volume', like '8 minutes' + '18 minutes'. Is it reduplicate ? Don't understand what you mean, but the CPU counter is a cumulative one, and asking for its sum is a non-sense. You want to ask for (max - min) to get the used value, something which is not in the API yet. 5) If I want to know how long has vm_1's cpu been used yesterday, how can I do ? Just like I wrote above. :) -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpLlWTwzAZGK.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] meter data volume
On Wed, Oct 31 2012, Eoghan Glynn wrote: Would that total usage be much more apparent if we started metering the delta between CPU times on subsequent polling periods as a gauge measure? (As opposed to treating it as a cumulative measure) I'm rather against the idea of transforming all cumulative counters to delta, for the simple reason that this imply to lose information if your system is not launched to compute delta, or that you have to maintaint a previous value accross restart. The API will be capable to do the operation you need, no matter what the type of counter is (delta or cumulative). I don't think (max - min) would suffice to give an accurate measure of the actual CPU time used, as the counter may have reset multiple times in the course of the requested duration. It is, because /max in the API should be aware of the fact a reset can occur and computes accordingly. We started to discuss this a bit in: https://bugs.launchpad.net/ceilometer/+bug/1061817 -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgpRVR7qdZlI9.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] meter data volume
On Wed, Oct 31 2012, Eoghan Glynn wrote: A-ha, OK, so not so much (max - min) as: (\Sigma local maxima) - first Yeah, excuse my math. :) Sounds computationally expensive to produce on the fly, but maybe the local maxima can be efficiently recorded as the data is being ingested. Yes it's more expense in theory, but in practice I'm rather than with a good back-end it's not a problem (either pre-compute or have the right toolslike PostgreSQL). -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgp32opSBDDAj.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] meter data volume
On Wed, Oct 31 2012, Doug Hellmann wrote: Is that better than just reporting the data in a more easily digested format in the first place? IMHO yes. Julien, I don't understand your comment about losing data if your system is not launched to compute delta. Can you clarify what you mean there? I do understand that the agent would need to store state about the counter locally in order to track the delta value, but I think we could provide a convenient way for pollsters to do that without complicating them excessively. Yes, actually I think you got what I meant, I just wrote it badly. By system, I meant pollster. If your pollster is not running to compute delta and you have no state stored, you'll miss a part of what has been used. Now, I don't think trying to circumvente that at the pollster level is a good idea either, because it complicates the pollster for no good reason. Ultimately, if you reaaay want to compute delta instead of using the real values of the counter for whatever (bad) reaason, doing it at the storage back-end lavel might be an option if you want. But as I said, for now there's now reason it should be needed. (And you know what they say, early optimization is the root of all evil :) -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpy2t7myJXp4.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] meter data volume
On Wed, Oct 31 2012, Eoghan Glynn wrote: Would we have also have some 'misses' with the cumulative approach when the ceilometer agent was down? No, unless the counter resets several times while your agent is down. But delta has the same issue. If I understood the (\Sigma local maxima)-first idea correctly, the usage up to the first polling cycle would always be discounted from any duration. No, because if you have: Time | Value 0| 10 1| 30 2| 50 3| 80 4| 100 If your delta-pollster is down at 1 and 2, you restart at 3, therefore at 4 you'll send 20 as usage (100 minus 80). So you miss the delta between 10 (time 0) and 80 (time 3) (therefore 70 for free!). If you send right away 80 at time 3 when restarting, the API will be able to guess that between 0 and 3 the value went from 10 to 80. With delta approach, the API cannot guess that. A more pernicious problem would occur if the instance was being regularly restarted with a higher frequency than the polling period. Yes, but in that case, whatever counting method you use, you're screwed. :) -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgpPm0HT9Gwc2.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, 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 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
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 API Glossary
On Thu, Oct 25 2012, Doug Hellmann wrote: We have special instructions for configuring glance to use rabbit for notifications in http://ceilometer.readthedocs.org/en/latest/install.html#configuring-devstackbut I don't see anything about cinder there. Do we need to add another step to set the notification_driver for cinder? I think so. -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgp4I0qLEd6g5.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] [OpenStack] Ceilometer API Glossary
On Wed, Oct 24 2012, 吴亚伟 wrote: I still have questions about the data in the mongodb. First: All the data about source in db is ?,for example: is it correct? Yes, that's what we used for now in the source code, so this is correct. second,when I create a instance,there will be meter data created in the mongodb as resource and meter,but for volume ,there is no any data about volume in the db,so why ?Is there something wrong with my devstack or there is configuration file should be modified? If you're talking about cinder volues, you need to configure and run cinder-volume-usage-audit regularly to get messages. third,I can only see cpu,disk,and network info for instance in the meter data by now ,but there is no memory info,so why? Make sure you enabled the notifications via RabbitMQ in nova. -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgp9T7Xj8PXY6.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 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] Release status 2012-10-05
On Fri, Oct 05 2012, Graham Binns wrote: These numbers were generated using a launchpadlib API script (attached). We haven't set up a milestone for the 0.9 release; I suggest that we do and will take care of it today if no-one objects. Agreed, thanks! Status of roadmap - According to http://wiki.openstack.org/EfficientMetering/RoadMap, there's one bug still in progress that should be targeted for Folsom.0: 1021775: Assignee: jdanjou; Listen Quantum notifications Julien, what's the situation with this? I know we're technically in feature freeze but we've got a week left until release and if we can get this committed and QA'd in time, that would be lovely. This has been merged by the time you wrote the mail I think. :-) -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpiYUgPutN1f.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] [Openstack-devel] Ubuntu and Debian package diff for nova
On Wed, Sep 05 2012, Thomas Goirand wrote: Hi Thomas, There may have been some other contributors (especially Debconf translations), but that's the main team. I'm not sure if Julien still wants to get involved in the Debian packaging of Openstack, since he is busy on the Ceilometer project. Well, I'm still interested, but don't have any direct use of them as of today, and have other things to do as you stated, so I'm not very active right now, I admit. :) What happened One of the problem we have in Debian, is that we have a strong allergy to bzr. We use Git, and we are happy to do so, and I don't believe that any of us wishes to go back to using bzr, for the same reasons Openstack itself moved to Github. Also, since we use Git, it's easy for us to import upstream code, which is a way better. FWIW I think you pointed (one of) the real problem here. :) It's a little bit too late in the release cycle, I'm fearing the release team reaction here. Oh, I think that all changes are too late now anyway. There shouldn't be a version depend on lsb-base. Any lsb-base is fine, IMO. I can't recall why, but I'm pretty sure the version is here for a good reason and for the init scripts. nova-ajax-console-proxy: - Debian does not provide this package at all. Ubuntu does. I think this is now superseded by novnc. nova-vncproxy nova-xvpvncproxy: - Ubuntu has nova-vncproxy while debian has nova-xvpvncproxy (that provides nova-vncproxy) - Ubuntu has a conflict against novnc, while debian does not. Same here, vncproxy is now novnc if I'm not mistaken. Don't know what nova-xvpvncproxy is. debian/nova-common.nova-manage.logrotate - ubuntu provides this, debian does not. This is a bug in our package that should be fixed. debian/nova-common.postinst --- - Ubuntu checks for the existance of an user/group before creating. Debian should do the same. You didn't read the script correctly then. The debian package uses getent, which is the correct way (tm) to do things. It's the Ubuntu package that is wrong here, IMO. Is it me, but I don't see any getent? Anyway, I think getent isn't the way togo neither, the current implementation is fine, adduser does not fail if a group or a user already exists. Cheers, -- Julien Danjou # Free Software hacker freelance # http://julien.danjou.info pgp1P4huk7FSY.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] [Openstack-devel] Ubuntu and Debian package diff for nova
On Wed, Sep 05 2012, Ola Lundqvist wrote: Do you mean that Ubuntu should no longer provide it? I think so, indeed. But why do ubuntu conflict novnc? Or is it so that ubuntu does nto have novnc? Honestly, I don't know. :) -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpG63CJDXAMS.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] Weekly irc meetings day and time change?
On Thu, Aug 30 2012, Angus Salkeld wrote: I'd like to attend but am in Australia. I am quite flexible so it might be easier to say what times don't suit. Basically midnight - 6am which in UTC is 14:00 to 20:00 That's gonna be a tough one. :) In the same idea, living in France, I'd exclude UTC 22:00 to 04:00. So that let us with UTC 04:00 to 14:00 and 20:00 to 22:00 Doug being in the US in IIRC UTC-7 that would exclude UTC 07:00 to UTC 13:00. Finally letting us with UTC 04:00 to 06:00 and 20:00 to 22:00. So finally, I would propose to use UTC 21:00: - 23:00 for me (and Nick most of the time I guess) in France - 14:00 for Doug - 7:00 for Angus or UTC 06:00: - 08:00 for me (and Nick most of the time I guess) in France - 23:00 for Doug - 16:00 for Angus (Hope I did not get the math wrong) -- Julien Danjou ;; Free Software hacker freelance ;; http://julien.danjou.info pgpqQHnka8krs.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
[Openstack] [Ceilometer] Project Technical Leader election result
Hi, The PTL election for Ceilometer¹ is over. The winner is Nick Barcet. Congratulations ! The results are available here: http://www.opavote.org/vote/491028 ¹ http://wiki.openstack.org/EfficientMetering/PTLElectionProcess Cheers, -- Julien Danjou // Free Software hacker freelance // http://julien.danjou.info pgpWkJFf1lvVk.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
[Openstack] [metering] Meeting agenda for Thursday at 16:00 UTC (July 19th, 2012)
Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. Agenda: http://wiki.openstack.org/Meetings/MeteringAgenda * Review last week's actions * Open discussion If you are not able to attend or have additional topic you would like to cover, please update the agenda on the wiki. Cheers, -- Julien Danjou /* Free Software hacker freelance http://julien.danjou.info */ pgp6LykcbBnYa.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] [metering] Meeting agenda for Thursday at 16:00 UTC (July 19th, 2012)
On Thu, Jul 19 2012, Julien Danjou wrote: Here is the summary of the meeting: Meeting started by jd___ at 16:03:44 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-07-19-16.03.log.html . Meeting summary --- * LINK: https://lists.launchpad.net/openstack/msg14876.html (jd___, 16:04:21) * Last week action review (jd___, 16:04:48) * ACTION: jd to setup opa voting system to start on 26th and end on Aug 3rd (jd___, 16:05:05) * nijaba asked for feedback on roadmap at http://www.mail-archive.com/openstack@lists.launchpad.net/msg14398.html (jd___, 16:05:43) * jd did it in https://review.openstack.org/#/c/10016/ (jd___, 16:06:22) * nijaba added a table showing the state of integration for each OpenStack project http://wiki.openstack.org/Governance/Proposed/Ceilometer (jd___, 16:06:42) * nijaba adjusted the proposal to reflect a longer incubation period http://wiki.openstack.org/Governance/Proposed/Ceilometer (jd___, 16:06:55) * ACTION: dhellmann to get some feedback now about the sorts of meters users want from the mailing list (jd___, 16:07:24) * ACTION: dhellmann to open a bug and work on devstack integration (jd___, 16:07:29) * ACTION: dhellmann create a diagram of ceilometer architecture (jd___, 16:07:33) * ACTION: dhellmann write a walk-through of setting up ceilometer and collecting data (jd___, 16:07:39) * discuss https://blueprints.launchpad.net/nova/+spec/volume-usage-metering (jd___, 16:08:37) * ACTION: lzyeval create a blueprint to add counter for nova-volume disk usage retrieval (jd___, 16:18:18) * ACTION: dricco work and reprt about nova-volume metering notification https://blueprints.launchpad.net/nova/+spec/volume-usage-metering (jd___, 16:22:06) Meeting ended at 16:25:41 UTC. Action items, by person --- * dricco * dricco work and reprt about nova-volume metering notification https://blueprints.launchpad.net/nova/+spec/volume-usage-metering * lzyeval * lzyeval create a blueprint to add counter for nova-volume disk usage retrieval * **UNASSIGNED** * jd to setup opa voting system to start on 26th and end on Aug 3rd * dhellmann to get some feedback now about the sorts of meters users want from the mailing list * dhellmann to open a bug and work on devstack integration * dhellmann create a diagram of ceilometer architecture * dhellmann write a walk-through of setting up ceilometer and collecting data People present (lines said) --- * jd___ (56) * dricco (23) * lzyeval (5) * openstack (2) -- Julien Danjou -- Free Software hacker freelance -- http://julien.danjou.info pgp2jhSeUQIeF.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] [metering] Ceilometer PTL Election Process - Call for candidate
On Wed, Jul 11 2012, Nick Barcet wrote: Candidates should, before July 24th: 1/ declare themselves on this mailing list I do declare myself as a candidate. I've added a page about this here: http://wiki.openstack.org/EfficientMetering/PTLElectionProcess/JulienDanjou 2/ add their name on the wiki page Done. Cheers, -- 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 application for incubation
On Fri, Jul 06 2012, Doug Hellmann wrote: Great! I'll be there, hopefully joined by other team members. I will try to make it, too. I won't be there, but I trust Nick 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] [metering] resource metadata changes and billing
On Thu, Jul 05 2012, Nick Barcet wrote: Makes sense? Yes. And we can probably bend the current API a bit to enhance things. :) -- 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] Stackforge migrating
On Wed, Jul 04 2012, Andrew Hutchings wrote: As far as I can tell the hard work of the migration is now complete. For anyone using Stackforge branches please pull the latest master and rebase any branches you were working on with this. It will update .gitreview to point to the correct server. Thanks for your work Andrew. It seems to work fine so far, I've already sent a review request to test. :) -- 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] [metering] resource metadata changes and billing
On Wed, Jul 04 2012, Nick Barcet wrote: I therefore propose that we leave the API as is, knowing the side effects of such high level sum and duration calculations. If we agree on this, I take the action to document the limitation of the summary functions of the API. So, if I understand you correctly, that would mean the API is non-usable for anybody wanting to do fine-grained billing and they would have to connect to the database engine directly? Because if that's the case I think we miss an abstraction layer somewhere. -- 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] [metering] resource metadata changes and billing
On Fri, Jun 29 2012, Doug Hellmann wrote: Hi Doug, Sorry for the late reply. I don't think I've made the problem clear. I'm not talking about wanting to calculate the different usage for CPU, RAM, etc. The different counters are calculated separately, so we can keep the amounts for CPU and RAM completely separate, and the API allows the outside user to ask for the amounts for each counter for a resource (or globally for a user/project). The problem is in deciding how the metadata associated with a meter event might cause the provider to change the rate they want to charge for that usage. It's not metadata of a counter that cause the provider to change the rate. It's a meter of a resource that can do that. That only solves part of the problem, though. As a provider I may want to charge different flat rates for the amount of RAM being used. For example, 1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the size of the VM changes, we need to produce multiple totals (the length of time that the VM had 1024 MB RAM and then the length of time it had 4096 MB RAM). Yeah, like I said, for the meter 'RAM' of resource 'instance' you can't request a total amount used, because the type of this meter (I don't know how to call it, it's the kind I named if-i-change-you-need-to-split-the-resource-in-several-stuff in my latest email) don't have this semantic. I might also want to change the rate I bill when a VM is migrated between hosts or availability zones (I think we said migration caused a new instance to be created, but bear with me). The availability zone for an instance is clearly metadata and not something we can track via a counter. Again, that's also a meter that has the same type of 'RAM' for a resource 'instance'. That's an interesting idea, and it might solve the problem. At this point in the Folsom schedule though, I would much rather implement a pared down API that handles the simple cases but makes the caller do a bit more data manipulation for complex cases, in favor of focusing on counting more things than we do now. Is that a reasonable approach? Problem is that we might break the API a bit with this. This would not be the first time an OpenStack API is broken, but if we can avoid it, it'd be better. I am not sure you can really bill anything if you're not able to handle a simple thing such a VM resize. So currently, it seems that the API is not designed correctly to handle such a case, and since it's not yet implemented, maybe it's still time to fix it? -- /* Julien Danjou ╭ Free Software hacker freelance ╰ http://julien.danjou.info */ pgpBtQSHifQMF.pgp Description: PGP signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [metering] resource metadata changes and billing
On Mon, Jul 02 2012, Doug Hellmann wrote: No, there are cases where the metadata will affect the rate. For instance, it costs a different amount to have an instance in each of Amazon's availability zones (data centers). The counter would still say that the instance has been running for a certain amount of time, but the *rate* for charging for that time would depend on where it is. A representative from HP requested the same thing in ceilometer, and we may use it at DreamHost, too, eventually. I totally agree with you, Doug. I'm just saying that's it's not *only* a metadata. The zone must be some kind of a meter, even if it's not numeric. It should be a meter with a type that causes the resource (here the instance) to be billed differently (and therefore to generate multiple objects when returning resource usage metering). Clearly the term meter is probably not the good one, maybe we should split this, but to me it must be extracted from metadata to become something more. Something we can rely on to take the decision that this is something worst splitting the metered resource in different parts because the billing must change (zone, RAM, flavor, volume size…). Speaking of volume size, if you take the example of a storage volume, you likely to have the same issue. You may not charge the same thing if your volume total size is 1 GB or 10 GB, and if it has been resize you want (not sure it's possible, but one day) to know when precisely. Whereas size used is likely to be just a generic absolute meter. We probably have time to fix it before the release. On the other hand, it seems much more important to use work on writing data collectors (new pollsters, adding notifications to other projects, etc.). I don't think we can do both things. Sure. Anyway, we both know that's a do-ocracy. :-) -- /* Julien Danjou ╭ Free Software hacker freelance ╰ http://julien.danjou.info */ pgpP7E1Rq08GA.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] [metering] resource metadata changes and billing
On Fri, Jun 29 2012, Doug Hellmann wrote:
Thoughts?
Please correct me if I'm wrong.
What I understand is that you're saying that something like:
GET
v1/[SOURCES/SOURCE/]USERS/USER_ID/RESOURCES/RESOURCE_ID/METER/VOLUME
as defined in the current API draft, for a counter like instance CPU
time or RAM size has no sense because it can depends on other metadata
From the instance.
That sounds right in many case, especially instances.
The best way to fix this is to not return a sum, but a set of documents
describing the different changes.
E.g. for an (simplified) instance liked you described
GET v1/users/jd/instances/1234
{
id: 1234,
name: foobar,
…,
memory: 1024,
cpu_time: 393010,
start: 2012-06-01 00:00:00,
end: 2012-06-12 12:00:00,
}
{
id: 1234,
name: foobar,
…,
memory: 2048,
cpu_time: 1231294,
start: 2012-06-12 12:00:01,
end: 2012-06-26 13:24:43
}
{
id: 1234,
name: foobar,
…,
memory: 1024,
cpu_time: 4013510,
start: 2012-06-26 13:24:44,
end: 2012-06-30 23:59:00,
}
Doing this does not sounds like too much crazy. You just have to iterate
over each record concerning instance 1234. You create a first document
From the first record. Then if you encounter a meter that is:
- a delta (i.e. cpu_time), you sum up to the data you got from the
latest record in your document
- an incremented counter, you replace the last one with this one
- an absolute counter (i.e. memory) you start a new document, keep the
latest values from incremented counters (so you can substract the
value and start from 0), and reset all delta counters to 0.
If none of the absolute counter (RAM, number of CPU, …) changes, you'll
end up with only one document for the whole period. If one change,
you'll get multiple document describing the resources consumed for each
span time.
WDYT?
--
Julien
pgpJHpowFKbmg.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] [metering] resource metadata changes and billing
On Fri, Jun 29 2012, Doug Hellmann wrote: We do have counters for RAM and CPU separate from instance. But the rate at which the provider bills for those things may vary based on metadata. My example may be bad because it uses 2 values we're measuring, one of which also shows up in the metadata for another. As a different example, take the instance display name. The display name is under the control of the user and is extremely unlikely to reflect a change in the billing rate. However, changing the display name changes the metadata for the instance. A naive implementation of the processing loop would pick that up and generate multiple documents even though there is no need to do so. Yep, but the display name is not a counter. Memory is a counter. An instance is made of several counter. We need to split metered objects based on their absolute counter changing (memory, number of core…), not based on random metadata, i.e. a resource have several meters. So what was considered as metadata (like memory) so far should changed to become a meter of an resource (like an instance) and have for this one a special type (not sure about the type name to use). We may need to refine our model to be a bit more hierarhical like: resource -- counter #1 of type 'relative' | `- counter #2 of type 'absolute' ` counter #3 of type 'if-i-change-you-need-to-split-the-resource-in-several-stuff' etc… -- Julien pgp0SCtPP0cCp.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] [metering] proposed changes to pollster plugin API
On Thu, Jun 28 2012, Doug Hellmann wrote: I propose that we move the code that connects to libvirt and gets the list of instances into the class that calls the pollsters (AgentManager) so we can support both calling patterns. That will make the AgentManager the ComputeAgentManager (since network pollsters won't necessarily need to talk to libvirt) and we will need other managers for calling pollsters that do not use compute resources. I don't see that as a problem, since those pollsters probably won't run on the compute nodes anyway so we will want them to be loaded in another agent process. What do the rest of you think about this change? That recalls me my first idea of having one nova.service.Service (but only one agent daemon) by OS component. Except this time we would put them in only one daemon. So that sounds fine to me. How do you propose we configure the enabled manager then? Using the same kind of system that we have for plugins? That'd basically makes us have a 2 levels plugin system in the end, which doesn't bother me anyway since for now everything is automagically configured and running. -- Julien pgpEQ95arULlc.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] [metering] proposed changes to pollster plugin API
On Thu, Jun 28 2012, Doug Hellmann wrote: I'm not sure we need that many different managers. If we only need a couple, we could just have separate wrapper scripts like we do for the collector and agent now. That makes me think about how nova-api works. We can mimic that. -- Julien pgp35esjabI09.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
[Openstack] [metering] Meeting agenda for Thursday at 16:00 UTC (June 28th, 2012)
Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. Agenda: http://wiki.openstack.org/Meetings/MeteringAgenda * Review last week's actions * Discuss and vote the incubation application proposal to be submitted to PPB http://wiki.openstack.org/Projects/IncubatorApplicationCeilometer * Open discussion Cheers, -- Julien pgp9BgeJq4JkS.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
[Openstack] [infra] Stackforge issues: tests mails
Hi infra team, We've a couple of problem on Stackforge currently with at least the ceilometer project. First, I don't receive any email from Gerrit anymore since several days. :-( Secondly, I've added a bunch of tests for Essex on Jenkins days ago, but it seems they are either not complete or not deployed. The changes are: https://github.com/openstack/openstack-ci-puppet/commit/15e8d50de49dccb5958ec241638e7609d722d697 Could someone check this both issues? Thanks in advance! Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [infra] Stackforge issues: tests mails
On Mon, Jun 25 2012, Andrew Hutchings wrote: As we have pointed out several times the Stackforge Gerrit mail is unreliable. This is because the Stackforge setup is hosted in HP Cloud and they have (quite rightly) anti-spam measures such as port 25 rate limiting. We have a plan to resolve this soon but it is not an easy fix. In the mean time the #stackforge-dev IRC channel can be used for Gerrit bot notifications. Ok, I though it was solved actually. No problem then, we'll suffer in silence until that can be really solved. :-) I can see the jobs on Jenkins just fine and puppet confirms there was no problem with deployment. The Zuul service, however, was not running. This has been fixed. Great, thank you Andrew! :) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [infra] Stackforge issues: tests mails
On Mon, Jun 25 2012, Andrew Hutchings wrote: I can see the jobs on Jenkins just fine and puppet confirms there was no problem with deployment. The Zuul service, however, was not running. This has been fixed. Things changed indeed, but something is still wrong I think. I just sent a review request: https://review.stackforge.org/#/c/232/ and Jenkins checked it. But we lost the link to Jenkins in the review. Looking for the check manually here: https://jenkins.stackforge.org/view/Ceilometer/job/gate-ceilometer-merge/ seems to show that build #73 was related to this request but it has been successful. But it reviews and reports as LOST. Any hint? :) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Implemented three methods in Ceilometer
On Wed, Jun 20 2012, Kobagana Kumar wrote: Hi Kobagana, I have implemented three more classes in Ceilometer plug-in module. Added those classes in libvirt.py file in compute. The classes which I have added are counters to find out the following: 1. Number of CPUs used 2. Memory used 3. Maximum memory used I am also ready with test cases for those methods. Please let me know the procedure to contribute my code to ceilometer code base. You need to send your patches to https://review.stackforge.org/ using git-review. You can find some documentation about this here: http://wiki.openstack.org/GerritWorkflow -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [metering] Glance usage data retrieval
Hello, As part of the ceilometer project¹, we're working on usage data retrieval from various OpenStack components. One of them is Glance. We're targeting Folsom for the first release, therefore it seems important for both projects to be able to work together, this is why we're bringing ceilometer to your attention and asking for advices. :) What we want is to retrieve the maximum amount of data, so we can meter things, to bill them in the end. For now and for Glance, this only includes the number of image uploaded (per user/tenant), but we'll need probaly more in a near future. At this point we plan to plug into the notification system, since it seems to be what Glance provides to accomplish this. And so far, the notifications provided seem enough to accomplish what we want to do. Do you have any advice regarding integration of Ceilometer and Glance together? Is this something a stable interface we can rely on, or is there a better way to do so? Thanks in advance, Regards, ¹ http://launchpad.net/ceilometer -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Meeting agenda for Thursday at 16:00 UTC (June 7th, 2012)
On Wed, Jun 06 2012, Julien Danjou wrote: Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. http://wiki.openstack.org/Meetings/MeteringAgenda Topic: Storage backend * Storage backend (high availability, SPOF etc.) * Agent configuration mechanism https://lists.launchpad.net/openstack/msg12760.html * Open discussion (if we have any time left) Here's the summary of that meeting: == #openstack-meeting Meeting == Meeting started by jd___ at 16:01:02 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-07-16.01.log.html . Meeting summary --- * LINK: https://lists.launchpad.net/openstack/msg12851.html (jd___, 16:01:03) * actions from previous meetings (jd___, 16:01:28) * Storage backend (high availability, SPOF etc.) (jd___, 16:06:14) * LINK: https://lists.launchpad.net/openstack/msg12884.html (jd___, 16:07:48) * AGREED: jd and dhellmann to focus on an SQL plugin storage (jd___, 16:11:19) * AGREED: use the plugin system proposed by dhellmann at https://lists.launchpad.net/openstack/msg12884.html (jd___, 16:16:23) * ACTION: dhellmann: submit plugin branch for review and merging (dhellmann, 16:16:36) * ACTION: dhellmann rename plugin to engine for storage backend ex-plugin-now-engine system (jd___, 16:24:59) * ACTION: nijaba to propose a google spreadsheet calculator to estimate volume of metering message (including nova, swift, cinder, quantum) (nijaba, 16:36:35) * AGREED: a database engine has a function to interpret the API queries in addition to the function to store the data (jd___, 16:40:26) * ACTION: dhellmann: start mapping API queries to database engine methods (dhellmann, 16:40:49) * Agent configuration mechanism (jd___, 16:43:36) * AGREED: agent are configured through traditional means, but agent get meter config from the central collector ? (dachary, 17:00:08) * ACTION: nijaba to rework meter configuration proposal on the basis of discussion (nijaba, 17:01:19) Meeting ended at 17:01:52 UTC. Action items, by person --- * dhellmann * dhellmann: submit plugin branch for review and merging * dhellmann rename plugin to engine for storage backend ex-plugin-now-engine system * dhellmann: start mapping API queries to database engine methods * nijaba * nijaba to propose a google spreadsheet calculator to estimate volume of metering message (including nova, swift, cinder, quantum) * nijaba to rework meter configuration proposal on the basis of discussion People present (lines said) --- * dhellmann (80) * nijaba (62) * jd___ (60) * dachary (38) * openstack (4) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Agent configuration mechanism
On Tue, Jun 05 2012, Nick Barcet wrote: The main idea is that all agents of a given type should be sending similarly formatted information in order for the information to be usable, hence the need to ensure that configuration info is centrally stored and retrieved. This would rule out, in my mind, the idea that we could use the global flags object, as distribution of the configuration file is left to the cloud implementor and does not lend for easy and synchronized updates of agent config. IMHO this is solving a problem that already exists for all other OpenStack components. A problem that no other OpenStack components tried to resolved, AFAIK. So I don't see why we should try to resolve configuration deployment in ceilometer when it's a much larger issue in the project. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Agent configuration mechanism
On Tue, Jun 05 2012, Nick Barcet wrote: The main idea is that all agents of a given type should be sending similarly formatted information in order for the information to be usable, hence the need to ensure that configuration info is centrally stored and retrieved. This would rule out, in my mind, the idea that we could use the global flags object, as distribution of the configuration file is left to the cloud implementor and does not lend for easy and synchronized updates of agent config. IMHO this is solving a problem that already exists for all other OpenStack components. A problem that no other OpenStack components tried to resolved, AFAIK. So I don't see why we should try to resolve configuration deployment in ceilometer when it's a much larger issue in the project. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Agent configuration mechanism
On Tue, Jun 05 2012, Nick Barcet wrote: I would have thought that we may want to support different intervals per meters, based on the billing rules that one may want to offer. For example, I may want to bill compute by the hour but floating IPs by the day, hence have a different reporting interval for each. I don't think you want to poll once a day something you bill per day. If you poll only at noon, and I use a resource from 8:00 to 10:00, you'll miss my usage and I'll use resource for free. :) Yes, there's a minimum interval to be configured, but it's the interval that defined how much grained your metering/billing will be. E.g. if it's 1 hour, you won't charge anything used for less than one hour. You probably wants something like 5 minutes or less, and be sure the agent can keep up with the needed polling speed. :) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Agent configuration mechanism
On Wed, Jun 06 2012, Nick Barcet wrote: Maybe the problem of discrepancy of configuration is more an issue for metering than for other components? At least that's my belief. […] Sure, I don't say that it's useless to have a centralized configuration management in our case. I just think that it shouldn't be our problem to fix that right now, and that we shouldn't spend our energy trying to fix this. Deployers use configuration management tools to handle this in various OpenStack components so far. I think it's saner, for now, to let this continue until OpenStack provides something better all components can rely on. I'm just having the feeling we're going out of scope here. But this is just my opinion. :) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Meeting agenda for Thursday at 16:00 UTC (June 7th, 2012)
Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. http://wiki.openstack.org/Meetings/MeteringAgenda Topic: Storage backend * Storage backend (high availability, SPOF etc.) * Agent configuration mechanism https://lists.launchpad.net/openstack/msg12760.html * Open discussion (if we have any time left) Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] News from 31/05 to 06/06
Hi, Here's a few things done in the last week concerning ceilometer: - The floating IP pollster have been merged https://github.com/stackforge/ceilometer/commit/bbc706c4c02d2750df961474b00998b9766cd47a - The configuration now uses openstack.common.cfg https://github.com/stackforge/ceilometer/commit/a49e59b1151ce87c8f4ed6e12368e01dbbb6243a - All instance events are listened to https://github.com/stackforge/ceilometer/commit/d615fb872ddceaf1ddef7e3997bcf2523cab283e - Updated to use the new Nova flag API https://github.com/stackforge/ceilometer/commit/6fa69bbdccb9273ef1e55f08dc3db926ab20529c Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [metering] Changes to the ceilometer Jenkins job
On Tue, May 29 2012, Julien Danjou wrote: We noticed that currently, on Stackforge, the ceilometer project has only one Jenkins job, checking that the merge occurs correctly. We'd like to add jobs to run unit tests, pep8, etc… I took a look at the openstack-ci-puppet repo, but I'm not sure of the changes, so I prefer to ask here for someone that understand this to help. From what I see, it's likely we would like to use the default python_jobs template. Is there a way to add more checks without touching the openstack-ci-puppet repository? I'd like to run tests with tox on the same py26/27 envs but using a different set of pip-requires. I found out how to write the tox.ini part, but I am not sure how the envlist is controlled on the Jenkins side. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Meeting agenda for Thursday at 16:00 UTC (May 31th, 2012)
On Wed, May 30 2012, Julien Danjou wrote: The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. http://wiki.openstack.org/Meetings/MeteringAgenda Topic: API message format * Discuss API message format * Open discussion (if we have any time left) The meeting took place yesterday, a summary follows. == #openstack-meeting Meeting == Meeting started by jd___ at 16:02:40 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-31-16.02.log.html . Meeting summary --- * LINK: https://lists.launchpad.net/openstack/msg12501.html (jd___, 16:02:40) * actions from previous meetings (jd___, 16:03:09) * jd___ and dhellmann opened a bunch of bugs on Launchpad to track things https://bugs.launchpad.net/ceilometer (jd___, 16:03:21) * ACTION: dhellmann to report on outcome of demo at DreamHost (dhellmann, 16:07:44) * ACTION: dhellmann to report on outcome of demo at DreamHost (jd___, 16:07:58) * API message format (jd___, 16:08:24) * ACTION: nijaba to comment on bug 1006990 for anti spoofing of messages (nijaba, 16:15:28) * ACTION: nijaba to define a configuration mechanism on a per agent basis (nijaba, 16:18:10) * AGREED: on the proposal from dhellmann https://gist.github.com/2844410 for API messaging format, pending the 2 modifications discussed during the meeting (nijaba, 16:47:10) * other topics (nijaba, 16:49:05) Meeting ended at 16:50:36 UTC. Action items, by person --- * dhellmann * dhellmann to report on outcome of demo at DreamHost * dhellmann to report on outcome of demo at DreamHost * nijaba * nijaba to comment on bug 1006990 for anti spoofing of messages * nijaba to define a configuration mechanism on a per agent basis People present (lines said) --- * dhellmann (52) * nijaba (41) * jd___ (39) * flacoste (11) * uvirtbot (5) * openstack (4) * dachary (2) * zykes- (2) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [metering] delta vs. cumulative meters
On Tue, May 29 2012, Doug Hellmann wrote: […] Thoughts? As you pointed out, it's not safe to compute delta when your counter is gauge, and vice versa. Rather than documenting, we may just add the counter type (à la RRD: gauge, counter, derive…) to the meter, so it's easier to make things evolve and discover counters by themselves. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Meeting agenda for Thursday at 16:00 UTC (May 31th, 2012)
Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. http://wiki.openstack.org/Meetings/MeteringAgenda Topic: API message format * Discuss API message format * Open discussion (if we have any time left) Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 pgpZvrBvKcwB3.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
[Openstack] [Metering] News from 24/05 to 30/05
Hi, Here's a few things done in the last week concerning ceilometer: - Various bugs have been opened to have more visibility on the project progress https://bugs.launchpad.net/ceilometer - Test suite have been fixed wrt db usage https://github.com/stackforge/ceilometer/commit/dbccf0ce6974fc3665f0ffd63a9b08725339d6cf - A floating IP pollster have been added https://github.com/stackforge/ceilometer/commit/d4635bede100934d1535b334dfc5a694bffe7d97 - We now publish and receive metering message https://github.com/stackforge/ceilometer/commit/b76f67d11f5bed61818b9dcaf77b20bfb087547b - Ceilometer specific configuration uses openstack.common.cfg https://github.com/stackforge/ceilometer/commit/a49e59b1151ce87c8f4ed6e12368e01dbbb6243a - Ceilometer now uses tox and has the standard Jenkins jobs installed https://github.com/stackforge/ceilometer/commit/5e0a32f47505d342676099518ec3fad558c61511 - Add listeners for other instance-related events https://github.com/stackforge/ceilometer/commit/d615fb872ddceaf1ddef7e3997bcf2523cab283e -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [metering] Changes to the ceilometer Jenkins job
Hi, We noticed that currently, on Stackforge, the ceilometer project has only one Jenkins job, checking that the merge occurs correctly. We'd like to add jobs to run unit tests, pep8, etc… I took a look at the openstack-ci-puppet repo, but I'm not sure of the changes, so I prefer to ask here for someone that understand this to help. From what I see, it's likely we would like to use the default python_jobs template. If anything is missing on our side to use the standard set of checks, we'll do what is necessary to be able to use them. :) Thanks in advance! Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] Meeting agenda for Thursday at 16:00 UTC (May 24th, 2012)
On Wed, May 23 2012, Julien Danjou wrote: Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. http://wiki.openstack.org/Meetings/MeteringAgenda Topic: message queue choice * Agree on which messaging queue system to use, based on criteria given in https://lists.launchpad.net/openstack/msg11937.html * Discuss message bus usage described in architecture proposal V1 http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1 * Open discussion (if we have any time left) The meeting took place yesterday, a summary follows. == #openstack-meeting Meeting == Meeting started by jd___ at 16:01:08 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-24-16.01.log.html Meeting summary --- * LINK: https://lists.launchpad.net/openstack/msg12156.html (jd___, 16:01:09) * actions from previous meetings (jd___, 16:01:19) * flacoste comments sent to the list (jd___, 16:03:22) * messaging queue system to use (jd___, 16:03:41) * LINK: https://lists.launchpad.net/openstack/msg11937.html (jd___, 16:04:26) * AGREED: use nova.rpc as a messaging bus and let the user chose what he wants behind (qpid, rabbit, zmq…) (jd___, 16:08:43) * AGREED: use nova.rpc from openstack.common when it moves to this (jd___, 16:08:57) * message bus usage described in architecture proposal V1 (jd___, 16:16:35) * we could do it like notifications do and publish multiple times to metering and metering + counter_id (jd___, 16:21:07) * Open discussion (jd___, 16:23:49) * ACTION: jd___ open tickets in launchpad for plugins, etc… (jd___, 16:34:53) * ACTION: jd___ open ticket to have the collector listen for notifications from the services other than nova (jd___, 16:38:17) * ACTION: jd___ we also need tickets for adding polling for hypervisor drivers that do not use libvirt (jd___, 16:42:48) Meeting ended at 16:45:00 UTC. Action items, by person --- * jd___ * jd___ open tickets in launchpad for plugins, etc… * jd___ open ticket to have the collector listen for notifications from the services other than nova * jd___ we also need tickets for adding polling for hypervisor drivers that do not use libvirt People present (lines said) --- * jd___ (91) * dhellmann (89) * mnaser (17) * flacoste (10) * clayg (8) * openstack (3) * uvirtbot (1) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] [Metering] News from 17/05 to 23/05
Hi, Here's a few things done in the last week concerning ceilometer: - Doug added plugin support to the notification portion of the collector daemon https://github.com/stackforge/ceilometer/commit/73c9150afe7fc07018b0435ae7b24b52bd6a0a15 - Doug added a tool for recording notifications and replaying them https://github.com/stackforge/ceilometer/commit/8f4ba1656c26ac7885c46f2fc8fcf9f519146f96 - Doug wrote a an architecture proposal: http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1 - I've added ceilometer-agent and ceilometer-collector daemons https://github.com/stackforge/ceilometer/commit/5717e9c5c9a029d1b1daa72f2e7ac0ab1039bf0c - I've added some code to fetch CPU time from libvirt https://github.com/stackforge/ceilometer/commit/cc5b02dc84e26af050a0983764a5977e25bd3726 Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] Stackforge server issue
Hi, It seems the Stackforge server has a little problem lately. I'm unable to post a review on Gerrit, nor to use git-review: error: unpack failed: error No space left on device fatal: Unpack error, check server log Anyone could take a look? Thanks, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] Stackforge server issue
On Mon, May 21 2012, Andrew Hutchings wrote: Should be OK now. Please let me know if you run into any problems. Everything seems fine now, thanks Andrew! -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
