Thursday, 2012-05-03

*** dtroyer_zzz is now known as dtroyer00:02
*** mdomsch has quit IRC00:07
*** mnewby has quit IRC00:19
*** ywu has joined #openstack-meeting00:19
*** mnewby has joined #openstack-meeting00:20
*** sleepsonzzz is now known as sleepsonthefloor00:21
*** anotherjesse is now known as anotherjesse_zz00:22
*** jgriffith is now known as jgriffith_away00:43
*** s0mik has quit IRC00:50
*** novas0x2a|laptop has quit IRC01:17
*** jakedahn is now known as jakedahn_zz01:19
*** littleidea has quit IRC01:24
*** littleidea has joined #openstack-meeting01:24
*** mnewby_ has joined #openstack-meeting01:34
*** mnewby has quit IRC01:38
*** mnewby_ has quit IRC01:39
*** jgriffith_away has quit IRC01:48
*** jgriffith_away has joined #openstack-meeting01:49
*** danwent has quit IRC02:26
*** mnewby has joined #openstack-meeting02:26
*** sleepsonthefloor is now known as sleepsonzzz02:28
*** deshantm_ has quit IRC02:50
*** deshantm has joined #openstack-meeting02:50
*** dwcramer has quit IRC02:51
*** ryanpetr_ has joined #openstack-meeting03:05
*** ryanpetrello has quit IRC03:08
*** jgriffith_away has quit IRC03:15
*** dtroyer is now known as dtroyer_zzz03:18
*** pimpministerp has quit IRC03:18
*** pimpministerp has joined #openstack-meeting03:22
*** dtroyer_zzz is now known as dtroyer03:24
*** anotherjesse_zz is now known as anotherjesse03:33
*** johnpostlethwait has quit IRC03:34
*** edygarcia has joined #openstack-meeting03:39
*** anotherjesse is now known as anotherjesse_zz03:52
*** anotherjesse_zz is now known as anotherjesse03:53
*** edygarcia has quit IRC03:56
*** edygarcia has joined #openstack-meeting03:58
*** edygarcia has quit IRC03:59
*** lloydde has joined #openstack-meeting04:04
*** deshantm has quit IRC04:07
*** lloydde has quit IRC04:08
*** jakedahn_zz is now known as jakedahn04:09
*** anotherjesse is now known as anotherjesse_zz04:20
*** adjohn has joined #openstack-meeting04:28
*** garyk has quit IRC04:37
*** sandywalsh has quit IRC04:54
*** Mandell has joined #openstack-meeting05:05
*** zul has quit IRC05:07
*** zul has joined #openstack-meeting05:09
*** littleidea has quit IRC05:15
*** martines has quit IRC05:31
*** gyee has quit IRC05:36
*** garyk has joined #openstack-meeting05:47
*** reed has quit IRC05:49
*** jakedahn is now known as jakedahn_zz05:52
*** mnewby has quit IRC05:54
*** ywu has quit IRC05:55
*** ryanpetr_ has quit IRC05:56
*** dtroyer is now known as dtroyer_zzz05:56
*** GheRivero has joined #openstack-meeting06:18
*** adjohn has quit IRC06:44
*** adjohn has joined #openstack-meeting06:52
*** adjohn has quit IRC06:53
*** blamar has quit IRC06:59
*** martines has joined #openstack-meeting07:02
*** Mandell has quit IRC07:12
*** Guest10929 has joined #openstack-meeting07:26
*** Guest10929 has left #openstack-meeting07:26
*** GheRivero has quit IRC07:34
*** GheRivero has joined #openstack-meeting07:50
*** sleepson- has quit IRC07:57
*** edleafe has quit IRC07:57
*** anotherjesse_zz has quit IRC07:57
*** sleepsonthefloor has joined #openstack-meeting07:57
*** dabo has joined #openstack-meeting07:57
*** anotherjesse_zz has joined #openstack-meeting07:58
*** anotherjesse_zz is now known as anotherjesse07:58
*** darraghb has joined #openstack-meeting08:08
*** derekh has joined #openstack-meeting08:12
*** garyk has quit IRC08:14
*** pknouff_ has joined #openstack-meeting08:16
*** garyk has joined #openstack-meeting08:19
*** chmouel_ has joined #openstack-meeting08:20
*** pknouff has quit IRC08:21
*** rkukura has quit IRC08:21
*** chmouel has quit IRC08:21
*** jacky has quit IRC08:21
*** Amw3000 has quit IRC08:21
*** jalcine has joined #openstack-meeting08:22
*** Amw3000 has joined #openstack-meeting08:22
*** ttrifonov_zZzz is now known as ttrifonov08:29
*** garyk has quit IRC09:34
*** garyk has joined #openstack-meeting09:51
*** garyk has quit IRC10:52
*** garyk has joined #openstack-meeting11:12
*** dwcramer has joined #openstack-meeting11:56
*** dwcramer has quit IRC12:52
*** dprince has joined #openstack-meeting13:02
*** joesavak has joined #openstack-meeting13:03
*** mikal has quit IRC13:05
*** mikal has joined #openstack-meeting13:07
*** GheRivero_ has joined #openstack-meeting13:28
*** littleidea has joined #openstack-meeting13:33
*** edygarcia has joined #openstack-meeting13:41
*** littleidea has quit IRC13:46
*** rkukura has joined #openstack-meeting13:48
*** dtroyer_zzz is now known as dtroyer13:54
*** dachary has joined #openstack-meeting13:56
*** markmcclain has joined #openstack-meeting13:58
*** jlebrijo has joined #openstack-meeting13:59
*** dwcramer has joined #openstack-meeting14:02
*** dtroyer is now known as dtroyer_zzz14:06
*** dtroyer_zzz is now known as dtroyer14:07
*** oubiwann1 has joined #openstack-meeting14:11
*** jd___ has joined #openstack-meeting14:16
*** dendro-afk is now known as dendrobates14:27
*** jlebrijo has left #openstack-meeting14:28
*** ryanpetrello has joined #openstack-meeting14:29
*** jlebrijo has joined #openstack-meeting14:29
*** tong has joined #openstack-meeting14:35
*** deshantm has joined #openstack-meeting14:40
*** dtroyer is now known as dtroyer_zzz14:42
*** deshantm has quit IRC14:45
*** rnirmal has joined #openstack-meeting14:49
*** deshantm has joined #openstack-meeting14:51
*** dtroyer_zzz is now known as dtroyer14:53
*** markwash has quit IRC14:56
*** ayoung has quit IRC15:00
*** danwent has joined #openstack-meeting15:01
*** dendrobates is now known as dendro-afk15:04
*** dwcramer has quit IRC15:04
*** ryanpetrello has quit IRC15:05
*** markmcclain has quit IRC15:05
*** johnpur has joined #openstack-meeting15:05
*** oubiwann1 has quit IRC15:05
*** dwalleck has joined #openstack-meeting15:06
*** dwcramer has joined #openstack-meeting15:18
*** rohitk has joined #openstack-meeting15:23
*** dendro-afk is now known as dendrobates15:23
*** blamar has joined #openstack-meeting15:27
*** sandywalsh has joined #openstack-meeting15:37
*** deshantm_ has joined #openstack-meeting15:39
*** sandywalsh_ has joined #openstack-meeting15:40
*** sandywalsh has quit IRC15:41
*** deshantm has quit IRC15:42
*** garyk has quit IRC15:42
*** dendrobates is now known as dendro-afk15:44
*** sandywalsh_ has quit IRC15:47
*** dwalleck has quit IRC15:47
*** dwalleck has joined #openstack-meeting15:48
*** glenc_ has quit IRC15:50
*** glenc has joined #openstack-meeting15:51
*** AlanClark has joined #openstack-meeting15:52
*** oubiwann1 has joined #openstack-meeting15:53
*** ryanpetrello has joined #openstack-meeting15:53
*** markmcclain has joined #openstack-meeting15:54
*** dhellmann has joined #openstack-meeting15:54
*** Aswad_ has joined #openstack-meeting15:56
*** zinux has joined #openstack-meeting15:58
*** sandywalsh has joined #openstack-meeting15:58
*** flacoste_ipod has joined #openstack-meeting15:58
nijabao/16:00
dachary#startmeeting16:00
openstackMeeting started Thu May  3 16:00:16 2012 UTC.  The chair is dachary. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
dachary#chair nijaba dachary16:00
dachary#meetingname ceilometer16:00
openstackCurrent chairs: dachary nijaba16:00
openstackThe meeting name has been set to 'ceilometer'16:00
dachary#topic actions from previous meetings16:00
dachary#info creation of the ceilometer project16:00
dachary#https://launchpad.net/ceilometer16:00
dachary#info The repository for the ceilometer project has been created16:00
dachary#link https://github.com/stackforge/ceilometer16:00
dachary#info and the first commit was successfully reviewed and merged today https://review.stackforge.org/#/c/25/16:00
*** openstack changes topic to "actions from previous meetings"16:00
*** dwalleck has quit IRC16:00
*** Guest2888 has joined #openstack-meeting16:00
dachary#topic meeting organisation16:01
dachary#info This is 1/5 meetings to decide the architecture of the Metering project https://launchpad.net/ceilometer16:01
dachary#info Today's focus is on the definition of the counters / meters and the associated schema for the storage16:01
dachary#info It is the conclusion of the discussions held on the mailing list and the goal is to make a final choice that will then be implemented.16:01
dachary#info The meeting is time boxed and there will not be enough time to introduce inovative ideas and research for solutions.16:01
dachary#info The debate will be about the pro and cons of the options already discussed on the mailing list.16:01
dachary#link https://lists.launchpad.net/openstack/msg10810.html16:01
*** openstack changes topic to "meeting organisation"16:01
dacharyany comments on the meeting organisation ?16:01
flacoste_ipodNo16:01
nijabaditto16:01
Aswad_no16:01
zinuxNo16:01
dhellmannsounds good to me16:01
jd___nop16:02
dacharyok :-) Now the real thing:16:02
dachary#topic counter definitions16:02
dachary#info Proposed http://wiki.openstack.org/EfficientMetering#Counters16:02
*** openstack changes topic to "counter definitions"16:02
*** whitt has joined #openstack-meeting16:02
*** Guest2888 has quit IRC16:02
nijabanote: this list is not a locked list, but a list of the counters we will want to have in a first version16:03
*** whitt has quit IRC16:03
nijabahoping that if we can satisfy this set, we will be able to add new ones easily later16:03
dacharyI'm happy with the counters as they are. I've crossed check them with sales and it has all we need for billing ;-)16:03
dacharyI'm not sure they will fit in what HP has done but I have no input from them so far.16:04
nijabaany other comments?16:04
*** dwcramer has quit IRC16:04
dhellmannfor the network counters, are we still talking about per-network or did we move to per IP/VIF?16:04
dacharywe moved per IP/VIF16:05
jd___FWIW, I've added a list of possible counter to add for Swift16:05
dhellmanndachary, thanks, that's what we need16:05
dhellmannthis list looks good, and if we plan to allow it to be extended that should take care of anything I don't know we need, yet16:06
dacharydhellmann: the IP shows in the database schema (the ID of the resource)16:06
dacharydhellmann: before that the database schema did not have an id16:06
dhellmannas the unique id of the resource for the counter?16:06
dacharyyes16:06
dhellmanngot it16:06
* dachary checking the counters again16:06
*** milner has joined #openstack-meeting16:07
dhellmannthe note for net_float still talks about "number of floating IPs" but we're actually counting time per IP, right?16:07
* nijaba does not see reference to the IP/VIF chjoice16:07
jd___I'm not sure we can fetch net_*_int directly, I think we will have net_int and net_out, and we can probably grab net_ext_* and deduce net_int_* from that16:07
dacharyjd___: added:16:07
dachary* Number of object in Swift16:07
dachary * Number of containers in Swift16:07
dachary * Number of GET/HEAD/PUT/POST requests in Swift16:07
nijabasounds good to me, but should be included in the table16:08
dacharydhellmann: yes16:08
dhellmannfor quantum there will be L3 devices (logical or hardware) so we (DreamHost) will want to count those and possibly bill for them16:09
dachary#action dachary fix the note for net_float still talks about "number of floating IPs"16:09
jd___dhellmann: do there's no int/ext distinction directly on that?16:09
jd___s/do/so/16:09
dhellmannwe want to account for the router, separately from the traffic it passes16:10
dachary#action jd___ include Number of object in Swift, Number of containers in Swift, Number of GET/HEAD/PUT/POST requests in Swift in the table16:10
*** DanD has joined #openstack-meeting16:10
*** cdub has joined #openstack-meeting16:10
dhellmannwe don't know yet what we will charge for, but if the tenant can create a bunch of routers we want to make sure we could charge for them in the future16:10
*** garyk has joined #openstack-meeting16:11
*** s0mik has joined #openstack-meeting16:11
nijabadhellmann: do you see anyhting in the checma that could prevent that?16:11
nijabas/checma/schema/16:11
flacoste_ipodI think this is just more counters?16:11
dhellmannnijaba, no, I think we can handle it with the schema16:11
dhellmannright16:12
flacoste_ipodOr is it exisiting counter with a different resource ids?16:12
*** whitt has joined #openstack-meeting16:12
dhellmanndachary, do we care about the # of objects or just the # of containers? (I'm not that familiar with swift)16:12
nijabaso I think we should be good, then.  will just need to work with quantum on having an "agent" that sends the stuff to our queue16:12
dhellmanna counter for routers would look like c1 but refer to the router id instead of the instance id16:13
dacharythere will be a lot of change when quantum, cinder are integrated properly. And having a uniform structure for counters is a big plus to evolve quickly without complex schema change. I'm concerned about how http://wiki.openstack.org/SystemUsageData will evolve because the structure of the information is not uniform.16:13
nijabadhellmann: as all counters should be made optional to collect, I don't think it matters what each of us care about16:13
dhellmannnijaba, agreed16:13
dacharydhellmann: we care about both because they impact performances / replication.16:13
dhellmanndachary, makes sense16:14
dacharydhellmann: if someone makes a huge number of small objects, we may want to charge a little more. Compared to creating a single large object.16:14
dhellmanndachary, sure, that makes sense16:14
dhellmannso count # of objects per container?16:15
*** Ravikumar_hp has joined #openstack-meeting16:15
*** jsavak has joined #openstack-meeting16:16
dhellmannwith the idea that containers with large # objects may cost more than containers with small # of objects16:16
dacharydhellmann: good question. I'm not sure it makes a difference. For a given tenant I kind of assume the total number of container + the total number of objects matters.16:16
dhellmannor you might just care about # objects for an account, which can be handled in aggregation logic16:16
*** patelna has joined #openstack-meeting16:17
flacoste_ipodDid we settle the "account" définition?16:17
dacharydhellmann: there 1 level of hierarchy and I don't think there is a penalty when you have 10000 objects on 100 containers versus 10000 objects in 1 container.16:17
nijabaflacoste_ipod: nope16:17
dhellmannright, but if you collect the data with the relationship intact you can ignore the relationship later. if you don't include the relationship, you can't discover it later16:17
nijabadhellmann: agreed16:17
dhellmannwhat is the question about account? isn't account == tenant?16:17
jd___dhellmann: for now it's really easy to retrieve total number of containers and objects for a tenant (1 request), but retrieving the number of objects per containers is probably harder from what I know16:18
nijabadhellmann: well, one question that we could ask is should we have a source + account, instaead of just account16:18
dhellmannok, maybe we do the simple thing for now and implement another counter later if we need to16:18
nijabaso that in the future we could extend ot other id stores16:18
dhellmannwhat is "source"?16:18
nijabafor example, if we wanted to meter a paas on top that would use something else than keystone16:19
flacoste_ipodDoes tenant include the project?16:19
dacharyI'm not sure how to encode the relationship container / object16:20
flacoste_ipodwe basically want a user/project tuple16:20
*** joesavak has quit IRC16:20
*** joesavak has joined #openstack-meeting16:20
*** jsavak has quit IRC16:20
*** joesavak has quit IRC16:20
*** joesavak has joined #openstack-meeting16:20
nijabadachary: use the id to specify the countainer for the object count?16:21
dacharynijaba: ok16:21
dachary#action dachary add note about the fact that the resource_id for the object count is the container_id16:21
*** flacoste has joined #openstack-meeting16:21
*** flacoste_ipod has quit IRC16:22
nijabaany comment about transforming account_id into project/account tupple?16:22
dacharynijaba: you propose that we add a "source" to the schema ?16:22
dacharyI agree16:22
dhellmannflacoste_ipod, tenant is the same thing as project, right?16:22
nijabadachary: either that, or use one field as a composite key16:23
flacostedhellmann: you tell me, i'm not intimate with the keystone data model :-016:23
jd___dachary: so that means we need to fetch object count per container?16:23
dhellmannnijaba, -1 to composite keys, let's just add both fields16:23
nijabadhellmann: I tend to agree with you16:23
dacharyjd___: yes. That won't be cheap.16:23
dhellmannflacoste_ipod, I think the terms mean the same thing16:23
jd___dachary: indeed.16:23
flacostethen we are fine16:23
dacharyflacoste: it's the same indeed tenant == project16:24
dhellmanndachary, maybe we can convince swift to give us a new API for that?16:24
nijabathe change should apply to both account and event records then16:24
dacharydhellmann: yes16:24
dacharyI think we're moving ahead, should we conclude this topic and agree on the counters before we move to the schema ?16:25
dacharyI propose:16:25
dhellmannnijaba, which change applies to both records?16:25
nijabadhellmann: the 2 fields instead o just account_id16:25
dacharyhttp://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out.16:25
*** jdg has joined #openstack-meeting16:25
nijabadachary: I thnk we miss an action to record the VIF/IP choice16:26
dhellmannyeah, we need to make sure that is clear somewhere16:26
dacharydhellmann: I'm indeed convinced that we need to talk to each component to agree on ways to extract metering information. swift, nova, quantum etc.16:26
dacharynijaba: this belongs to the schema, doesn't it ? It's the resource_id of the net* counters. Or am I missing something ?16:27
*** patelna has quit IRC16:27
nijabadachary: I think it needs to be in net counters definition16:27
dacharyok.16:27
dhellmanndidn't the counters table get an id column at some point, or was that on the mailing list?16:28
dacharysecondary is the IP ?16:28
dacharysecondary is the IP for net_out_ext for instance ?16:28
nijabasounds good to me.  dhellmann?16:28
*** mnewby has joined #openstack-meeting16:28
dacharydhellmann: I added a resource_id at some point but then it was move to the schema because all counters need that.16:28
*** mnewby_ has joined #openstack-meeting16:29
dacharynijaba: what would be the resource_id for a net_out_ext counter then ?16:29
dhellmanndachary, we should document what the resource id for each counter is meant to be, though, right?16:29
dacharydhellmann: right16:29
*** mnewby_ has quit IRC16:29
*** jdg is now known as j_griff16:29
*** mnewby_ has joined #openstack-meeting16:29
*** j_griff is now known as jgriff16:29
dhellmannok, I didn't see that in the "storage" section. Is there another place the schema is defined?16:29
*** reed has joined #openstack-meeting16:30
dachary#action jd___ document the resource_id for each counter16:30
dacharydhellmann: resource_id ( the unique ID of a resource, for instance the IP, the nova instance id, the glance image id etc. )16:30
nijabadachary: good point.  I think we have a small misalignment between schema and counters that we need to fix16:30
dacharyin http://wiki.openstack.org/EfficientMetering#Storage16:30
dhellmanndachary, yeah, I took those as examples rather than hard documentation16:31
dhellmannwhen we're done, what I would like is something that describes the general table schema and then something that says for each counter exactly what goes in the fields of that table16:31
nijabadachary: and we need to be able to record secondary field counters in the schema too16:31
dhellmannI think we're close to that with the existing tables16:31
jd___doesn't schema miss resource_type too?16:31
dhellmannthe resource type is implied by the counter id, isn't it?16:32
nijabadhellmann: yes16:32
dhellmanndachary, back to your question about secondary id being IP, was that for all network counters?16:32
jd___and the counter id is in the schema ? (can't see it)16:32
dhellmanncounter_type?16:33
*** reed has quit IRC16:33
*** mnewby has quit IRC16:33
*** mnewby_ is now known as mnewby16:33
dacharydhellmann: yes16:33
jd___dhellmann: ah ok :)16:33
dhellmann(btw, I like mark's suggestion of calling them "meters" instead of "counters")16:33
dachary#action jd___  describes the general table schema and then something that says for each counter exactly what goes in the fields of that table and show how secondary field counters are recorded in the in the schema too16:33
*** reed has joined #openstack-meeting16:33
dacharydhellmann: me too16:33
*** shang has joined #openstack-meeting16:34
nijabadachary: nice action summary16:34
dacharyI think we agree on the basics and on the fact that the documentation needs to be clarified16:35
dhellmannyes16:35
* dhellmann likes progress16:35
dacharyI should have left the "resource_id" column in the counters section where there is a description for each counter.16:35
nijabaI think everyone here does, or we would not bother ;)16:35
dhellmann:-)16:35
dacharydo we agree to s/counter/meter/ ?16:35
dhellmann+116:36
nijaba+116:36
* dachary +116:36
flacoste+116:36
Aswad_+116:36
zinux+116:36
dachary#agreed s/counter/meter/16:37
*** dendro-afk is now known as dendrobates16:37
dacharyhttp://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. ?16:37
dhellmann+116:37
nijaba+116:37
Aswad_+116:38
*** troytoman-away is now known as troytoman16:38
flacoste+116:38
dachary#agree http://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. ?16:38
dachary#topic schema definition16:39
dachary#info Proposed http://wiki.openstack.org/EfficientMetering#Storage16:39
*** openstack changes topic to "schema definition"16:39
dacharyI realize it needs cleanup.16:39
dacharyI was entirely focused on the part describing the fields necessary for the meters16:39
dachary(s/counter/meter/ in effect ;-)16:39
* nijaba brings back the requirement for a tupple instead of just "account_id"16:39
*** littleidea has joined #openstack-meeting16:40
flacosteit seems that account_id should be renamed to tenant_id16:40
flacosteand that contains both account and project16:40
flacosteas tenant_id is a keystone identifier really16:40
dhellmannflacoste, is account the same as user?16:40
flacostewhich encapsulates both16:40
* dhellmann is confused by shifting terminology16:40
dachary#action jd___ clarify / document the fact that the secondary field or the resource_id field carries the IP/VIF for the meters related to network so that they can be "per IP"16:40
flacostedhellmann: indeed16:40
flacostedhellmann: yes, in my mind account == user16:40
flacostewe should use keystone terminoly16:40
flacosteand i shouuld learn it :-)16:41
whittwe are using tenant at the lowest level16:41
dhellmannok. I'm not sure which is the current terminology, but for now let's talk in terms of "tenant" and "user" and then agree to figure out the right values when we write the docs16:41
flacoste+116:41
nijaba+116:41
dhellmannI agree that we should have both tenant and user. I don't know why we would want to have them in a single field instead of separately, though. Can you elaborate flacoste?16:42
dacharyso the fields should be source (paas, iaas, etc.), user_id, tenant_id, resource_id, counter_type, counter_volume, counter_duration, counter_datetime, secondary type, message_signature, message_id ?16:42
zinuxThe name tenants will perhaps disappear for projects16:42
*** jakedahn_zz is now known as jakedahn16:42
dacharyzinux: you're correct16:43
* dhellmann thought it was the other way around, but ok16:43
dacharyso the fields should be source (paas, iaas, etc.), user_id, project_id, resource_id, counter_type, counter_volume, counter_duration, counter_datetime, secondary type, message_signature, message_id ?16:43
dhellmanndachary, where does the value for source come from?16:43
* dachary confused now16:43
dachary:-D16:43
dhellmannis it in the event?16:43
dhellmanndachary, join the club :-)16:43
nijabasource is set by the agent, based on what it uses for auth16:44
dacharynijaba: suggested it. I'm not sure how it set but I can see the value.16:44
nijabaso we can later add agents for projects outside of openstack, but yet billable by the same owner16:45
dhellmannnijaba, that assumes separate agents though, right? I thought we were going to try monitoring notifications to start16:45
dhellmannah, so "source" for the event monitoring may just be "internal" or something?16:45
dacharythat allows separate agents16:45
nijabadhellmann: the concept of agents is fuzzy, as they can both be sepaate or intergrated.  who cares, as long as they speak the same queue API language?16:46
*** donaldngo_hp has joined #openstack-meeting16:46
nijabadachary: no, for openstack project, it should be keystone16:46
dacharyhum16:46
dhellmannit's always easier to add something than to remove it, so I want to make sure version 1 only includes stuff we're going to use out of the gate16:46
dhellmannwe also need to be able to document the expected value(s) for each field, so I want to make sure I understand that16:47
dhellmannI agree that a "source" or "agent" field may provide value, FWIW16:47
flacostedhellmann: please bear with me, i apologize for being keystone illeterate, i thought a tenant encapsulates both project and user, if that's not the case, then yeah, we want two fields16:47
dacharyme too.16:47
nijabadhellmann: so expected value for all existing counters should be keystone16:47
dacharytenant == project16:47
dacharyonly one term replaces the other16:47
flacostethen yes, we want both tenant and user16:47
dacharyand indeed we need both16:47
dhellmannflacoste, a user may have access to more than one tenant but a tenant owns things16:48
dacharyflacoste: yes :-D16:48
flacosteso that we can bill projects and/or users depending on our business model16:48
flacostesorry for the confusion16:48
flacostetenant + user is what we need16:48
nijabanp... better all agree now...16:48
dacharynijaba: I trust your vision when you say that encoding the authentication source (a URL maybe ? ) is a way to distinguish the global set of counters. And maybe aggregate them for billing purposes without mixing them.16:48
nijabadachary: yep16:49
dhellmannso the source is the *authentication* source?16:49
dacharynijaba: would you agree to explain the rationale in the document and discuss it afterwards on the list ?16:49
dhellmannnot the thing that triggered the operation that is going to be costing the customer $?16:49
dhellmanndachary, good plan, we're running out of time16:50
nijabaok16:50
dachary#action nijaba describe the source field rationale and use case, initiate a thread to validate its use.16:50
dacharyso the fields should be source (to be discussed), user_id, project_id, resource_id, counter_type, counter_volume, counter_duration, counter_datetime, secondary type, message_signature, message_id ?16:50
dacharyare we missing something ?16:51
* nijaba does not think so16:51
dhellmann+116:51
nijaba+116:51
zinux+116:52
* dhellmann may want to bike shed the name of "secondary type" on the list16:52
Aswad_+116:52
* dachary +116:52
jd___payload? :)16:52
dacharydhellmann: I don't like it either16:52
dacharyjd___: +1 on payload16:52
dhellmannok, let's table that discussion for now, though16:52
dacharyok16:53
dhellmann8 more minutes, right?16:53
*** Guest2888 has joined #openstack-meeting16:53
nijabaright16:53
dhellmannwhat else is on the agenda?16:53
nijabathat were the 2 main items16:53
dachary#agree the fields should be source (to be discussed), user_id, project_id, resource_id, counter_type, counter_volume, counter_duration, counter_datetime, secondary type / payload, message_signature, message_id ?16:53
dhellmannsomeone needs to propose a formula for calculating the message signature16:53
dachary#action jd___ update the documentation16:53
dachary#action jd___ document the resource_id for each counter16:54
dacharydhellmann: yes ;-)16:54
jd___dhellmann: gpg ;)16:54
nijabadhellmann: should that be part of the message API discussion? (24 may)16:54
dachary#topic discuss API assumptions16:54
*** openstack changes topic to "discuss API assumptions"16:54
dhellmannnijaba, that sounds like a good idea16:54
dacharyhum16:55
dhellmannI propose hmac16:55
dacharyI feel like we should move to the last topic16:55
dachary#topic open discussion16:55
*** openstack changes topic to "open discussion"16:55
dacharythere won't be room for anything else really ;-)16:55
dacharydhellmann: +1 on hmac16:55
dacharyjd___: could you tell us about your plans to bootstrap the software ?16:56
* nijaba proposes to set the signature algo on the discusion to be agreed on may 2416:56
Aswad_are we storing the past data too? should there be a time stamp for each recorded data - just a thought16:56
dacharynijaba: ok16:56
dhellmannnijaba, +116:57
nijabaAswad_: counter_datetime?16:57
dacharythere is a timestamp already counter_datetime16:57
jd___dachary: since there's no decision made on everything, I'll start with things that are agreed on, like an agent getting nova compute creation events, swift middlewares16:57
Aswad_ah i missed it16:57
* dhellmann probably wants to bike shed that column name, too :-)16:58
dacharydoes anyone have any advice on how to approach the project leads with regard to introducing metering code ? swift ?16:58
nijabadachary: ml sounds best?16:58
* dachary taking advantage of the last 90 secs ;-)16:58
dacharymouhahahah16:58
dhellmannright, we should send a concrete proposal (we want to record X for project Y, and will need to change it in Z way)16:59
dacharythank you everyone, I'm glad we came to an understanding :-D16:59
*** dendrobates is now known as dendro-afk16:59
Aswad_:) thanks !16:59
nijabathanks everyone16:59
dhellmannjd__, are you going to be working on a prototype in the new repo or separately on github?16:59
dacharyjd___: +117:00
dachary#endmeeting17:00
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"17:00
openstackMeeting ended Thu May  3 17:00:05 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-16.00.html17:00
flacostethanks17:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-16.00.txt17:00
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-16.00.log.html17:00
jd___dhellmann: in the new repo17:00
*** renuka has joined #openstack-meeting17:00
dhellmannjd__, ok, good17:01
jaypipeshi all17:01
Guest2888hi17:01
Ravikumar_hpHi jay . Good Afternoon17:02
davidkranzHi.17:02
jaypipesdavidkranz, Ravikumar_hp: afternoon :)17:02
*** JoseSwiftQA has joined #openstack-meeting17:02
jaypipes#startmeeting17:02
openstackMeeting started Thu May  3 17:02:18 2012 UTC.  The chair is jaypipes. Information about MeetBot at http://wiki.debian.org/MeetBot.17:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:02
donaldngo_hpgood morning17:02
jaypipesJoseSwiftQA: heya :)17:02
davidkranzDaryll said he will be late or might have to miss the meeting.17:02
jaypipesdonaldngo_hp: afternoon!17:02
jaypipesall: unfortunately, I only just now sent my email to the QA and main mailing list about the smoke test stuff, so I'm happy to move that discussion to next week since I was delayed in getting it out to everyone.17:03
jaypipes#link http://wiki.openstack.org/Meetings/QATeamMeeting17:04
davidkranzOK, next week it is.17:04
JoseSwiftQAcoolbeans :D17:04
jaypipes#topic Status of the devstack tempest Jenkins job17:04
*** openstack changes topic to "Status of the devstack tempest Jenkins job"17:04
davidkranzjaypipes: Do tell.17:05
jaypipesOK, so there was a bunch of mess that needed to be cleaned up17:05
*** dendro-afk is now known as dendrobates17:05
jaypipes:)17:05
jaypipesFixes needed to be made to devstack, the devstack-gate project (part of the openstack-ci project) and to tempest itself.17:05
jaypipesThe devstack and devstack-gate fixes are now in trunk. The tempest change I just pushed about 20 minutes ago.17:06
jaypipesIn the meantime, while all this was being sorted, I disabled the Jenkins job17:06
*** Aswad_ has left #openstack-meeting17:06
jaypipesSince it takes about 45 minutes to run on some of the CI environments (the HP zones...)17:06
jaypipesOnce the tempest change is approved, I will enable the job again.17:06
jaypipeshttps://review.openstack.org/#/c/7067/17:07
jaypipesthat is the relevant change...17:07
jaypipesThe root of the problem was that devstack was creating the volume group with a backing file size of only 2G17:07
jaypipesand so the volume list test was failing (since it tries to create 3 1G volumes)17:08
jaypipesand leaving those volumes around without cleaning them up...17:08
davidkranzOK, will look at that right after the meeting.17:08
jaypipesThere were also issues with the image tests (using the Glance API, not the compute API) that stemmed from a change in the setup of devstack's Keystone service catalog17:08
jaypipesThat required a fix in both Glance and Tempest, and those patches are also now both in the trunks17:09
donaldngo_hpthe volume list tearDownClass fix has been submitted17:09
*** joesavak has quit IRC17:09
*** dwalleck has joined #openstack-meeting17:09
donaldngo_hpand also backported to stable/diablo17:09
jaypipesdonaldngo_hp: to essex :)17:09
jaypipesyes, diablo too17:09
donaldngo_hpawaiting review17:09
dwallecksorry, run a bit late17:09
jaypipesBottom line, we should have a fully passing Tempest gating job by end of day today.17:09
davidkranzjaypipes: Hooray. Great work.17:10
jaypipesand at that point, I believe we should start gating the Temepst project trunk on that job.17:10
jaypipesAll in agreement for that, I presume?17:10
Ravikumar_hpyes Jay17:10
Ravikumar_hp+117:10
fattarsi+117:11
jaypipesexcellent.17:11
davidkranzAgreed17:11
*** derekh has quit IRC17:11
donaldngo_hpagreed17:11
jaypipesalrighty, per the agenda, let's move on to the next topic17:11
davidkranzNo blockers as far as I know.17:11
jaypipes#topic 2. (David) Strategy for maintaining the stable/essex tempest branch:17:12
*** openstack changes topic to "2. (David) Strategy for maintaining the stable/essex tempest branch:"17:12
*** flacoste has left #openstack-meeting17:12
jaypipesdavidkranz: you are up my friend :)17:12
davidkranzI think we should backport new tests if they don't have to be rewritten due to config changes and such.17:12
*** DuncanT has joined #openstack-meeting17:13
donaldngo_hp+117:13
Ravikumar_hpBackport from Master to Essex/stable17:13
Ravikumar_hpfine.17:13
davidkranzWe also need to make sure that tempest stable/essex keeps up with changes to the stable branch team checkins.17:14
jaypipesdavidkranz: yes, I think that is a reasonable standard17:14
Ravikumar_hpbut do we need to backport further to diablo/stable?17:14
davidkranzSince I volunteered to be on that team I will keep an eye on that.17:14
jaypipesRavikumar_hp: don't *have* to, but if some team wants to manage the diablo branch, they should feel free to do so17:15
*** troytoman is now known as troytoman-away17:15
davidkranzI would not recommend keeping diablo stable active. The stable branch team is not going to approve any change unless it is a security hole or some such.17:15
*** mdrnstm has quit IRC17:15
*** Mandell has joined #openstack-meeting17:15
davidkranzI mean to stable/diablo. There was only ever one release of that.17:15
Ravikumar_hpdavidkranz; +117:15
donaldngo_hpwe need some changes in stable/diablo mainly to fix bugs in test clean up17:16
davidkranzdonaldngo_hp: That's fine. I was talking about a policy going forward.17:16
jaypipes++17:16
davidkranzOf course we should be gating tempest on changes to essex/stable too.17:16
Ravikumar_hp++17:17
davidkranzIf there is no disagreement I think that takes care of agenda item 2.17:17
jaypipesdavidkranz: we will be.17:17
jaypipesdavidkranz: the CI jobs are all ready to run17:17
davidkranzjaypipes: Excellent17:18
jaypipesdavidkranz: basically, devstack builds the appropriate branches of the projects based on the branch that the fix is proposed to17:18
donaldngo_hpis the devstack builds for essex and trunk only?17:18
jaypipesdavidkranz: so, the nice thing is we don't need different jobs for different release branches... it's all one job, with environment variables switching the source of the git pulls...17:18
davidkranzjaypipes: Great. Set it and forget it.17:19
jaypipesdonaldngo_hp: no, I think there is a diablo one too.... but I'd have to check with dtroyer17:19
jaypipesdavidkranz: right17:19
donaldngo_hpcool17:19
*** shang has quit IRC17:19
jaypipesdavidkranz: OK, so I think there is agreement to both of your points?17:19
davidkranzSeems so.17:19
jaypipesand also to Ravikumar_hp's #4 on the agenda?17:19
davidkranzDitto.17:20
Ravikumar_hp4. (Ravi) Freezing Diablo/Stable branch as we have Essex/Stable.17:20
*** dachary has quit IRC17:20
Ravikumar_hpIt is already taken care in previous discussion17:20
jaypipesk. davidkranz, I'm going to assign an action item to you, then, for posting to the mailing list a summary of those decisions about stable branch maintenance for tempest.17:20
jaypipes#action davidkranz to post decision summary to ML about stable release branch maintenance policy for Tempest17:21
jaypipesGood to go to next item in agenda?17:21
*** Gordonz has quit IRC17:21
davidkranzjaypipes: OK, I will send it to the group first to make sure.17:21
jaypipesdavidkranz: cheers and thx!17:21
jaypipes#topic 3. (Ravi) Status of Swift test development for Tempest17:22
*** openstack changes topic to "3. (Ravi) Status of Swift test development for Tempest"17:22
*** Gordonz has joined #openstack-meeting17:22
jaypipesJoseSwiftQA: ping!17:22
dwalleckjaypipes: pong17:22
jaypipesdwalleck: got a status on those eagerly-anticipated Swift Tempest tests? :)17:22
dwalleckIn case he doesn't pong =P17:22
dwalleckjaypipes: Close to being converted. Gigi said to ping her, she has the timeline17:23
jaypipesdwalleck: hmm, OK. Hoping for something to put in the post-meeting summary post to ML... ;)17:24
dwalleckShe has me focused on Nova stuff so I'm not as in the know17:24
jaypipesdwalleck: gimme something more! :)17:24
dwalleckSoon? :D17:24
jaypipeslol :)17:24
JoseSwiftQAjaypipes: Sorry, zoned out.  I've put in all the new config changes17:24
dwalleck2012?17:24
fattarsilol17:25
jaypipesJoseSwiftQA: ah, cool.17:25
jaypipesJoseSwiftQA: going to push to Gerrit this week?17:25
JoseSwiftQAi'd say yes but I'm in a pessimistic mood. probably next week.17:25
jaypipesk, good to be realistic.17:25
jaypipesJoseSwiftQA: and about how many tests are in the making for swift? just curious..17:26
* mtaylor injects https://jenkins.openstack.org/job/dev-gate-tempest-devstack-vm/400/console and runs away17:26
JoseSwiftQAI aim to finish it up this weekend and have it tested against at least devstack17:26
JoseSwiftQAI want to have basic api exercises for everythign in the client at least.17:26
jaypipesJoseSwiftQA: awesome. anything the QA team can assist with?17:27
Ravikumar_hpGreat JoseSwiftQA:17:27
fattarsiJoseSwiftQA: curious if you have anything planned for large uploads, as mentioned in https://bugs.launchpad.net/tempest/+bug/89333317:27
uvirtbotLaunchpad bug 893333 in tempest "Test large object support (>5GB)" [Medium,Confirmed]17:27
JoseSwiftQAonce I actually manage to finish writing the client, it should be fairly straight forward to write more tests.17:27
jaypipesmtaylor: :( I disabled that job a couple days ago... someone enabled it again?17:28
JoseSwiftQAfattarsi:  I have that written, but it's flakey17:29
JoseSwiftQAi'll push it up anyway with many comments about caveats17:29
jaypipescoolio.17:29
jaypipesAll: Not to jinx anything... but https://jenkins.openstack.org/job/dev-gate-tempest-devstack-vm/401/console17:30
jaypipestests all passing up to now...17:30
fattarsiJoseSwiftQA: cool, I'd like to see anyway, I might be able to help17:30
mtaylorjaypipes: oh, I enabled it because dwalleck was saying in the channel that he wanted tempest gating ... so I wanted to be able to give him a linnk to look at17:30
jaypipesmtaylor: k, no worries...17:31
JoseSwiftQAfattarsi: cool, i'll push everything to my fork on github once it's running, and send out an email17:31
jaypipesJoseSwiftQA: rock on, thx man!17:31
*** dendrobates is now known as dendro-afk17:31
mtaylorjaypipes: do you guys have support for xunit test output?17:31
* dwalleck refuses to comment about the positive or negative nature of that test run17:31
davidkranzOops. Just failed.17:31
jaypipesmtaylor: yup.17:31
dwalleckWell fudge17:32
fattarsiJoseSwiftQA: awesome17:32
jaypipesmtaylor: how do you think the graphs on the jenkins job main page are generated? ;)17:32
JoseSwiftQA:D17:32
dwalleckWell, good reason. A server went into error status17:32
Ravikumar_hpJoseSwiftQa: Thanks17:32
dwalleckHurray for AUT bugs!17:32
JoseSwiftQAno prob :)17:32
jaypipesdwalleck: hey, that right there is the BEST RESULT of the tempest jenkins job we've had to date. Huzzah!17:32
jaypipesRan 144 tests in 531.165s -- not bad :)17:33
mtaylorjaypipes: SO CLOSE17:33
jaypipesNODE_PROVIDER=hpcloud-az117:33
jaypipesalso not bad :)17:33
mtayloraz1 is being a real bitch today17:33
jaypipesHooray for stable providers! :)17:33
*** johnpostlethwait has joined #openstack-meeting17:33
jaypipesOK, final agenda item before open discussion...17:34
jaypipes#topic (Jay) Can we come to a consensus on the subset of Tempest tests that we recommend to the core projects to gate their trunks?17:34
*** openstack changes topic to "(Jay) Can we come to a consensus on the subset of Tempest tests that we recommend to the core projects to gate their trunks?"17:34
jaypipesI suppose this may be better to discuss on the mailing list ... but17:35
davidkranzjaypipes: We will run everything overnight regardless, right?17:35
jaypipesdavidkranz: sure.17:35
jaypipesdavidkranz: what we're talking about is what we recommend be the set of tests whose failure will prevent a merge into a core project trunk.17:35
*** rafaduran has joined #openstack-meeting17:36
davidkranzjaypipes: Right.17:36
jaypipesdavidkranz: and of course we must balance the total length of testing time with the overall breadth of coverage those tests provide...17:36
Ravikumar_hpjaypipes: yes . may be tests are identified with existing @attr=smoke17:36
*** JoseSwiftQA has quit IRC17:36
jaypipesRavikumar_hp: well, see my mailing list post about that particular topic ;)17:36
davidkranzI think we should see how reliable the nightly runs are while discussing this with others.17:36
jaypipesdavidkranz: k, good point.17:37
davidkranzThe only other objection will be the time it takes.17:37
*** DanD has quit IRC17:37
rohitkthere are about 300+ tests in tempest today17:37
*** adjohn has joined #openstack-meeting17:37
davidkranzIf they were fast and reliable we would run them all on every trunk checkin.17:37
jaypipesrohitk: there are?17:37
*** martine has joined #openstack-meeting17:37
rohitkjust did a grep on 'def test_'|wc -l in tests17:38
Ravikumar_hpyes. service level tests only - for example nova will run nova smoke tests - 5 or 6 tests17:38
jaypipesdavidkranz: right. but for instance, do we want a failure of, say, a test of a particular API extension to hold up merging? those are the kinds of decisions we must make...17:38
jaypipesrohitk: ah! :)17:38
fattarsijaypipes: you have an idea how to separate out the 'recommended' set of tests?17:38
donaldngo_hpit will be cool to have a smoke test run under 15 minutes and a regression nightly run that takes hours17:39
jaypipesfattarsi: well, we can certainly use nose's @attr decorator for this.17:39
davidkranzjaypipes: I don't think so. As long as a tempest nightly failure is considered to be an urgent issue that might be good enough.17:39
Ravikumar_hpjaypipes: yes17:39
sdaguejaypipes: a related question, is there some sort of high level map out of the tests, especially the big holes where there is a desire for new tests?17:39
jaypipesfattarsi: we just need to be careful about the consistency with which we use that decorator. Haven't been so consistent up to now ;)17:39
fattarsijaypipes: isee17:39
davidkranzI think we should try that first.17:39
davidkranz There is already significant overlap between tempest and various unit tests.17:40
jaypipessdague: unfortunately, you kind of have to check the Tempest open bug list on Launchpad right now...17:40
jaypipessdague: but we really should have a single "status of coverage" page. agreed...17:40
jaypipesdavidkranz: correct.17:40
sdaguejaypipes: what about actually documenting it in the repo in another text file? web pages are great, but they tend to stale relative to what's in the repo17:41
dwalleckdavidkranz: There is, but regardless of that, many bugs seem to be getting past the unit tests anyway....17:41
rohitkjaypipes: We need documentation on using the attr decorator and the allowed/possible types, that may help test writers17:41
jaypipessdague: we could do that, sure... though that page can just as easily get out of date! :)17:42
jaypipesrohitk: ++++17:42
jaypipesrohitk: yes, that is definitely the case.17:42
dwalleckrohitk: ++17:42
jaypipesrohitk: I can take a stab at that one today.17:42
sdaguejaypipes: true, but if I pull tempest it would be nice to have an idea in the code about what its actually covering :)17:42
rohitkjaypipes: thanks17:42
jaypipesrohitk: I'll put together a doc on using it17:42
davidkranzdwalleck: I know. Just worried that running tempest on every checkin everywhere will suck huge resources for possibly little gain relative to a nightly build with failures treated as urgent.17:43
jaypipessdague: :) no disagreement from me17:43
dwallecksdague: The problem is that you can't easily measure functional test coverage like code test coverage without instrumentation17:43
*** anderstj has joined #openstack-meeting17:44
dwalleckdavidkranz: That's why we need to solve the parallezation problem. We can easily get the full test run in the 20-30 zone17:44
davidkranzdwalleck: Yes, but it consumes the same amount of resources.17:44
jaypipesdavidkranz, dwalleck: I agree with both of you, actually. That's where the whole question of "balance" comes into play... there are tradeoffs for eveything of course. If we had a good, consistently-applied use of the @attr decorator, I think we can get the best of both worlds, and have the gate job focus on quick, important tests and have the nightly job run a series of more thorough tests17:44
donaldngo_hp++17:45
davidkranzjaypipes: Agreed. Perhaps we should ask the PTLs to identify such a set that makes sense to them17:45
jaypipesdavidkranz: PTLs have too much on their plate already IMHO ;) I think we should make our best recommendation and tune it over time...17:46
*** GheRivero_ has quit IRC17:46
dwalleckjaypipes: ++. Sounds reasonable17:46
donaldngo_hpyea for example uploading a 5GB file will take pretty long that is my opinion is a regression test17:46
davidkranzOK17:46
jaypipesdavidkranz: if we notice a test is taking a long time and it may not cover an important area, we can remove it from the gate, etc17:46
davidkranzjaypipes: Yeah. This will be a work in progress for a while if not forever.17:47
rohitkwe should probably have a longevity test suite in future17:47
*** dwalleck has quit IRC17:47
jaypipesFOREVER! :)17:47
jaypipesrohitk: yes, I think davidkranz's stress test module would be a good basis for that.17:47
davidkranzWe will have to make the same sorts of tradeoffs for nightly streses tests.17:47
rohitkjaypipes, davidkranz: ++17:48
jaypipesdavidkranz: yup17:48
jaypipesalright guys, anyone got any other things to discuss?17:48
jaypipes#topic open discussion17:49
*** openstack changes topic to "open discussion"17:49
rohitkping! Do we have a timeframe to get the networks client in? https://review.openstack.org/#/c/4896/317:49
rohitkwe have a bunch of quantum tests17:49
jaypipesrohitk: ah, yes...17:49
jaypipesmnewby: ping17:49
davidkranzI think we should add an item to the agenda template for "Stuff likely to get posted in the next week."17:49
mnewbyjaypipes: here17:49
jaypipesmnewby: Hi! :)17:50
jaypipesmnewby: so, we actually put off the discussion on smoke testing to next week...17:50
mnewbyjaypipes: hi!  I was watching the conversation for signs of the discussion.17:50
mnewbySame time next week?17:50
jaypipesmnewby: but I'd like to get the quantum tests in https://review.openstack.org/#/c/4896/ into tempest this week17:50
mnewbyjaypipes: They look good to me.17:51
jaypipesmnewby: k, I will remove my -1. they were tiny nits anyway...17:51
jaypipesmnewby: approved. off to the test pit they go.17:51
mnewbyjaypipes; I'll hopefully be talking with Daryl about the potential for automating the golden paths.17:52
jaypipesrohitk: so there's the answer to your question ;) in about 20 minutes.17:52
jaypipesmnewby: excellent.17:52
rohitkjaypipes: awesome!17:52
davidkranzHopefully some one can review my recent stress test submission.17:53
jaypipesdavidkranz: will do today.17:53
*** zinux has left #openstack-meeting17:53
davidkranzjaypipes: Thanks!17:53
jaypipesnp!17:53
rohitki would like some suggestions on how get tests that depend on mysql-client into tempest17:53
*** Guest2888 has quit IRC17:53
rohitki have scenarios where I need to update the DB to test functionality17:54
jaypipesrohitk: hmmm.... the whitebox tests...17:54
*** dhellmann has quit IRC17:54
rohitkyes17:54
*** zinux has joined #openstack-meeting17:54
rohitkdecorator for such tests (skip_if mysql not installed, attr type=wb)17:54
rohitksomething like that17:54
jaypipesrohitk: please see my mailing list post about the smoke tests and also this draft merge prop: https://review.openstack.org/#/c/7069/17:54
rohitkjaypipes: ok17:55
jaypipesrohitk: We can add another test case class of WhiteboxTest to go along with FuzzTest and SmokeTest17:55
*** rafaduran has quit IRC17:56
davidkranzWhitebox tests may be the next frontier.17:56
rohitkjaypipes: ++17:56
*** darraghb has quit IRC17:56
davidkranzLike flapping a service during a stress test :)17:56
jaypipesdavidkranz: yep. I always wanted them, but wanted to complete our API coverage tests (blackbox) first... we're almost there and I think starting on whitebox is good now..17:57
*** dhellmann has joined #openstack-meeting17:57
rohitkso ssh into an openstack node (not the vm) and mysql stuff would be whitebox?17:57
rohitkright?17:57
jaypipesrohitk: correct17:57
davidkranzrohitk: Yes.17:57
rohitkok, thanks17:57
jaypipesOK all,  we're out of time now... please feel free to comment/suggest/critique on my mailing list post about smoke tests... :)17:58
davidkranzBye all.17:58
rohitkjaypipes: looking forward for that...thanks!17:58
*** vladimir3p has joined #openstack-meeting17:58
jaypipesdavidkranz: you'll send summary to ML? and ping dwalleck about his rotation next week?17:58
*** gyee has joined #openstack-meeting17:59
jaypipesOK, bye all!17:59
jaypipes#endmeeting17:59
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"17:59
openstackMeeting ended Thu May  3 17:59:30 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-17.02.html17:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-17.02.txt17:59
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-17.02.log.html17:59
*** Ravikumar_hp has quit IRC17:59
*** donaldngo_hp has quit IRC17:59
jgriff#startmeeting18:00
openstackMeeting started Thu May  3 18:00:53 2012 UTC.  The chair is jgriff. Information about MeetBot at http://wiki.debian.org/MeetBot.18:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:00
*** mdrnstm has joined #openstack-meeting18:01
DuncanTHi18:01
vladimir3pHi18:01
rnirmalhey18:01
jgriffLet's hope my internet connection doesn't die this week and lock up the channel :(18:01
rnirmal:)18:02
jgriffrnirmal: Sorry I didn't get your pull request last night before migration started back into gerrit18:02
rnirmalnp send the PR thru gerrit18:02
rnirmalsend/ will send18:02
jgriffrnirmal: :)18:02
*** jbrogan has joined #openstack-meeting18:03
rnirmalshall we start the meeting18:03
jgriffOk, so you've probably all noticed a flury of activity :)18:03
jgriffThanks especially to anotherjesse !!!18:03
rnirmaljgriff: #startmeeting18:03
jgriffI did18:03
rnirmaloops my bad..18:03
jgriff:>18:04
rnirmalI think it just cleared off my screen.. n/m18:04
jgriffAhhh18:04
vladimir3pso, there is an official openstack/cinder repo now18:04
anotherjessehi18:04
jgriffvladimir3p: yes has been for about a week now18:04
rnirmal#link https://github.com/openstack/cinder18:05
vladimir3pyeah, just for some reason my git shows that it was created 15 min ago18:05
jgriffso anyway... I'd suggest everybody take a look at the wiki page if you haven't: http://wiki.openstack.org/Cinder18:06
anotherjessevladimir3p: we just pushed a squash to it 15 minutes ago18:06
jgriffMost importantly check out the etherpad18:06
jgriffvladimir3p: Also I was convinced (fortunatley) that the way I was going about it wasn't so great so we did a reset18:07
jgriffInstead we just pulled in all of nova and culled18:07
vladimir3pok, great18:07
anotherjessedtroyer is working on getting cinder support into devstack - https://review.openstack.org/#/c/7042/18:07
jgriffand vishy is working on the first item in the decoupling section18:08
anotherjessewe need to get vishy's python-cinderclient moved to official repo this week as well18:08
jgriffanotherjesse: ahhh.. I'll hit up mtaylor about that, assuming keep it in it's current form18:09
anotherjessejgriff: that's ok, I think it bit rotted though18:09
jgriffanotherjesse: still could use as a baseline yes?18:10
rnirmalso is the cinder repo setup with gerrit now?18:10
mtayloryup18:10
jgriffrnirmal: yep18:10
anotherjessejgriff: yeah18:10
rnirmalcool thanks18:10
mtaylorjgriff: let me know when it's there and I'll get cinderclient added18:10
jgriffmtaylor: assuming just pull in vish's version18:10
mtayloryeah, prolly so18:11
jgriffmtaylor: guess I'll need to do LP pages again18:11
mtaylorwe actually just use the cinder pages for cinderclient if we're following the model of the other projects18:11
jgriffmtaylor: yes please18:11
*** mdrnstm has left #openstack-meeting18:12
*** mdrnstm has joined #openstack-meeting18:12
jgriffmtaylor: thanks, wasn't sure on that one18:12
jgriff#topic next-steps18:12
*** openstack changes topic to "next-steps"18:12
jgriffSo I'd like to propose continuing the usage of the etherpad for starters18:12
jgriffif anybody sees something inparticular they'd like to tackle it would be good to keep this record up to date18:13
anotherjessejgriff: it probably works for another week, but we will want to move to blueprints once we figure out what we don't know ;)18:13
rnirmalI'd like to start opening up bugs/blueprints for anything new that's going to get merged in... easier to figure out what's getting worked on18:13
jgriffrnirmal: fair18:14
anotherjessernirmal: I think limiting to things we know need done - such as prototype http API extensions (#4 in decoupling work)18:14
jgriffMy proposal is this:18:14
anotherjessehttp://etherpad.openstack.org/cinder-worksheet18:14
jgriffdecoupling work, general structure etc is still in flux18:14
jgriffuse etherpad18:14
*** dhellmann has quit IRC18:14
jgriffbuilding on top of what's there, features etc need bp18:14
vishyjgriff: I started outlining the basic flow of attaching a volume in nova18:15
vishyjgriff: in the etherpad, and how it 'should' work in the future18:15
vishyjgriff: it is a little complex and weird right now18:15
*** dhellmann has joined #openstack-meeting18:15
jgriffvishy: I saw that, was thinking that's where I should probably copy it into a bp once it's a bit settled18:16
jgrifflike anotherjess mentioned, maybe another week of etherpad18:16
jgriffMaybe a little less18:16
*** dwcramer has joined #openstack-meeting18:16
jgriffalso I don't think that precludes anybody from submitting bp's18:16
rnirmalit's probably worthwhile to hold off on new code submissions, till we get a base working copy with nova18:18
rnirmalI mean new features18:18
anotherjessernirmal: I actually don't know if getting it working with nova is #1 goal18:18
*** ryanpetrello has quit IRC18:18
jgriffrnirmal: I think I agree but it's "all" new code :)18:18
anotherjesseI would like it to work on its own18:18
anotherjesseand expose the APIs nova would need18:18
*** novas0x2a|laptop has joined #openstack-meeting18:18
jgriffSo I believe we are all on the same page18:18
anotherjessebut the code changes to nova will be more complicated, so lets not block on them18:19
*** ryanpetrello has joined #openstack-meeting18:19
jgriffWe agreed previously, get nova functionality working before anything else18:19
rnirmalok18:19
jgriffin other words, existing nova-volume functionality18:19
anotherjessejgriff: define "nova functionality" - being able to do the functions or having nova actually using cinder?18:19
jgriffI'd like to have nova actually use cinder before going into "new" features18:20
rnirmalmimic nova-volumes in current functionality18:20
vladimir3pjgriff: let's start with operating cinder without nova18:20
jgriffyeah, granted it might not be perfect but focus efforts on just getting it usable18:20
vladimir3plike with some externall app18:20
anotherjessecinder is a service, having cinder do the right thing and having nova integrate well with cinder are different problem sets18:20
anotherjessevladimir3p: yep!  we have python-cinderclient which we can make work with all the changes needed in the API to support volumes18:21
anotherjesse(without a shared queue/db)18:21
vladimir3pyeah, it will be the 1st step18:21
vladimir3pnova tune-up will be a big step by itself18:21
jgriffanotherjess: yeah, the nova side complicates18:21
anotherjesseattach/detach first18:22
vladimir3pif cinder could handle APIs properly and expose iSCSI devices - it is a good 1st milestone, IMHO18:22
anotherjesseand then we can move into reserve/init connection if we want18:22
jgriffI would like to try and get attach/detach working in F1 if possible18:22
anotherjessejgriff: agreed18:22
jgriffso does anybody have time to dedicate/commit to some of these items?18:23
jgriffhmm... ok, maybe that's to vague or commital18:24
jgriffdoes everybody like what they see so far and agree with the direction still?18:24
*** dwcramer has quit IRC18:24
anotherjesseactually looks like initialize/terminate are more important18:24
anotherjesseI just asked vishy what those where18:24
anotherjessethat is how you actually get the iscsi connection information18:25
rnirmalinitialize/terminate is what provides the connection info18:25
jgriffanotherjesse: guess you can't attach/detach without that18:25
anotherjesseattach/detach is just metadata18:25
rnirmaljgriff: yes18:25
rnirmalno it's the other way round18:25
vladimir3pjgriff: I like it :-) can't commit for next couple of weeks. I would prefer to see more stuff in common rather copy/pasting to cinder18:25
rnirmalinitialize/terminate is metadata that the volume service provides18:26
anotherjessevladimir3p: there should be a blueprint of blueprints to common-ize stuff18:26
vladimir3panotherjesse: ok18:26
DuncanTI'm starting to look at cinder, but can't commit this week. Might get chance to make some progress18:26
jgriffvladimir3p: I started using the approach but was educated by anotherjess and vishy18:26
vladimir3p:-D18:26
jgriffvladimir3p: I think it's a good idea to work on this after getting goals for F1 and F218:27
anotherjessevladimir3p: we can move things towards common, but don't block on it landing in common18:27
jgriffanotherjess: exactly18:27
rnirmalyeah it's a nice to have at this point18:27
vladimir3panotherjesse: makes sense18:27
jgriffI think nova will be striving for the same thing as well during Folsom18:27
jgriffDoes anybody see any glaring holes or things we didn't think of?18:28
anotherjessegoal: (in a user story):  a user can use python-cinderclient to create a volume, and get the iscsi attach info, then manually attach to their system (this assumes networks are accessible), then store things, dettach, move it to another server and see the info written in the first server, then detach and delete18:28
*** novas0x2a|laptop has quit IRC18:29
rnirmal+118:29
jgriffanotherjess: I plan to write something like that up and post on the wiki...18:29
jgriff+118:29
vladimir3p+118:29
jgriffAlso break it out and have stories per Folsom milestones18:30
jgriffdoes that seem worthwhile/useful?18:30
vladimir3pif I understand correctly this user story - the main functionality here is create/expose/delete.18:31
DuncanTDefinitely. Helps have everybody pulling in a similar direction18:31
*** rohitk has quit IRC18:31
vladimir3pthe entier attach/detach is kind of optional metadata update within cinder18:31
anotherjessevladimir3p: create / use outside nova / delete18:31
*** zinux has quit IRC18:32
vladimir3panotherjesse: use outside nova == any host with iSCSI init18:32
anotherjesse#action also to vladimir3p's point we should create a blueprint about openstack common - and start creating child blueprints for subcomponents - a blueprint for scheduler, a blueprint for service.py, ...18:32
anotherjessevladimir3p: yep18:32
rnirmalanotherjesse: that should be in openstack-common right?18:32
rnirmalthe blueprints.. cos it pertains to nova too18:32
anotherjessewe can move blueprints around, and they can point to things in other projects18:33
anotherjessethe important thing is to start writing them ;)18:33
anotherjessegiven that we deleted ~100k lines in nova to make cinder, it might be easier for us to look at things in cinder repo and see what shouldn't be there.18:34
rnirmalok cool.. there's one for rpc already.. we'll just have to get the other ones out18:34
anotherjesserootwrap - https://github.com/openstack/cinder/tree/master/cinder/rootwrap18:34
anotherjesse...18:34
*** novas0x2a|laptop has joined #openstack-meeting18:35
rnirmalrpc, notifier, some more of the wsgi and extensions functionality, not sure how much of that is in common already18:35
*** dhellmann has quit IRC18:36
*** dwcramer has joined #openstack-meeting18:36
jgriffrnirmal: probably about half I believe18:38
*** dhellmann has joined #openstack-meeting18:38
rnirmalk18:38
jgriffalright, no reason to keep people hanging around for nothing....18:39
jgriffrnirmal: I know you started working on some things, antyhing you want to go on record with right now?18:39
rnirmalwell I just have that one commit I need to make18:39
jgriffok18:40
rnirmalthat removes the compute/versions stuff from the api... added the missing pieces into the volume api code18:40
rnirmalI'll just open a bug for it and submit it.. easier to do it that way for me18:40
jgriff#action rnirmal submit his compute tear out and api work18:40
rnirmaljgriff: do we have jenkins setup to run the unit tests to gate commits?18:41
jgriffrnirmal: yes18:42
rnirmalthanks to mtaylor for the infra setup18:42
jgriffrnirmal: Yes, big thanks to mtaylor as well as jeblair !!!18:43
mtaylorall thanks should really go to jeblair - I'm just here to sign his paycheck...18:43
mtaylor:)18:43
jgriffOk, going forward:18:44
jgriffKeep an eye on the etherpad for updates over the next few days18:44
jgriffKeep an eye open for reviews needed in gerrit18:45
jgriffFeel free to use email: [Openstack][Cinder] in the subject line18:45
jgriffIf you want to pick something up let folks know either IRC or ehterpad or both18:45
jgriff(preferrably both)18:46
jgriffAnybody have anything else?18:46
jgriffalrighty.. thanks everyone, and HUGE thanks to anotherjesse vishy mtaylor and jeblair18:47
jgriff#endmeeting18:47
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"18:47
openstackMeeting ended Thu May  3 18:47:55 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:47
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-18.00.html18:47
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-18.00.txt18:47
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-18.00.log.html18:48
jgriffand comcast for not embarassing me again this week :)18:48
rnirmaljgriff: you made it this week18:48
jgriff:)18:49
jgriffThat was just awful!!18:49
*** whitt has quit IRC18:50
*** pimpministerp has quit IRC18:50
*** pimpministerp has joined #openstack-meeting18:51
*** renuka has quit IRC18:51
*** pimpministerp has quit IRC18:51
*** novas0x2a|laptop has quit IRC18:51
*** pimpministerp has joined #openstack-meeting18:51
*** novas0x2a|laptop has joined #openstack-meeting18:51
*** dachary has joined #openstack-meeting18:54
*** dprince has quit IRC19:02
*** adjohn has quit IRC19:03
*** s0mik has quit IRC19:05
*** s0mik has joined #openstack-meeting19:07
*** cdub has quit IRC19:13
*** cdub has joined #openstack-meeting19:13
*** rkukura has quit IRC19:16
*** ayoung has joined #openstack-meeting19:21
*** ayoung has quit IRC19:23
*** ayoung has joined #openstack-meeting19:23
*** anderstj_ has joined #openstack-meeting19:27
*** anderstj has quit IRC19:30
*** anderstj has joined #openstack-meeting19:33
*** anderstj_ has quit IRC19:36
*** cdub has quit IRC19:38
*** cdub has joined #openstack-meeting19:40
*** milner has quit IRC19:56
*** rnirmal_ has joined #openstack-meeting20:04
*** mikeyp has joined #openstack-meeting20:05
*** rnirmal has quit IRC20:05
*** rnirmal_ is now known as rnirmal20:05
*** n0ano has joined #openstack-meeting20:06
n0anoanyone here for the orchestration meeting?20:07
* mikeyp is present 20:07
n0anolet20:07
n0anolets's see if yun or sriram make it before we start20:08
mikeypsounds good - my should probably announce on the main list in future.20:09
*** patelna has joined #openstack-meeting20:11
*** patelna has quit IRC20:16
*** adjohn has joined #openstack-meeting20:23
*** rkukura has joined #openstack-meeting20:27
*** jlebrijo has quit IRC20:33
mikeypn0ano: suspect nobody will show20:40
*** pimpministerp has quit IRC20:50
*** pimpministerp has joined #openstack-meeting20:54
*** shang has joined #openstack-meeting20:58
*** ttrifonov is now known as ttrifonov_zZzz21:00
*** rnirmal has quit IRC21:00
*** cdub has quit IRC21:06
*** cdub has joined #openstack-meeting21:08
*** ayoung has quit IRC21:15
*** dendro-afk is now known as dendrobates21:18
*** martine has quit IRC21:18
*** anderstj has quit IRC21:22
*** dwcramer has quit IRC21:30
*** shang has quit IRC21:34
n0anomikeyp, oh well, next week (I didn't have anything myself)21:44
*** dtroyer is now known as dtroyer_zzz21:47
*** oubiwann1 has quit IRC21:50
*** ryanpetrello has quit IRC21:53
*** markmcclain has quit IRC21:53
*** dhellmann has quit IRC21:55
*** dtroyer_zzz is now known as dtroyer21:58
*** rnirmal has joined #openstack-meeting22:00
*** mattray has joined #openstack-meeting22:01
*** mnewby has quit IRC22:07
*** ywu has joined #openstack-meeting22:09
*** mnewby has joined #openstack-meeting22:09
*** dtroyer is now known as dtroyer_zzz22:15
*** Gordonz has quit IRC22:17
*** blamar has quit IRC22:21
*** shang has joined #openstack-meeting22:30
*** littleidea has quit IRC22:31
*** littleidea has joined #openstack-meeting22:41
*** adjohn has quit IRC22:47
*** adjohn has joined #openstack-meeting22:48
*** AlanClark has quit IRC22:52
*** mattray has quit IRC22:59
*** gyee has quit IRC23:04
*** edygarcia has quit IRC23:07
*** adjohn has quit IRC23:07
*** blamar has joined #openstack-meeting23:07
*** adjohn has joined #openstack-meeting23:07
*** sandywalsh_ has joined #openstack-meeting23:08
*** sandywalsh has quit IRC23:09
*** _adjohn has joined #openstack-meeting23:10
*** dachary has quit IRC23:14
*** adjohn has quit IRC23:14
*** _adjohn is now known as adjohn23:14
*** mikeyp has left #openstack-meeting23:18
*** tong has quit IRC23:28
*** blamar has quit IRC23:29
*** littleidea has quit IRC23:33
*** dwcramer has joined #openstack-meeting23:38
*** littleidea has joined #openstack-meeting23:48
*** dhellmann has joined #openstack-meeting23:48
*** vladimir3p has quit IRC23:49
*** ryanpetrello has joined #openstack-meeting23:56
*** dhellmann has quit IRC23:56
*** blamar has joined #openstack-meeting23:56
*** dhellmann has joined #openstack-meeting23:57
*** jgriff has quit IRC23:57
*** oubiwann1 has joined #openstack-meeting23:58
*** ayoung has joined #openstack-meeting23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!