Tuesday, 2012-05-15

*** joearnold has quit IRC00:16
*** jgriffith has quit IRC00:17
*** rafaduran has quit IRC00:22
*** dtroyer is now known as dtroyer_zzz00:42
*** jakedahn is now known as jakedahn_zz00:52
*** ryanpetr_ has joined #openstack-meeting00:52
*** ryanpetrello has quit IRC00:54
*** shang has joined #openstack-meeting01:13
*** reed has quit IRC01:23
*** dolphm has quit IRC01:34
*** dolphm has joined #openstack-meeting01:35
*** edygarcia has joined #openstack-meeting01:37
*** jdurgin has quit IRC01:43
*** heckj has quit IRC01:46
*** torgomatic has quit IRC01:53
*** ryanpetr_ has quit IRC02:18
*** dwcramer has quit IRC02:35
*** mnewby has quit IRC02:43
*** sandywalsh has quit IRC02:45
*** dwcramer has joined #openstack-meeting02:48
*** novas0x2a|laptop has quit IRC02:50
*** dtroyer_zzz is now known as dtroyer02:54
*** dolphm has quit IRC03:02
*** mnewby has joined #openstack-meeting03:07
*** jakedahn_zz is now known as jakedahn03:25
*** littleidea has quit IRC03:26
*** littleidea has joined #openstack-meeting03:28
*** edygarcia has quit IRC03:31
*** dwcramer has quit IRC03:40
*** garyk has quit IRC03:42
*** ywu has quit IRC03:46
*** joearnold has joined #openstack-meeting03:47
*** joearnold has quit IRC03:53
*** anderstj has joined #openstack-meeting04:01
*** gyee has quit IRC04:12
*** joearnold has joined #openstack-meeting04:16
*** sleepsonzzz is now known as sleepsonthefloor04:25
*** reed has joined #openstack-meeting04:34
*** garyk has joined #openstack-meeting04:34
*** dtroyer is now known as dtroyer_zzz04:40
*** joearnold has quit IRC04:43
*** wabat has quit IRC04:53
*** wabat has joined #openstack-meeting04:54
*** littleidea has quit IRC04:57
*** adjohn has quit IRC05:06
*** dragondm has quit IRC05:17
*** reed has quit IRC05:18
*** dragondm has joined #openstack-meeting05:18
*** reed has joined #openstack-meeting05:18
*** jeblair has quit IRC05:19
*** jeblair has joined #openstack-meeting05:19
*** paul_ has joined #openstack-meeting05:30
*** paul_ has left #openstack-meeting05:30
*** joearnold has joined #openstack-meeting05:31
*** anderstj has quit IRC05:57
*** joearnold has quit IRC05:58
*** adjohn has joined #openstack-meeting06:02
*** adjohn has quit IRC06:03
*** sleepsonthefloor is now known as sleepsonzzz06:09
*** GheRivero has joined #openstack-meeting06:10
*** ttrifonov_zZzz is now known as ttrifonov06:17
*** joearnold has joined #openstack-meeting06:19
*** mnewby has quit IRC06:25
*** joearnold has quit IRC06:26
*** mnewby has joined #openstack-meeting06:27
*** jakedahn is now known as jakedahn_zz06:30
*** mikal has quit IRC06:36
*** torgomatic has joined #openstack-meeting06:59
*** mikal has joined #openstack-meeting07:01
*** Razique has joined #openstack-meeting07:30
*** derekh has joined #openstack-meeting08:02
*** darraghb has joined #openstack-meeting08:47
*** d_theodor has joined #openstack-meeting09:21
*** d_theodor has quit IRC09:24
*** dtheodor has joined #openstack-meeting09:27
*** GheRivero has quit IRC09:35
*** GheRivero has joined #openstack-meeting09:49
*** shang has quit IRC09:59
*** shang has joined #openstack-meeting09:59
*** davidkranz_ has joined #openstack-meeting11:23
*** davidkranz has quit IRC11:23
*** davidkranz_ has quit IRC11:33
*** davidkranz has joined #openstack-meeting11:38
*** davidkranz_ has joined #openstack-meeting11:40
*** davidkranz has quit IRC11:40
*** dolphm has joined #openstack-meeting11:40
*** dolphm has quit IRC11:40
*** dwcramer has joined #openstack-meeting11:47
*** dendro-afk is now known as dendrobates11:51
*** dhellmann_ has joined #openstack-meeting11:51
*** dhellmann_ has quit IRC11:52
*** dhellmann has quit IRC11:55
*** dolphm has joined #openstack-meeting12:00
*** hggdh has quit IRC12:03
*** sandywalsh has joined #openstack-meeting12:12
*** hggdh has joined #openstack-meeting12:19
*** dwcramer has quit IRC12:27
*** dendrobates is now known as dendro-afk12:29
*** dprince has joined #openstack-meeting12:49
*** GheRivero has quit IRC12:54
*** GheAway has joined #openstack-meeting12:55
*** dendro-afk is now known as dendrobates13:00
*** AlanClark has joined #openstack-meeting13:00
*** ryanpetrello has joined #openstack-meeting13:12
*** ryanpetrello has quit IRC13:12
*** dendrobates is now known as dendro-afk13:16
*** markmcclain has quit IRC13:16
*** rachmtl has joined #openstack-meeting13:18
*** joesavak has joined #openstack-meeting13:23
*** dwcramer has joined #openstack-meeting13:26
*** dolphm has quit IRC13:26
*** dolphm has joined #openstack-meeting13:27
*** dtroyer_zzz is now known as dtroyer13:27
*** blamar has joined #openstack-meeting13:27
*** ayoung has joined #openstack-meeting13:28
*** dolphm_ has joined #openstack-meeting13:29
*** dtheodor has quit IRC13:31
*** dolphm has quit IRC13:31
*** littleidea has joined #openstack-meeting13:33
*** sandywalsh_ has joined #openstack-meeting13:36
*** sandywalsh has quit IRC13:37
*** dhellmann has joined #openstack-meeting13:40
*** GheRivero has joined #openstack-meeting13:44
*** rafaduran has joined #openstack-meeting13:54
*** sleepsonzzz is now known as sleepsonthefloor13:55
*** markmcclain has joined #openstack-meeting14:00
*** rkukura has joined #openstack-meeting14:02
*** dolphm_ has quit IRC14:03
*** edygarcia has joined #openstack-meeting14:04
*** jgriffith has joined #openstack-meeting14:13
*** ryanpetrello has joined #openstack-meeting14:15
*** rnirmal has joined #openstack-meeting14:23
*** rohitk has joined #openstack-meeting14:25
*** oubiwann1 has joined #openstack-meeting14:28
*** dtroyer is now known as dtroyer_zzz14:30
*** rohitk has quit IRC14:33
*** rohitk has joined #openstack-meeting14:34
*** Gordonz has joined #openstack-meeting14:42
*** Gordonz has quit IRC14:44
*** Gordonz has joined #openstack-meeting14:44
*** sleepsonthefloor is now known as sleepsonzzz14:47
*** Gordonz has quit IRC14:48
*** Gordonz has joined #openstack-meeting14:58
*** anderstj has joined #openstack-meeting15:00
*** anderstj has quit IRC15:01
*** reed has quit IRC15:08
*** rnirmal has quit IRC15:09
*** littleidea has quit IRC15:14
*** oubiwann1 has quit IRC15:16
*** dhellmann has quit IRC15:17
*** heckj has joined #openstack-meeting15:17
*** markmcclain has quit IRC15:19
*** ryanpetrello has quit IRC15:19
*** dolphm has joined #openstack-meeting15:20
*** rnirmal has joined #openstack-meeting15:21
*** dolphm has quit IRC15:24
*** rohitk has quit IRC15:31
*** Razique has quit IRC15:37
*** jsavak has joined #openstack-meeting15:39
*** joesavak has quit IRC15:41
*** Daviey has quit IRC15:41
*** Daviey has joined #openstack-meeting15:43
*** dolphm has joined #openstack-meeting15:52
*** littleidea has joined #openstack-meeting15:54
*** garyk has quit IRC15:54
*** mdomsch has joined #openstack-meeting15:58
*** reed has joined #openstack-meeting16:00
*** reed_ has joined #openstack-meeting16:01
*** reed has quit IRC16:04
*** shang has quit IRC16:07
*** mnewby has quit IRC16:07
*** byeager has quit IRC16:07
*** sleepson- has quit IRC16:07
*** anotherjesse has quit IRC16:07
*** mnewby has joined #openstack-meeting16:07
*** anotherjesse_zz has joined #openstack-meeting16:08
*** anotherjesse_zz is now known as anotherjesse16:08
*** shang has joined #openstack-meeting16:12
*** byeager has joined #openstack-meeting16:12
*** sleepson- has joined #openstack-meeting16:12
*** sleepsonzzz is now known as sleepsonthefloor16:16
*** garyk has joined #openstack-meeting16:21
*** jakedahn_zz is now known as jakedahn16:23
*** dtroyer_zzz is now known as dtroyer16:25
*** ryanpetrello has joined #openstack-meeting16:40
*** oubiwann1 has joined #openstack-meeting16:40
*** dhellmann has joined #openstack-meeting16:41
*** AlanClark has quit IRC16:42
*** markmcclain has joined #openstack-meeting16:42
*** anderstj_ has joined #openstack-meeting16:44
*** AlanClark has joined #openstack-meeting16:46
*** jsavak has quit IRC16:49
*** joesavak has joined #openstack-meeting16:49
*** rnirmal has quit IRC16:50
*** joearnold has joined #openstack-meeting16:50
*** rnirmal has joined #openstack-meeting16:51
*** reed_ has quit IRC17:01
*** reed has joined #openstack-meeting17:02
*** derekh has quit IRC17:02
*** bcwaldon has joined #openstack-meeting17:06
*** jdurgin has joined #openstack-meeting17:10
*** darraghb has quit IRC17:17
*** gyee has joined #openstack-meeting17:20
*** mnewby has quit IRC17:24
*** markmcclain has quit IRC17:25
*** markmcclain has joined #openstack-meeting17:28
*** vladimir3p has joined #openstack-meeting17:32
*** GheRivero has quit IRC17:34
*** dhellmann has quit IRC17:53
*** oubiwann1 has quit IRC17:53
*** jog0 has joined #openstack-meeting17:55
*** dhellmann has joined #openstack-meeting17:55
*** kevin-lewis-9 has joined #openstack-meeting17:55
*** jakedahn is now known as jakedahn_zz17:57
*** reed has quit IRC17:57
heckjtesting, 1.2.3...17:58
openstackMeeting started Tue May 15 17:58:37 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.17:58
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:58
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"17:58
openstackMeeting ended Tue May 15 17:58:43 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:58
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-17.58.html17:58
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-17.58.txt17:58
*** mnewby has joined #openstack-meeting17:58
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-17.58.log.html17:58
*** zul has quit IRC17:59
heckjhere for the keystone meeting? 0/18:00
*** zul has joined #openstack-meeting18:00
openstackMeeting started Tue May 15 18:02:26 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.18:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:02
*** lcheng has joined #openstack-meeting18:02
heckjBig topic for today: rafaduran discussing https://bugs.launchpad.net/keystone/+bug/963098 and related blueprint18:02
uvirtbotLaunchpad bug 963098 in keystone "Keystone isn't acting on consecutive failed logins" [High,Triaged]18:02
heckj#topic  https://bugs.launchpad.net/keystone/+bug/96309818:03
*** openstack changes topic to "https://bugs.launchpad.net/keystone/+bug/963098"18:03
*** ryanpetrello has quit IRC18:03
heckjwhy don't we start there - rafaduran, you good with that?18:03
rafaduranno problem18:03
*** ryanpetrello has joined #openstack-meeting18:03
*** Haneef has joined #openstack-meeting18:03
rafaduranas bug https://bugs.launchpad.net/keystone/+bug/963098 reported keystone is not acting on consecutive login fails18:04
uvirtbotLaunchpad bug 963098 in keystone "Keystone isn't acting on consecutive failed logins" [High,Triaged]18:04
*** liemmn has joined #openstack-meeting18:04
rafaduranhowever I think the real problem is that keyhstone is no acting on any suspicious activity18:04
rafaduranthus I've registered a blueprint for that https://blueprints.launchpad.net/keystone/+spec/improve-keystone-security18:04
rafaduranthat show how I think keyston should manage this situation18:05
heckj#link https://blueprints.launchpad.net/keystone/+spec/improve-keystone-security18:05
rafaduranthere is also a working draft for this https://review.openstack.org/#/c/7239/18:05
ayoungrafaduran, think that link is wrong18:06
rafaduranayoung: which one?18:06
ayoung https://review.openstack.org/#/c/7239/18:06
ayoungI'm getting a 40418:06
joesavak404 on that18:06
heckjhttps://review.openstack.org/#/c/7239/ is returning a "NotFound"18:06
rafadurannot for me18:07
ayoungIts too secure18:07
ayoungrafaduran, is it draft only?18:07
rafaduranayoung: yes18:07
ayoungI think you need to publish or perish18:07
rafaduranis working now?18:08
*** devananda has joined #openstack-meeting18:08
joesavakso experation, tolerance, etc are global configs?18:08
ayoung#link  https://review.openstack.org/#/c/7239/18:08
clarkbyou can also add specific people to drafts (if you still want to keep it mostly secret)18:08
rafaduranjoesavak: no they are specific for a middleware that send emails on 401 errors18:09
rafaduranjoesavak: that middleware is just an example but it also solves original bug18:10
dolphmi assume this all should be disabled out of the box?18:10
rafadurandoesn't matter18:11
ayoungdolphm, I think that the middle ware must be explicitly added to the pipeline in order to work18:12
ayoungbut by default it would be left out?18:12
rafaduranIf you think if should be disabled by default i can disable in etc/keystone.conf.sample18:12
rafaduranif everything looks good I will add some tests and updated docs how to enable it18:13
ayoungrafaduran, so is it "all or nothing"?18:13
ayoungOr can you turn on a limited subset of Functionaliry18:13
rafaduranthe backends are not activate unless a middleware use them18:14
dolphmshould be removed from the pipeline out of the box; doc'd as to how to enable it; most config should be commented out with assumed defaults in case it remains commented out; 'admin_emails' needs to be renamed, as 'admin' is very overloaded and the existing usage doesn't apply here18:14
rafadurandolphm: ok18:15
dolphmnot clear on what the 'secinfo' table is storing -- is it a log in sql?18:16
rafadurannot it stores information about requests/responses, so a middleware can query later and thus track suspicious activity18:17
joesavakid, response code, request mothod, path, date, response body - look like it's an audit trail18:17
*** jaypipes has quit IRC18:17
joesavaknot sure what "extra" is. Just a col to store notes?18:17
dolphmrafaduran: it doens't appear to store statistics, are they computed per request then?18:17
rafadurandolphm: yes, e.g: the MailConsecutive401 middleware store information if response is 401 and then query the 401 in a certain period18:19
rafadurandolphm: then if 401 errors are greater than a given number (tolerance) it will send an email18:19
joesavak+1 - i like it18:21
dolphmso the 'security' driver implements a queryable request/response log; the middleware provides email-based alerts (but doesn't actually throttle, right?)18:22
joesavakright - not acting as repose or a rate-limit. Just notificaiton. Back-end could be atom-hopper18:22
rafaduranthe rate limit would be the second part18:23
zykes-uhm, vishy still getting: /usr/bin/qemu-system-x86_64 -S -M pc-1.0 -no-kvm -m 4096 -smp18:23
rafaduranbut as I mentioned at bp ayoung at last meeting said that it probably conflict http work18:23
vishyzykes-: this is the meeting room18:23
heckjzykes-: wrong channel… :-)18:23
dolphmzykes-: wrong channel?18:23
joesavakraf - you may want to look at http://openrepose.org/ for rate-limiting18:23
rafaduranso I don't work on that after httpd work is done18:23
zykes-ah, wrong chan :)18:23
ayoungrafaduran, maybe,  but also seems like you could use either.18:24
ayoungIt might be possible to Rate limit this way18:24
rafaduranayoung: you mean using middlewares?18:25
ayoungif each request is handled by a separate process...it would need to be dealt with at the HTTPD level18:25
ayoungso I think, while this might  function OK, it wouldn't actually protect against a DOS or  cracking attempt...18:26
ayoungunless it hits a DB table each time?18:26
*** arunkant has joined #openstack-meeting18:26
rafaduranyes it queries DB for each request if response is 40118:26
ayoungI like the idea of using middlewares for it.  I think it will work ok then against the cracking attempt,  just not against a DOS18:27
ayoungbut that is still better than nothing18:27
ayoungby a long shot18:27
dolphmrafaduran: if the response is 401, isn't it too late to rate limit?18:27
dolphmthe dos has already succeeded at that point18:27
rafadurandolphm: as I said right now I'm not doing rate limiting, just reporting18:28
joesavakrate limiting should be split outside of keystone, imo18:29
dolphm'security' is probably too broad of a driver name, then... it's really just very specific monitoring18:29
liemmnI think this will increase the network chattiness for the middleware quite a bit... When I think of rate limiting, it is better done at the server, like a rest proxy.  Why can't we configure the server to optionally send notification, rather than involving the middleware?18:29
dolphmi.e. there's no additional security18:29
rafadurandolphm: I like monitoring18:29
dolphmrafaduran: very specific monitoring18:29
dolphmliemmn: +118:30
rafaduranliemmm: I think the idea is keystone itself can handle it, but of course you can provide same thing using others approachs18:31
dolphmheckj: thoughts18:32
liemmnI am just concerned that we need to keep the middleware "lean and mean"...  A lot of token (and later signature) validation is going through it already...18:32
*** novas0x2a|laptop has joined #openstack-meeting18:32
heckjI think having an optional middleware that does ratelimiting is just fine18:32
heckjIf we also want to enable some simple audit&report mechanism, then I think that might be best as a separate middleware18:33
joesavakfyi - rackspace developed this and made rate-limting configurable through a couple API calls. I can share some doc on that if it would help.18:33
heckjper liemmn comment's we want to be very careful about keeping the /token API piece performance18:33
dolphmheckj: that's what this is - audit & reporting via email18:33
liemmnAudt trails have to be secure... It's easier to secure it on the keystone server than on a bunch of service nodes... (IMO)18:34
joesavakliemn - +1 - especially since you're putting in the path which could include tokens18:34
dolphmliemmn: referring to the 'secinfo' table as the audit trail?18:34
ayoungheckj, that is why the PKI Blueprint...the fastest code is that which doesn't have to run....18:36
liemmnno... I think that is not the audit trail right?  That's just for checking the rate of failure....  If we want to implement audit trails, I am just saying it should be done on the server side.18:36
heckjayoung: word18:37
dolphmayoung: i'm a fan :)18:37
liemmnNOOP is the fastest :)18:37
liemmnand bug-free18:38
ayoungI updated the PKI Blueprint to make it clearer.  I can talk through it if anyone wants18:38
dolphmliemmn: noop takes a cycle :P18:38
*** matwood has joined #openstack-meeting18:38
ayoungif we are done with rafaduran 's code?18:38
dolphmayoung: yeah, we can carry that into code review18:38
liemmndolphm:  I am talking about code ;)18:38
heckjrafaduran: did you get the feedback you were after?18:38
rafaduranI think so, the reporting seems is not going to work18:39
rafaduranbut then we are not addressing the original bug18:39
dolphmrafaduran: cite the bug in your commit msg, and clean up the Change-Id's plz18:40
dolphmi didn't even know this was for a bug18:40
rafaduran#link https://bugs.launchpad.net/keystone/+bug/96309818:40
uvirtbotLaunchpad bug 963098 in keystone "Keystone isn't acting on consecutive failed logins" [High,Triaged]18:40
*** lcheng has quit IRC18:40
rafaduranI've explained it at the start18:41
dolphmrafaduran: sorry, i jumped straight to the review18:41
ayoungAm I up?18:42
rafaduranI think I will re-think this and try something not using middlewares18:42
rafaduranayoung: yes18:42
*** Haneef has quit IRC18:42
ayoungOK  updated the write up here: http://wiki.openstack.org/PKI  specifically the section  "Delegation and Scaling"18:42
heckj#topic: PKI ness18:43
*** openstack changes topic to ": PKI ness"18:43
heckj#link http://wiki.openstack.org/PKI18:43
*** Shrews has joined #openstack-meeting18:43
ayoungI had to find out from some people smarter than me what the right API to use was18:43
ayoungturns out it is called CMS18:43
ayoungCrypt Message Syntax18:43
ayoungthe short of it is this18:43
ayoungwhen you get a token,  there is a part of the response that lists the tenant and roles18:44
*** lcheng has joined #openstack-meeting18:44
ayoungso  the data is something like18:44
*** Haneef has joined #openstack-meeting18:44
ayoung{user: ayoung,  tenant: coop-city,  role: hallmonitor, groundskeeper}18:44
ayoungyou then take that date and sign it by encrypting it with a private key18:45
ayoungsomeone else with the corresponding public key can decrypt it and know that it was encrypted by the private key18:45
ayoungnow this key-pair is going to be from Keystone,  thus validating the name Keystone18:46
ayoungand so  when you get a token signed like this,  something like Nova won't have to go back to Keystone in order to authenticate18:46
ayoungnow,  the expiration date needs to be in there,  and there are details about key management,  but that the TL:DR version18:47
dolphm(this is the exciting part)18:47
ayoungdolphm, sorry,  that was the exciting part.18:47
ayoungthe rest is boring details18:47
dolphmayoung: i meant nova not having to go back to keystone :)18:47
dolphmayoung: it's like magic scalability18:48
ayoungit will put a little more CPU load on the services,  but I suspect that what is saved in terms of network and SSL back to Keystone will more than make up for it18:48
dolphmayoung: cpu time is cheap18:48
ayoungIf we really are concerned about CPU time for this,  we've won...18:49
dolphmayoung: so, this all fits with the existing X-Subject-Token header, it'll just be encrypted?18:49
ayoungMy next task is to get a proof of concept working using the command line tools18:49
dolphmerr X-Auth-Token**18:49
ayoungdolphm, yes18:49
heckjayoung: with the API pieces you've found, is it possible to have multiple signers18:49
ayoungI think the X-Auth-Token will just be huge18:49
ayoungheckj, yes18:50
dolphmayoung: how much bigger than the data it contains?18:50
ayoungheckj, so say there are 3 keystone servers,  each has a different key. That needs to be part of the token18:50
ayoungdolphm, 1K18:50
*** dhellmann has quit IRC18:50
ayoungI think that is the nature of using the encryption18:50
dolphmayoung: is there a maximum length on header values?18:50
ayoungI think we are OK.  I'll confirm18:51
ayoungbut I've seen some that are huge18:51
dolphm(first google: http://stackoverflow.com/questions/686217/maximum-on-http-header-values )18:51
heckjayoung: I believe you're OK, and the token as it stands today is already a string (albiet much smaller). It makes a nice add-on extra-fit18:51
ayoungdolphm, to answer your question "the HTTP spec does not define a limit, however many servers do by default. This means, practically speaking, the lower limit is 8K."18:52
ayoungheckj, yes.  The idea is that we should be able to switch out Keystone first, and then the rest.  However, I don't know if /tokens/{id} will allow the super long ones either....18:52
ayoungbut if we go with the scheme that token auth is in the page as opposed the URL we should be OK18:53
ayoungand having tokens in the URL is problematic for other reasons already stated18:53
*** oubiwann1 has joined #openstack-meeting18:53
heckjayoung: yp, with ya18:53
*** liemmn has quit IRC18:53
*** dhellmann has joined #openstack-meeting18:54
dolphmheckj: does this have potential to be core for v3?18:54
heckjdolphm: absolutely18:54
dolphmheckj: that would be awesome if we can do it18:54
*** liemmn has joined #openstack-meeting18:55
ayoungdolphm, I'll try to have a demo for next week,  totally hand jammed,  but should show the flow18:55
heckjayoung: that would be excellent18:55
heckjWe've got 5 minutes left. Any more questions or feedback for ayoung?18:56
*** sdague_ has joined #openstack-meeting18:56
ayoungI'd like to use python-nss as the Crypto library,  and it will need to have the CMS API added to it.  CMS is in the native.  Fortunatly,  I've talked with the maintainer and he is more than willing to add it.18:56
*** sdague has quit IRC18:56
heckj#topic open discussion18:57
*** openstack changes topic to "open discussion"18:57
rafaduranI've have some patches that need review again...18:57
heckjAdministrative bits - there's quite a number of reviews pending for Keystone, with lots of new/good work. Please go take a look and put in your thoughts on the code and such18:57
rafaduran#link https://review.openstack.org/#/c/6425/18:57
rafaduran#link https://review.openstack.org/#/c/7127/18:58
heckj#link https://review.openstack.org/#/q/status:open+keystone,n,z18:58
heckjI'm a bit behind on bug triage, but will be going through it this week as well18:58
heckjAnd… that's it for this week!19:00
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"19:00
openstackMeeting ended Tue May 15 19:00:13 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-18.02.html19:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-18.02.txt19:00
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-18.02.log.html19:00
*** novas0x2a|laptop has quit IRC19:01
mtaylorwho wants to talk about CI???19:01
heckjthanks all!19:01
*** rnirmal has quit IRC19:01
openstackMeeting started Tue May 15 19:01:14 2012 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.19:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:01
clarkber o/19:01
mtaylor#topic gerrit trigger plugin19:01
*** openstack changes topic to "gerrit trigger plugin"19:01
mtaylorjeblair: you go19:01
jeblairthat looks exactly like a person scratching their head19:01
mtaylorwhat's up?19:01
jeblairo?  <- gerrit trigger plugin makes jim scratch his head a lot19:02
*** novas0x2a|laptop has joined #openstack-meeting19:02
jeblairour current changes have been merged upstream19:02
jeblairdarragh points out that a few things may have been missed, but i'm sure they can be fixed with small patches19:02
mtaylorcool. does that mean we can close out https://bugs.launchpad.net/bugs/90337519:02
uvirtbotLaunchpad bug 903375 in openstack-ci "Finish and install new Gerrit Trigger Plugin" [High,Fix committed]19:02
sorenWhat were these changes?19:02
sorenToo many to enumerate?19:03
jeblairi'm working on speculative execution, which will let us test lots of changes in parallel and merge them in series, maintaining our current behavior of testing patches "as they will be merged", but parallelizing the process for speed19:03
jeblairmtaylor: i think so19:03
mtaylorjeblair: awesome19:03
jeblairsoren: we added support for triggering on comment-added and ref-updated events19:04
jeblaircomment-added is what we use to trigger testing and merging on APRV+1 votes19:04
jeblairref-updated we use for building tarballs, etc, when changes land19:04
sorenjeblair: Neat. I was just sweating at the Gerrit trigger plugin a couple of hours ago for not supporting that.19:04
mtaylorsoren: you should use ours19:05
jeblairwe have a jenkins job that builds ours and has the hpi as an artifact19:05
mtaylorLinuxJedi: your changes to the docs for that don't seem to have made it to ci.openstack.org19:05
jeblairso whatever crazynees we're working on is available pre-built19:05
LinuxJedimtaylor: awesome, something to look at19:05
mtaylorsoren: https://jenkins.openstack.org/view/All/job/gerrit-trigger-plugin-package19:06
jeblairso, immediate future work for me: continue working on spec-ex, fixing upstream merge problems as i go, and roll that out to openstack19:06
mtaylorsoren: https://jenkins.openstack.org/view/All/job/gerrit-trigger-plugin-package/lastSuccessfulBuild/artifact/gerrithudsontrigger/target/gerrit-trigger.hpi19:06
mtaylorjeblair: sounds fantastic. you are enjoying java threading I take it?19:07
mtaylorLinuxJedi: AH - I know why...19:08
jeblairi'm hoping that the spec-ex patch will be pretty small, but there are a lot of events and listeners going on here, so it'll take a bit to get it just right.  :)19:08
mtaylorLinuxJedi: when I was cleaning unused stuff from openstack-ci, I removed setup.py, but we use that to build docs...19:08
mtaylorjeblair: cool19:08
LinuxJedihaha! :)19:08
*** jgriffith has quit IRC19:08
mtaylor#topic etherpad19:09
*** jgriffith has joined #openstack-meeting19:09
*** openstack changes topic to "etherpad"19:09
mtaylorclarkb: how's tricks?19:09
*** pcrews has joined #openstack-meeting19:09
clarkbI think linuxjedi merged the puppet module today19:09
mtaylorI believe you are right19:09
LinuxJediI did, was I not supposed to?19:10
mtaylornope, that's great19:10
clarkbthere are a couple extra things that I hsould eventually fix in that module, but for now you get everything but ssl certs, backups, and the json settings file (because passwords)19:10
clarkbOnce I get accounts I can spin up a box to run that on and migrate the data from the old etherpad to the new19:11
mtaylorclarkb: LinuxJedi would be more than happy to spin you up a machine :)19:12
clarkbI suppose I should also document this which has not been done.19:12
mtaylorclarkb: we have an openstackci account at rackspace that we use for important servers19:12
LinuxJedisure thing19:12
mtaylorspeaking of ... we should probably delete some old servers from the openstack account19:12
* LinuxJedi makes a note...19:12
clarkbthat works for me too19:12
*** liemmn has quit IRC19:13
mtaylorbut yeah - docs would probably be splendid. :)19:13
LinuxJedimtaylor: there is a stale meetbot server that can die19:13
mtaylorthere are several stale servers ...19:13
clarkbdocument note is on the whiteboard19:13
mtaylorShrews: you around?19:13
mtaylor#topic pypi mirror19:14
*** openstack changes topic to "pypi mirror"19:14
LinuxJedimtaylor: if you have a list of them I can clear them out19:14
Shrewspypi mirror is initialized and up and running on http://pypi.openstack.org19:14
mtaylorShrews: ++19:14
Shrewsright now, only updating once a day. may need to adjust that at some point19:14
Shrewsnow trying to figure out how to use it correctly so that we fall back to normal pypi.python.org in case there is something we are not mirroring19:15
* Shrews not 100% convinced that we ARE mirroring everything, but not sure how to verify19:15
sorenWhat makes you think we aren't?19:15
Shrewssoren: download size is around 6GB. from older posts about setting it up, i was expecting much more19:15
*** dolphm has quit IRC19:16
sorenYeah, that doesn't sound like much19:16
clarkbwill it be a public mirror at some point? or is that more trouble than its worth?19:17
mtaylorwell, I'm mostly wanting it to reduce latency and make our stuff more resilient... not so sure I care if other people get benefit from it :)19:17
*** Haneef has quit IRC19:17
mtayloralthough there's really nothing preventing its use by anyone at the moment I guess19:18
Shrewsfuture stuff: see if pygerrit is worth anything19:18
* Shrews done19:19
mtaylorexcellent ...19:19
mtaylor#topic jenkins job filer 2.019:19
*** openstack changes topic to "jenkins job filer 2.0"19:19
* LinuxJedi up?19:19
mtaylorLinuxJedi: yup19:20
LinuxJediok, so...19:20
LinuxJediafter massive complications with the puppet way of trying to create jobs in jenkins I have now re-written this in Python19:20
LinuxJediand it takes YAML scripts for job configuration parameters19:20
*** ryanpetrello has quit IRC19:20
LinuxJediand is all nice and modular and stuff19:21
mtaylorit makes me happy19:21
LinuxJediit also talks the Jenkins API so can add/modify/delete jobs without any reload/restart19:21
sorenYeah, generating config.xml from Puppet templates doesn't seem like much fun. I've been doing that a fair bit the last while.19:21
LinuxJediand logs everything in the job config history correctly and stuff19:21
sorenLinuxJedi: Sweet.19:21
mtaylorsoren: you should look at LinuxJedi's new stuff ... I think you'll like it19:22
sorenLinuxJedi: So is Puppet involved in that at all?19:22
LinuxJedisoren: yes, just to specify which projects to push live19:22
*** ryanpetrello has joined #openstack-meeting19:22
LinuxJedisoren: and it executes the python script19:22
mtaylorsoren: https://github.com/openstack/openstack-ci-puppet/tree/master/modules/jenkins_jobs19:22
LinuxJedisoren: so nothing essential19:22
*** rkukura has quit IRC19:23
sorenLinuxJedi: I'll take a look. Thanks!19:23
clarkbLinuxJedi: you wrote a new implementation of the api for it?19:23
LinuxJedinext step is to make it support batches of jobs instead of having a long YAML per-project.  I've made a start on this but it won't be finished until at least tomorrow19:23
LinuxJediclarkb: yes, I tried 4 different APIs, they all sucked19:23
LinuxJediclarkb: the only one that supported all the commands we needed didn't actually work :)19:24
LinuxJediit took me *much* longer testing those libraries than writing a new one too unfortunately19:25
*** GheRivero has joined #openstack-meeting19:25
mtaylor#topic openvz19:26
LinuxJediStackforge RedDwarf (currently disabled) and Ceilometer are using it currently19:26
*** openstack changes topic to "openvz"19:26
mtaylorLinuxJedi: anything else?19:26
mtaylordevananda: you wanna tell the nice folks how openvz support is going?19:27
LinuxJedimtaylor: nothing else on jenkins jobs right now19:28
jeblairmtaylor: is jclouds plugin far enough along to be used instead of devstack-gate on the HP internal jenkins for openvz (assuming that's the plan)?19:30
mtaylorjeblair: I do not know.19:30
mtaylorI'm going to see if I can do a unittests poc with it this week some time19:31
sorenI forget... Why do we care about openvz?19:31
mtaylorthe story so far on openvz is that we can finally build the kernel module19:31
mtaylorsoren: hp and rackspace both want nova to support it to use behind dbaas stuff ... the migrations feature I think it one of the big plusses iirc19:32
mtaylorbut we're not going to merge the patch until we can test the patch19:32
devanandamtaylor: sorry, missed the ping...19:32
mtaylorall good19:33
devanandaso, like mtaylor said, we've got a .deb package of openvz kernel that boots in ubuntu.19:34
LinuxJedidevananda: you made it work with 3.x or is it an older kernel?19:35
devanandai'll be working this week to get jenkins building and testing it (probably with significant help from jeblair)19:35
devanandaLinuxJedi: 2.6.3219:35
LinuxJediah, ok :)19:35
devanandathat's the last one supported by openvz, as far as they've said to me19:36
devanandaas far as what tests to run on it, or gating, etc, i leave to others at this point :)19:37
mtayloryeah - I think for now we're just gonna focus on being able to spin up openvz enabled machines19:37
mtayloronce we've got that, other folks can help actually drive testing and stuff19:37
*** maoy has joined #openstack-meeting19:37
mtaylor#topic open discussion19:38
*** openstack changes topic to "open discussion"19:38
mtayloranything else ?19:38
* LinuxJedi raises hand19:38
mtaylorLinuxJedi: go!19:39
LinuxJedistackforge email...19:39
LinuxJedithe stackforge gerrit server has been migrated to a different cloud account19:39
mtaylorah yes.19:39
LinuxJedithis needed to happen anyway, but was accelerated due to mail not actually sending19:39
LinuxJediabout 20 minutes ago I was finally told why that happened and that it will happen again19:39
* jeblair perks up19:40
LinuxJediso we need an action plan that will most certainly involve a relay server outside of HP Cloud19:40
LinuxJedijeblair, mtaylor: I've just emailed you the exact reason19:40
* mtaylor is so happy ...19:41
*** mrmartin has joined #openstack-meeting19:41
LinuxJediyep, I want to use pointy things because it took a week to find out this information19:41
LinuxJediand I was told it when I wasn't even looking for it19:41
mtaylorLinuxJedi: do we know what the 25 rate limit actually is?19:42
LinuxJedimtaylor: I didn't get that far, but it explains why a few cronspam were getting through19:42
LinuxJedimtaylor: lets just assume really damn low for now19:42
mtayloryeah. that's probably fair19:43
LinuxJedimtaylor: so low you will see that before PBL19:43
mtaylorjeblair: any thoughts other than just running a mail relay on rackspace?19:44
jeblairmtaylor: i don't think that's appropriate19:44
*** dwcramer has quit IRC19:44
mtaylorI don't either19:44
LinuxJediso I'm going to need to investigate this further this week19:44
mtaylorit's possible we might be able to get the rate limiting lifted on our account I believe19:44
LinuxJedias there is an implied workaround on a case-by-case basis19:44
LinuxJediwe just need to figure out who to talk to, and the guy I emailed you about is probably a good starting point19:45
LinuxJedijust wish *someone* had told me in all those mails in the last week :)19:46
*** jbryce has joined #openstack-meeting19:46
LinuxJediI can't be the only person that is going to hit this :)19:46
*** jog0 has quit IRC19:47
*** mnewby has quit IRC19:47
jeblairmtaylor: eom?19:48
mtayloryeah. I think so19:48
mtaylorthanks everybody!19:48
clarkboh I will be out friday19:48
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"19:49
openstackMeeting ended Tue May 15 19:48:59 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:49
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-19.01.html19:49
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-19.01.txt19:49
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-19.01.log.html19:49
*** Shrews has left #openstack-meeting19:50
*** pcrews has left #openstack-meeting19:50
*** lcheng has quit IRC19:52
*** jk0 has joined #openstack-meeting19:58
*** ewanmellor has joined #openstack-meeting19:58
*** dwcramer has joined #openstack-meeting19:59
anotherjessettx: -o20:00
*** danwent has joined #openstack-meeting20:00
* ewanmellor here20:00
openstackMeeting started Tue May 15 20:00:51 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
jbrycehi everyone20:01
ttxhaz quorum?20:01
jbrycenow we do20:01
jbryceone quick question coming out of last week20:02
jbrycesince we agreed on an approach concerning 3rd party APIs, has that been communicated at all to any of those working on 3rd party API patches?20:02
vishyjbryce: it has not, I will send out a message to the list outlining the options20:03
*** devcamcar_ has joined #openstack-meeting20:03
vishy(for nova)20:03
heckjnotmyname made a reference to it on the list, but nothing else has flowed out as yet20:03
notmynameI've talked to the IBM people about CDMI on swift, and swift3 compatibility extraction is currently in-progress20:03
jbryce#action vishy to send note out about 3rd party api plan20:03
jbrycevishy: thanks20:03
jbrycenotmyname: cool...those are ones i was wondering about20:04
jbryce#topic completeness of core20:04
*** openstack changes topic to "completeness of core"20:04
jbrycettx: do you want to introduce this one?20:04
ttxSure. As explained in https://lists.launchpad.net/openstack-poc/msg00513.html ...20:05
ttxAs several projects consider splitting some existing parts out, I think it's the responsibility of the PPB to make sure OpenStack Core (as a whole) remains complete and usable on its basic functionality20:05
ttxThe PPB accept projects in Core based on the features they bring, so it's fair that we watch to make sure those features don't dramatically change20:05
anotherjessettx: I know jgriffith is here to talk about the cinder aspect20:05
ttxThere are two ways to split features out. One is to split into another Core project (like Cinder)20:05
ttxThe other is to split into a non-Core project (I suspect most of the Swift splits so far belong to this category)20:06
ttxFor the first category, last week we established the rule that the project split needs to be completed by the middle of the cycle (a.k.a. folsom-2). A Core project split also needs a dedicated team/PTL to pursue development on it20:06
ttxIn order to assess if a split is a core or non-core split, I suggest that proposed splits should be acked by the PPB20:06
ttxProject teams/PTLs still get to decide what feature should be split and what feature should not...20:07
ttxBut we get to decide if a split feature is a Core feature or not. And therefore if it should be split into a Core project (with all the constraints that creates) or into an ecosystem project.20:07
ttxThoughts ?20:07
anotherjessettx: I think maybe pbb should be an oversight not an active decider20:08
ttxanotherjesse: it's sometimes hard to fix after the fact. And you may discover certain things late...20:08
anotherjessettx: for instance in nova we might want to split volumes out to cinder and be core, but split cloudpipe out to a non-core project20:08
*** mnewby has joined #openstack-meeting20:08
jbrycehow significant does a split need to be to involve people outside of the project?20:08
*** mnewby has quit IRC20:08
ttxanotherjesse: that's perfectly alright to me. I just think the decision of removing features from core does not belong solely to the project20:09
ttxsince the PPB defines what's "core"20:09
*** mnewby has joined #openstack-meeting20:09
anotherjessettx: do you have an estimate of how much are we signing up for20:09
vishyttx: i think another possibility is for features to go into another core project20:10
ttxvishy: indeed. Good point.20:10
ttxwhich would be perfectly alright if both projects agree.20:10
devcamcar_are we expecting to split anything else out in the near term?20:10
vishyI think it is a bit much to assume that we should ack everything that wants to be pulled out, but perhaps there isn't really a lot20:10
devcamcar_if not then I'd suggest treating a one off as such20:10
bcwaldonmnaser: sure, that looks right20:11
vishythere is one specific concern that started this, so lets just address the concern and move on20:11
jgriffithsorry... late20:11
heckjvishy: ++20:11
ttxas an example, swift splitting swift3 sounds sane. Swift splitting keystone auth, a bit less.20:11
vishynotmyname: we were discussing keystone middleware for swift. Were you planning on pulling it out?20:11
anotherjessea core project that doesn't speak core auth doesn't make sense...20:12
notmynamekeystone middleware was never part of swift to begin with20:12
anotherjessenotmyname: because keystone didn't exist until recently :-)20:12
devcamcar_that's crazy to suggest removing keystone middleware from swift20:12
ttxvishy: we could simply make the requirement that splits need to be announced on the ML some time before they are done... to let us intervene in case of need (oversight)20:12
vishynotmyname: so it is currently in keystone. What about the changes to the client to enable keystone?20:12
vishyttx: that seems fine20:12
devcamcar_all that does is say that swift doesn't care about the rest of the projects20:13
notmynamevishy: the swift client is being removed from swift (into a separate deliverable for the swift project)20:13
vishynotmyname: gotcha, but it is still managed by swift-core?20:13
notmynameso that it can be developed separately and require other projects to have less dependencies20:13
ttxanotherjesse: would that work for you ? Announce clearly in advance to let the PPB react if they don't like the idea ?20:13
notmynamevishy: yes20:13
vishynotmyname: I think the general concern is that if there is some part of a core projects that other projects are depending on, that we make sure it stays in core somewhere20:13
anotherjessettx: yeah, I'm not against having pbb actively involved, it just seems like it would be a lot of work that isn't needed if there is a way like you just suggested20:14
notmynamehowever, swift client libs and bins don't have anything to do with where keystone/swift middleware lives20:14
heckjkeystone/swift middleware is currently in keystone, no plans to remove it.20:14
anotherjessenotmyname: so the preference of swift-core is that keystone integration would be a drop-in - not part of the project?20:14
ttxanotherjesse: agreed. I just want to make sure we are in the loop and have the final word on those.20:14
notmynamevishy: agreed. there is no plan to remove the client lib and bin from swift-core team20:15
notmynameheckj: and swift want to keep it there too20:15
anotherjessenotmyname: why?20:15
vishynotmyname: ok cool that deals with most of my concerns then.20:15
bcwaldonsorry if I missed something, but why in the world does it make sense for keystone to own the identity api middleware that converts headers into swift-specific attrs?20:15
anotherjessebcwaldon: yeah, that seems like it belongs in swift20:16
vishynotmyname, anotherjesse: I think more important than the location of the middleware, is that we have a gating test somewhere20:16
heckjthere's dependencies both ways - glance and swift have gone "one off" in middleware auth20:16
notmynamethe swift (or any project) middleware that provides keystone integration should, IMO, live with keystone (the auth system). therefore the auth system become a contained piece that develops it's features as a whole20:16
heckjnova, keystone, and quantum are all using token_auth to add context up the pipe20:16
ttxjbryce: before we address the specific case of keystone auth in Swift... do we have agreement that core projects splits should be announced in advance to let the PPB question or oppose them if need be ?20:17
jbrycettx: was just writing the same thing = )20:18
bcwaldonnotmyname: it shouldnt live with keystone, its only used by swift, and what it does depends directly on how swift is organized20:18
ttxthat way we can solve the problem earlier next time, in case it happens again. Then we can talk about how we solve the current questionable split20:18
jbrycebefore we dive too far into specific case, does everyone feel like having major feature splits announced prior to the work being complete and giving people a chance to comment is a good idea?20:18
bcwaldonyes, so there is time to say no20:19
heckjjbryce: yes20:19
bcwaldonwhen necessary20:19
*** adjohn has joined #openstack-meeting20:19
anotherjessenotmyname: there is a middleware that keystone maintains that converts keystone auth headers to a wsgi context20:19
vishyjbryce: yup20:19
devcamcar_ttx: +120:19
anotherjessenotmyname: what swift needs inside it is a middleware that takes that wsgi context and converts it to what swift needs20:19
jbryceand my practical definition for major splits would be pulling something out that would then go into a project of its own20:19
notmynamejbryce: I'm not sure I agree with that20:19
ttxjbryce: and that the PPB is ultimately competent on Core feature content ?20:19
anotherjessenotmyname: that shouldn't live in keystone, that should be in swift and should be versioned with swift not keystone20:20
anotherjessejbryce: yes20:20
ttxjbryce: or at least completeness / basic operation needs20:20
jbrycenotmyname: do you have an alternate idea or just would prefer no prior notification?20:21
notmynamejbryce: no, separating parts of the project requiring approval by the PPB is not something I support. it's technical decisions that should live within the project20:21
*** edygarcia_ has joined #openstack-meeting20:21
bcwaldonnotmyname: not if its going to affect the ecosystem20:21
jbrycenotmyname: the proposal did not require approval just notification20:22
notmynamebcwaldon: one problem is the original problem that ttx proposed to solve is that it can't be solved. we already are relying on projects "out of our control" to provide functionality within openstack projects (all the 3rd party libraries)20:22
ttxnotmyname: but for authentication, we rely on an openstack project.20:23
ttxmaking it incomplkete would look very bizarre.20:24
jbrycesure we can't solve it for all code in the world, but for code that we have been responsible for, it seems like it's not a bad idea to do a sanity check that we are not throwing out something that is critical to openstack as a whole20:24
heckjnotmyname: the technical choices of one project need to consider the ecosystem as a whole - OpenStack Core as a viable, coordinated product20:24
*** edygarcia has quit IRC20:24
*** edygarcia_ is now known as edygarcia20:24
bcwaldonheckj: ++20:24
notmynamettx: ok, so about 10 minutes ago was the first time (recently) that keystone swift integration has been mentioned as a major problem requiring ppb oversight. I don't really feel ready to address that issue fully here (especially with the several conversations going on at once)20:25
notmynameheckj: I agree20:25
ttxnotmyname: sure, we can defer to next week20:25
anotherjessenotmyname: is the reason for making the integration be in keystone because swift doesn't want to maintain it?20:25
ttxnotmyname: I just wanted to have teyh general rule spelled out, not the particular case20:25
anotherjesseor does the swift team want to maintain integration but in a different project20:26
notmynameanotherjesse: I'm not sure I'm ready to answer that :-)20:26
ttxjbryce: maybe for this week we should just vote on the general rule ("advance announcement" and "PPB rules the completeness of core")20:26
notmynamettx: but I don't think we need a general rule. ie nobody is proposing to remove any sort of "core" functionality20:26
jbrycei'm fine with deferring on the specifics of swift until next week20:26
notmynameI don't think there is a problem that we need to have a policy about20:27
anotherjessenotmyname: the concern is that swift doesn't care about integrating with openstack auth20:27
anotherjessewhich hurts the community20:27
ttxnotmyname: I think that example proves otherwise. I don't see a drawback in saying that splits should be announced in advance to let a chance for the PPB to question it.20:28
jbrycedo other people think we should have a general standard around notification?20:28
ttxI don't really want to watch all commits for all projects and discover stuff.20:28
jgriffithjbryce: yes20:28
bcwaldonjbryce: yes20:28
anotherjessettx: agreed - if I am downstream of a project I'd like to know significant changes that are coiming20:29
heckjjbryce: yes20:29
devcamcar_jbryce: +120:29
anotherjessejbryce: +120:29
jgriffithbottom line is if there's a change that impacts other projects there has to be some notification/discussion20:29
jbryceanotherjesse: +1  and for me it's not just about the oversight of ppb, but just helping everyone be aware20:29
ttxjbryce: should be announced on the development list, yes20:30
vishyI don't see the need for more policy. I think we notice these things when they come up and i don't think any of the ptls would remove major pieces of the code without discussion/notification20:30
danwentvishy: +120:30
ttxvishy: it's not really policy, it's communication20:30
ttxlike we said that new deps should be discussed as well20:30
danwentI think we can agree that such things should be communicated… whether we need an official rule on it vs. trusting someone's common sense and good judgement is another thing.20:31
ttxlet's file that one under "obligation of communication"20:31
vishyttx: I agree that it is a good idea and should be done, I just don't see the need for an explicit policy about it.20:31
notmynamevishy: +120:31
ttxvishy: so that nobody can pretend they understood otherwise ?20:31
jbrycedanwent, vishy: i agree with you guys but it sounds like notmyname doesn't even agree with the idea?20:31
*** jakedahn_zz is now known as jakedahn20:32
notmynameI agree that communication is good. I don't think there needs to be a policy and I _really_ don't think that non-core devs should be able to approve or deny the technical decisions of the core dev team20:32
ttxvishy: I really don't want to fly to San Francisco to learn about the next one.20:32
ttxI'd like to make sure it will be on the ML20:33
vishyI would much rather solve this technically: i.e. get devstack gating in on the swift fuctionality we are depending on20:33
ttxvishy: we might miss special cases. Anything wrong with communication ?20:34
vishycurrently ec2 support depends on the swift3 middleware.  That is in core right now...20:34
*** dhellmann has quit IRC20:34
*** GheRivero has left #openstack-meeting20:34
anotherjessenotmyname: those are two different issues - whether we have a recommendation to communicate changes that affect users ----------- and whether a project has complete autonomy20:34
*** oubiwann2 has joined #openstack-meeting20:34
*** dwcramer has quit IRC20:34
vishyvishy: I think we are much more likely to miss proposed domino-effects from splits through announcements than through gating.20:34
jbryceso instead of a policy, can we just agree that there should be a general standard of communication where major feature removal is communicated to the mailing list before the change is complete?20:34
ttxvishy: I'm not asking that we have a formal PPB meeting before each proposed code split. Just that the splits are announced on the ML20:35
vishyttx: ^^20:35
*** oubiwann1 has quit IRC20:35
bcwaldonnotmyname: these aren't just technical decisions, where code lives and what projects exist arent' technical decisions solely up to swift-core20:35
*** markmcclain1 has joined #openstack-meeting20:35
*** ryanpetr_ has joined #openstack-meeting20:35
jbryceis vishy talking to himself again?20:35
vishyvishy: yup20:35
ttxvishy: checking on gating is a complement, not an alternative20:35
*** dhellmann has joined #openstack-meeting20:35
*** devcamcar_ has quit IRC20:35
ttxvishy: I'd rather discuss the issue before the change is pushed to jenkins.20:36
*** markmcclain1 has quit IRC20:36
vishyttx: if we want to officially support announcements that is fine20:36
*** arunkant has quit IRC20:36
*** markmcclain1 has joined #openstack-meeting20:36
vishyttx: I think we're trying to fix a problem that doesn't exist though20:36
ttxvishy: some PPB members follow development from some projects from quite far and might miss something that affect them.20:37
*** ryanpetrello has quit IRC20:37
*** markmcclain has quit IRC20:37
vishyttx: i agree, but the two examples we have of this so far there have been announcements already20:37
sorenvishy: After that fact.20:38
vishysoren: Oh?20:38
vishymaybe i was misinformed, I thought the announcement about the breakout of stuff was for the next release of swift (i.e. it hasn't happened yet)20:39
vishynotmyname: am I mistaken?20:39
notmynamevishy: you are correct20:40
notmynameall of the changes that we proposed were discussed extensively with the whole swift-core team, the 3rd party developers, over email, IRC,  and in person at the summit. the email that I sent was the conclusion of all of those discussions, but it was not sent after the code changes happened (some of the changes haven't happened yet)20:40
*** reed has joined #openstack-meeting20:40
vishynotmyname: ok I'm not going insane then :)20:41
*** s0mik has joined #openstack-meeting20:41
jbryceyeah, and i'm honestly not really big on trying to define yet another policy (YAP?). can we just say that it's good practice to announce big changes/splits/removals on the mailing list before they're completed?20:41
sorenSorry, my bad.20:41
vishyjbryce: +120:41
jbrycethen we can discuss on a one-off basis if someone feels like something specific is really going in the wrong direction20:41
anotherjessejbryce: and I think there is a lot of concern about keystone integration with swift20:42
ttxjbryce: I could agree with that.20:42
anotherjessefor next week :)20:42
*** dwcramer has joined #openstack-meeting20:42
vishyI think this all started because I thought that the swift/keystone middleware was in swift and it was on the list to get pulled out.20:42
jbryceanotherjesse: yes. let's get it on the agenda and talk about it specifically20:42
vishyso my bad too :)20:42
ttxjbryce: discussing it in advanace shouyld be the benefit of everyone. Prevents painful reverts20:42
jbrycenotmyname: can we talk about swift + keystone next week?20:43
notmynamejbryce: sure20:43
jbrycedo people have specific issues they'd like notmyname to address next week?20:43
ttxSo does everyone agree that we need to care about "OpenStack Core" being able to deliver basic functionality using non-ecosystem components ?20:44
jbryceor just general discussion on swift+keystone integration and maintenance of the integration code?20:44
anotherjessejbryce: what the intention is for the swift team in regard to keystone integration - active involvement? preferred deployment? assumed default?20:44
vishyttx: +120:44
ttxand that discussing splits in advance is a good thing ?20:44
vishyttx: +120:44
ttxdoesn't have to be policy, just some assertion of what we care about20:44
jbrycettx: +1 and +120:45
vishyI think that is just good community sense20:45
*** rkukura has joined #openstack-meeting20:45
jbrycei assert that i care about that = )20:45
*** maoy has quit IRC20:45
*** russellb has joined #openstack-meeting20:45
ttx(and if there is a specific issue with that, it should be raised as a topic separately)20:46
jbryceanything else on this for this week?20:47
heckjwas there anything specific we needed to talk about re: Cinder?20:47
jbryce#topic open discussion20:48
*** openstack changes topic to "open discussion"20:48
anotherjesseregarding cinder - we should write this up a little more formal but I hope that we can go down a path that results in:20:49
jbryceheckj: cinder is on a fastrack for being core in folsom if it is able to match existing nova-volume functionality by folsom-2 milestone20:49
anotherjesseshipping cinder as core in folsom, removal of nova-volume from nova20:49
heckjgood by me20:49
anotherjesseotherwise we are updating code in both places20:49
ttxheckj: that was last week discussion20:49
anotherjesseit does mean we can't do huge changes - we need to treat the code as "stable" and do incremental work20:49
ttxheckj: we'll track progress towards that at the weekly project/release meeting20:49
heckjyes, but vishy mentioned jgriffith was here to talk about Cindr - didn't know if there was another topic pending20:49
jbryceanotherjesse: we discussed that last week and agreed on doing a big health check at folsom-220:50
anotherjessejbryce: cool - was on a flight last week :-/20:50
devcamcaranotherjesse: basically if things are looking good by folsom-2 then thats how we'll proceed20:50
anotherjessedevcamcar: hawt20:50
ttxjbryce: i'll make sure to rise any red flag in advance of that milestone20:50
jgriffithheckj: Just an update for the upcoming project meeting (10 minutes)20:50
*** dwcramer has quit IRC20:50
jbryceanything else?20:50
notmynamedo we have a policy on copyright assignment?20:51
jbrycein what regard?20:51
anotherjessenotmyname: the cla doesn't require it - so we haven't been doing copyright assignment afaik20:51
jbrycewe don't require it20:51
*** dprince has quit IRC20:51
anotherjesseif someone wants to assign copyright, they are allowed to20:51
notmynamewe've had some recent submissions that are new files with copyright assigned to both the submitter and openstack llc. that seems weird to me20:52
russellbi'm betting that was not intentional.  they probably just did a copy/paste and added their name.20:52
jbrycenotmyname: i'll ask alice about it20:53
jbrycedoes seem a little strange20:53
notmynamejbryce: ok, will do20:53
anotherjessenotmyname: ianal, but the copyright holder can assign copyright - but I agree with russellb that it is probably just copy-paste of header20:53
*** mnaser has joined #openstack-meeting20:53
ttxjbryce: quite a few files in Nova are this way20:53
jbryce#action jbryce to ask Alice King about copyright assignment to OpenStack, LLC20:53
notmynamettx: that makes sense if it was an edited file, but not a new file20:53
ttxjbryce: it's definitely not required or forbidden.20:53
anotherjessenotmyname: some people start a new file by copying an existing and deleting the code leaving the header …20:54
anotherjessea guess20:54
vishyjbryce, ttx : generally that is due to multiple edits on the same file20:54
notmynamejbryce: all the RAX contributed stuff (to swift) is assigned to openstack llc20:54
ttxnotmyname: oh, you mean he probably shouldn't have assigned copyright to OpenStack LLC. Isee, and I concur20:54
notmynameie, there is no RAX copyright in any swift file20:54
jk0same for nova20:54
ttxnotmyname: but I'm pretty sure he can if he wants (IANAL, etc)20:54
jbrycenotmyname: right. i asked alice about something similar and she was concerned about people assigning new IP to OpenStack LLC without our awareness20:55
jbrycebut i'll send her an email20:55
notmynamejbryce: the question there is who is "our"20:55
jbrycenotmyname: exactly20:55
jbryce5 minutes...anything else?20:55
*** gabrielhurley has joined #openstack-meeting20:56
*** jog0 has joined #openstack-meeting20:56
*** jsavak has joined #openstack-meeting20:57
jbryceall right. thanks everyone!20:57
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"20:57
openstackMeeting ended Tue May 15 20:57:50 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:57
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-20.00.html20:57
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-20.00.txt20:57
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-20.00.log.html20:57
*** jk0 has left #openstack-meeting20:58
ttxheckj, notmyname, bcwaldon, vishy, devcamcar, danwent: still around ?21:00
bcwaldonhey hey21:00
vishyttx: here, can we do nova first today?21:00
*** jbryce has quit IRC21:00
vishyttx: I'm supposed to jump into another meeting in 1521:00
ttxvishy: Ok21:00
ttxlets' start quickly then21:00
openstackMeeting started Tue May 15 21:01:07 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:01
notmynamettx: o/21:01
*** joesavak has quit IRC21:01
ttxToday's agenda: http://wiki.openstack.org/Meetings/ProjectMeeting21:01
ttx#info We have one week left before folsom-1 milestone-proposed cut21:01
ttxso for affected projects we'll be reviewing progress against published milestone goals21:01
ttx#info General release status page is back, available at:21:01
ttx#link http://wiki.openstack.org/releasestatus/21:01
*** jsavak has quit IRC21:01
*** joesavak has joined #openstack-meeting21:02
ttxIn other news, would be good if you could let me know what you think of:21:02
ttxhttps://lists.launchpad.net/openstack/msg11678.html (the open bug triager thread)21:02
ttxif you haven't cast your opinion yet, let me know what you think21:02
*** SumitNaiksatam has joined #openstack-meeting21:02
bcwaldonttx: that release status page is awesome21:03
ttxIt existed in previous releases as well :P21:03
ttx#topic Nova status21:03
*** openstack changes topic to "Nova status"21:03
ttxvishy: hey21:03
ttx#link https://launchpad.net/nova/+milestone/folsom-121:03
ttxversioned-rpc-apis (russellb, needscodereview): was all code proposed for that ?21:04
ttxor is there more to it ?21:04
vishyI think that is all of it.  russellb ^^ ?21:04
russellbthat's all of it21:04
ttxok, cool21:04
ttxfinish-uuid-conversion (mikal, goodprogress): are we getting closer to code proposed ?21:04
russellbwell ... i haven't converted the network or volume rpc apis, actually.21:04
ttxfwiw I need to work on more gerrit/LP integration to more accurately drive the status of blueprints from commit messages21:05
ttxwhich would remove the need for most of those questions21:05
vishyrussellb: that is ok, I don't see any point in those21:05
russellbvolume because i didn't want to interfere with heavy cinder dev, and network because ... well i don't remember why.  i think i just figured that code isn't changing.21:05
russellbok cool21:06
*** edgarmagana has joined #openstack-meeting21:06
russellbthen yes, that's all of it.21:06
vishyttx: there are only two tables left to convert21:06
*** GheRivero has joined #openstack-meeting21:06
ttxok, so looking on track21:06
ttxvolume-decoupling (vishy, goodprogress): same question ?21:06
vishynot sure if mikal is here for status update21:06
*** User95 has joined #openstack-meeting21:07
*** ewanmellor has quit IRC21:07
vishyttx: there are a few items left, not sure that all of them will be done for folsom-121:07
vishyttx: they depend on having a functioning cinderclient, so probably going to defer the later items to folsom-221:07
ttxok. We'll talk about Cinder progress just after Nova21:07
ttxBack to nova folsom-1: 2 targeted bugs21:07
ttxhttps://bugs.launchpad.net/nova/+bug/990019 seems to need a new push to pass the gate21:07
uvirtbotLaunchpad bug 990019 in nova "Self links don't contain tenant id for server entity in images response" [Undecided,In progress]21:07
ttxon https://review.openstack.org/#/c/6979/21:08
ttxand https://bugs.launchpad.net/nova/+bug/966329 looks abandoned to me. jk0 ? bcwaldon ?21:08
uvirtbotLaunchpad bug 966329 in nova "RAX-specific auth in novaclient" [Low,In progress]21:08
vishyyes if he doesn't rebase in the next couple days i will rebase21:08
bcwaldonttx: I'll follow up with westmaas on that21:09
ttxbcwaldon: thx21:09
*** maoy has joined #openstack-meeting21:09
ttx#action bcwaldon to follow up on bug 966329 status21:09
uvirtbotLaunchpad bug 966329 in nova "RAX-specific auth in novaclient" [Low,In progress] https://launchpad.net/bugs/96632921:09
ttxA quick look at the general folsom plan at:21:09
ttx#link https://blueprints.launchpad.net/nova/folsom21:09
ttxvishy: Looks pretty complete to me. Should I set all the ones with undefined priorities to Low ?21:09
ttxor will you adjust them more precisely ?21:10
vishyttx: I was going to go through them21:10
vishyI haven't prioritized stuff after folsom-1 yet21:10
ttx#action vishy to adjust 'undefined' folsom bp priorities21:10
ttx2 bps are targeted but without folsom series goal: instance-type-extra-specs-extension and per-user-quotas21:11
ttxWant me to add them to folsom series goal ?21:11
vishyi think those are new ones i havent looked at yet21:12
ttx#action vishy to look at instance-type-extra-specs-extension and per-user-quotas for potential inclusion in folsom series goal21:12
ttxLast remark: In general it would be good if assignees could set the milestone where they think their folsom-goal blueprints will land.21:12
vishyok looked, will approve them21:13
ttxit's not really the PTL's job :)21:13
ttxvishy: Anything else ?21:13
ttxQuestions on Nova ?21:13
vishySo I announced last week that I'm going to clean house on blueprints21:14
vishyLast chance before I obsolete them all!21:14
ttxdo it do it do it21:14
vishy(This is reversible so if someone notices later it isn't too big of a deal)21:14
russellbNO WAIT!21:14
* vishy beheads russelb21:14
ttxjgriffith: could you give us a quick update on how Cinder is going so far ?21:15
jgriffithttx: yep21:15
jgriffithStill working mostly on decoupling efforts21:15
ttxjgriffith: should we make a proof-of-concept folsom-1 cut next week ? Or would that be totally useless ?21:15
jgriffithHopefully the last of the volume FK dependencies is removed with the bug I'm workign on now21:15
jgriffithttx: useless21:15
ttxjgriffith: even on the client side ?21:16
jgriffithttx: I'm targetting F2 for functional21:16
jgriffithttx: I could be persuaded but I don't think it's realistic21:16
* ttx is begging for more work21:16
jgriffithttx: :)21:16
ttxjgriffith: ok then :)21:16
jgriffithCurrently it's me vish and jesse21:16
jgriffithjesse has been out, but he's back in starting tomorrow21:17
jgriffithShould see some good progress in the next week but not enough to stand up I don't think21:17
jgriffithI'd like to see functional drop in by F2, that's been my goal all along21:17
*** joesavak has quit IRC21:17
ttxjgriffith: I'll use folsom-1 to check if the CI stuff is up to snuff, but won't produce tarballs.21:18
ttxjgriffith: anything more ?21:18
jgriffithttx: More than fair... good news is the CI stuff w/ exception of pythong-cinderclient should be good to go21:18
jgriffithttx: Nope, think that sums it up for now21:18
ttxBack to our regular schedule then.21:18
ttx#topic Keystone status21:19
jgriffiths/pythong/python/ :)21:19
*** openstack changes topic to "Keystone status"21:19
ttxheckj: o/21:19
ttx#link https://launchpad.net/keystone/+milestone/folsom-121:19
ttxheckj: Both blueprints now in good progress ?21:19
heckjgood progress on the V3 keystone API draft - should have it up for public review this weekend.21:19
*** MarkAtwood has joined #openstack-meeting21:19
ttxheckj: publication would complete this informational blueprint, right ?21:20
heckjThe tokenID/URI is in patches getting kicked back and forth between ayound and gyee, getting close to landing for a code review21:20
heckjttx: yes, publication will complete it21:20
ttx3 open targeted bugs... a few of them look stuck to me:21:20
uvirtbotLaunchpad bug 856887 in keystone "Keystone cannot listen on IPv6" [Medium,In progress]21:20
ttxThis one should be turned into a blueprint and probably targeted to another milestone ?21:21
*** dwcramer has joined #openstack-meeting21:21
heckjttx: yeah, it probably should. DOn't know that it'll make a f1 milestone21:21
heckjI'll do that21:22
uvirtbotLaunchpad bug 963098 in keystone "Keystone isn't acting on consecutive failed logins" [High,Triaged]21:22
ttxI think this one should be closed as FILED_AS_BLUEPRINT_NOW21:22
ttxNo need for duplicate pointers. I can do that for you.21:22
ttxLooking at the rest of the folsom plan at: https://blueprints.launchpad.net/keystone/folsom21:23
ttxDoes that plan fully reflect your folsom objectives ?21:23
heckjat this time, yes. We might be able to bring some of PKI in earlier, depending on progress. Playing it by ear, will if we can.21:23
heckjAnnounced the page and details to the list earlier today - it will mean new dependencies for the PKI related library to the project(s)21:24
ttxheckj: could you set priorities so that we make sure essential stuff is properly tracked ?21:24
heckjwill do21:24
ttx#action heckj to set priorities on https://blueprints.launchpad.net/keystone/folsom21:24
ttxAt first glance there seems to be a lot targeted to folsom-3 compared to folsom-{1,2}21:24
ttxBut based on the priorities you set it may or may not matter that much.21:25
ttxheckj: anything else ?21:25
heckjquestions for Keystone?21:25
ttxnone apparently, switching to swift21:26
ttx#topic Swift status21:26
*** openstack changes topic to "Swift status"21:26
ttx#link https://launchpad.net/swift/+milestone/1.5.021:26
ttxHow are the splits into associated projects going so far ?21:26
notmynamein progress. may have happened, but a few are still outstanding21:27
ttxOh. Two new blueprints since I last looked21:27
ttxIs that task assigned to the whole core team, or to a specific individual ?21:27
notmynamethey are currently proposed patches21:27
notmynamethe associated projects split? that involves nearly everyone21:27
ttxnotmyname: ack21:27
ttxStill on track for an end-of-May/start-of-June release ?21:28
notmynameI still hope that 1.5.0 will be ready by the end of the month, but no promises yet21:28
notmynameI'll have a better idea by next week21:28
ttxworks for me.21:28
ttxSo "expand swift recon support" and "proxy logging middleware" are already proposed changes ?21:28
ttxwill mark them "good progress".21:29
ttxnotmyname: Anything else ?21:29
notmynamenot from me21:29
ttxQuestions on Swift ?21:29
*** sdague_ is now known as sdague21:29
ttx#topic Glance status21:30
*** openstack changes topic to "Glance status"21:30
ttxbcwaldon: yo21:30
ttx#link https://launchpad.net/glance/+milestone/folsom-121:30
bcwaldonttx: hey hey21:30
*** Gordonz has quit IRC21:30
ttxI suspect the status is accurate on your 7 targeted blueprints ?21:30
bcwaldonYep, making great progress on the v2 API21:30
ttxLooks all on-track21:30
bcwaldonJosh Harlow's blueprint has a patch waiting to go through jenkins21:31
bcwaldonI'll add in more bp's as I get to them21:31
ttx4 open targeted bugs, mostly on track as well.21:32
uvirtbotLaunchpad bug 994609 in glance "wsgi.Server() starts but is broken on osx (test_multiprocessing never ends)" [Critical,In progress]21:32
ttxI suspect there is more to this than just https://review.openstack.org/#/c/7172/21:32
ttxAnyone working on completing it ? Or should the bug be split ?21:32
bcwaldonttx: commented on that this morning21:32
bcwaldonttx: I think Patrick will do it, he was waiting on me to answer21:32
bcwaldonttx: definitely my bad there21:32
uvirtbotLaunchpad bug 988099 in glance "Monkey patch all the (eventlet) things" [Medium,In progress]21:33
ttxMight need its change resubmitted.21:33
bcwaldonmaybe s1rp can follow up on that21:33
ttx(was abandoned while we were looking the other way)21:33
ttxIn the meantime, let's look at the rest of Folsom now:21:34
ttx#link https://blueprints.launchpad.net/glance/folsom21:34
ttxThere are a number of undefined priorities there. Should those all be set to Low ?21:34
bcwaldonthe bottom 4 are not yet defined as a feature, so I'm not willing to prioritize them21:34
bcwaldonthe 5th from the bottom I will take care of now21:35
ttxThere are also a bit too much of "Essential" in there. Essential means "defer release if not here", which makes me nervous and annoying.21:35
ttxSo if you can downgrade a few of the Essential to "High" priority where it makes sense...21:35
bcwaldonttx: why's that?21:36
bcwaldonttx: to me, Essential means its gotta happen21:36
bcwaldonttx: High is I'd like to have it but we can ship without it21:36
ttxYou understand it well. It's just that when essential stuff is not completed by folsom-2 I tend to start knocking at your door.21:37
bcwaldonttx: everything Essential will be done by folsom-2, I promise21:37
ttxbut if that's what you really meant, it's ok. I guess :)21:37
ttx#info <bcwaldon> ttx: everything Essential will be done by folsom-2, I promise21:37
ttxbcwaldon: Anything else you wanted to mention ?21:37
ttxQuestions on Glance ?21:38
ttx#topic Quantum status21:38
*** openstack changes topic to "Quantum status"21:38
ttxdanwent: hey21:38
ttx#link https://launchpad.net/quantum/+milestone/folsom-121:38
danwentSo we decided to bump the keystone stuff to F-2, just not going to happen.21:38
danwentkey focus in on v2.0 API21:39
ttxwhich bp is that ?21:39
danwentah sorry, that's the keystone one21:39
ttxmelange-integration (jkoelker, started): what's the status of this ? Any chance it will be completed before Tuesday next week ?21:39
danwentwasn't sure what you were asking for.21:39
danwentttx: yes, I jkoelker and _cerberus_  are full speed on this one.21:40
ttxdatabase-common (garry kotton, needscodereview): is that completed by https://review.openstack.org/#/c/7169/ ? The commit message there was particularly unhelpful.21:40
danwentits a lot of work, but its also the top prority for the project, so I expect everyone to chip in and help out21:40
*** littleidea has quit IRC21:40
danwentttx: yes, please refresh21:41
danwentthat one merged in, but missed the automated hooks21:41
ttxexposed by caching21:41
ttxman-support: in folsom-1 but not is folsom series goal, should I fix that for you ?21:41
ttxLooking now at the more generic plan for folsom at:21:42
ttx#link https://blueprints.launchpad.net/quantum/folsom21:42
ttxThere are a number of folsom-2 blueprints that are missing the series goal, let me know if I should set those for you:21:42
ttxquantum-l3-fwd-nat, provider-networks, quantum-horizon, improved-nova-quantum-integration, new-cli, scalable-agent-comms21:42
danwentsorry, will do that :)21:42
ttxdanwent: I can do it21:43
ttxI actually have a script to catch the discrepencies.21:43
ttxDoes that folsom page represent all you had in store ? Or is there a lot more coming ?21:43
ttx#action ttx to fix series goal for quantum/folsom bps21:43
danwentttx: we're putting everything critical in F-1 and F-221:44
ttxthis is how I like it21:44
danwentanything else if opportunistic for Folsom..21:44
ttxdanwent: Anything else ?21:44
danwentdont' think so.21:44
ttxQuestions on Quantum ?21:44
ttx#topic Horizon status21:45
*** openstack changes topic to "Horizon status"21:45
ttxdevcamcar: o/21:45
ttx#link https://launchpad.net/horizon/+milestone/folsom-121:45
ttxStatus looks good to me on the blueprint side... no red flags ?21:45
devcamcarno big updates since last week - folsom 1 is moving well21:45
devcamcari still owe blueprints for folsom 221:45
ttxI'm a bit more scared about the 20+ F1-targeted bugs21:45
ttxI guess we'll refine that list before we hit the milestone-proposed cut Tuesday next week21:46
devcamcarwe're making steady progress on them21:46
devcamcarsounds good21:46
ttxLooking at folsom plan at: https://blueprints.launchpad.net/horizon/folsom21:46
ttxdoes it represent your current Folsom goals ?21:47
devcamcarstill owe a blueprint for proper quantum integration21:47
devcamcarand a few smaller ones, but yes this is pretty much accurate21:47
ttxunfortunately, contrary to bugs, blueprints do not support multiple projects21:47
*** jog0 has quit IRC21:47
danwentdevcamcar:  i actually have "sister" bps in quantum21:48
devcamcaronce we have https://blueprints.launchpad.net/horizon/+spec/workflows that will enable a great quantum integration21:48
danwentsharing them would be much nicer21:48
devcamcardanwent: yea that would be nice. maybe some day :)21:48
ttxthe idea is to use those "Folsom" pages, togther with prioritization, to make sure the important stuff lands21:48
ttxdevcamcar: Anything else ?21:48
devcamcarttx: sounds good21:49
devcamcarthats it for me21:49
ttxthanks to gabrielhurley for championing our I18N effort, btw21:49
ttxQuestions for Horizon ?21:49
gabrielhurleyttx: happy to :-)21:49
ttx#topic Other Team reports21:50
*** openstack changes topic to "Other Team reports"21:50
gabrielhurleyttx: I'll be working with heckj on keystone i18n coming up soon21:50
gabrielhurleyjust fyi21:50
ttxAnyone from docs team ?21:50
ttxannegentle asked me to post the link to the Docs team meeting minutes21:51
ttx#link http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-14-19.59.html21:51
ttxthe docs team had a meeting yesterday.21:51
ttxmtaylor/jaypipes: anything from CI/QA land ?21:51
ttxlike an online tempest gate ?21:52
ttxNote that in addition to a I18N advocacy team, we should soon have a Python 3 advocacy team21:53
ttxformed after the meeting we had at the openstack design summit21:53
ttxAny other team lead with a status report ?21:53
ttx#topic Open discussion21:54
*** openstack changes topic to "Open discussion"21:54
ttxAnything else, anyone ?21:54
oubiwann2ttx: who should we contact about the Python 3 advocacy team?21:56
*** salv has joined #openstack-meeting21:56
ttxoubiwann: Mike Pittaro should send an email about this soon21:56
oubiwann2I know dhellmann will be very interested in that :-)21:56
ttxoubiwann: how is the ML setup going ?21:56
oubiwann2jeblair: has some changes for puppet that should be landing soon21:57
oubiwann2this will give us Exim configured for mailman21:57
oubiwann2the next step is getting some DNS setup so we can start testing21:57
oubiwann2*DNS set up, rather ;-)21:58
oubiwann2(verb, not noun)21:58
ttxok then21:58
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"21:59
openstackMeeting ended Tue May 15 21:59:05 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-21.01.html21:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-21.01.txt21:59
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-21.01.log.html21:59
*** russellb has left #openstack-meeting21:59
*** gabrielhurley has left #openstack-meeting21:59
openstackMeeting started Tue May 15 22:00:36 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.22:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.22:00
danwenthello quantum team22:00
*** User95 has quit IRC22:00
danwent#link Agenda: http://wiki.openstack.org/Network/Meetings22:01
SumitNaiksatamHi All!22:01
danwent#topic Folsom-1 Release22:01
*** openstack changes topic to "Folsom-1 Release"22:01
danwent#info 1 week until Folsom-1 branch point22:01
danwent#link https://launchpad.net/quantum/+milestone/folsom-122:01
danwentMost everything is in review or already committed, which is great.22:02
*** anotherjesse is now known as anotherjesse_zz22:02
danwentAs a community, I think we really need to pitch in and do what we can to make sure the v2.0 API gets in and tested…. there's still a good deal of work there22:02
danwentis jkoelker around?22:02
danwent(or perhaps he should be coding? :P)22:02
*** ywu has joined #openstack-meeting22:02
*** blamar has quit IRC22:03
danwentWas good to see that people were commenting on the etherpads:22:03
danwent#links API v2.0 etherpad:  http://etherpad.openstack.org/quantum-v2-api22:03
danwentthough conversations get a bit hard to follow after a while on the etherpad22:03
edgarmaganahola mundo!22:04
*** oubiwann2 has quit IRC22:04
*** ryanpetr_ has quit IRC22:04
danwentI'm hoping jkoelker and _cerberus_ will have a first cut of the API code by thursday.22:04
danwentI'll be working on plugin interface and wiring a base plugin22:04
danwent_cerberus_: yeah, I know, but if you do the math...22:05
*** ayoung has quit IRC22:05
danwent_cerberus_:  what can people do to help out?22:05
_cerberus_danwent: we have a team outing tomorrow ;-)22:05
jkoelkersorry, was coding22:05
danwent_cerberus_: damn....22:05
danwentok, well, I'm just trying to work backward from tuesday branch point.22:05
jkoelkerthursday eh?22:05
jkoelkerwell nothing like the present to start setting expectations... ;)22:05
danwentor do we not consider tuesday branch point feasible?22:06
*** ryanpetrello has joined #openstack-meeting22:06
jkoelkerthursday might be pushing it, if we have to include XML22:06
jkoelkeri can probably get you a JSON only by Friday-ish22:06
danwentjkoelker: ok, i think we obviously have to support xml eventually, but for a concrete impl that people can look at, I hink json should be a-ok22:06
jkoelkersounds good to me22:07
jkoelkerthe serialization should be a middleware anyway...22:07
*** ryanpetrello has quit IRC22:07
* jkoelker ducks22:07
danwentbut my sense is that a review on something this big would have to start early monday to have a good chance of landing by end of tuesday22:07
* _cerberus_ stands behind jkoelker, still shorter22:07
danwentI'm clearing my plate of other stuff to help out this week, and hopefully other quantum team members can help out as wel.22:08
danwentso as you get an idea of things that other people might be able to bite off, please let people know.22:08
salvI will happily review over the weekend.22:08
danwent(xml serlialization/deserialization might be one)22:08
_cerberus_We're tackling the networks and ports controllers atm22:08
_cerberus_Basically everything else is fair game.22:09
danwentsalv:  great, early feedback will be really helpful.22:09
_cerberus_We've been yak shaving about how to clean up all the fiddly bits like serialization and whatnot22:09
*** dhellmann has quit IRC22:09
danwent_cerberus_: ok, I'm working on the plugin interface, and we already have basic DB models right?22:09
danwentare those committed anywhere, or just on etherpad?  would be good to get them committed.22:09
jkoelkergithub.com/jkoelker/quantum/tree/melange is the repo22:09
_cerberus_dragondm was looking into the models22:09
jkoelkeryea we have them sketched out the etherpad22:10
danwent_cerberus_:  i'd save the yak shaving and get a first cut in so people get start to get a sense of the code.  I'd like to avoid everything landing at the last minute :)22:10
*** markmcclain1 has quit IRC22:10
_cerberus_Of course22:10
danwentjkoelker: are models ready to be committed?22:10
dragondmnot yet22:10
danwentok… pls ping me when they are.22:10
dragondmthere was some refactoring to do, but they should be tommorow22:11
danwentdragondm: cool, thanks.22:11
dragondmwill do22:11
danwentcool, well let the rest of us know how we can help you out here.  a lot of things in F-2 depend on getting the API in, so I want to minimize slippage :)22:11
danwentNext topic for F-1 is the set of outstanding reviews22:12
danwentWe're actually in not so bad shape.22:12
danwentI'd encourage reviewers to spend cycles on things that are bugs/bps targeted for F-122:12
danwentand higher priority over lower priority22:13
edgarmaganadanwent: will do!22:13
danwentany reviews that are important for F-1 (other than the v2.0 API) that are not listed on the agenda?22:13
danwent#info Man page: https://review.openstack.org/#/c/7192/22:13
danwent#info Agent Common Dir: https://review.openstack.org/#/c/7460/22:13
danwent#info Client --debug flag: https://review.openstack.org/#/c/7336/22:14
danwent#info LB-plugin tuntap issue: https://review.openstack.org/#/c/7433/22:14
danwent#info Multi-node Quantum devstack: https://review.openstack.org/#/c/7001/22:14
danwentif so, please make sure they get targeted for F-1, and that they are appropriately targeted.22:14
danwentSince we have a lot of new people since the last release, I wanted to quickly cover the milestone release propose.22:14
danwentWe'll branch late tuesday of next week.22:15
garykthat would be great22:15
danwentat that point, we'll have a milestone-proposed branch, which will only be used for important bug fixes, and master will be re-opened for F-222:15
danwenteven bugs that need to go into milestone-proposed should first be pushed to master.22:15
danwentyou can then notify me that it needs to be pulled into milestone-proposed (there is no review needed for this step, unless it is import complicated than a cherry-pick)22:16
danwentOn wed, Thierry will check with me to make sure there aren't any important issues still outstanding, and if so, he will take the contents of milestone-proposed and release it as F-1 sometime in the following 24 hours.22:17
danwentso if we're close to a release and you hit what you think is a blocker, let me know ASAP.22:17
danwentduring that time, please keep you eyes on the mailing list, as I will send out a note if we urgently need reviews on a bug fix.22:18
danwentok, any questions/concerns about the process?22:18
danwentOk, moving on :)  ( think everyone's falling asleep)22:18
danwentone last comment on F-122:18
danwent#info we moved the keystone integration blueprint out of F-1, though we still need to early in F-2: https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum22:19
danwent_cerberus_: who should that be assigned to?22:19
danwentcurrently it is troytoman22:19
_cerberus_Kevin Mitchell22:19
* salv reminds folk to remind Kevin to get in touch with me22:20
*** GheRivero has quit IRC22:20
danwentturns out there are a lot of kevin mitchells on launchpad22:20
_cerberus_klmitch, I believe22:20
danwent#action: send kevin mitchell a note to contact salv about keystone + quantum22:20
danwentgot it, thanks.22:21
danwentOk, anything else for F-1?22:21
danwent#topic community topics22:21
*** openstack changes topic to "community topics"22:21
danwenta couple items I wanted to bring up22:21
*** maoy has quit IRC22:22
danwentFirst off, I don't think we ever wrapped up the "discussion" around python 2.4 and whether we should enforce that any code that might be pulled in by an agent will be compatible.22:22
garykthis could be very problematic for the RPC support (so i think)22:23
danwentI think there were concerns that openstack-common code will be used in agents, and thus this requirement would be somewhat "viral".  I believe (but am not sure) that openstack in general decided not to focus on 2.4 support.22:23
danwentbut if someone wants to champion this, I don't want to be the one standing in their way22:23
danwentis mnewby here?22:23
garykrpc support => some form of openstack common22:23
danwentI think he discussed this ont he ML22:23
danwent#action #danwent revive python 2.4 in agent discussion on ML, get to conclusion22:24
rkukuraopenstack common rpc also depends on common cfg, which I'd like to see the agents and server use22:24
danwentrkukura: +122:25
danwentrkukura: want to create a BP around adding cfg support?22:25
rkukuradanwent: sure22:25
rkukurawhat milestone?22:25
danwentrkukura:  probably F-2, as we don't want people having to change their config file (if required) later in the release cycle...22:26
mnewbyi'm here22:26
danwentI expect the set of people testing out quantum as it prepares to be core to keep growing each milestone.22:26
danwentmnewby: hey22:26
garykanyone else having devstack quantum issues or is it just me?22:27
danwentwas trying to see what we need to do to drive the python 2.4 in agents discussion22:27
danwentgaryk: please hold one sec22:27
mnewbydanwent: What kind of discussion?22:28
mnewbydanwent: Is there some question as to whether 2.4 support is necessary?22:28
danwentmnewby:  yes, I think there was some discussions around the implications of 2.4 support for openstack-common22:28
mnewbydanwent: The question is simple - should quantum support Xen?22:29
danwentand whether that means that we should try to make all code used by agents (likely to grow considerably with security groups, dhcp, etc.) 2.4 compatible.22:29
danwentmnewby:  I think of it more as should the existing agents be able to run on XenServer dom022:29
mnewbydanwent: Given that xen isn't moving in the near term, the questions are the same.22:30
danwentsome people had mentioned approaches for using the service VM… I believe Citrix folks did this for some items in essex22:30
danwentmnewby: well, there's actually kronos that runs xenserver on newer debian, but I believe we're both focused on commercial XenServer, which is the main platform.22:31
danwentsalv: are you able to comment?  is running an agent in dom0 pretty much our only option?22:31
mnewbydanwent: We're using XCP here at internap, which closely follows xenserver.22:31
danwentmnewby:  sounds like you have a vested interest :)22:31
danwentthat's fair.22:31
salvFrom my experience it is the only efficient option so far22:32
mnewbyNova has the same issue, btw.22:32
mnewbyAgents intended to run in dom0 have to be python2.4 compatible.22:32
salvI heard of people which upgraded their dom0 python environment to 2.6, but this practice is not advisable.22:32
mnewbyWhat would drive agents to not be 2.4 compatible?22:33
danwentmnewby: I thought someone said that nova only uses xenserver "plugins", and that their main agents (i.e., nova-compute) runs in the service vm.22:33
danwentmnewby: I think code that we write is easy to control22:33
salvdanwent: correct.22:33
mnewbydanwent: I'm pretty sure that's not true.22:33
s0mikdanwent: I think thats correct22:33
mnewbydanwent: There is agent code in nova, too.22:33
danwentopenstack-common code is more of a concern, as we'll likely be using rpc, config, etc. from there.22:33
danwentperhaps you can work with them to make sure it is 2.4 compatible22:33
*** gyee has quit IRC22:33
salvok, now I'm confused :)22:33
danwentmnewby:  what is not true?22:34
mnewbysalv: Sorry, I was delayed.  You're right.22:34
salvmnewby: by agent code you mean code which is supposed to run on dom0?22:34
mnewbydanwent: that nova agent code doesn't run in dom0.22:34
mnaserafaik, there is no services running on the dom0 (and it has been something that was enforced not to run in dom0 due to security)22:34
danwentI think we may be using the term agent loosely here.22:34
mnewbysalv: yes22:34
danwentmnewby: yes, that's what I was trying to say22:34
mnaserthere are xenapi plugins that are included (simple files) that are being called from the service VM on the node.  the small xenapi plugins extend the functionality of the xapi that nova-compute connects to22:35
mnewbymnaser: I reviewed code as recently as february that was intended to be run in dom0.22:35
danwentok, well, regardless, from salv's comments it sounds like our agent code would need to run on dom022:35
danwentso I'd like to focus on how we could make that work.22:35
danwentperhaps coordinating with the openstack-common folks is a good next step22:35
danwentI believe mnewby is already working with mtaylor to get some automated testing in.22:36
rkukurado the nova VIF drivers currently run in dom0?22:36
salvThe alternative to running the agent in dom0 is cumbersome and involves development of new plugins. I tried it back last october :)22:36
mnewbyDespite all the apparent enthusiasm to do so, there is no requirement that we use rpc at all let alone from openstack common.22:36
danwentrkukura: not the xenserver one22:36
danwentsalv: yeah, I don't want to slow things down by implementing a lot of platform specific stuff if we can avoid it...22:36
danwentrkukura: xenserver vif driver using XAPI api, which makes webservice call to dom022:37
danwent(salv can correct me)22:37
salvdanwent: no need to correct, you;re rigth22:37
rkukuradanwent: could that be done by something like the rootwrap hook?22:37
danwentrkukura: don't follow...22:38
salvBtw, There's some code for baseline network protection which is not a xapi plugin and is supposed to run in dom022:38
danwentmnewby:  sure, but at the least the config stuff..22:38
danwentsalv: are those the OVS filters?22:38
*** sleepsonthefloor is now known as sleepsonzzz22:38
salvdanwent: yes22:38
mnewbydanwent: We may want to consider holding off on using openstack.common until dom0 is no longer 2.4.  I will check, but keeping common 2.4 compatible will probably not be possible.22:39
danwentok, well, sounds like there's still a lot to explore here.  let's take this offline22:39
danwentI just wanted to make sure we were either moving forward with the discussion, or had reached a conclusion.  Let's keep talking about this on the ML.  In the mean time, I'm fine with reviewers requesting 2.4 compliance for our agent code.22:40
danwentbut I suspect we will want to leverage openstack-common functionality in agents, so I think we need to explore more there.22:40
danwentsound fair?22:40
danwenti'll take that as agreement :)22:41
danwentOk, on a new topic...22:41
danwentI wanted to encourage people to help out in responding to questions on the ML about quantum.22:41
danwentand also to sign up to be notified when people submit questions via answers.launchpad.net/quantum22:42
danwentthe load is definitely going up, now that more people are trying out quantum, and we want them to have a good experience.22:42
danwentits also a good chance to identify gaps in our documentation.22:42
danwentand one last comment22:43
danwent#info anyone interested in helping maintain essex/stable branches for quantum should ping me.22:43
danwent#topic open discussion22:43
*** openstack changes topic to "open discussion"22:43
danwentanyone have anything else to discuss?22:43
danwentah, thanks garyk22:44
danwentare you talking about the linuxbridge issue you mentioned?22:44
SumitNaiksatamgaryk: are you referring to the issue about bridge and gw devices created? or is it something else?22:44
garykdanwent: correct22:44
danwentlately i've been using devstack with OVS on the version that is under review:  https://review.openstack.org/#/c/7001/22:44
danwentbut I saw that issue as well when testing with linuxbridge… didn't have time to explore it.22:45
*** markvoelker has quit IRC22:45
SumitNaiksatamgaryk: I noticed it first when I was reviewing your agent changes22:45
danwenti'm not seeing a similar issue with OVS, so I suspect it is specific to the interface-driver (which is different between linuxbridge and OVS)22:45
garyki guess i'll invest some time and explore22:45
danwentgaryk: great… would be good to have more people familiar with that code as well.  I can be a point of contact if you have questions about what is going on there.22:46
danwent(in terms of QuantumManager code).  SumitNaiksatam is probably best for anything that is linuxbridge specific.22:46
danwentor just send to the ML :)22:46
garykok, i'll take a look and get back to you guys22:46
danwentanything else?22:46
SumitNaiksatamyeah, I am looking at it as well22:47
garykSumitNaiksatam: tx22:47
danwentok, let's see what we can all do to help out with reviews this week, and to help with the new API code.22:47
garykscaling agents: in process of getting it up and running22:47
garykwould like to discuss one issue here or can take it to the ML22:47
danwentgaryk: go ahead22:47
danwentjust in time :P22:48
garykFrom my understanding concensus was to have the agent use attachment id to retrieve the network info. There may be false positives here if the plugin does not ensure that this is unique system wide.22:48
*** rafaduran has quit IRC22:48
mnewbyit's a uuid, no?22:49
danwentmnewby:  yes, but multiple switches could claim to have it.22:49
mnewbythat doesn't sound very uuid-like22:49
garykif the vif could notify the agent with the id's then it is not a problem.22:50
danwentmnewby: this actually happens in real life, like when a VM migrates from one server to another, for a brief period of time that vif (and its UUID) actuallly exists in two locations.22:50
mnewbydanwent: ah, gotcha22:50
danwentgaryk: not sure I follow...22:51
mnewbygaryk: what about udev notification?22:51
danwentgaryk: do you mean vif-drivers?22:51
danwentgaryk: maybe write an email to the ML on this?22:51
garykok - mail will be best22:52
danwentok, last call.  any quick updates before we close out?22:52
danwentthanks folks, talk to you next week (and see you on gerrit :P)22:53
*** openstack changes topic to "Status and Progress (Meeting topic: keystone-meeting)"22:53
openstackMeeting ended Tue May 15 22:53:07 2012 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:53
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-22.00.html22:53
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-22.00.txt22:53
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-22.00.log.html22:53
s0miktake care folks till next time22:53
*** SumitNaiksatam has quit IRC22:53
*** oubiwann1 has joined #openstack-meeting22:56
*** edgarmagana has quit IRC23:01
*** littleidea has joined #openstack-meeting23:03
*** edygarcia has quit IRC23:05
*** littleidea has quit IRC23:08
*** ryanpetrello has joined #openstack-meeting23:09
*** heckj has quit IRC23:14
*** littleidea has joined #openstack-meeting23:29
*** AlanClark has quit IRC23:31
*** joearnold has quit IRC23:39
*** hggdh has quit IRC23:39
*** anderstj_ has quit IRC23:41
*** dtroyer is now known as dtroyer_zzz23:42
*** mrmartin has quit IRC23:42
*** anotherjesse_zz is now known as anotherjesse23:49
*** novas0x2a|laptop has quit IRC23:51
*** dhellmann has joined #openstack-meeting23:53
*** dtroyer_zzz is now known as dtroyer23:53

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