| *** jpipes is now known as jaypipes-afk | 00:02 | |
| *** ryanpetrello has quit IRC | 00:02 | |
| *** dolphm has joined #openstack-meeting | 00:03 | |
| *** mcclurmc_ has quit IRC | 00:06 | |
| *** dolphm has quit IRC | 00:07 | |
| *** dtroyer is now known as dtroyer_zzz | 00:08 | |
| *** deshantm has quit IRC | 00:09 | |
| *** mcclurmc_ has joined #openstack-meeting | 00:10 | |
| *** littleidea has joined #openstack-meeting | 00:12 | |
| *** lloydde has quit IRC | 00:12 | |
| *** edygarcia has joined #openstack-meeting | 00:14 | |
| *** ryanpetr_ has quit IRC | 00:21 | |
| *** anderstj has quit IRC | 00:22 | |
| *** deshantm has joined #openstack-meeting | 00:23 | |
| *** asdfasdf has quit IRC | 00:23 | |
| *** nati_ueno has joined #openstack-meeting | 00:29 | |
| *** asdfasdf has joined #openstack-meeting | 00:37 | |
| *** nati_ueno has quit IRC | 00:37 | |
| *** asdfasdf has quit IRC | 00:40 | |
| *** joearnold has joined #openstack-meeting | 00:40 | |
| *** joearnold has quit IRC | 00:44 | |
| *** Adri2000 has joined #openstack-meeting | 00:48 | |
| *** Adri2000 has quit IRC | 00:48 | |
| *** Adri2000 has joined #openstack-meeting | 00:48 | |
| *** mcclurmc_ has quit IRC | 00:48 | |
| *** edygarcia has quit IRC | 00:54 | |
| *** joearnold has joined #openstack-meeting | 00:59 | |
| *** joearnold has quit IRC | 01:02 | |
| *** milner has quit IRC | 01:11 | |
| *** mcclurmc_ has joined #openstack-meeting | 01:14 | |
| *** ywu has joined #openstack-meeting | 01:15 | |
| *** dtroyer_zzz is now known as dtroyer | 01:17 | |
| *** mcclurmc_ has quit IRC | 01:20 | |
| *** nati_ueno has joined #openstack-meeting | 01:30 | |
| *** jog0 has quit IRC | 01:35 | |
| *** Mandell_ has quit IRC | 01:35 | |
| *** ayoung has quit IRC | 01:35 | |
| *** ryanpetrello has joined #openstack-meeting | 01:36 | |
| *** ryanpetrello has quit IRC | 01:41 | |
| *** alpha_ori has joined #openstack-meeting | 01:50 | |
| *** alpha_ori has left #openstack-meeting | 01:50 | |
| *** Weighed has quit IRC | 02:03 | |
| *** danwent has quit IRC | 02:10 | |
| *** nati_ueno has quit IRC | 02:25 | |
| *** deshantm has quit IRC | 02:39 | |
| *** mnewby has joined #openstack-meeting | 02:58 | |
| *** ryanpetrello has joined #openstack-meeting | 03:00 | |
| *** nati has joined #openstack-meeting | 03:01 | |
| *** littleidea has quit IRC | 03:02 | |
| *** littleidea has joined #openstack-meeting | 03:03 | |
| *** nati has quit IRC | 03:04 | |
| *** nati has joined #openstack-meeting | 03:04 | |
| *** nati has quit IRC | 03:10 | |
| *** joearnold has joined #openstack-meeting | 03:20 | |
| *** nati has joined #openstack-meeting | 03:25 | |
| *** anderstj has joined #openstack-meeting | 03:33 | |
| *** ywu has quit IRC | 03:35 | |
| *** danwent has joined #openstack-meeting | 03:42 | |
| *** joearnold has quit IRC | 03:43 | |
| *** joearnold has joined #openstack-meeting | 03:44 | |
| *** nati has quit IRC | 03:53 | |
| *** danwent has quit IRC | 03:55 | |
| *** jakedahn is now known as jakedahn_zz | 04:08 | |
| *** nati has joined #openstack-meeting | 04:11 | |
| *** danwent has joined #openstack-meeting | 04:11 | |
| *** Mandell has joined #openstack-meeting | 04:30 | |
| *** markvoelker has quit IRC | 04:36 | |
| *** ttx has quit IRC | 04:36 | |
| *** ttx has joined #openstack-meeting | 04:36 | |
| *** ttx has joined #openstack-meeting | 04:36 | |
| *** kpepple_ has quit IRC | 04:36 | |
| *** devcamcar has quit IRC | 04:36 | |
| *** kpepple has joined #openstack-meeting | 04:36 | |
| *** dragondm has quit IRC | 04:37 | |
| *** devcamcar has joined #openstack-meeting | 04:37 | |
| *** westmaas has quit IRC | 04:37 | |
| *** westmaas has joined #openstack-meeting | 04:37 | |
| *** anotherjesse_zz has quit IRC | 04:37 | |
| *** garyk has quit IRC | 04:38 | |
| *** dragondm has joined #openstack-meeting | 04:38 | |
| *** anotherjesse has joined #openstack-meeting | 04:39 | |
| *** anderstj has quit IRC | 04:43 | |
| *** Mandell_ has joined #openstack-meeting | 04:43 | |
| *** Mandell has quit IRC | 04:43 | |
| *** sdague has quit IRC | 05:09 | |
| *** sdague has joined #openstack-meeting | 05:09 | |
| *** novas0x2a|laptop has quit IRC | 05:09 | |
| *** nati has quit IRC | 05:12 | |
| *** garyk has joined #openstack-meeting | 05:31 | |
| *** primeministerp has quit IRC | 05:35 | |
| *** primeministerp has joined #openstack-meeting | 05:42 | |
| *** dtroyer is now known as dtroyer_zzz | 05:44 | |
| *** jakedahn_zz is now known as jakedahn | 05:44 | |
| *** mnewby has quit IRC | 06:01 | |
| *** GheAway is now known as GheRivero | 06:01 | |
| *** mnewby has joined #openstack-meeting | 06:03 | |
| *** danwent has quit IRC | 06:10 | |
| *** GheRivero is now known as Ghe | 06:15 | |
| *** Ghe is now known as Ghe_Rivero | 06:15 | |
| *** mcclurmc_ has joined #openstack-meeting | 06:26 | |
| *** Mandell_ has quit IRC | 06:26 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 06:29 | |
| *** joearnold has quit IRC | 06:50 | |
| *** mnewby has quit IRC | 07:23 | |
| *** garyk has quit IRC | 07:43 | |
| *** darraghb has joined #openstack-meeting | 07:51 | |
| *** garyk has joined #openstack-meeting | 07:51 | |
| *** littleidea has quit IRC | 07:53 | |
| *** derekh has joined #openstack-meeting | 07:59 | |
| *** Ghe_Rivero has quit IRC | 08:28 | |
| *** jakedahn is now known as jakedahn_zz | 08:32 | |
| *** journeeman has joined #openstack-meeting | 08:36 | |
| *** adjohn has joined #openstack-meeting | 08:36 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 09:10 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 09:14 | |
| *** ryanpetrello has quit IRC | 09:16 | |
| *** GheRivero has joined #openstack-meeting | 09:21 | |
| *** adjohn has quit IRC | 09:43 | |
| *** mikal has quit IRC | 10:09 | |
| *** mikal has joined #openstack-meeting | 10:11 | |
| *** markvoelker has joined #openstack-meeting | 11:44 | |
| *** littleidea has joined #openstack-meeting | 12:11 | |
| *** sandywalsh has joined #openstack-meeting | 12:15 | |
| *** dprince has joined #openstack-meeting | 12:24 | |
| *** ryanpetrello has joined #openstack-meeting | 12:26 | |
| *** littleidea has quit IRC | 12:26 | |
| *** garyk has quit IRC | 12:32 | |
| *** dhellmann has quit IRC | 12:35 | |
| *** ryanpetrello has quit IRC | 12:38 | |
| *** dolphm has joined #openstack-meeting | 12:40 | |
| *** garyk has joined #openstack-meeting | 12:46 | |
| *** blamar has joined #openstack-meeting | 12:56 | |
| *** dolphm has quit IRC | 12:56 | |
| *** rkukura has quit IRC | 13:00 | |
| *** garyk has quit IRC | 13:16 | |
| *** nati has joined #openstack-meeting | 13:22 | |
| *** jsavak has joined #openstack-meeting | 13:25 | |
| *** dtroyer_zzz is now known as dtroyer | 13:28 | |
| *** markmcclain has quit IRC | 13:29 | |
| *** lloydde has joined #openstack-meeting | 13:29 | |
| *** nati has quit IRC | 13:31 | |
| *** ayoung has joined #openstack-meeting | 13:38 | |
| *** dachary has joined #openstack-meeting | 13:45 | |
| *** ryanpetrello has joined #openstack-meeting | 13:46 | |
| *** jsavak has quit IRC | 13:46 | |
| *** jsavak has joined #openstack-meeting | 13:46 | |
| *** rkukura has joined #openstack-meeting | 13:48 | |
| *** markvoelker has quit IRC | 13:56 | |
| *** joe-savak has joined #openstack-meeting | 13:56 | |
| *** jsavak has quit IRC | 13:59 | |
| *** edygarcia has joined #openstack-meeting | 14:05 | |
| *** lloydde has quit IRC | 14:06 | |
| *** markmcclain has joined #openstack-meeting | 14:09 | |
| *** oubiwann1 has joined #openstack-meeting | 14:14 | |
| *** dhellmann has joined #openstack-meeting | 14:15 | |
| *** anderstj has joined #openstack-meeting | 14:16 | |
| *** jgriffith has joined #openstack-meeting | 14:20 | |
| *** Mandell has joined #openstack-meeting | 14:22 | |
| *** dwalleck has joined #openstack-meeting | 14:23 | |
| *** garyk has joined #openstack-meeting | 14:44 | |
| *** dhellmann has quit IRC | 14:48 | |
| *** dhellmann has joined #openstack-meeting | 14:48 | |
| *** oubiwann2 has joined #openstack-meeting | 14:48 | |
| *** oubiwann1 has quit IRC | 14:49 | |
| *** ryanpetr_ has joined #openstack-meeting | 14:49 | |
| *** ryanpetrello has quit IRC | 14:49 | |
| *** edygarcia has quit IRC | 14:50 | |
| *** edygarcia has joined #openstack-meeting | 14:53 | |
| *** anderstj has quit IRC | 14:54 | |
| *** Gordonz has joined #openstack-meeting | 14:55 | |
| *** primeministerp has quit IRC | 14:56 | |
| *** primeministerp has joined #openstack-meeting | 14:57 | |
| *** dtroyer is now known as dtroyer_zzz | 14:57 | |
| *** joearnold has joined #openstack-meeting | 15:01 | |
| *** rnirmal has joined #openstack-meeting | 15:04 | |
| *** Mandell has quit IRC | 15:04 | |
| *** dachary has quit IRC | 15:08 | |
| *** primeministerp has quit IRC | 15:09 | |
| *** ayoung has quit IRC | 15:09 | |
| *** littleidea has joined #openstack-meeting | 15:09 | |
| *** dachary has joined #openstack-meeting | 15:09 | |
| *** Gordonz has quit IRC | 15:09 | |
| *** Gordonz has joined #openstack-meeting | 15:10 | |
| *** primeministerp has joined #openstack-meeting | 15:17 | |
| *** ayoung has joined #openstack-meeting | 15:18 | |
| *** joearnold has quit IRC | 15:19 | |
| *** joearnold has joined #openstack-meeting | 15:22 | |
| *** lloydde has joined #openstack-meeting | 15:22 | |
| *** danwent has joined #openstack-meeting | 15:22 | |
| *** adjohn has joined #openstack-meeting | 15:24 | |
| *** adjohn has quit IRC | 15:24 | |
| *** dachary has quit IRC | 15:26 | |
| *** jaypipes-afk is now known as jaypipes | 15:26 | |
| *** jamespage has joined #openstack-meeting | 15:26 | |
| *** jaypipes has quit IRC | 15:27 | |
| *** Gordonz_ has joined #openstack-meeting | 15:28 | |
| *** Gordonz has quit IRC | 15:29 | |
| *** joearnold has quit IRC | 15:30 | |
| *** jaypipes has joined #openstack-meeting | 15:33 | |
| *** dtroyer_zzz is now known as dtroyer | 15:39 | |
| *** dachary has joined #openstack-meeting | 15:44 | |
| *** egallen has joined #openstack-meeting | 15:45 | |
| *** milner has joined #openstack-meeting | 15:46 | |
| *** lloydde has quit IRC | 15:47 | |
| *** sprintnode has joined #openstack-meeting | 15:53 | |
| *** DuncanT has joined #openstack-meeting | 15:55 | |
| sprintnode | --help | 15:58 |
|---|---|---|
| nijaba | o/ | 15:58 |
| dachary | \o | 15:59 |
| *** dwalleck has quit IRC | 16:00 | |
| sprintnode | :) | 16:00 |
| jaypipes | dachary: afternoon. :) | 16:00 |
| dachary | #startmeeting | 16:00 |
| openstack | Meeting started Thu May 10 16:00:22 2012 UTC. The chair is dachary. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| dachary | #chair nijaba dachary | 16:00 |
| dachary | #meetingname ceilometer | 16:00 |
| dachary | #link https://lists.launchpad.net/openstack/msg11523.html | 16:00 |
| dachary | #topic actions from previous meetings | 16:00 |
| dachary | #link http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-16.00.html | 16:00 |
| dachary | #info dachary removed obsolete comment about floating IP http://wiki.openstack.org/EfficientMetering?action=diff&rev2=70&rev1=69 | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| dachary | #info dachary o6 : note that the resource_id is the container id. http://wiki.openstack.org/EfficientMetering?action=diff&rev2=71&rev1=70 | 16:00 |
| openstack | Current chairs: dachary nijaba | 16:00 |
| openstack | The meeting name has been set to 'ceilometer' | 16:00 |
| *** journeeman has quit IRC | 16:00 | |
| *** openstack changes topic to "actions from previous meetings" | 16:00 | |
| dachary | jaypipes: hi | 16:00 |
| dachary | jd___: actions ? | 16:00 |
| dachary | nijaba: actions ? | 16:01 |
| nijaba | #info The discussion about adding the source notion to the schema took place on the mailing list https://lists.launchpad.net/openstack/msg11217.html | 16:01 |
| nijaba | #info The conclusion was to add a source field to the event record, but no additional record type to list existing sources. | 16:01 |
| jaypipes | nijaba: could you explain that a bit more please? | 16:02 |
| jaypipes | nijaba: what are existing sources? | 16:02 |
| nijaba | jaypipes: sources could be different installation of openstack, or metering of other projects not sharing their creds with keystone | 16:03 |
| jd___ | #info jd___ add Swift counters, add resource ID info in counter definition, describe the table http://wiki.openstack.org/EfficientMetering?action=diff&rev2=57&rev1=54 | 16:03 |
| *** Dan__ has joined #openstack-meeting | 16:03 | |
| *** Dan__ is now known as Guest32307 | 16:03 | |
| *** flacoste has joined #openstack-meeting | 16:03 | |
| jaypipes | nijaba: k, got it. so basically, a source field that is NULLable. | 16:04 |
| *** woorea has joined #openstack-meeting | 16:04 | |
| nijaba | jaypipes: or set to a default, as the implementor prefers | 16:04 |
| jaypipes | gotcha | 16:04 |
| dachary | #topic meeting organisation | 16:04 |
| dachary | #info This is 2/5 meetings to decide the details of the architecture of the Metering project https://launchpad.net/ceilometer | 16:04 |
| dachary | #info Today's focus is on the definition of external REST API | 16:04 |
| dachary | #info There has not been enough discussions on the list to cover all aspects and the focus of this meeting was modified to cope with it. | 16:04 |
| dachary | #info The meeting is time boxed and there will not be enough time to introduce inovative ideas and research for solutions. | 16:04 |
| dachary | #info The debate will be about the pro and cons of the options already discussed on the mailing list. | 16:04 |
| dachary | #link https://lists.launchpad.net/openstack/msg11368.html | 16:04 |
| *** openstack changes topic to "meeting organisation" | 16:04 | |
| *** ss7pro has joined #openstack-meeting | 16:04 | |
| dachary | comments anyone ? | 16:04 |
| nijaba | dachary: on which topic? ;) | 16:05 |
| dachary | organization ;-) | 16:05 |
| *** lloydde has joined #openstack-meeting | 16:05 | |
| * nijaba +1 the org | 16:05 | |
| dachary | ok | 16:05 |
| dachary | :-D | 16:05 |
| dachary | #topic API defaults and API extensions | 16:05 |
| *** openstack changes topic to "API defaults and API extensions" | 16:05 | |
| jaypipes | My only comment is that I believe Ceilometer shouldn't invent its own API extensions mechanism... it should use the system in Nova. | 16:05 |
| dhellmann | +1 jaypipes | 16:05 |
| dachary | jaypipes: +1 | 16:05 |
| ss7pro | +1 jaypipes | 16:05 |
| * nijaba had no idea this was going on, so +1 | 16:05 | |
| jaypipes | it has its rough edges, but it gets you 90% of the way there. | 16:05 |
| dhellmann | I propose we table "extensions" for now and concentrate on the core API pending further discussion of extensions on the list. | 16:06 |
| jd___ | +1 jaypipes | 16:06 |
| jaypipes | dachary: also, it might just be my misunderstanding, but I want to make sure that API extensions and plugins are clearly delineated. | 16:06 |
| *** ryant has joined #openstack-meeting | 16:06 | |
| jaypipes | dachary: the description in the mailing list thread of API extensions seems to bleed a bit into plugin land. :) | 16:07 |
| dachary | well, I kind of assume we only need plugins for the purpose of implementing API extensions | 16:07 |
| nijaba | that's my understanding as well | 16:07 |
| jaypipes | Essentially, things like backend stores and such should not be API extensions, but rather plugins that use an adapter/driver model to have a pluggable implementation, using that same external API | 16:07 |
| dachary | which may not be true but I was only thinking about the API at the time | 16:07 |
| nijaba | the other type of "plugins" being agents | 16:07 |
| dhellmann | we can also use plugins to add event monitors and polling to the agents running on the compute nodes | 16:08 |
| jaypipes | ok, just wanted to make sure things like /extensions/MongoDbBackend/ etc weren't being considered... | 16:08 |
| nijaba | dhellmann: polling? the whol model we are discussing is push... | 16:08 |
| *** markvoelker has joined #openstack-meeting | 16:08 | |
| dachary | As far as the API is concerned, my suggestion was that each API extention is implemented as a plugin with a predefined interface. | 16:08 |
| dhellmann | well, we're going to have to poll libvirt, right? | 16:08 |
| woorea | some effort has been done in https://github.com/cloudbuilders/openstack-munin | 16:08 |
| nijaba | dhellmann: an agent should poll libvirt and push | 16:09 |
| dachary | #agreed Ceilometer shouldn't invent its own API extensions mechanism... it should use the system in Nova. | 16:09 |
| jaypipes | dachary: k | 16:09 |
| dhellmann | nijaba, exactly. There may be other things that we want to/need to poll, though. | 16:09 |
| nijaba | dhellmann: right | 16:09 |
| sprintnode | would nova-instancemonitor be useful ? | 16:09 |
| dachary | woorea: and recently improved by https://github.com/sileht/openstack-munin | 16:10 |
| jaypipes | not sure who brought it up on the ML, but I also agreed with the statement that ceilometer should try as much as possible to disaggregate the concept of collection from the concept of aggregation or reporting. | 16:10 |
| nijaba | sprintnode: yes, but let's save this for the agent discussion | 16:10 |
| dachary | #link https://github.com/cloudbuilders/openstack-munin | 16:10 |
| dachary | #link https://github.com/sileht/openstack-munin | 16:10 |
| woorea | exactly | 16:10 |
| sprintnode | ok | 16:10 |
| dhellmann | nijaba, so if we define a plugin API for all of the things that poll and another for things that care about notification events then it is easy to add new counters | 16:10 |
| dachary | jaypipes: there seems to be a consensus on that (aggregation != collection) | 16:10 |
| ss7pro | but those mumin plugins are using sql db directly | 16:11 |
| *** Weighed has joined #openstack-meeting | 16:11 | |
| ss7pro | nova db | 16:11 |
| woorea | dachary +1 | 16:11 |
| nijaba | dhellmann: here we are talking about the external rest API, not the internal agent API that will be discussed on the 24th | 16:11 |
| dhellmann | nijaba, sure, I'm speaking more generally about plugins: Use the nova system and use it everywhere. | 16:11 |
| nijaba | dhellmann: ah, makes sense then :) | 16:12 |
| dachary | #action dachary add info to the wiki on the topic of poll versus push | 16:12 |
| dhellmann | so, should we discuss the core API? | 16:12 |
| dachary | let's move on to the next topic | 16:12 |
| dachary | #topic API defaults | 16:13 |
| *** openstack changes topic to "API defaults" | 16:13 | |
| dachary | #info GET list components | 16:13 |
| dachary | #info GET list components meters (argument : name of the component) | 16:13 |
| dachary | #info GET list [user_id|project_id|source] | 16:13 |
| dachary | #info GET list of meter_type | 16:13 |
| dachary | #info GET list of events per [user_id|project_id|source] ( allow to specify user_id or project_id | 16:13 |
| dachary | or both ) | 16:13 |
| dachary | #info GET sum of (meter_volume, meter_duration) for meter_type and [user_id|project_id|source] | 16:13 |
| dachary | #info other ? | 16:13 |
| dachary | this is the current list in the wiki | 16:13 |
| dhellmann | would "GET list of events" allow for filtering by event type? | 16:13 |
| dachary | I'm under the impression that there is thin line between the "core API" and the "extensions" | 16:13 |
| *** Divakar has joined #openstack-meeting | 16:13 | |
| nijaba | dachary: there was a proposal to allow queries for user_id && project_id | 16:13 |
| nijaba | for anyone of thecounters | 16:14 |
| dhellmann | for example, I may want to charge a user a flat rate to create an instance and then a separate rate for keeping it alive for a period of time. So I need to know about creation events and aggregated runtime | 16:14 |
| dachary | #info GET list of events per user_id && project_id | 16:14 |
| woorea | for me : sum meter_volume and meter_duration is aggregation, not collector | 16:14 |
| jaypipes | Doesn't quite look like a RESTful API that is similar to the other OpenStack APIs... | 16:14 |
| nijaba | jaypipes: what would you suggest? | 16:15 |
| jaypipes | nijaba: perhaps it is just me not understanding :) I was thinking of an API like GET /components, GET /components/<COMPONENT_ID>, GET /components/<COMPONENT_ID>/events, etc | 16:15 |
| dachary | #link http://wiki.openstack.org/OpenStackRESTAPI | 16:15 |
| dhellmann | what are "components"? | 16:15 |
| dachary | dhellmann: swift, nova etc. | 16:16 |
| jaypipes | dhellmann: I assume a component was "nova-compute" or "nova-network", etc | 16:16 |
| dhellmann | dachary, is that the "source" field? | 16:16 |
| nijaba | dhellmann: no | 16:16 |
| woorea | for me source is the host | 16:16 |
| dachary | #link http://wiki.openstack.org/EfficientMetering#Meters | 16:16 |
| nijaba | dhellmann: source should be unique per AUTH system, not per component | 16:16 |
| dachary | it's the Component column of the above link dhellmann | 16:17 |
| nijaba | woorea: nor the host | 16:17 |
| dhellmann | aha, I didn't realize that was a key piece of information | 16:17 |
| dhellmann | why would a client want that list? | 16:17 |
| jaypipes | dachary: may I suggest renaming "meter" to "metric"? | 16:17 |
| nijaba | dhellmann: it was a suggestion from doug at hp yesterday on the ml | 16:18 |
| dachary | jaypipes: the proposal is poorly formated because we focus on the semantic. However, I fully agree that it should be a PATH ( or arguments I don't mind ) from which the parameters to the query are parsed. | 16:18 |
| *** garyk has quit IRC | 16:18 | |
| jaypipes | dachary: gotcha. no probs. | 16:19 |
| dachary | jaypipes: we renamed counter into meter during the last meeting ;-) I'm ok with metric too (no strong feelings on names) but I'm not sure it will be readable. | 16:19 |
| Weighed | Would a network xmit counter be the network traffic sent over the most recent hour, sent since the VM was booted, or sent since the VM host was booted? | 16:19 |
| * dachary not being a native english speaker does not help ;-) | 16:20 | |
| jaypipes | dachary: :) no worries | 16:20 |
| ss7pro | Weighed: xmit is a delta | 16:20 |
| * jaypipes would prefer counter or metric to meter, but not a big deal | 16:20 | |
| ss7pro | Weighed: generaly we store only deltas at this moment | 16:20 |
| nijaba | Weighed: whatever the duration specifies, but should be a delta from the last measure | 16:20 |
| dachary | +1 | 16:21 |
| nijaba | on? | 16:21 |
| Weighed | So the client cannot select a duration? | 16:21 |
| dachary | nijaba: on a delta from the last measure ;-) | 16:21 |
| ss7pro | Weighed: Client can | 16:22 |
| nijaba | Weighed: yes it can, in the sum API | 16:22 |
| Guest32307 | time interval should be part of the query and drive the results | 16:22 |
| ss7pro | But it will return delta sum for given period | 16:22 |
| jd___ | having a delta assume you have the old value if you're polling from absolute counter, which may not be the case on agent restart | 16:22 |
| nijaba | GET sum of (counter_volume, counter_duration) for counter_type and account_id | 16:22 |
| nijaba | optional start and end for counter_datetime | 16:22 |
| dhellmann | should the query for a list of events allow filtering by type? | 16:22 |
| dachary | Weighed: the client must be able to select a duration. Actually I think (start + end) should be a common parameter to all queries. | 16:22 |
| nijaba | this is what is specified in the wiki | 16:22 |
| dhellmann | or is that implied in that you ask each meter for the list? | 16:23 |
| nijaba | same applies to list | 16:23 |
| nijaba | so I agree with dachary | 16:23 |
| nijaba | http://wiki.openstack.org/EfficientMetering#API | 16:23 |
| dhellmann | how are "get list of meter_type" and "list components meters" different? | 16:24 |
| *** Guest32307 has quit IRC | 16:24 | |
| nijaba | dhellmann: list component meter will restrict the query to a cmpnent | 16:24 |
| ss7pro | I agree but we need also to decide if the end pointer is a end of current window or the begining of the next window (less, less or equal) | 16:24 |
| dachary | dhellmann: I think the query for a list of events should allow filtering by type | 16:24 |
| *** Gordonz_ has quit IRC | 16:25 | |
| dachary | ss7pro: I tend to link [start,end[ | 16:25 |
| *** DanD_ has joined #openstack-meeting | 16:25 | |
| dachary | s/link/like/ | 16:25 |
| dhellmann | nijaba, I'm still trying to understand how the component part of the API is useful. I'll have to find that email thread. | 16:25 |
| * nijaba too | 16:25 | |
| ss7pro | ok so end is a closing value | 16:25 |
| dhellmann | dachary, is that start <= timestamp < end? | 16:25 |
| dachary | yes | 16:26 |
| dhellmann | agreed | 16:26 |
| dachary | #agreed all meters have a [start,end[ ( start <= timestamp < end ) that limits the returned result to the events that fall in this period | 16:26 |
| dachary | dam | 16:26 |
| nijaba | dhellmann: https://lists.launchpad.net/openstack/msg11504.html | 16:26 |
| dachary | #agreed all queries have a [start,end[ ( start <= timestamp < end ) that limits the returned result to the events that fall in this period | 16:26 |
| *** littleidea has quit IRC | 16:26 | |
| woorea | we need event_type (eg : start or end) + timestamp | 16:27 |
| woorea | nor start + end + event_type | 16:27 |
| dachary | There is one query that everyone agrees on, I think : GET /events that returns raw events. | 16:27 |
| *** dwalleck has joined #openstack-meeting | 16:27 | |
| *** Gordonz has joined #openstack-meeting | 16:28 | |
| ss7pro | What are raw events ? | 16:28 |
| dhellmann | nijaba, thanks | 16:28 |
| ss7pro | list of deltas ? | 16:28 |
| nijaba | ss7pro: what is stored in the DB | 16:28 |
| dhellmann | ss7pro, yes, the discrete values recorded in the database | 16:28 |
| dachary | ss7pro: sorry for being imprecise | 16:28 |
| nijaba | ss7pro: with no aggreagation | 16:28 |
| woorea | raw is unprocessed info, just collected | 16:28 |
| woorea | no business rules applied | 16:28 |
| dachary | There is one query that everyone agrees on, I think : GET /events that returns all fields for each event ( as described in http://wiki.openstack.org/EfficientMetering#Storage ) | 16:28 |
| ss7pro | what about components ? | 16:29 |
| DanD_ | raw events are determined by the service you query. nova= vm state changes, network usage, block storage create/delete ... | 16:29 |
| dhellmann | the list of components is just a list of strings for the names, right? | 16:29 |
| ss7pro | how do we like events to components ? | 16:29 |
| dhellmann | ss7pro, the meter type defines the component | 16:29 |
| DanD_ | events need a serviceTypeId associated with them | 16:29 |
| dachary | DanD_: we're talking about the events stored in the ceilometer storage, not the events sent by the nova component (for instance) | 16:30 |
| woorea | components generate events that are collected by "counters" (raw data) and the processed by business process | 16:30 |
| DanD_ | I know, but you still need to have the meta data to determine what to return on a query | 16:30 |
| woorea | s/the/then | 16:30 |
| ss7pro | dhellmann: But what part of the code will decide which counter belongs to which component ? | 16:30 |
| ss7pro | eg: external network traffic ? | 16:30 |
| dhellmann | ss7pro, the code that defines the counter | 16:31 |
| woorea | dhellmann +1 | 16:31 |
| dachary | ss7pro: that's GET list of meter_type : return the list of all meters available . It describes the available meters as shown in http://wiki.openstack.org/EfficientMetering#Meters | 16:31 |
| dhellmann | the thing that actually collects the data | 16:31 |
| ss7pro | dhellmann: so it will require collector to be able to query openstack api | 16:31 |
| *** whitt has joined #openstack-meeting | 16:31 | |
| dhellmann | I would actually prefer to leave components out of the API entirely. Focusing just on the meters would let other systems inject data for aggregation without worrying about where it comes from. | 16:32 |
| dhellmann | ss7pro, I don't understand that conclusion | 16:32 |
| dachary | dhellmann: the "component" part of http://wiki.openstack.org/EfficientMetering#Meters is merely a hint | 16:32 |
| woorea | a collector can query openstack api, libvirt, logs, whatever | 16:32 |
| *** reed has joined #openstack-meeting | 16:32 | |
| nijaba | dhellmann: I think covering copomnent will have little effect as long as it is an option in the query, not a req | 16:32 |
| ss7pro | So how to guess what is the component for traffic to/from single IP address ? | 16:32 |
| dhellmann | dachary, it was until we added to the API. If the API has to be able to provide a list of components and has to know which meters are part of which component, then we have to store that information somewhere the API can find it. | 16:33 |
| dachary | woorea: yes. And then it passes along the information to the storage that stores it as described in http://wiki.openstack.org/EfficientMetering#Storage | 16:33 |
| dhellmann | ss7pro, a human would look at the documentation | 16:33 |
| *** joearnold has joined #openstack-meeting | 16:33 | |
| DanD_ | metrics need to have a set of meta data associated with them so you can determine how to apply billing farther downstream. the component or service type along with other things like location, type, ... all contribute to the charges you will apply to the metric | 16:33 |
| ss7pro | but how collector can do this without API query ? | 16:34 |
| woorea | i sent an arch diagram to the list yesterday | 16:34 |
| dachary | dhellmann: I agree. The information in http://wiki.openstack.org/EfficientMetering#Meters must be stored somewhere. I'm not sure where. Database ? Configuration file ? Configuration file specific to an API extension ? | 16:34 |
| woorea | where you can see the scopes of every component | 16:34 |
| dachary | woorea: I missed it could you link the mail ? | 16:34 |
| dhellmann | DanD_ why does it matter that "quantum" collected billing data for me to calculate the bill? The meter type should be enough, right? "Network traffic in/out" | 16:34 |
| Divakar | all the metrics needs to be associated with a resource | 16:34 |
| ss7pro | Divakar: But how to gues resource without nova API query ? | 16:35 |
| ss7pro | If we take example of counting traffic for single ip address ? | 16:35 |
| dachary | DanD_: in my mind the http://wiki.openstack.org/EfficientMetering#Meters are metadata common to all rows found inhttp://wiki.openstack.org/EfficientMetering#Storage and that can be looked up using the meter_type | 16:35 |
| dhellmann | dachary, maybe the code that defines the meters should provide a plugin for the API service to add a component name? we can work that out on the list, though. | 16:35 |
| Divakar | one needs to have a list of resources | 16:35 |
| *** ryant has quit IRC | 16:35 | |
| DanD_ | <dhellman> we charge differently depending on some of the characteristics of the service that we are metering. i.e. what data center it is in, ... | 16:36 |
| Divakar | it can be separate api which provides the inventory data | 16:36 |
| dachary | Divakar: yes, that's the resource_id field of each record from http://wiki.openstack.org/EfficientMetering#Storage | 16:36 |
| nijaba | dachary: I think it is always a good idea to always store the dictionnary with the data anyway | 16:36 |
| *** sprintnode has quit IRC | 16:37 | |
| dhellmann | DanD_, that's a reasonable point. Somewhere in the spec there is a notion of "extra" data associated with each metering event, but that is not exposed in the aggregation API | 16:37 |
| woorea | here the diagram: http://markmail.org/search/?q=openstack%20ceilometer%20woorea#query:openstack%20ceilometer%20woorea+page:1+mid:lshk27cd7miz64tl+state:results | 16:37 |
| dachary | dhellmann: ok | 16:37 |
| *** byeager has joined #openstack-meeting | 16:37 | |
| dhellmann | ah, right, dachary, the resource_id can lead to that other information | 16:37 |
| dhellmann | so we should be able to aggregate by resource_id | 16:38 |
| nijaba | dhellmann: good point | 16:38 |
| dachary | woorea: thanks | 16:38 |
| dhellmann | although if a resource does not exist at the point of billing (because the instance was destroyed, for example) that might not be enough | 16:38 |
| DanD_ | dhellman, if you don't allow the API queries to filter based on the criteria you use for billing, how do you seperate the data after the fact? | 16:38 |
| dhellmann | DanD_, also a good point. I was expecting to pull the raw data out and "translate" it to the type of data we need in our existing billing system. | 16:39 |
| *** oubiwann2 has quit IRC | 16:39 | |
| *** alpha_ori has joined #openstack-meeting | 16:40 | |
| dhellmann | DanD_, is a component for you just the name "compute" or is a specific instance of a compute node? | 16:40 |
| Weighed | If a VM is disabled, would its CPU use be 0 or be NaN? 0 is OK for billing needs, but for diagnostics it is good to know the difference between down and 0 | 16:40 |
| dachary | dhellmann: true. However, the billing is expected to extract meta data information independently. Otherwise we will end up replicating the full logs / archive all events from all components and providing a database of all historical events that ever happen in openstack. I believe that was agreed on during the last meeting. | 16:41 |
| DanD_ | depends on what you define as aggregation I guess. If you plan to just pull relatively raw data out of the API, then that works. but if you are looking to get something like, how much large vm usage did account x consume in data center 1 then its harder | 16:41 |
| dhellmann | dachary, because we are dealing with ephemeral objects, we might have to collect that data | 16:41 |
| dhellmann | DanD_, we want to be able to report for our customers how much they spent on each VM, not just how much on a type of VM | 16:41 |
| dhellmann | so we need both | 16:41 |
| nijaba | Weighed: metering != monitoring: I would not do diagnostic with it | 16:41 |
| DanD_ | yes, I agree | 16:42 |
| * nijaba agrees too | 16:42 | |
| nijaba | we then need to expose ressource_id to the query... | 16:42 |
| Divakar | since the metrics is going to be provided as samples if the vm is down for a particular period of time, there will be no sample isnt it? | 16:42 |
| dachary | and we do | 16:42 |
| dhellmann | DanD_, location of the resource is not something we've discussed collecting but I think we need to add that | 16:42 |
| DanD_ | we differentiate on region, data center and availability zone as well as the characteristics of the VM for compute | 16:43 |
| nijaba | dhellmann: yes we do, it is the resource_id isn't it? | 16:43 |
| dhellmann | we might want to do the same | 16:44 |
| dhellmann | nijaba, I thought the resource ID was the UUID of the actual object (the instance, for example) | 16:44 |
| dachary | dhellmann: we need a pointer to the resource, that is unique. That's what resource_id provide. Matching this unique id to the actual resource is outside of the scope of the metering project. If we try to fit that in, we will never complete the project I'm afraid ;-) | 16:44 |
| dhellmann | the billing system can only query for the other information if that object still exists, which it may not | 16:44 |
| nijaba | dhellmann: ok, so location as in zone... got it... | 16:44 |
| dachary | dhellmann: yes, resource ID was the UUID of the actual object (the instance, for example) | 16:44 |
| *** dwalleck has quit IRC | 16:45 | |
| dhellmann | dachary, well, I'm afraid I'm with DanD_ on this one | 16:45 |
| woorea | pull(rest api) or push(driver) are the options for a billing system to integrate with ceilometer | 16:45 |
| nijaba | dachary: but I would think that the zone (which is a subset of datacenter) is indeed needed | 16:45 |
| ss7pro | woorea: billing will pull the data | 16:46 |
| woorea | users can choose the way they want to work with ceilometer | 16:46 |
| *** alpha_ori has left #openstack-meeting | 16:46 | |
| woorea | ss7pro: we should offer the two options | 16:46 |
| Divakar | dachary: one should be able to corelate the metering data with the resource in use for which a unique identifier of the resource isnt it a must to have? | 16:46 |
| dachary | that calls for a different storage and schema. | 16:46 |
| nijaba | woorea: not in what we are proposing atm, but you are welcome to propose | 16:46 |
| DanD_ | if you use an external billing provider, then a pull model is not viable, not both options | 16:46 |
| dhellmann | in order to be able to audit the billing information, the user is going to want to know the names and unique ids of the things causing the charges. We need to record that at the time the charge is incurred. Each meter type will need to define what that data is | 16:47 |
| nijaba | woorea: but that should be done via the ml and discussed in a separate meeting | 16:47 |
| woorea | nijaba: supose that ceilometer is not visible from outside | 16:47 |
| ss7pro | +1 dhellmann | 16:47 |
| woorea | nijaba: ok | 16:47 |
| dhellmann | DanD_, we're building a bridge to pull data out of ceilometer and push it into our existing billing system. | 16:47 |
| dhellmann | probably just a cron job | 16:47 |
| dachary | I think we must acknowledge that one hour won't be enough to resolve this. We will need to keep discussing this on the list and resolve the points that were raised. | 16:48 |
| dhellmann | you need a translation layer between those two pieces anyway because they are likely to have different views of the data | 16:48 |
| nijaba | dachary: +1 | 16:48 |
| dhellmann | dachary, +1 | 16:48 |
| DanD_ | that's basically what we do as well. The benefit of exposing a push model would be that it would provide some leverage to get billing providers to conform | 16:48 |
| nijaba | dhellmann: would you take the action to reformulate the API proposal as a start point for the dicussion on the ML? | 16:48 |
| dhellmann | sure | 16:49 |
| dachary | I will post a summary of this discussion to the list so that we can start independant threads to address each issue. Do you agree on this ? | 16:49 |
| nijaba | dhellmann: thanks :) | 16:49 |
| ss7pro | yes | 16:49 |
| dachary | ok :-) | 16:49 |
| dachary | +1 | 16:49 |
| woorea | +1 | 16:49 |
| nijaba | +1 | 16:49 |
| dachary | dhellmann: the action is on you, thanks ;-) | 16:49 |
| dachary | #action dhellmann reformulate the API proposal as a start point for the dicussion on the ML. | 16:49 |
| *** lloydde has quit IRC | 16:50 | |
| dhellmann | #action dhellmann: reformulate the API proposal as a start point for the dicussion on the ML | 16:50 |
| nijaba | dachary: I think we need to push other topics by one week as a consequence.... | 16:50 |
| dachary | That will give me time to think about the need to store meta data information and revisit the storage if it needs to be. | 16:50 |
| *** Ravikumar_hp has joined #openstack-meeting | 16:50 | |
| dachary | nijaba: +1 | 16:50 |
| dhellmann | dachary, +1 | 16:50 |
| dachary | #action dachary push next meetings one week | 16:50 |
| ss7pro | dachary: metadata is needed | 16:50 |
| *** Mandell has joined #openstack-meeting | 16:51 | |
| ss7pro | counting network traffic is a typical example | 16:51 |
| dachary | ss7pro: I see why it is. I can't figure out how it will actually work. | 16:51 |
| dachary | ss7pro: yes | 16:51 |
| *** lloydde has joined #openstack-meeting | 16:51 | |
| nijaba | dachary: dictionary is the extended schema with data definition = metadata. | 16:51 |
| dachary | it's easy to say : this is outside of the scope. But it makes it a lot more difficult for the billing. | 16:52 |
| nijaba | dachary: what does? | 16:52 |
| dachary | not storing metadata in the storage makes it more difficult for the billing to figure out what a resource_id relates to | 16:52 |
| ss7pro | dachary: There's also one more thing that ip addresses assigned to instances may change. We need also to track which ip address belong to which instances as this data is not available now | 16:52 |
| dachary | ss7pro: that's what I'm afraid of. The extent of the "required metada" is virtually boundless. | 16:53 |
| nijaba | dachary: agreed on the metadata | 16:54 |
| dachary | (not sure it's proper english but you get my meaning ;-) | 16:54 |
| dachary | unless someone wants to add something, are we done ? | 16:54 |
| nijaba | ss7pro: why would we care about this? will you bill differently on which instance an IP is attahced to? | 16:54 |
| *** dwalleck has joined #openstack-meeting | 16:54 | |
| dachary | nijaba: maybe not but it's an information that is valuable to the customer. To track the bandwidth usage for instance. | 16:55 |
| DanD_ | we only bill based on internal and external traffic, but I could see where you would charge for incremental addresses | 16:55 |
| *** epim has joined #openstack-meeting | 16:55 | |
| dachary | DanD_: yes :-) | 16:55 |
| ss7pro | nijba: You need to know which customer generated traffic. | 16:55 |
| dachary | ss7pro: you will know that because tenant_id / project_id is part of the record. | 16:56 |
| ss7pro | So if instances are changing ip address (this is possible with quantum) you need to be sure that you charge the right customer | 16:56 |
| nijaba | DanD_: floating ip billing: yes, but billing per floating per instance_type seems far fetched | 16:56 |
| dachary | each meter is associated to a tenant. | 16:56 |
| ss7pro | dachary: But collector needs to be aware of it, so it'll need to query nova API each time it's doing collection | 16:56 |
| DanD_ | we have a component that filters traffic based on IP and tracks the total bytes | 16:57 |
| dhellmann | DanD_, we will probably be doing that, too | 16:57 |
| dachary | and we will do that too. | 16:57 |
| dachary | Our customers will want to know which IP is responsible for the most of the bandwidth used. | 16:58 |
| *** nati has joined #openstack-meeting | 16:58 | |
| DanD_ | thats a lot harder | 16:58 |
| dachary | thank you for your participation. That was a very rich session :-) | 16:58 |
| nijaba | too rich maybe ;) | 16:58 |
| ss7pro | It's also needed to differentiate beetwen internal and external traffic | 16:58 |
| nijaba | thanks all! | 16:58 |
| dhellmann | this is a complicated problem. :-) | 16:58 |
| ss7pro | thanks | 16:59 |
| woorea | thanks! | 16:59 |
| dhellmann | thanks! | 16:59 |
| dachary | nijaba: it shows the problem is not resolved ;-) That was no troll session. | 16:59 |
| nijaba | true | 16:59 |
| dachary | #endmeeting | 16:59 |
| ss7pro | dhellmann: which problem ? | 16:59 |
| *** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)" | 16:59 | |
| openstack | Meeting ended Thu May 10 16:59:20 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-16.00.html | 16:59 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-16.00.txt | 16:59 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-16.00.log.html | 16:59 |
| *** ss7pro has left #openstack-meeting | 17:00 | |
| *** rohitk has joined #openstack-meeting | 17:00 | |
| *** JoseSwiftQA has joined #openstack-meeting | 17:00 | |
| *** Weighed has quit IRC | 17:00 | |
| *** donaldngo_hp has joined #openstack-meeting | 17:01 | |
| dwalleck | hey QA folks, ready to get started? | 17:01 |
| fattarsi | let's do it | 17:01 |
| Ravikumar_hp | yes | 17:01 |
| rohitk | Hey | 17:01 |
| JoseSwiftQA | yeppers | 17:01 |
| dwalleck | bam | 17:01 |
| dwalleck | #startmeeting | 17:01 |
| openstack | Meeting started Thu May 10 17:01:38 2012 UTC. The chair is dwalleck. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:01 |
| *** joe-savak has quit IRC | 17:01 | |
| *** Divakar has quit IRC | 17:01 | |
| rohitk | Jay?? | 17:02 |
| dwalleck | #topic Action items: getting the smoke test branch in gerrit | 17:02 |
| *** openstack changes topic to "Action items: getting the smoke test branch in gerrit" | 17:02 | |
| *** ryanpetr_ has quit IRC | 17:02 | |
| dwalleck | Which Jay has done :) Pretty slick stuff | 17:02 |
| rohitk | yes, im waiting for that to go through :) | 17:02 |
| *** derekh has quit IRC | 17:02 | |
| davidkranz | What needs to happen to get it in? | 17:02 |
| *** woorea has left #openstack-meeting | 17:03 | |
| *** longshot has joined #openstack-meeting | 17:03 | |
| dwalleck | One more review technically. I just wanted to give it enough time for folks to see things and get comfortable | 17:03 |
| fattarsi | as it is I think it will conflict with my recent review | 17:03 |
| rohitk | dwalleck ++ | 17:03 |
| jaypipes | o/ | 17:03 |
| fattarsi | \o | 17:04 |
| dwalleck | Once everyone's good, we should be good to go | 17:04 |
| *** mnewby has joined #openstack-meeting | 17:04 | |
| dwalleck | Any more questions/thoughts on the smoke tests? | 17:04 |
| *** mnewby has quit IRC | 17:04 | |
| rohitk | Yes! | 17:05 |
| *** mnewby has joined #openstack-meeting | 17:05 | |
| rohitk | Would we be getting rid of the decorators | 17:05 |
| rohitk | after having the base Smoke class? | 17:05 |
| *** dhellmann has quit IRC | 17:06 | |
| jaypipes | rohitk: my thought was yes, because the decorators can be reused for other things (like positive vs negative, etc) | 17:06 |
| jaypipes | rohitk: and the base Smoke test class can automatically decorate its test methods with a smoke attr | 17:06 |
| dwalleck | rohitk: That depends. Personally, I internally use decorators to break my test groups down into finer grained groups, but we can leave that up to individual groups to tag if we like | 17:06 |
| *** hggdh has joined #openstack-meeting | 17:06 | |
| rohitk | frankly I am not too comfortable with the attr decorators | 17:06 |
| jaypipes | rohitk: they are not consistently applied right now | 17:06 |
| rohitk | unless, they are used consistently | 17:06 |
| rohitk | right | 17:07 |
| jaypipes | rohitk: and having the base classes decoarate automatically solves that problem.. | 17:07 |
| rohitk | jaypipes +1 | 17:07 |
| dwalleck | Well, we're setting standards now (and we should probably document them), and we'll follow them from this point forward | 17:07 |
| jaypipes | rohitk: and allows the attrs to be more specifically used for targeting other things | 17:07 |
| jaypipes | dwalleck: +++ | 17:07 |
| dwalleck | can't fix the past, just the future :) | 17:08 |
| Ravikumar_hp | right | 17:08 |
| rohitk | hmm | 17:08 |
| jaypipes | dwalleck: for instance, I'd like to have a @attr(bug=XXXX) standard where we can run tests based on a failing bug report, etc | 17:08 |
| dwalleck | We can even have further discussions about what attrs make sense so that we're consistent | 17:08 |
| dwalleck | jaypipes: ++ | 17:08 |
| dwalleck | definitely agree | 17:08 |
| jaypipes | dwalleck: and I'd rather not have to do: @attr(type='smoke', cls='positive', bug=XXXX) :) | 17:08 |
| jaypipes | gets very verbose ;) | 17:09 |
| rohitk | jaypipes: that would be helpful. tag tests based on test type/ bug linkage, etc | 17:09 |
| jaypipes | rohitk: right | 17:09 |
| dwalleck | Sounds good to me | 17:09 |
| jaypipes | coolio. I will add that to the merge prop for the smoke tests (the auto-decorate thing...) | 17:09 |
| jaypipes | davidkranz: FYI, stress test merge prop review done | 17:10 |
| dwalleck | And is everyone okay with using the @attr(bug=XXXX) for now? | 17:10 |
| *** garyk has joined #openstack-meeting | 17:10 | |
| JoseSwiftQA | I like it | 17:10 |
| davidkranz | jaypipes: Great. I'll patch it after the meeting. | 17:10 |
| Ravikumar_hp | i like it | 17:10 |
| jaypipes | dwalleck: I am, obviously :) | 17:10 |
| dwalleck | Well there you have it then, done and done :) | 17:11 |
| fattarsi | this would decorate each test? | 17:11 |
| jaypipes | fattarsi: it would decorate tests that were specifically hindered by a bug upstream | 17:11 |
| dwalleck | fattarsi: Only tests that expose/exercise a bug | 17:11 |
| *** markmcclain has quit IRC | 17:11 | |
| jaypipes | fattarsi: what dwalleck said :) | 17:11 |
| rohitk | those test also need to be skipped right? | 17:11 |
| fattarsi | ok cool | 17:11 |
| jaypipes | rohitk: up to when they are fixed, yep | 17:12 |
| rohitk | jaypipes: got it | 17:12 |
| dwalleck | skipped or failed, but there was still some discussion around which would be preferred... | 17:12 |
| jaypipes | rohitk: the bug=XXX decorator is more of an easy way to "run the test to check if bug XXX is now fixed" | 17:12 |
| rohitk | ok | 17:12 |
| dwalleck | Okay, on we go then | 17:13 |
| davidkranz | dwalleck: I think we need to skip if we are gating trunk, at least until tempest is embraced by other teams. | 17:13 |
| jaypipes | davidkranz: that is correct. | 17:13 |
| dwalleck | right | 17:13 |
| dwalleck | #topic Outstanding code reviews | 17:13 |
| *** openstack changes topic to "Outstanding code reviews" | 17:13 | |
| jaypipes | Ravikumar_hp: would you mind communicating with rajalakshmi about holding off on the volume filters merge prop for now? | 17:13 |
| Ravikumar_hp | jaypipes: sure . right now she is working on some other task | 17:14 |
| jaypipes | Ravikumar_hp: dwalleck commented correctly on that merge prop that the API hasn't actually caught up to the proposed filtering functionality yet. | 17:14 |
| jaypipes | Ravikumar_hp: gotcha | 17:14 |
| dwalleck | davidkranz: I'm looking at yours today as well. I think I also reviewed anything that was still pending a review | 17:14 |
| Ravikumar_hp | so we will hold on volme attachment test | 17:14 |
| jaypipes | k | 17:14 |
| davidkranz | I would like to see the volumes attach stuff that has the drive letter problem go in. For now it could just use vdk,vdq,vdx until we have a better fix. That is probably safe. | 17:15 |
| jaypipes | fattarsi: did you catch my comment on #openstack-dev about assigning you to https://bugs.launchpad.net/tempest/+bug/997685? | 17:15 |
| uvirtbot | Launchpad bug 997685 in tempest "tests.identity.test_roles.RolesTest.test_role_create_blank_name Fails" [High,Confirmed] | 17:15 |
| davidkranz | There is a volume stress test coming that will use this code. | 17:15 |
| jaypipes | davidkranz: ++ | 17:15 |
| fattarsi | jaypipes: yes, is there a bug filed in keystone about this? | 17:15 |
| dwalleck | And the more folks who look at this, the better: https://review.openstack.org/#/c/6359/ | 17:15 |
| fattarsi | jaypipes: now that I look I cannot find one | 17:15 |
| jaypipes | fattarsi: I don't know yet if it is a bug in Keystone or not :) | 17:16 |
| jaypipes | dwalleck: will do that shortly. | 17:16 |
| dwalleck | awesome | 17:17 |
| davidkranz | dwalleck: I like the ssh thing but the issues about getting an address and ssh credentials is still a problem. | 17:17 |
| rohitk | There are quite a few negative scenarios in keystone where expected Error codes are not returned | 17:17 |
| fattarsi | jaypipes: in the meantime you think I should just that test until confirmed? | 17:17 |
| davidkranz | I can't run it now and the ubuntu images do not accept user/password to ssh as far as I can tell. | 17:17 |
| fattarsi | jaypipes: then it won't be the only test failing | 17:17 |
| dwalleck | davidkranz: But it's more of a deployment problem, not a test problem. That's why I added an attr for them, because of that very situation | 17:17 |
| davidkranz | If it is going in without solutions to those problems there needs to be a config to skip the ssh part. | 17:18 |
| *** mcclurmc_ has quit IRC | 17:18 | |
| davidkranz | dwalleck: How do I use the attr to turn it off? | 17:18 |
| jaypipes | fattarsi: no, let's find out if it really is a mismatch of spec /bug in Keystone and work with the Keystone folks on a fix. In the meantime, sure, we can do a @skip("Bug XXX not fixed in Keystone"), sure | 17:18 |
| davidkranz | dwalleck: Sorry for my python/nose lameness. | 17:18 |
| *** dachary has quit IRC | 17:18 | |
| dwalleck | -a type!=ssh, which probably isn't the most...fun to look at. A config might be a better option, like we've done with resize | 17:19 |
| davidkranz | dwalleck: ++ | 17:19 |
| dwalleck | I'm just very anxious to get this branch in as I have quite a large chunk of code I can submit once it's in | 17:19 |
| dwalleck | Cool, I'll do that | 17:19 |
| davidkranz | dwalleck: OK with me. | 17:19 |
| rohitk | dwalleck++ | 17:19 |
| jaypipes | dwalleck: ++ | 17:19 |
| dwalleck | And default it to not run, just in case | 17:19 |
| jaypipes | ya | 17:20 |
| dwalleck | Speaking of merge props.... | 17:20 |
| dwalleck | #topic Swift Tests | 17:20 |
| *** openstack changes topic to "Swift Tests" | 17:20 | |
| davidkranz | dwalleck: We might need another version of the ssh config to use keys. But that can wait. | 17:20 |
| dwalleck | Jose? | 17:20 |
| JoseSwiftQA | what up | 17:20 |
| JoseSwiftQA | ah, yes | 17:20 |
| dwalleck | JoseSwiftQA: you are =P | 17:20 |
| JoseSwiftQA | what I want to push is mostly code complete, needs some very minor additions + pep8 attention. Should have it submitted by day's end with dwalleck's help. | 17:21 |
| davidkranz | JoseSwiftQA: Are you doing anything with swift ACLs? | 17:21 |
| dwalleck | Which will be great to have in :) Good job man | 17:21 |
| jaypipes | JoseSwiftQA: nice work. | 17:21 |
| JoseSwiftQA | Not in tempest, yet. It's technically just adding metadata, but I want to add 'helper' functions for all that kind of stuff too | 17:22 |
| JoseSwiftQA | possibly in a 'middleware' client of some sort? | 17:22 |
| jaypipes | JoseSwiftQA: how would that work? | 17:22 |
| davidkranz | JoseSwiftQA: OK. When you figure out what the spec for that stuff is, please let us know :) | 17:22 |
| JoseSwiftQA | for things like tempurl generation, you have to do some stuff with passwords, keys, hmac etc that are tedious and static | 17:23 |
| JoseSwiftQA | so I want to write a helper function to do that, but it really shouldn't live in object, container, or account | 17:23 |
| jaypipes | k | 17:24 |
| dwalleck | I'll make sure he survives the first commit process :) | 17:24 |
| JoseSwiftQA | ^^main concern numero uno :D ^^ | 17:24 |
| uvirtbot | JoseSwiftQA: Error: "^main" is not a valid command. | 17:24 |
| dwalleck | #topic Documenting/Reporting functional test coverage | 17:24 |
| *** openstack changes topic to "Documenting/Reporting functional test coverage" | 17:24 | |
| dwalleck | Tricky stuff.... | 17:25 |
| dwalleck | But I saw this, and I generally like the concept for tracking functional test coverage http://code.google.com/p/test-analytics/wiki/AccExplained | 17:25 |
| dwalleck | This feels right because it's a type of coverage you can manage regardless of where the dev cycle is | 17:26 |
| jaypipes | interesting | 17:26 |
| *** rohitk has quit IRC | 17:26 | |
| dwalleck | So for example, for Nova I came up with attributes of functional, secure, robust, and responsive | 17:26 |
| egallen | /buffer #openstack-metering | 17:26 |
| dwalleck | Which is much more descriptive than just positive/negative | 17:27 |
| *** egallen has quit IRC | 17:27 | |
| jaypipes | dwalleck: but what is the definition of responsive? :) | 17:27 |
| jaypipes | dwalleck: do we decorate methods with an expected time to complete? | 17:28 |
| dwalleck | jaypipes: Good question! | 17:28 |
| jaypipes | dwalleck: something like @attr(ttc<=2.0) | 17:28 |
| dwalleck | jaypipes: oh no no, I didn't mean to use these as decorators necessarily (though we could) | 17:28 |
| jaypipes | dwalleck: or just create a new decorator like @complete_in_less_than(2.0) | 17:28 |
| Ravikumar_hp | do we fail the test if ttc is not met | 17:28 |
| jaypipes | Ravikumar_hp: good question | 17:29 |
| *** darraghb has quit IRC | 17:29 | |
| dwalleck | I meant from a higher level, if someone asks us right now how much of each application Tempest covers...well, I can make up numbers :) | 17:29 |
| davidkranz | Ravikumar_hp: I think the situations with testing on "real deploys" and virtual infrastructure are very different in this regard. | 17:29 |
| jaypipes | dwalleck: sorry to get you off track... what were your thoughts on how to apply ACC to Tempest tests? | 17:29 |
| dwalleck | But if I can categorize what components/capabilities to attributes, I can show happy colored heatmaps that show where I have the least/most testing | 17:30 |
| dwalleck | This still isn't perfect, but it helps more than me telling my management I have x smoke tests, y positive, z negative | 17:31 |
| dwalleck | Maybe I say I have 0 tests under nova api stability...they might freak :) | 17:31 |
| jaypipes | ++ | 17:31 |
| dwalleck | But if I just say I have positive or negative tests, there's no context | 17:31 |
| dwalleck | I just wanted to bring this up. It's definitely not a finished thought yet, but out of everything I could think of, it was the thing I hated the least :) | 17:32 |
| jaypipes | :) | 17:32 |
| dwalleck | food for thought | 17:32 |
| dwalleck | #topic Development Blueprints for Folsom release, and test coverage for those implementations | 17:33 |
| *** openstack changes topic to "Development Blueprints for Folsom release, and test coverage for those implementations" | 17:33 | |
| dwalleck | Ravikumar_hp: you're up! | 17:33 |
| Ravikumar_hp | may be this is question: | 17:33 |
| Ravikumar_hp | How we are tracking progress of development blueprint and making progress on addressing/adding testcases for those blueprint tasks | 17:33 |
| Ravikumar_hp | basically we want to address all blueprints by sharing work | 17:34 |
| *** ohnoimdead has joined #openstack-meeting | 17:34 | |
| jaypipes | Ravikumar_hp: you're talking about which blueprints? | 17:34 |
| jaypipes | Ravikumar_hp: new stuff coming in Folsom in Nova/Glance/Swift, etc? | 17:34 |
| Ravikumar_hp | Folsom release - blueprints and developmane based on those blueprints | 17:34 |
| jaypipes | I see now... | 17:35 |
| jaypipes | Ravikumar_hp: first thing we need is a decent list of those blueprints that are currently in progress. | 17:35 |
| davidkranz | Ravikumar_hp: I would like to make sure we don't have tempest spending a lot of time duplicating stuff that is covered by unit tests that will go with these new projects. | 17:36 |
| davidkranz | How do we draw that line? | 17:36 |
| jaypipes | davidkranz: by ensuring that the developer does unit tests and QA does the functional test? | 17:36 |
| davidkranz | jaypipes: Right. But sometimes it is not so easy. | 17:37 |
| davidkranz | jaypipes: In pre-openstack life I always had QA people working more closely with the dev team than we seem to have here. | 17:37 |
| *** gyee has joined #openstack-meeting | 17:38 | |
| Ravikumar_hp | daidkranz: ++ . i see a gap here. | 17:38 |
| davidkranz | Ideally, each blueprint would have a test plan which would greatly help with this issue. | 17:38 |
| davidkranz | That plan could talk about what non-unit tests were needed. | 17:39 |
| dwalleck | So if I can map blueprints to stories my developers are playing, I can do some mapping as I can | 17:39 |
| jaypipes | davidkranz: I think that the QA team just needs to be more aggressive in working with the developers on functional and integration tests (and test plans) while development is going on (and right after development is complete) | 17:39 |
| Ravikumar_hp | Developement can add those (test plan - non unit tests )in blueprints | 17:40 |
| davidkranz | jaypipes: I agree, but the result needs to be written down somewhere | 17:40 |
| jaypipes | Ravikumar_hp: why wouldn't the QA team add that to the buleprints? | 17:41 |
| Ravikumar_hp | sure . should we involve development to review that? | 17:42 |
| jaypipes | Ravikumar_hp: yes, of course. get the dialog going now rather than later... | 17:42 |
| *** hggdh has quit IRC | 17:42 | |
| jaypipes | the dialog can be on the blueprints and IRC of course... | 17:42 |
| *** anderstj has joined #openstack-meeting | 17:43 | |
| Ravikumar_hp | jaypipes: ok | 17:43 |
| dwalleck | #topic open discussion | 17:44 |
| *** openstack changes topic to "open discussion" | 17:44 | |
| dwalleck | What else folks? | 17:44 |
| davidkranz | I will be on vacation the next two weeks. | 17:44 |
| jaypipes | nothing from me | 17:44 |
| jaypipes | davidkranz: enjoy! | 17:45 |
| dwalleck | lucky! | 17:45 |
| jaypipes | Ravikumar_hp: you are next week's QA Captain, FYI... http://wiki.openstack.org/QACaptainRotation | 17:45 |
| Ravikumar_hp | Ok | 17:45 |
| davidkranz | I would like to look at the auto-reclaim of resources when I get back. | 17:45 |
| dwalleck | davidkranz: I agree. I'm still bouncing implementations around in my head | 17:46 |
| davidkranz | dwalleck: OK. That's all from me. | 17:47 |
| dwalleck | Going once? | 17:47 |
| dwalleck | twice? | 17:47 |
| dwalleck | #endmeeting | 17:47 |
| *** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)" | 17:47 | |
| openstack | Meeting ended Thu May 10 17:47:32 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:47 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-17.01.html | 17:47 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-17.01.txt | 17:47 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-17.01.log.html | 17:47 |
| dwalleck | Have 13 minutes of your day back :) | 17:47 |
| jaypipes | :) | 17:47 |
| *** dwalleck has quit IRC | 17:49 | |
| *** longshot has quit IRC | 17:51 | |
| *** whitt has quit IRC | 17:51 | |
| *** donaldngo_hp has quit IRC | 17:51 | |
| *** JoseSwiftQA has quit IRC | 17:51 | |
| *** flacoste has left #openstack-meeting | 17:57 | |
| *** pvo is now known as pvo-away | 17:59 | |
| jgriffith | #startmeeting | 18:01 |
| openstack | Meeting started Thu May 10 18:01:37 2012 UTC. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:01 |
| jgriffith | Role call? | 18:01 |
| jgriffith | Wow.. nobody? | 18:03 |
| DuncanT | Present, couldn't possibly comment on being correct | 18:03 |
| jgriffith | DuncanT: pheww, just go with correct | 18:03 |
| jgriffith | Well I guess this might be rather short unless we get some folks late | 18:04 |
| jgriffith | #topic last weeks action items | 18:04 |
| *** openstack changes topic to "last weeks action items" | 18:04 | |
| jgriffith | rnirmal caught up with me this morning, and unfortunately didn't get much done last week | 18:04 |
| jgriffith | vladimir: you here? | 18:05 |
| jgriffith | Those were two we had, sounds like no updates | 18:05 |
| Mandell | Sorry I'm late. | 18:05 |
| jgriffith | Mandell: no problem, glad you're here | 18:05 |
| jgriffith | So vladimir was going to work on openstack common, haven't seen anything there | 18:06 |
| jgriffith | rnirmal was working on some compute tear out and api work, but didn't get to it last week | 18:07 |
| jgriffith | I've pushed a change to drop the instance relationship from volumes, need review :) | 18:07 |
| jgriffith | Mandell: thanks! | 18:07 |
| jgriffith | Still needs approved etc | 18:07 |
| DuncanT | I saw that, haven't had time to look yet but will do tomorrow if not before | 18:08 |
| jgriffith | DuncanT: thanks! much appreciated | 18:08 |
| jgriffith | which brings me to the next topic... | 18:08 |
| jgriffith | #topic reviews | 18:08 |
| *** openstack changes topic to "reviews" | 18:08 | |
| *** mcclurmc_ has joined #openstack-meeting | 18:09 | |
| *** hggdh has joined #openstack-meeting | 18:09 | |
| jgriffith | So there hasn't been a "ton" of activity but... | 18:09 |
| vishy | o/ | 18:09 |
| jgriffith | There are a couple items that have been submitted and just sit | 18:09 |
| jgriffith | vishy: Yo | 18:09 |
| jgriffith | Just want to make sure folks that signed up for core are able to help out here | 18:09 |
| *** asdfasdf has joined #openstack-meeting | 18:10 | |
| jgriffith | Doesn't seem right for me to review, +1, +2 and A my own changes :) | 18:10 |
| DuncanT | We have out public-beta go-live today so it has been kind of hectic... will definitely make time to keep up | 18:10 |
| jgriffith | DuncanT: No worries, I understand | 18:10 |
| jgriffith | Just wanted to put a reminder out | 18:10 |
| jgriffith | #topic current status for cinder | 18:11 |
| *** openstack changes topic to "current status for cinder" | 18:11 | |
| *** mcclurmc_ has left #openstack-meeting | 18:11 | |
| DuncanT | Is there a dashboard for outstanding cinder reviews? | 18:11 |
| DuncanT | I've not used gerrit in anger all that much.... | 18:11 |
| jgriffith | DuncanT: Youre core so should be getting emails, else just look in gerrit | 18:11 |
| DuncanT | ok | 18:12 |
| jgriffith | Not a ton there but want to form good habbits :) | 18:12 |
| *** jakedahn_zz is now known as jakedahn | 18:12 | |
| jgriffith | So I've been doing some work on seperating instance relationships and working on cinderclient | 18:12 |
| jgriffith | vishy: has been doing a bunch of work on the compute tear out | 18:13 |
| jgriffith | vishy: updates? | 18:13 |
| *** nati has quit IRC | 18:13 | |
| jgriffith | Or any updates on work other folks are doing/planning? | 18:14 |
| vishy | jgriffith: haven't been working on anything yet :( | 18:14 |
| DuncanT | I've only gotten as far as pulling the code and getting the unit tests working, and that was only today | 18:15 |
| vishy | jgriffith: but I still have plans to do step 3 on the blueprint | 18:15 |
| jgriffith | vishy: :) | 18:15 |
| jgriffith | DuncanT: unit tests should have already been working? | 18:15 |
| jgriffith | DuncanT: did you have an issue running them? | 18:16 |
| DuncanT | jgriffith: Yeah, I was getting them working without virtual env, so I can package cinder for our test infrastructure | 18:16 |
| jgriffith | Ahhh | 18:16 |
| DuncanT | virtual env worked out of the box, dpkg based run didn't take long | 18:16 |
| *** DanD_ has quit IRC | 18:16 | |
| jgriffith | DuncanT: ok | 18:17 |
| DuncanT | I'll put some packaging files somewhere accessible once they are working | 18:17 |
| jgriffith | DuncanT: great | 18:17 |
| jgriffith | Also need volunteers from core to hit mtaylors change in gerrit as well | 18:17 |
| vishy | jgriffith: has anyone tried updating python-cinderclient yet? | 18:18 |
| jgriffith | Mine can wait until it hits nova | 18:18 |
| vishy | that should be a chunk of work | 18:18 |
| jgriffith | vishy: I started working on that about 30 minutes ago | 18:18 |
| jgriffith | and yes, it seems like a good chunk | 18:18 |
| vishy | nice, you probably need to pull in all of the changes from novaclient | 18:18 |
| vishy | and then we can reset the repo like we did for cinder | 18:18 |
| jgriffith | vishy: I'm currently putting in fakes for the delete/list/detail tests | 18:18 |
| jgriffith | vishy: Ahh... repo is set | 18:19 |
| jgriffith | vishy: Sorry, I should've mentioned | 18:19 |
| jgriffith | mtaylor apparently had the forethought to pull your version in as the base :) | 18:19 |
| jgriffith | vishy: Oh, I think I see what you're saying now. | 18:20 |
| vishy | jgriffith: i mean get rid of annoying history :) | 18:20 |
| jgriffith | Rather than use the base you had set up pull in novaclient and rip appart | 18:20 |
| jgriffith | Ohhh | 18:20 |
| vishy | jgriffith: no that is what i did | 18:20 |
| vishy | but there have been a number of fixes/changes to novaclient since i split | 18:20 |
| jgriffith | vishy: I'm with ya... take three or four tries but I catch up | 18:20 |
| vishy | which it would be nice to get in | 18:20 |
| mtaylor | vishy, jgriffith do you guys want/need to start the cinderclient repo over like we did for cinder? | 18:21 |
| jgriffith | vishy: I planned to work on that next assuming my instance ref's patch doesn't get rejected :) | 18:22 |
| vishy | jgriffith: i'm reviewing it now | 18:22 |
| jgriffith | mtaylor: Yes, but after I makes some changes today and tomorow | 18:22 |
| vishy | looking good so far | 18:22 |
| * jgriffith sigh of relief | 18:22 | |
| jgriffith | mtaylor: BTW sorry about the "false" bug to set up the repo :( | 18:23 |
| jgriffith | #action jgriffith get cinderclient up to speed and ask mtaylor to reset repo when ready | 18:23 |
| jgriffith | anybody else looking for ways/places to help out? | 18:24 |
| jgriffith | Just a reminder we had a goal of having base functionality at F1 I think, which is approaching very quickly | 18:24 |
| jgriffith | ok, one more thing from my side no cinder... | 18:26 |
| Mandell | All I can commit to for the next couple weeks is reviews, but I'll commit to one a day. | 18:26 |
| jgriffith | Mandell: Reviews are a huge help so that's great | 18:26 |
| jgriffith | So there was a submission for auto cleanup of orphaned volumes: | 18:26 |
| jgriffith | #link https://review.openstack.org/#/c/7314/ | 18:27 |
| jgriffith | I wanted to get other volume folks opinion... | 18:27 |
| jgriffith | I'd rather see this manual or configurable via conf file? | 18:27 |
| jgriffith | Agree/Disagree? | 18:28 |
| DuncanT | Definitely don't like it being manual | 18:28 |
| DuncanT | Just reading through the patch, but I can't see it being something we want turned on | 18:29 |
| jgriffith | DuncanT: You mean automatic? | 18:29 |
| DuncanT | Yeah | 18:29 |
| jgriffith | DucanT: Ahh ok | 18:29 |
| DuncanT | Possibly at all | 18:30 |
| DuncanT | If users want to keep volumes lying around, who are we to argue? | 18:30 |
| jgriffith | DuncanT: yeah, but I can see the desire to go through and do cleanup but I don't like the idea of having it take place on it's own | 18:30 |
| *** darraghb has joined #openstack-meeting | 18:30 | |
| jgriffith | Providers may like that depending on how they do their billing :) | 18:30 |
| DuncanT | Possibly an api to list 'orphan' volumes? | 18:30 |
| DuncanT | I think that can be done purely in the client TBH | 18:31 |
| jgriffith | DuncanT: Actually that's a bette approach than what i had in mind, and yes it can | 18:31 |
| *** rnirmal_ has joined #openstack-meeting | 18:31 | |
| *** patelna has joined #openstack-meeting | 18:31 | |
| jgriffith | DuncanT: The needed functionality is already there, just query via the api and delete if you want | 18:32 |
| vishy | jgriffith: reviewed, have three extra chunks of code that can be deleted, otherwise looks great | 18:32 |
| *** ryanpetrello has joined #openstack-meeting | 18:32 | |
| jgriffith | vishy: awesome THANKS!!! | 18:32 |
| DuncanT | jgriffith: Agreed | 18:32 |
| vishy | autoclean is not good | 18:33 |
| jgriffith | DuncanT: Ok, I'll update my review and put our reasoning in | 18:33 |
| vishy | at least in nova. I don't mind a deployer doing it externally | 18:33 |
| *** oubiwann1 has joined #openstack-meeting | 18:33 | |
| jgriffith | vishy: I didn't think so... exactly, external is easy enough | 18:33 |
| vishy | if a user creates a volume and doesn't use it that is fine | 18:33 |
| vishy | a task to log a notification or something would make sense | 18:34 |
| jgriffith | Ok, I'll update my review of it accordingly but that's where I was headed with it | 18:34 |
| vishy | but deleting it seems really bad. | 18:34 |
| *** hggdh has quit IRC | 18:34 | |
| *** markmcclain has joined #openstack-meeting | 18:34 | |
| jgriffith | I thought it seemed really dangerous personally, especially if it's not at least configurable (on/off/interval) | 18:34 |
| jgriffith | but as DuncanT pointed out it's really not necessary to have in the code at all | 18:35 |
| *** dhellmann has joined #openstack-meeting | 18:35 | |
| jgriffith | Just external via the api can accomplish for somebody that wants it | 18:35 |
| *** rnirmal has quit IRC | 18:35 | |
| *** rnirmal_ is now known as rnirmal | 18:35 | |
| jgriffith | rnirmal: you made it :) | 18:35 |
| rnirmal | well logged in..but still in another meeting | 18:36 |
| jgriffith | :) | 18:36 |
| jgriffith | Anybody else have anything they want to bring up? Questions/Concerns ? | 18:36 |
| jgriffith | Is this meeting worthwhile for you? | 18:37 |
| jgriffith | The nice thing about no response is I can interpret it any way I like :) | 18:38 |
| DuncanT | It's good to see progress, and also means there is at most a week between kicks, so yes | 18:38 |
| *** vladimir3p has joined #openstack-meeting | 18:39 | |
| jgriffith | DucnanT: cool... I'll be here no matter what so just want to make sure folks don't want to see something different | 18:39 |
| jgriffith | or "need" something different | 18:39 |
| jgriffith | I do believe the pace will start picking up significantly with each week | 18:39 |
| jgriffith | vladimir3p: Hey there | 18:40 |
| vladimir3p | hey | 18:40 |
| vladimir3p | sorry :-) | 18:40 |
| jgriffith | vladimir3p: Any updates on openstack-common? | 18:40 |
| vladimir3p | had couple customers meetings | 18:40 |
| vladimir3p | nope :-) | 18:40 |
| jgriffith | vladimir3p: NP | 18:40 |
| jgriffith | vladimir3p: :) | 18:41 |
| jgriffith | Alright, well I was going to go ahead and wrap up if nobody has anything.... | 18:41 |
| jgriffith | vladimir3p: if you want to catch up we can do so offline or you can grab the minutes off of eavesdrop | 18:41 |
| vladimir3p | jgriffith: it will be great to talk offline - might be faster | 18:42 |
| jgriffith | Oh... one other thing, I think the etherpad is probably not the place to add anything any longer | 18:42 |
| jgriffith | vladimir3p: sounds good | 18:42 |
| rnirmal | lets start opening blueprints and bugs to work on items | 18:42 |
| jgriffith | rnirmal: +1 | 18:42 |
| jgriffith | the etherpad is still good reference for some stuff, but anything new anybody wants to grab we start using the formal process | 18:43 |
| jgriffith | Ok... well if there's nothing else? | 18:43 |
| jgriffith | Alright, thanks everyone. Ping me if you think of anything | 18:44 |
| jgriffith | #endmeeting | 18:44 |
| *** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)" | 18:44 | |
| openstack | Meeting ended Thu May 10 18:44:24 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:44 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-18.01.html | 18:44 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-18.01.txt | 18:44 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-18.01.log.html | 18:44 |
| DuncanT | jgriffith: Just finished reviewing your change :-) | 18:44 |
| jgriffith | Hey... two weeks in a row of having internet coverage for the whole meeting | 18:44 |
| jgriffith | DuncanT: Thanks!! | 18:44 |
| DuncanT | 1 minor nit, otherwise looks good | 18:45 |
| jgriffith | DuncanT: yeah, I pulled in changes from nova that aren't "needed" :) | 18:45 |
| jgriffith | I'll nuke it and resubmit, THANKS | 18:46 |
| *** Gordonz has quit IRC | 18:49 | |
| *** jog0 has joined #openstack-meeting | 18:49 | |
| *** Gordonz has joined #openstack-meeting | 18:49 | |
| *** anderstj_ has joined #openstack-meeting | 18:51 | |
| *** joearnol_ has joined #openstack-meeting | 18:51 | |
| *** anderstj has quit IRC | 18:51 | |
| *** novas0x2a|laptop has joined #openstack-meeting | 18:52 | |
| *** joearnold has quit IRC | 18:52 | |
| *** darraghb has quit IRC | 18:56 | |
| *** bcwaldon has joined #openstack-meeting | 18:57 | |
| *** jog0 has quit IRC | 19:06 | |
| *** jakedahn is now known as jakedahn_zz | 19:07 | |
| *** jakedahn_zz is now known as jakedahn | 19:10 | |
| *** hggdh has joined #openstack-meeting | 19:13 | |
| *** jog0 has joined #openstack-meeting | 19:13 | |
| *** patelna__ has joined #openstack-meeting | 19:32 | |
| *** patelna has quit IRC | 19:35 | |
| *** mattray has joined #openstack-meeting | 19:36 | |
| *** jog0 has quit IRC | 19:42 | |
| *** jakedahn is now known as jakedahn_zz | 19:43 | |
| *** danwent has quit IRC | 19:43 | |
| *** danwent has joined #openstack-meeting | 19:44 | |
| *** hggdh has quit IRC | 19:45 | |
| *** littleidea has joined #openstack-meeting | 19:46 | |
| *** patelna__ has quit IRC | 19:47 | |
| *** patelna has joined #openstack-meeting | 19:48 | |
| *** maoy has joined #openstack-meeting | 19:58 | |
| *** n0ano has joined #openstack-meeting | 19:59 | |
| maoy | it appears that we are still in keystone-meeting | 20:01 |
| *** reed has quit IRC | 20:02 | |
| n0ano | oh great, not that again | 20:03 |
| n0ano | #startmeeting | 20:03 |
| openstack | Meeting started Thu May 10 20:03:15 2012 UTC. The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:03 |
| n0ano | no, we're good for orchestration | 20:03 |
| maoy | cool | 20:04 |
| *** jakedahn_zz is now known as jakedahn | 20:04 | |
| n0ano | now if sriram appears we'll have full quorum | 20:04 |
| maoy | my WIP feature branch is at github | 20:05 |
| maoy | that seems like the way to do it for openstack for now. | 20:05 |
| *** dhellmann has quit IRC | 20:05 | |
| n0ano | I think that follows the BKM (Best Known Method), in fact I think you're the first one to do that. | 20:06 |
| maoy | glad to be the lab rat.. | 20:06 |
| *** dhellmann has joined #openstack-meeting | 20:06 | |
| n0ano | we like to call it `bleeding edge` :-) | 20:07 |
| n0ano | have you had anyone look at your feature branch yet? | 20:07 |
| maoy | Yes. Mark McLoughlin and Jay Pipes | 20:08 |
| maoy | i'm also in contact with some folks from IBM and NTT | 20:08 |
| n0ano | excellent, any feedback so far? | 20:09 |
| maoy | yes, some inline comments at github. | 20:09 |
| maoy | will have a much better update next week | 20:09 |
| n0ano | sounds good | 20:09 |
| maoy | i'm not entirely sure if I should rebase or merge the new update though.. | 20:09 |
| *** markvoelker has quit IRC | 20:10 | |
| n0ano | I would think re-basing would be the way to go, is there a problem. | 20:10 |
| maoy | perhaps i should just use a different branch every time.. | 20:10 |
| maoy | and rebase | 20:10 |
| n0ano | branches are very cheap in git, I use them extensively | 20:11 |
| n0ano | pretty much, when I doubt I create a new branch | 20:11 |
| *** troytoman-away is now known as troytoman | 20:13 | |
| maoy | about the blueprint, i'm inclined to update the blueprint inplace than creating a new one | 20:13 |
| *** ryanpetrello has quit IRC | 20:14 | |
| n0ano | works for me, that should actually create a history which is good | 20:14 |
| vishy | I have some comments about orchestration stuff | 20:14 |
| vishy | esp. regarding maoy's proposed code | 20:14 |
| maoy | great | 20:15 |
| maoy | i was hoping to hear from you vishy.. | 20:15 |
| *** jdurgin has joined #openstack-meeting | 20:15 | |
| vishy | maoy: should i mention now? | 20:16 |
| n0ano | #topic proposed code | 20:16 |
| *** openstack changes topic to "proposed code" | 20:16 | |
| vishy | so first the major concern: we are trying to get rid of all db access in nova-compute | 20:16 |
| *** ryanpetrello has joined #openstack-meeting | 20:16 | |
| maoy | yes please. | 20:17 |
| maoy | that should work when the zookeeper backend is in. | 20:17 |
| maoy | without database access, i'm assuming there is a place to write persistent state, such as the health monitor, or report capability | 20:18 |
| vishy | maoy: so there are to other things | 20:20 |
| vishy | a) if compute isn't hitting the db, I don't think we need distributed state management in compute | 20:20 |
| vishy | b) it is possible that distributed state isn't needed at all. Some people have suggested that there are lock-free approaches which might save us a lot of extra work | 20:21 |
| *** jog0 has joined #openstack-meeting | 20:21 | |
| vishy | the scheduler could be a a different story | 20:21 |
| vishy | but for individual vm state management i think in memory state machine is probably fine on the compute node | 20:22 |
| vishy | here is the general principle that I'm going to suggest | 20:22 |
| vishy | user requests come into api and they are performed by simply making a call to compute and succeding or failing | 20:23 |
| vishy | state is propogated back up from compute to api periodically | 20:23 |
| vishy | the api node doesn't need to make decisions about state because it lets the owning node do it | 20:23 |
| vishy | there are a few special cases which need to be considered but this can be solved in a lock-free way as well. | 20:24 |
| maoy | this should work if the state is local. e.g. the compute node owns the VM | 20:24 |
| vishy | thoughts? | 20:24 |
| maoy | but my concerns are mostly non local state: | 20:24 |
| vishy | maoy: such as? | 20:24 |
| maoy | a) volume + vm needs to work together, also network | 20:25 |
| maoy | b) vm migration | 20:25 |
| vishy | i think a) makes sense and so there may be a need for that kind of state management at a higher layer | 20:25 |
| vishy | although I'm not totally sure we are doing anything complicated enough there to warrant distributed locking | 20:26 |
| vishy | b) what kind of state is important in this case? and does it need to be managed on multiple nodes? | 20:26 |
| maoy | for b) which node owns the VM? the source or the target? | 20:27 |
| vishy | maoy: the source until the migration is complete | 20:29 |
| vishy | maoy: the two nodes already need to communicate directly to perform the migration so having a higher level lock arbiter seems like a bit of overkill in this case | 20:30 |
| vishy | maoy: but perhaps there is a complicated case where it would be necessary | 20:30 |
| maoy | vishy: there might be tricky crash cases where it's not clear who owns what.. | 20:33 |
| vishy | maoy: I think in general i would prefer if we are doing distributed locking that it does not happen in the compute worker | 20:33 |
| vishy | maoy: i want the compute worker to be as dumb as possible and have access to as little as possible | 20:33 |
| maoy | vishy: regardless of how it's implemented, the task abstraction still holds. | 20:34 |
| vishy | maoy: however it probably needs an internal state machine | 20:34 |
| vishy | maoy: to handle some of the transitions required. | 20:35 |
| maoy | vishy: ok. points taken. but i don't think the locking mechanism i have in mind is more complicated than local locks. | 20:35 |
| vishy | maoy: otherwise i like the idea of tracking actions and steps via something like what you proposed. In fact I tried to make a generalized task system for python here https://github.com/vishvananda/task | 20:36 |
| vishy | maoy: before i discovered that celery does essentially the same thing only better :) | 20:36 |
| maoy | vishy: i need to look into celery. does celery allow you to kill tasks and recycle locks/resources? | 20:37 |
| vishy | maoy: not sure I never got into it that deeply | 20:38 |
| maoy | vishy: so even within the compute node, the tracking actions and kill tasks functions are still necessary.. | 20:38 |
| vishy | maoy: doesn't look like it has it out of the box: http://loose-bits.com/2010/10/distributed-task-locking-in-celery.html | 20:38 |
| vishy | maoy: I agree, I just don't want it to have to talk to a centralized db/zookeeper if possible | 20:39 |
| vishy | maoy: and I wonder how much of it is already implemented in the drivers | 20:39 |
| maoy | vishy: i see your point. that's one backend change. right? from a centralized db to a in memory one.. | 20:39 |
| vishy | maoy: as in xen and libvirt already have to handle state management | 20:40 |
| vishy | maoy: so we may get a lot of it for free | 20:40 |
| maoy | vishy: i saw those i was actually planning to use the state management code as well. | 20:40 |
| vishy | maoy: by just going try: reboot() except: libvirtError rollback() | 20:40 |
| vishy | maoy: true, but I wonder if using the db layer is necessary at all. | 20:41 |
| vishy | maoy: you could use in memory sqlite but that is going to do table locking and nastiness | 20:42 |
| vishy | maoy: so maybe something specifically designed to handle that kind of stuff would be better. | 20:42 |
| maoy | vishy: a in memory hash table is enough. actually that's how i started. | 20:42 |
| vishy | maoy: That seems like a great place to start, do a simple in memory one | 20:43 |
| vishy | maoy: we may find that is all we need. | 20:43 |
| maoy | vishy: but I felt that the information is useful for ops to gain insight of the system in general, so keeping the log in db is not a bad place. | 20:43 |
| vishy | maoy: hmm i guess that is a good point. There is a review in to store running greenlets, have you seen it? | 20:44 |
| maoy | vishy: the thing is, once the task traverse the node boundry, e.g. from compute to network, you lose the context | 20:44 |
| maoy | vishy: not yet.. link plz.. | 20:44 |
| vishy | maoy: https://review.openstack.org/#/c/6694/ | 20:44 |
| vishy | maoy: so this seems like it is solving a very similar problem | 20:45 |
| *** vladimir3p has quit IRC | 20:45 | |
| *** joearnol_ has quit IRC | 20:45 | |
| *** anderstj has joined #openstack-meeting | 20:45 | |
| *** joearnold has joined #openstack-meeting | 20:45 | |
| *** anderstj_ has quit IRC | 20:46 | |
| vishy | maoy: especially if we add subtasks/logging to the idea | 20:46 |
| vishy | maoy: persistence is also a possibility but I feel like we could add that later if needed. | 20:46 |
| maoy | vishy: ok. will take a look. it's local task tracking or cross node? i can't tell from the title.. | 20:46 |
| maoy | vishy: i can't connect the blueprint with the patch title. perhaps i should ping JE and read the code for more details. | 20:47 |
| vishy | maoy: yeah do that | 20:47 |
| vishy | maoy: it is just local | 20:48 |
| vishy | maoy: and it is specific to greenthreads (no further granularity) | 20:48 |
| maoy | vishy: i'd also have a function where the ops can just say, find all running tasks against that VM, kill them if necessary | 20:48 |
| *** rkukura has quit IRC | 20:48 | |
| vishy | maoy: yes i think that is where the patch tries to get | 20:48 |
| vishy | maoy: you should probably sync up with him | 20:49 |
| maoy | vishy: then i though migration might make this tricky so a centralized version is dead simple to get started. | 20:49 |
| maoy | vishy: yeah sure. | 20:49 |
| maoy | vishy: i have some VM+EBS race conditions in my amazon cloud so I'd like to get that right in openstack. :) | 20:50 |
| vishy | maoy: i think we can see how far we get without centralizing. I agree that we will need it for higher-level orchestration | 20:50 |
| maoy | vishy: but local task tracking is definitely composable with a global/distributed one | 20:50 |
| vishy | maoy: but that could be something that lives above nova / quantum / cinder | 20:51 |
| *** jgriffith has quit IRC | 20:51 | |
| maoy | vishy: that's indeed what's in my mind but i have to start from somewhere.. so nova.. | 20:51 |
| vishy | maoy: also check out this one https://review.openstack.org/#/c/7323/ | 20:52 |
| vishy | maoy: it looks like johannes is trying to solve the same problems as you, so you should probably communicate :) | 20:52 |
| maoy | vishy: ok. that means i'm solving the right problems at least. :) | 20:53 |
| *** dachary has joined #openstack-meeting | 20:53 | |
| maoy | vishy: is there more docs on how to get rid of db? | 20:54 |
| maoy | vishy: at compute. | 20:54 |
| *** troytoman is now known as troytoman-away | 20:54 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 20:56 | |
| maoy | vishy: I'm afraid we might have to abuse rabbitmq more to extract state from compute nodes. | 20:56 |
| *** ttrifonov_zZzz is now known as ttrifonov | 20:57 | |
| n0ano | compute nodes are already sending state info to the scheduler, can you ride on top of that? | 20:57 |
| vishy | maoy: i don't know if there are docs yet | 20:58 |
| vishy | maoy: but the idea is to just allow computes to report state about there vms | 20:58 |
| vishy | maoy: and all relevant info will be passed in through the queue | 20:58 |
| vishy | maoy: my initial version was going to make the api nodes listen and just throw data back in a periodic task | 20:59 |
| vishy | maoy: and update the state of the instance on the other end | 21:00 |
| vishy | if we keep the user requested state as a separate field, then we don't run into weird timing collisions | 21:00 |
| maoy | vishy: i'm not sure i follow this. but it seems like the api nodes, other than translating api calls to compute/network apis, it also monitors the task execution status? | 21:02 |
| vishy | maoy: no not task execution status, just vm state | 21:02 |
| vishy | maoy: nova-api is just an easy place to put the receiving end of the call, it could also be a separate worker: nova-instance-state-writer or some such | 21:03 |
| *** rnirmal has quit IRC | 21:03 | |
| maoy | vishy: got you | 21:04 |
| *** epim_ has joined #openstack-meeting | 21:04 | |
| maoy | vishy: so the vm state change in db now happens in n-cpu, but will be rpc-ed to nova-state-writer who does the db ops | 21:05 |
| *** epim has quit IRC | 21:05 | |
| *** epim_ is now known as epim | 21:05 | |
| vishy | maoy: correct | 21:05 |
| vishy | maoy: and the calls from api -> compute will pass in all the relevant info so it doesn't need to read from the db either | 21:05 |
| vishy | i.e. the entire instance object instead of just an id | 21:06 |
| maoy | vishy: great. that makes sense. | 21:06 |
| maoy | vishy: i will take a closer look at the the code in review and see how that fits the task management i have. | 21:09 |
| maoy | vishy: will make the backend plugable to fit both local in memory and distributed case. | 21:09 |
| maoy | vishy: I wish I saw Johannes's patch earlier.. | 21:11 |
| vishy | maoy: hard to keep track of this stuff, I know :) | 21:11 |
| maoy | vishy: is there any attempt on utilizing celery by anyone else? | 21:11 |
| vishy | maoy: not that i know of | 21:11 |
| maoy | vishy: ok. so i'll ignore it for now. :) | 21:13 |
| maoy | vishy: where would the compute node health status update go without db? | 21:13 |
| maoy | i know the IBM folks are working on a zookeeper backend for that. | 21:14 |
| vishy | maoy: passed through the queue most likely | 21:14 |
| maoy | is this going to happen in folsom or later release? | 21:15 |
| vishy | maoy: we are going to try and get all db access out in folsom | 21:16 |
| vishy | maoy: but we will see how it goes | 21:16 |
| maoy | vishy: what about which VMs should be running on the node -- used periodically to compare it against libvirt/xenapi | 21:17 |
| maoy | vishy: does that mean the compute node need to maintain a local copy? | 21:17 |
| vishy | maoy: I don't think so, I think the periodic task could be initiated by api/external worker | 21:17 |
| vishy | maoy: it could glob the instances directory periodically or something | 21:18 |
| vishy | maoy: but having a separate data store I don't think would be needed | 21:18 |
| vishy | maoy: alternatively it could keep a list in memory, and make a request out to api/scheduler/nova-db-reader or something and get a list when it starts up | 21:19 |
| *** hggdh has joined #openstack-meeting | 21:19 | |
| maoy | vishy: ok. sounds like a lot of changes. will this happen gradually in trunk or on a feature branch? | 21:20 |
| vishy | maoy: feature branch i think | 21:20 |
| vishy | we are trying to pull staged changes out of trunk | 21:20 |
| *** ywu has joined #openstack-meeting | 21:21 | |
| maoy | vishy: ok. will keep an eye on it. thanks! | 21:22 |
| maoy | vishy: i would imagine there are some tricky cases to get the periodic tasks right on n-cpu. but in general i think making n-cpu dumb is the right direction. | 21:25 |
| *** ttrifonov is now known as ttrifonov_zZzz | 21:26 | |
| maoy | n0ano: i think we are done in the discussion. | 21:28 |
| maoy | vishy: thanks so much for jumping in. :) | 21:29 |
| *** ayoung has quit IRC | 21:29 | |
| n0ano | sounds good | 21:29 |
| *** ayoung has joined #openstack-meeting | 21:30 | |
| n0ano | is there a resolution that needs tp be documented? | 21:30 |
| vishy | maoy: yw | 21:31 |
| maoy | n0ano: tp? | 21:33 |
| n0ano | tp - sorry, don't know the abbreviation | 21:33 |
| *** ryanpetrello has quit IRC | 21:34 | |
| *** dhellmann has quit IRC | 21:34 | |
| *** gyee has quit IRC | 21:35 | |
| *** dachary has quit IRC | 21:36 | |
| maoy | n0ano: oh i think you mean "needs to be documented". right? | 21:39 |
| n0ano | oops | 21:39 |
| n0ano | s/tp/to | 21:39 |
| maoy | we have the meeting log for everything, right? | 21:39 |
| maoy | not sure about resolution.. | 21:39 |
| n0ano | yep, if you don't have a succinct summary that is sufficient. | 21:39 |
| n0ano | let's go with the full log and we'll talk again next week | 21:40 |
| n0ano | #endmeeting | 21:41 |
| *** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)" | 21:41 | |
| openstack | Meeting ended Thu May 10 21:41:04 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:41 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-20.03.html | 21:41 |
| maoy | sounds ogod. | 21:41 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-20.03.txt | 21:41 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-20.03.log.html | 21:41 |
| maoy | later | 21:41 |
| *** jakedahn is now known as jakedahn_zz | 21:42 | |
| *** n0ano has left #openstack-meeting | 21:50 | |
| *** ttrifonov_zZzz is now known as ttrifonov | 21:54 | |
| *** jakedahn_zz is now known as jakedahn | 21:55 | |
| *** ttrifonov is now known as ttrifonov_zZzz | 21:55 | |
| *** hggdh has quit IRC | 21:59 | |
| *** ayoung has quit IRC | 22:04 | |
| *** milner has quit IRC | 22:06 | |
| *** milner has joined #openstack-meeting | 22:07 | |
| *** jog0_ has joined #openstack-meeting | 22:09 | |
| *** edygarcia has quit IRC | 22:11 | |
| *** milner has quit IRC | 22:11 | |
| *** sleepson- has joined #openstack-meeting | 22:11 | |
| *** jog0 has quit IRC | 22:12 | |
| *** LinuxJedi has quit IRC | 22:12 | |
| *** sleepsonthefloor has quit IRC | 22:12 | |
| *** jog0_ is now known as jog0 | 22:12 | |
| *** LinuxJedi has joined #openstack-meeting | 22:12 | |
| *** maoy has quit IRC | 22:17 | |
| *** jamespage_ has joined #openstack-meeting | 22:22 | |
| *** jamespage_ has quit IRC | 22:27 | |
| *** Gordonz has quit IRC | 22:27 | |
| *** dprince has quit IRC | 22:27 | |
| *** shang has joined #openstack-meeting | 22:28 | |
| *** lloydde_ has joined #openstack-meeting | 22:29 | |
| *** lloydde has quit IRC | 22:33 | |
| *** oubiwann1 has quit IRC | 22:35 | |
| *** blamar has quit IRC | 22:38 | |
| *** patelna has quit IRC | 22:41 | |
| *** mattray has quit IRC | 22:46 | |
| *** Ravikumar_hp has quit IRC | 22:49 | |
| *** jakedahn is now known as jakedahn_zz | 22:49 | |
| *** novas0x2a|lapto1 has joined #openstack-meeting | 22:52 | |
| *** novas0x2a|laptop has quit IRC | 22:52 | |
| *** markmcclain has quit IRC | 22:53 | |
| *** mikal has quit IRC | 22:53 | |
| *** jakedahn_zz is now known as jakedahn | 23:00 | |
| *** edygarcia has joined #openstack-meeting | 23:01 | |
| *** milner has joined #openstack-meeting | 23:03 | |
| *** dtroyer is now known as dtroyer_zzz | 23:09 | |
| *** lloydde_ has quit IRC | 23:09 | |
| *** lloydde has joined #openstack-meeting | 23:10 | |
| *** dhellmann has joined #openstack-meeting | 23:12 | |
| *** lloydde has quit IRC | 23:14 | |
| *** ryanpetrello has joined #openstack-meeting | 23:26 | |
| *** mikal has joined #openstack-meeting | 23:28 | |
| *** lloydde has joined #openstack-meeting | 23:34 | |
| *** pvo-away is now known as pvo | 23:34 | |
| *** dhellmann has quit IRC | 23:38 | |
| *** ryanpetrello has quit IRC | 23:39 | |
| *** pvo is now known as I | 23:40 | |
| *** ryanpetrello has joined #openstack-meeting | 23:40 | |
| *** I is now known as pvo | 23:40 | |
| *** ryanpetrello has quit IRC | 23:41 | |
| *** anderstj has quit IRC | 23:43 | |
| *** ryanpetrello has joined #openstack-meeting | 23:47 | |
| *** ryanpetrello has quit IRC | 23:51 | |
| *** ryanpetrello has joined #openstack-meeting | 23:51 | |
| *** lloydde has quit IRC | 23:54 | |
| *** lloydde has joined #openstack-meeting | 23:55 | |
| *** ryanpetrello has quit IRC | 23:55 | |
| *** ryanpetrello has joined #openstack-meeting | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!