Tuesday, 2013-11-26

*** julim has quit IRC00:04
*** MarkAtwood has quit IRC00:05
*** hemna is now known as hemnafk00:09
*** otherwiseguy has quit IRC00:14
*** sdake_ has joined #openstack-meeting00:14
*** sdake_ has quit IRC00:14
*** sdake_ has joined #openstack-meeting00:14
*** vahidh has quit IRC00:18
*** fnaval_ has quit IRC00:19
*** branen_ has quit IRC00:21
*** nati_uen_ has joined #openstack-meeting00:23
*** markwash has quit IRC00:25
*** nati_uen_ has quit IRC00:25
*** nati_uen_ has joined #openstack-meeting00:26
*** nati_ueno has quit IRC00:27
*** vkmc has quit IRC00:28
*** rakhmerov has joined #openstack-meeting00:28
*** ndipanov_gone has quit IRC00:31
*** matsuhashi has joined #openstack-meeting00:32
*** hemanth has quit IRC00:32
*** lexx has quit IRC00:32
*** carl_baldwin has joined #openstack-meeting00:36
*** carl_baldwin has left #openstack-meeting00:37
*** armax has joined #openstack-meeting00:37
*** oubiwann has joined #openstack-meeting00:38
*** ryu25 has quit IRC00:39
*** gyee_ has joined #openstack-meeting00:45
*** sushils has quit IRC00:47
*** yamahata_ has joined #openstack-meeting00:48
*** ivar-lazzaro has joined #openstack-meeting00:50
*** tanisdl has quit IRC00:52
*** adrian_otto has joined #openstack-meeting00:54
*** atiwari has quit IRC01:01
*** otherwiseguy has joined #openstack-meeting01:02
*** rakhmerov has quit IRC01:02
*** cathy_zhang has joined #openstack-meeting01:02
*** cathy_zhang has quit IRC01:03
*** banix has joined #openstack-meeting01:04
*** mrodden has quit IRC01:09
*** nosnos has joined #openstack-meeting01:09
*** jorisroovers has quit IRC01:14
*** nati_ueno has joined #openstack-meeting01:14
*** jorisroovers has joined #openstack-meeting01:17
*** nati_uen_ has quit IRC01:17
*** jomara has quit IRC01:17
*** adrian_otto has quit IRC01:18
*** rongze has joined #openstack-meeting01:21
*** gyee_ has quit IRC01:23
*** herndon has quit IRC01:24
*** jomara has joined #openstack-meeting01:25
*** mrodden has joined #openstack-meeting01:25
*** rongze has quit IRC01:26
*** thomasem has joined #openstack-meeting01:27
*** mrodden1 has joined #openstack-meeting01:27
*** sjing has joined #openstack-meeting01:28
*** mrodden has quit IRC01:30
*** jorisroovers has quit IRC01:31
*** Sukhdev has quit IRC01:37
*** rongze has joined #openstack-meeting01:39
*** markpeek has joined #openstack-meeting01:39
*** colinmcnamara has quit IRC01:40
*** thomasem has quit IRC01:41
*** _ozstacker_ has joined #openstack-meeting01:44
*** mrodden has joined #openstack-meeting01:45
*** rongze has quit IRC01:46
*** mrodden1 has quit IRC01:47
*** ozstacker has quit IRC01:48
*** sandywalsh has quit IRC01:49
*** SumitNaiksatam has quit IRC01:54
*** rnirmal has quit IRC01:55
*** yaguang has joined #openstack-meeting01:56
*** sarob has joined #openstack-meeting01:56
*** rakhmerov has joined #openstack-meeting01:58
*** rongze has joined #openstack-meeting02:01
*** nosnos_ has joined #openstack-meeting02:02
*** yamahata_ has quit IRC02:03
*** rakhmerov has quit IRC02:03
*** nati_uen_ has joined #openstack-meeting02:03
*** nosnos has quit IRC02:05
*** nati_ueno has quit IRC02:06
*** coolsvap has quit IRC02:06
*** martines has quit IRC02:07
*** nati_uen_ has quit IRC02:09
*** nati_ueno has joined #openstack-meeting02:10
*** martines has joined #openstack-meeting02:11
*** dcramer_ has quit IRC02:18
*** zhikunliu has joined #openstack-meeting02:19
*** nati_ueno has quit IRC02:21
*** epim has joined #openstack-meeting02:22
*** reed has quit IRC02:29
*** ryanpetrello has joined #openstack-meeting02:31
*** armax has left #openstack-meeting02:31
*** markwash has joined #openstack-meeting02:32
*** Mandell has quit IRC02:34
*** jhenner|afk has quit IRC02:37
*** dims has quit IRC02:38
*** markpeek has quit IRC02:40
*** sarob has quit IRC02:40
*** rbowen has quit IRC02:40
*** sarob has joined #openstack-meeting02:40
*** fifieldt has quit IRC02:41
*** markpeek has joined #openstack-meeting02:44
*** sarob has quit IRC02:45
*** arosen has quit IRC02:45
*** sarob has joined #openstack-meeting02:45
*** arosen has joined #openstack-meeting02:47
*** dolphm has joined #openstack-meeting02:48
*** danwent has quit IRC02:48
*** ndipanov has joined #openstack-meeting02:50
*** ryanpetrello has quit IRC02:56
*** rakhmerov has joined #openstack-meeting02:59
*** noslzzp has quit IRC03:00
*** sarob has quit IRC03:01
*** sarob has joined #openstack-meeting03:02
*** rakhmerov has quit IRC03:04
*** noslzzp has joined #openstack-meeting03:05
*** sarob has quit IRC03:07
*** neelashah has joined #openstack-meeting03:08
*** matsuhashi has quit IRC03:11
*** gyee has quit IRC03:12
*** paragan has joined #openstack-meeting03:21
*** novas0x2a|laptop has quit IRC03:22
*** rakhmerov has joined #openstack-meeting03:22
*** colinmcnamara has joined #openstack-meeting03:22
*** dolphm has quit IRC03:25
*** epim has quit IRC03:25
*** epim has joined #openstack-meeting03:26
*** vkozhukalov has joined #openstack-meeting03:26
*** lbragstad has joined #openstack-meeting03:26
*** nati_ueno has joined #openstack-meeting03:28
*** arosen has quit IRC03:28
*** dolphm has joined #openstack-meeting03:33
*** nati_ueno has quit IRC03:35
*** nati_ueno has joined #openstack-meeting03:35
*** sarob has joined #openstack-meeting03:37
*** markpeek has quit IRC03:40
*** dolphm has quit IRC03:40
*** NikitaKonovalov has quit IRC03:41
*** banix has quit IRC03:41
*** otherwiseguy has quit IRC03:45
*** twoputt_ has quit IRC03:46
*** twoputt has quit IRC03:46
*** coolsvap has joined #openstack-meeting03:50
*** nermina has joined #openstack-meeting03:55
*** jorisroovers has joined #openstack-meeting03:59
*** jroovers has joined #openstack-meeting04:01
*** jorisroovers has quit IRC04:03
*** Mandell has joined #openstack-meeting04:04
*** markpeek has joined #openstack-meeting04:05
*** chandankumar has joined #openstack-meeting04:05
*** fnaval has joined #openstack-meeting04:06
*** markpeek has quit IRC04:08
*** Linz has quit IRC04:09
*** Linz has joined #openstack-meeting04:09
*** markpeek has joined #openstack-meeting04:12
*** markpeek has quit IRC04:13
*** yamahata_ has joined #openstack-meeting04:14
*** matsuhashi has joined #openstack-meeting04:19
*** vipul-away is now known as vipul04:29
*** nati_uen_ has joined #openstack-meeting04:29
*** coolsvap has quit IRC04:31
*** nosnos_ has quit IRC04:32
*** nosnos has joined #openstack-meeting04:32
*** nati_ueno has quit IRC04:33
*** aguzikova has joined #openstack-meeting04:37
*** markpeek has joined #openstack-meeting04:39
*** radsy has joined #openstack-meeting04:39
*** markpeek has quit IRC04:44
*** yamahata_ has quit IRC04:47
*** Mandell has quit IRC04:47
*** rongze has quit IRC04:48
*** ArxCruz has quit IRC04:50
*** markpeek has joined #openstack-meeting04:52
*** banix has joined #openstack-meeting04:55
*** maxdml has quit IRC04:59
*** suo has joined #openstack-meeting05:02
*** sarob has quit IRC05:02
*** coolsvap_ has joined #openstack-meeting05:05
*** jasondotstar has quit IRC05:10
*** zigo_ has quit IRC05:10
*** zigo has joined #openstack-meeting05:11
*** epim has quit IRC05:14
*** markpeek has quit IRC05:16
*** pablosan has quit IRC05:16
*** rongze has joined #openstack-meeting05:19
*** markpeek has joined #openstack-meeting05:23
*** coolsvap_ has quit IRC05:24
*** oubiwann has quit IRC05:27
*** markpeek has quit IRC05:27
*** rongze has quit IRC05:27
*** sarob has joined #openstack-meeting05:28
*** coolsvap has joined #openstack-meeting05:29
*** Mandell has joined #openstack-meeting05:30
*** zhikunliu has quit IRC05:31
*** markpeek has joined #openstack-meeting05:35
*** sarob has quit IRC05:39
*** lbragstad has quit IRC05:42
*** markpeek has quit IRC05:44
*** matsuhashi has quit IRC05:50
*** matsuhashi has joined #openstack-meeting05:51
*** matsuhas_ has joined #openstack-meeting05:53
*** matsuhashi has quit IRC05:53
*** radix_ has joined #openstack-meeting05:59
*** nermina has quit IRC06:02
*** banix has quit IRC06:04
*** comay has quit IRC06:06
*** radsy has quit IRC06:07
*** sarob has joined #openstack-meeting06:07
*** comay has joined #openstack-meeting06:11
*** vkozhukalov has quit IRC06:15
*** michchap has quit IRC06:16
*** michchap has joined #openstack-meeting06:16
*** matsuhas_ has quit IRC06:20
*** denis_makogon has joined #openstack-meeting06:23
*** rongze has joined #openstack-meeting06:24
*** coolsvap has quit IRC06:26
*** neelashah has quit IRC06:28
*** rongze has quit IRC06:28
*** noslzzp has quit IRC06:28
*** matsuhashi has joined #openstack-meeting06:29
*** boris-42 has joined #openstack-meeting06:29
*** terriyu has joined #openstack-meeting06:31
*** coolsvap has joined #openstack-meeting06:33
*** ildikov has joined #openstack-meeting06:35
*** coolsvap has quit IRC06:36
*** rongze has joined #openstack-meeting06:38
*** akuznetsov has quit IRC06:45
*** colinmcnamara has quit IRC06:49
*** haomaiwa_ has quit IRC06:52
*** skraynev has quit IRC06:52
*** haomaiwang has joined #openstack-meeting06:52
*** haomaiwang has quit IRC06:53
*** matsuhashi has quit IRC06:53
*** haomaiwang has joined #openstack-meeting06:53
*** sarob has quit IRC06:54
*** matsuhashi has joined #openstack-meeting06:54
*** skraynev has joined #openstack-meeting06:54
*** nati_uen_ has quit IRC06:56
*** matsuhashi has quit IRC06:58
*** matsuhashi has joined #openstack-meeting06:59
*** sjing has quit IRC07:04
*** sjing has joined #openstack-meeting07:06
*** mengxd has joined #openstack-meeting07:06
*** mengxd has quit IRC07:07
*** NikitaKonovalov has joined #openstack-meeting07:10
*** Shaan7 has quit IRC07:11
*** nati_ueno has joined #openstack-meeting07:12
*** afazekas has joined #openstack-meeting07:13
*** NikitaKonovalov_ has joined #openstack-meeting07:14
*** NikitaKonovalov has quit IRC07:15
*** NikitaKonovalov_ is now known as NikitaKonovalov07:15
*** doron_afk has joined #openstack-meeting07:18
*** evgenyf has joined #openstack-meeting07:20
*** matsuhashi has quit IRC07:26
*** matsuhashi has joined #openstack-meeting07:27
*** ikhudoshyn has joined #openstack-meeting07:29
*** doron_afk is now known as doron07:30
*** SergeyLukjanov has joined #openstack-meeting07:38
*** jtomasek has quit IRC07:38
*** jtomasek has joined #openstack-meeting07:38
*** matsuhas_ has joined #openstack-meeting07:39
*** sushils has joined #openstack-meeting07:40
*** matsuhashi has quit IRC07:42
*** boris-42 has quit IRC07:42
*** imarnat_ has quit IRC07:43
*** SumitNaiksatam has joined #openstack-meeting07:43
*** terriyu has quit IRC07:44
*** jtomasek has quit IRC07:45
*** boris-42 has joined #openstack-meeting07:45
*** igormarnat has joined #openstack-meeting07:45
*** katyafervent has quit IRC07:46
*** tsufiev has quit IRC07:46
*** tsufiev has joined #openstack-meeting07:46
*** katyafervent has joined #openstack-meeting07:47
*** doron is now known as doron_afk07:47
*** doron_afk is now known as doron07:47
*** doron is now known as doron_afk07:49
*** jtomasek has joined #openstack-meeting07:49
*** doron_afk is now known as doron07:49
*** DinaBelova has joined #openstack-meeting07:53
*** jlibosva has joined #openstack-meeting07:59
*** lexx has joined #openstack-meeting08:00
*** igormarnat_ has joined #openstack-meeting08:00
*** mrunge has joined #openstack-meeting08:01
*** akuznetsov has joined #openstack-meeting08:04
*** matsuhas_ has quit IRC08:05
*** matsuhashi has joined #openstack-meeting08:05
*** belmoreira has joined #openstack-meeting08:06
*** avishayb has joined #openstack-meeting08:06
*** SergeyLukjanov has quit IRC08:06
*** jcoufal has joined #openstack-meeting08:07
*** DinaBelova has quit IRC08:09
*** flaper87|afk is now known as flaper8708:10
*** nprivalova has joined #openstack-meeting08:14
*** yuan has joined #openstack-meeting08:16
*** romcheg has joined #openstack-meeting08:18
*** romcheg1 has joined #openstack-meeting08:20
*** romcheg has quit IRC08:20
*** sarob has joined #openstack-meeting08:20
*** vkozhukalov has joined #openstack-meeting08:23
*** sarob has quit IRC08:24
*** romcheg1 has quit IRC08:26
*** lexx has quit IRC08:27
*** Kharec has quit IRC08:29
*** nati_ueno has quit IRC08:29
*** ndipanov has quit IRC08:29
*** ndipanov has joined #openstack-meeting08:30
*** Kharec has joined #openstack-meeting08:30
*** vkozhukalov has quit IRC08:34
*** NikitaKonovalov has quit IRC08:39
*** denis_makogon has quit IRC08:39
*** vkozhukalov has joined #openstack-meeting08:41
*** thelorax123 has quit IRC08:42
*** sarob has joined #openstack-meeting08:50
*** sarob has quit IRC08:52
*** uaberme has joined #openstack-meeting08:52
*** sarob has joined #openstack-meeting08:52
*** sjing has quit IRC08:53
*** derekh has joined #openstack-meeting08:54
*** romcheg has joined #openstack-meeting08:54
*** sarob has quit IRC08:57
*** safchain has joined #openstack-meeting09:06
*** fbo_away is now known as fbo09:06
*** _coolsvap_ has joined #openstack-meeting09:06
*** nati_ueno has joined #openstack-meeting09:09
*** yassine has joined #openstack-meeting09:10
*** alatynskaya has joined #openstack-meeting09:18
*** aguzikova_ has joined #openstack-meeting09:20
*** doron is now known as doron_afk09:21
*** aguzikova has quit IRC09:23
*** NikitaKonovalov has joined #openstack-meeting09:24
*** ruhe has joined #openstack-meeting09:25
*** yamahata_ has joined #openstack-meeting09:30
*** doron_afk is now known as doron09:30
*** _coolsvap_ has quit IRC09:37
*** coolsvap has joined #openstack-meeting09:37
*** nati_ueno has quit IRC09:40
*** ttrifonov_zZzz is now known as ttrifonov09:42
*** jamespage has joined #openstack-meeting09:46
*** jamespage has quit IRC09:46
*** jamespage has joined #openstack-meeting09:46
*** doron is now known as doron_afk09:46
*** doron_afk is now known as doron09:48
*** jhenner has joined #openstack-meeting09:50
*** sarob has joined #openstack-meeting09:50
*** DinaBelova has joined #openstack-meeting09:53
*** matsuhas_ has joined #openstack-meeting09:58
*** matsuhas_ has quit IRC09:58
*** coolsvap has quit IRC10:00
*** matsuhashi has quit IRC10:02
*** SergeyLukjanov has joined #openstack-meeting10:02
*** coolsvap has joined #openstack-meeting10:06
*** aguzikova_ has quit IRC10:08
*** jcoufal has quit IRC10:13
*** avishayb has quit IRC10:16
*** DinaBelova has quit IRC10:18
*** bauzas1 is now known as bauzas10:20
*** sarob has quit IRC10:22
*** evgenyf has quit IRC10:23
*** nprivalova has quit IRC10:24
*** bauzas has left #openstack-meeting10:25
*** DinaBelova has joined #openstack-meeting10:25
*** ildikov has quit IRC10:29
*** rongze has quit IRC10:29
*** coolsvap has quit IRC10:32
*** nprivalova has joined #openstack-meeting10:32
*** paragan has quit IRC10:35
*** ttrifonov is now known as ttrifonov_zZzz10:35
*** ildikov has joined #openstack-meeting10:36
*** yamahata_ has quit IRC10:36
*** coolsvap has joined #openstack-meeting10:38
*** doron is now known as doron_afk10:40
*** doron_afk is now known as doron10:40
*** doron is now known as doron_afk10:43
*** doron_afk is now known as doron10:44
*** coolsvap has quit IRC10:44
*** doron is now known as doron_afk10:47
*** doron_afk is now known as doron10:48
*** colinmcnamara has joined #openstack-meeting10:50
*** sarob has joined #openstack-meeting10:50
*** jroovers has quit IRC10:54
*** sarob has quit IRC10:54
*** evgenyf has joined #openstack-meeting10:55
*** colinmcnamara has quit IRC10:55
*** nprivalova has quit IRC10:57
*** rossella_s has joined #openstack-meeting11:03
*** yaguang has quit IRC11:05
*** ruhe has quit IRC11:07
*** rfolco has joined #openstack-meeting11:11
*** jamespage has quit IRC11:12
*** jamespage has joined #openstack-meeting11:12
*** igormarnat_ has quit IRC11:15
*** igormarnat__ has joined #openstack-meeting11:16
*** avishayb has joined #openstack-meeting11:22
*** doron is now known as doron_afk11:22
*** jorisroovers has joined #openstack-meeting11:26
*** jorisroovers has quit IRC11:27
*** jorisroovers has joined #openstack-meeting11:27
*** ArxCruz has joined #openstack-meeting11:30
*** coolsvap has joined #openstack-meeting11:35
*** doron_afk is now known as doron11:37
*** pcm_ has joined #openstack-meeting11:41
*** igormarnat__ has quit IRC11:41
*** igormarnat__ has joined #openstack-meeting11:42
*** n0ano has quit IRC11:44
*** jroovers has joined #openstack-meeting11:44
*** michchap has quit IRC11:46
*** jorisroovers has quit IRC11:46
*** igormarnat__ has quit IRC11:47
*** igormarnat__ has joined #openstack-meeting11:47
*** michchap has joined #openstack-meeting11:48
*** saschpe_ has joined #openstack-meeting11:49
*** saschpe has quit IRC11:50
*** sarob has joined #openstack-meeting11:50
*** igormarnat__ has quit IRC11:50
*** DinaBelova has quit IRC11:51
*** rpodolyaka has quit IRC11:51
*** romcheg has quit IRC11:53
*** jcoufal has joined #openstack-meeting11:53
*** pcm_ has quit IRC11:55
*** pcm_ has joined #openstack-meeting11:56
*** 5EXAAWDOS has joined #openstack-meeting11:57
*** nprivalova has joined #openstack-meeting11:58
*** bogdando has quit IRC12:04
*** DinaBelova has joined #openstack-meeting12:05
*** bgorski has joined #openstack-meeting12:11
*** flaper87 is now known as flaper87|afk12:11
*** nosnos has quit IRC12:11
*** sarob has quit IRC12:12
*** michchap has quit IRC12:13
*** rongze has joined #openstack-meeting12:15
*** Guest46324 is now known as med_12:15
*** med_ is now known as medberry12:15
*** flaper87|afk is now known as flaper8712:16
*** suo has quit IRC12:19
*** spligak has quit IRC12:23
*** spligak has joined #openstack-meeting12:24
*** sarob has joined #openstack-meeting12:32
*** vkmc has joined #openstack-meeting12:32
*** doron is now known as doron_afk12:34
*** ttrifonov_zZzz is now known as ttrifonov12:36
*** sarob has quit IRC12:37
*** boris-42 has quit IRC12:41
*** michchap has joined #openstack-meeting12:43
*** yamahata_ has joined #openstack-meeting12:47
*** sarob has joined #openstack-meeting12:50
*** romcheg has joined #openstack-meeting12:50
*** michchap has quit IRC12:51
*** ttrifonov is now known as ttrifonov_zZzz12:54
*** sarob has quit IRC12:54
*** dims has joined #openstack-meeting12:55
*** wwallnrr__ has joined #openstack-meeting12:55
*** paragan has joined #openstack-meeting12:56
*** markmcclain has joined #openstack-meeting12:56
*** michchap has joined #openstack-meeting12:57
*** pdmars has joined #openstack-meeting12:59
*** ttrifonov_zZzz is now known as ttrifonov13:00
*** arosen has joined #openstack-meeting13:00
*** dkranz has joined #openstack-meeting13:01
*** doron_afk is now known as doron13:01
*** michchap has quit IRC13:01
*** jhenner1 has joined #openstack-meeting13:03
*** igormarnat__ has joined #openstack-meeting13:03
*** jhenner has quit IRC13:04
*** 5EXAAWDOS has quit IRC13:07
*** sandywalsh has joined #openstack-meeting13:07
*** yaguang has joined #openstack-meeting13:11
*** ygbo has joined #openstack-meeting13:12
*** doron is now known as doron_afk13:13
*** rpodolyaka has joined #openstack-meeting13:14
*** coolsvap has left #openstack-meeting13:15
*** dhellmann-afk is now known as dhellmann13:15
*** coolsvap has joined #openstack-meeting13:16
*** coolsvap has left #openstack-meeting13:17
*** rongze has quit IRC13:17
*** marios has quit IRC13:18
*** marios has joined #openstack-meeting13:19
*** nprivalova has quit IRC13:20
*** weshay has joined #openstack-meeting13:21
*** nprivalova has joined #openstack-meeting13:23
*** doron_afk is now known as doron13:25
*** sandywalsh has quit IRC13:27
*** michchap has joined #openstack-meeting13:28
*** rongze has joined #openstack-meeting13:29
*** arosen has quit IRC13:31
*** dhellmann is now known as dhellmann-afk13:31
*** gongysh has joined #openstack-meeting13:32
*** mrunge has quit IRC13:33
*** igormarnat__ has quit IRC13:34
*** neelashah has joined #openstack-meeting13:35
*** michchap has quit IRC13:37
*** amotoki has joined #openstack-meeting13:37
*** thomasem has joined #openstack-meeting13:40
*** markvoelker1 has joined #openstack-meeting13:42
*** sandywalsh has joined #openstack-meeting13:42
*** Fdot has joined #openstack-meeting13:44
*** igormarnat_ has joined #openstack-meeting13:46
*** marios has quit IRC13:46
*** marios has joined #openstack-meeting13:47
*** arosen has joined #openstack-meeting13:47
*** sarob has joined #openstack-meeting13:50
*** markmcclain has quit IRC13:50
*** sandywalsh has quit IRC13:51
*** slong has joined #openstack-meeting13:51
*** dprince has joined #openstack-meeting13:51
*** dguitarbite has joined #openstack-meeting13:52
*** slong is now known as summerlong13:53
*** sarob has quit IRC13:54
*** sarob has joined #openstack-meeting13:56
*** gongysh has quit IRC13:57
*** michchap has joined #openstack-meeting13:58
*** ruhe has joined #openstack-meeting13:58
annegentleready to start?14:01
*** rbowen has joined #openstack-meeting14:01
*** fnaval has quit IRC14:01
annegentle#startmeeting DocTeamMeeting14:01
openstackMeeting started Tue Nov 26 14:01:52 2013 UTC and is due to finish in 60 minutes.  The chair is annegentle. Information about MeetBot at http://wiki.debian.org/MeetBot.14:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
*** openstack changes topic to " (Meeting topic: DocTeamMeeting)"14:01
*** fnaval has joined #openstack-meeting14:01
openstackThe meeting name has been set to 'docteammeeting'14:01
annegentlehey EmilienM14:02
chandankumarhello all!14:02
annegentleour agenda is here:14:02
annegentle#link https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting14:02
annegentleHm, need to think about which action items to review14:02
*** michchap has quit IRC14:03
annegentleI'll review the ones from last week14:03
annegentleLoquacity to begin working on a proposal for config-reference and cloud admin guide IA14:03
annegentleNot sure how she's doing there, but she has started it14:03
annegentle fifieldt to organise a doc bug day14:03
*** NikitaKonovalov has quit IRC14:03
annegentleThe selected doc bug day is Dec 2014:03
annegentlefollow the sun14:03
annegentle#info Doc Bug Day scheduled for Dec 20 201314:03
*** sandywalsh has joined #openstack-meeting14:04
summerlongannegentle, just do as much as you can in that one day?14:04
annegentle#topic Announcement Google Hangout14:04
*** openstack changes topic to "Announcement Google Hangout (Meeting topic: DocTeamMeeting)"14:04
annegentlehee hee summerlong14:04
annegentleI'd been meaning to get this scheduled, and it'll be next week14:04
annegentle#info Google Hangout Monday, December 2, 2013 at 03:00:00 (that's 7:00 PM PST, 9:00 PM CST, 10:00 PM EST)14:04
annegentlePretty excited to do some higher fidelity talking :)14:05
annegentlesummerlong: oh sorry reread your question, yes, do as much as you can in one day, triage, fix14:05
chandankumarannegentle, for me it is about 08:30 a:m in the morning. :)14:05
summerlong:), ta14:05
*** shaunm has joined #openstack-meeting14:05
annegentlehey shaunm14:06
shaunmmorning annegentle14:06
annegentledoc bug day is more for already contributing people14:06
annegentlenot for new contributors per se14:06
annegentlesince onboarding takes a while and we want efficiency14:07
*** lbragstad has joined #openstack-meeting14:07
annegentleoh I'll skip to onboarding in the agenda14:07
annegentleany other Qs on doc bug day?14:07
annegentle#info doc bug day for bugs in openstack-manuals and openstack-api-site14:08
annegentle#info idea for doc bug day is to get numbers down, not necessarily onboard new contributors14:08
annegentle#topic Onboarding doc contributors14:08
*** openstack changes topic to "Onboarding doc contributors (Meeting topic: DocTeamMeeting)"14:08
annegentleSpeaking of which14:08
annegentleI've asked Nick Chase to help out with onboarding, so I've been emailing him on CC when I get new people who want to help with docs14:08
annegentleTwo in the past two weeks I want to say?14:08
annegentleSo that's AWESOME and thank you Nick!14:09
annegentle#info Nick Chase to help with onboarding doc contributors14:09
*** jhenner1 has quit IRC14:09
annegentleSo copy Nick if you get anyone reaching out with questions, you can always help also, but I thought it would be nice to have one point of contact14:09
annegentleWhich also leads into another topic14:09
*** jd__` has joined #openstack-meeting14:09
annegentle#topic Educating devs on what goes where14:09
*** openstack changes topic to "Educating devs on what goes where (Meeting topic: DocTeamMeeting)"14:09
annegentleSo I've had a few conversations lately and the TC is working on better definitions for incubation and integration graduation14:10
annegentleAnd there are teams going for incubation who would bring a writer with them, which is nice14:10
annegentleso I'm working on definitions for doc requirements for each stage14:10
annegentlefor incubation, I think dev docs are the only requirement14:10
*** jd__ has quit IRC14:10
*** jd__` is now known as jd__14:10
summerlongannegentle, great idea!14:10
annegentlefor graduation, projects would have to show they are supporting users with their docs14:10
chandankumarannegentle, +114:11
annegentleAlso, I don't think devs are as familiar with our titles as I'd like, so I want to do some sort of education campaign around "what goes where"14:11
annegentleAny thoughts on this?14:11
annegentleTo me, the main titles where we'd want integrated projects to "plug in" are install, config, admin, ops14:11
annegentleSecurity and HA seem secondary14:11
annegentleInput? Ideas on how to educate?14:11
summerlongin the dev session, we were wanting to do a HowTo page for devs?14:11
*** dhellmann-afk is now known as dhellmann14:11
annegentlesummerlong: yes, that's right, Diane is working on a page about the API docs specifically14:12
*** julim has joined #openstack-meeting14:12
annegentlesummerlong: I think we can expand that (or slice it into a second page, here's the titles for deployers/operators)14:12
annegentlesummerlong: but that's the idea14:12
annegentlesummerlong: I wonder if a podcast/ screencast would help? What do you think?14:12
*** garyk has joined #openstack-meeting14:12
annegentleStephen Spector at HP cloud asked for that and I think it's a great idea14:13
summerlongannegentle, for devs? Basic steps, places would work, I'd think.14:13
annegentleI think we have to have the wiki page at a minimum, looking for more ideas too.14:13
annegentlesummerlong: yeah, for devs who want to write and for people looking for info, might work for both.14:14
annegentleI could tweet a title a day for a week :) LOL14:14
annegentleOh twitter.14:14
annegentleblog post maybe?14:14
summerlongannegentle, I meant that the dev personality is not as much a video walkthrough.14:14
annegentleI didn't get a ton of input on the blog post about docimpact but people are reading it14:14
annegentlesummerlong: yeah that's a good point14:14
annegentlesummerlong: match to the personality14:15
*** salv-orlando has quit IRC14:15
summerlongannegentle, a blog sounds good14:15
annegentlesummerlong: maybe a few edits in READMEs scattered throughout the repos would help?14:15
summerlongannegentle, shotgun effect14:15
chandankumarsummerlong, ;)14:16
annegentle#action Anne to write a blog post describing all the titles and their priorities (we'd want integrated projects to "plug in" are install, config, admin, ops; security and HA are secondary)14:16
EmilienMannegentle: Security & HA are secondary but we also need more contributions on it14:16
annegentleEmilienM: very true14:16
annegentle#action Anne to follow up with HP Cloud's Spector for a podcast/screencast14:16
annegentleAnyone want to draft a parallel page to Diane's page?14:17
annegentlewiki page that is14:17
*** arosen has quit IRC14:17
annegentleit's ok if no one can :)14:17
summerlongannegentle, any work items for me will have to wait for a bit until our release in Dec.14:17
*** sgordon has joined #openstack-meeting14:18
annegentlesummerlong: got it, yeah14:18
annegentlehey sgordon14:18
* sgordon slinks in14:18
annegentle#topic Cancel regular office hours now that we meet weekly14:18
sgordonsorry was on another call till 9 and totally forgot14:18
*** openstack changes topic to "Cancel regular office hours now that we meet weekly (Meeting topic: DocTeamMeeting)"14:18
annegentlesgordon: no worries14:18
annegentleSo, I had something else scheduled the last two weeks during office hours, and it seemed okay14:18
annegentlenow that we're meeting weekly is it okay to cancel "office hours" for docs?14:18
annegentleI think it was a good experiment, but not really necessary any more14:19
annegentleok, I'll call it agreed :)14:21
annegentle#agreed Cancel regular office hours now that we meet weekly14:21
annegentle#topic Doc Boot Camp?14:21
*** openstack changes topic to "Doc Boot Camp? (Meeting topic: DocTeamMeeting)"14:21
*** salv-orlando has joined #openstack-meeting14:21
annegentleI left it as a question mark to see what the interest is, do we want another boot camp this release? Do we still call it a boot camp if it's more of what nova and other projects are calling a mid-release meetup?14:21
annegentleWould the goals change if we don't call it boot camp?14:22
summerlongannegentle, what timeframe are you thinking then?14:22
annegentleReally just put it on the agenda to get people thinking about it. At the last one our energy was high and we really wanted to get together again.14:22
annegentlesummerlong: to be similar to last time, it'd be Feb.14:22
*** coolsvap has joined #openstack-meeting14:22
*** jhenner has joined #openstack-meeting14:22
annegentlesummerlong: like end of Feb?14:22
annegentleI'll just throw it out there, for discussion, and discuss next week too.14:23
summerlongFeels very soon after the summit14:23
annegentleI'm still just kind of pondering it, you can probably tell :)14:23
*** maxdml has joined #openstack-meeting14:23
annegentlesummerlong: and I want to figure out what we'd do, for how many days, etc14:24
annegentlegoals for it14:24
summerlongThe two-day span felt right14:24
annegentlewe really had great outcomes from last time, the number of contributors has grown14:24
sgordonyeah - i personally wonder if remote activities might not be a better use of time/resources mid cycle for us - like the bug day for example14:24
annegentlesgordon: yeah that's good input, travel and all is such a time loss in some ways. Esp. if we can all get together at the summit in April14:25
annegentlelet's talk about it and keep it in the agenda for discussion14:25
annegentle#topic Operations Guide workflow14:25
*** openstack changes topic to "Operations Guide workflow (Meeting topic: DocTeamMeeting)"14:25
*** alatynskaya has quit IRC14:26
*** Loquacity has quit IRC14:26
annegentleSo mordred (Monty), jeblair (Jim) and I met with our O'Reilly project manager and editor and technical rep about how to maintain master while enabling a developmental edit and copy edit and indexing on the Operations Guide14:26
*** dkranz has quit IRC14:26
mordredI didn't do it14:26
annegentlethat meeting was yesterday and I just wanted to report back some progress14:26
annegentlemordred: you didn't sign me up for merging, I did :)14:27
*** Loquacity has joined #openstack-meeting14:27
annegentleso what we'll do is as late as possible, like next Jan, create a branch for O'reilly to do copy edits and such in, and I'll backport to master branch14:27
annegentlemordred: keep me honest in case I'm not 'splainin' it right14:27
annegentleso we can keep editing master branch of openstack/operations-guide as much as possible14:28
annegentleand also get the benefits of the custom edit14:28
sgordonannegentle, what is the plan for that guide target wise?14:28
sgordoni.e. havana/icehouse ?14:28
annegentlesgordon: havana14:28
annegentleAlso, in Jan/Feb, we're gonna do a mini 2-day sprint with the original authors14:28
annegentleI'm still working out details there14:28
*** sarob_ has joined #openstack-meeting14:29
summerlongannegentle, RH is still trying to find an Ops person to help. I need to bug them again.14:29
annegentleI'm happy we can keep working in master and not freez14:29
*** ttrifonov is now known as ttrifonov_zZzz14:29
annegentlesummerlong: great14:29
annegentleI keep asking around at Rackspace too14:29
annegentlereally they can update master any time14:30
*** sarob__ has joined #openstack-meeting14:30
annegentleI don't know if the sprint will be all that useful to people new to it, ya know? Not sure.14:30
annegentle2 days, havana updates14:30
annegentlealso, a lot of our planning depends on another meting with O'Reilly so I understand their developmental edit14:30
annegentlepossibly a big rewrite is around the corner and I just don't know it yet14:30
annegentlenot to make people nervous but who knows14:31
annegentleso the next meeting is next Thurs. or Fri. and I'll report what I know then14:31
annegentleOk, last but not least,14:31
annegentle#topic Doc tools updates14:31
*** openstack changes topic to "Doc tools updates (Meeting topic: DocTeamMeeting)"14:31
*** oubiwann has joined #openstack-meeting14:31
annegentle#info The Clouddocs-maven-plugin is now in Stackforge14:32
annegentle#link http://git.openstack.org/cgit/stackforge/clouddocs-maven-plugin/14:32
sgordonsummerlong, cant convince graeme to be volunteered?14:32
annegentleThis enables all openstack contributors to work on the maven plugin that builds our HTML and PDF and api-ref output14:32
annegentlespread the word to all your friends :)14:33
*** sarob_ has quit IRC14:33
chandankumarannegentle, sure14:33
*** oubiwann_ has joined #openstack-meeting14:33
annegentlechandankumar: it should make it easier for you to research the Disqus replacement (and find others to help!)14:34
annegentle(well, easier is relative, that's a BIG project)14:34
chandankumarannegentle, yes14:34
annegentleI'll have to ask reed or fifieldt if they know anything about the ask.openstack.org integration, I don't have any further updates on that.14:34
annegentleWe've updated nearly all of the repos to use 1.12.014:35
chandankumarannegentle, yes14:35
annegentlethat takes care of a pair of XSS vulnerabilities reported14:35
annegentlethat's all I've got!14:35
annegentle#topic Open discussion14:35
*** openstack changes topic to "Open discussion (Meeting topic: DocTeamMeeting)"14:35
annegentleSo yesterday we announced our selections for the GNOME Outreach Program for Women, and I'm pleased to say we got 4 interns starting Dec. 10th!14:36
*** radez_g0n3 is now known as radez14:36
chandankumarannegentle, how to test maven cloud plugin locally in my machine?14:36
*** oubiwann has quit IRC14:36
annegentle#link https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch#Accepted_Participants14:36
annegentleMiranda Zhang will work with Diane as her mentor on the API documentation.14:37
annegentleHP really stepped up and helped out here, for the whole OPW program. (thanks mordred for that lead!)14:37
summerlongAnother pair of eyes just for the API docs, far out.14:37
*** lexx has joined #openstack-meeting14:37
annegentleso, keep an eye out for Miranda and welcome her, help her with reviews, patches, and so on14:37
*** Shaan7 has joined #openstack-meeting14:38
annegentlesummerlong: oh the API docs are sooooo underserved :)14:38
summerlongIndeed, Diane slaving away out in the wilderness14:38
annegentlesummerlong: hee14:39
annegentleI did talk through a few incubation ideas with Doug Hellman on IRC yesterday. One idea, and I like it, is to create a sample "wrapper" book that people can use to write easily-pluggable content for later integration14:39
annegentleso, set up a set of sample generic books for install, for config, that would fit in easily later14:40
annegentleI think that if a project applies now for incubation, the soonest they'd get in to integration is the J release14:40
*** ttrifonov_zZzz is now known as ttrifonov14:40
annegentleand as a doc team, we're not really fully resourced for all integrated projects, so I want to find ways for them to bootstrap14:40
annegentlemaybe write up how to create pluggable content and also how to use pandoc to convert content14:41
annegentlewe can quit early if there's no other open discussion items14:41
annegentleHope you all have a happy Thanksgiving if you gobble turkey in your corner of the world!14:42
summerlongHappy Thanksgiving!14:42
annegentleThanks all!14:42
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"14:42
openstackMeeting ended Tue Nov 26 14:42:52 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:42
openstackMinutes:        http://eavesdrop.openstack.org/meetings/docteammeeting/2013/docteammeeting.2013-11-26-14.01.html14:42
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/docteammeeting/2013/docteammeeting.2013-11-26-14.01.txt14:42
openstackLog:            http://eavesdrop.openstack.org/meetings/docteammeeting/2013/docteammeeting.2013-11-26-14.01.log.html14:42
*** summerlong has quit IRC14:43
*** shaunm has left #openstack-meeting14:43
*** banix has joined #openstack-meeting14:43
*** markpeek has joined #openstack-meeting14:44
*** joesavak has joined #openstack-meeting14:45
*** colinmcn_ has joined #openstack-meeting14:46
*** vijendar has joined #openstack-meeting14:47
*** thedodd has joined #openstack-meeting14:50
*** ttrifonov is now known as ttrifonov_zZzz14:50
*** claytonc has joined #openstack-meeting14:51
*** masayukig has joined #openstack-meeting14:52
*** sarob__ is now known as sarob_14:53
*** sarob has quit IRC14:54
*** colinmcn_ has quit IRC14:55
*** colinmcn_ has joined #openstack-meeting14:55
*** r_m_r has joined #openstack-meeting14:55
*** n0ano has joined #openstack-meeting14:56
*** jroovers has quit IRC14:56
*** ryanpetrello has joined #openstack-meeting14:56
*** toan-tran has joined #openstack-meeting14:57
*** bgorski has quit IRC14:57
*** fnaval_ has joined #openstack-meeting14:58
*** michchap has joined #openstack-meeting14:59
*** adrian_otto has joined #openstack-meeting14:59
*** adrian_otto has quit IRC14:59
*** jgallard has joined #openstack-meeting14:59
*** r_m_r has quit IRC14:59
*** bauzas has joined #openstack-meeting15:00
n0anoanyone here for the scheduler meeting?15:00
bauzasyes, first time here15:00
n0ano#startmeeting scheduler15:01
openstackMeeting started Tue Nov 26 15:01:00 2013 UTC and is due to finish in 60 minutes.  The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot.15:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
*** openstack changes topic to " (Meeting topic: scheduler)"15:01
openstackThe meeting name has been set to 'scheduler'15:01
n0anobauzas, welcome (we don't bite - much :-)15:01
*** dolphm has joined #openstack-meeting15:01
*** armax has joined #openstack-meeting15:01
bauzasn0ano: thanks :)15:01
*** fnaval has quit IRC15:02
n0anoI sent out an agenda but most of the people that are concerned with those items aren't here yet15:02
*** Yathi has joined #openstack-meeting15:02
*** dvarga has joined #openstack-meeting15:03
*** MikeSpreitzer has joined #openstack-meeting15:03
*** michchap has quit IRC15:03
n0anoGiven the US holiday this week this meeting might be a bust15:03
toan-tranI see Boris with memcached based15:04
*** jecarey has joined #openstack-meeting15:04
toan-tranYathi with instance group15:04
jgallardhi all15:04
toan-trancollins cannot join15:04
n0anoboris doesn't appear to be online and yathi hasn't said anything15:04
*** adrian_otto has joined #openstack-meeting15:04
toan-tranwhat is "black box scheduler" ?15:04
n0anoa session from the summit, basically allow the system to use a `black box' scheduler, put in the data and the black box gives the scheduling answer15:05
jgallardthis is the same thing as "scheduling as a service" ?15:05
MikeSpreitzerHow is BB sched different from plugging in a custom scheduler?15:06
bauzasn0ano: is it related to the scheduling-as-a-service thing ?15:06
Yathiis it the session we proposed ? - smart resource placement ?15:06
bauzasjgallard: :)15:06
n0anojgallard, I don't think so, saas is move the scheduler into a separately addressable service, black box is changing the internals of the scheduler15:06
Yathigaryk are you on?15:06
*** dcramer_ has joined #openstack-meeting15:07
alaskiI think a "black box" scheduler would have to be a new scheduler that's plugged in rather than filter_scheduler.  There would have to be a compelling reason for a deployer to use it15:07
garykhi, sorry, was on a call15:07
n0anoYathi, I believe the BB was from the rethinking scheduler design session15:07
jgallardn0ano: ok, thanks for the clarification15:07
toan-trando we have a etherpad on BB?15:07
n0anoone was started at the summit, it should still be there15:08
n0ano#topic black blox scheduler15:08
*** openstack changes topic to "black blox scheduler (Meeting topic: scheduler)"15:08
garyktoan-tran: let me try and look up lifeless's etherpad on the scheduling15:08
toan-trangaryk: thanks15:09
n0anoalaski, yes, I was worried about throwing out the baby with the bath water with this proposal15:09
*** vkozhukalov has quit IRC15:09
YathiIt will be good to have the link... for all the session etherpads.. I seem to have lost it15:09
n0anothe current filter scheduler has some scaling concerns, I don't know that we have to throw it away completely to address them.15:10
MikeSpreitzerI do not see the words "black box" on that index15:10
jgallardMikeSpreitzer: thanks15:10
garykhere is the proposal - https://etherpad.openstack.org/p/icehouse-external-scheduler15:10
*** BillArnold has joined #openstack-meeting15:10
n0anoMikeSpreitzer, that's my interpretation, that's probably not the exact words from the session but I think it describes it better15:10
MikeSpreitzerWhat garyk posted is Robert Collins' proposal15:11
MikeSpreitzerthat's not "black box", that's code refactoring15:11
bauzasn0ano: was it about extending the resource tracker ?15:11
garykMikeSpreitzer: yes, that is correct. it seems be be gaining momentum15:11
garykMy understanding is that the first step will be code moving15:12
garykThen there will be discussion how to make it into a service15:12
bauzasgaryk: agreed, that's the saas goal15:12
MikeSpreitzergaryk: neither of those is "black box", at least as the words are usually construed15:12
n0anobauzas, it was to create a set of constraints that could be fed to an industry standard scheduler code15:12
Yathiblack box, if I remember about the rethinking scheduler design proposal - it is about the multiple scheduler threads15:12
Yathibut can't recollect this being called as black box15:13
bauzasn0ano: ah, so you talk about this one ? https://etherpad.openstack.org/p/IcehouseNovaExtensibleSchedulerMetrics15:13
MikeSpreitzerOK, maybe the problem is just bad wording on today's agenda15:13
alaskiI think there was concern that a solver scheduler would be a black box15:13
Yathias part of the smart resource placement design session - we talked about Solver Scheduler - a constraint based solver15:14
*** bgorski has joined #openstack-meeting15:14
n0anobauzas, no, that's not it either, let me look15:14
Yathia pluggable "black box" so to say!15:14
MikeSpreitzerAny replaceable module in a system is a black box in that sense, alaski, right?  We define its interface, internals are private.15:14
*** dkranz has joined #openstack-meeting15:15
toan-tranpluggable? plugged to what?15:15
n0anofound it - https://etherpad.openstack.org/p/RethinkingSchedulerDesign15:15
toan-tranor openstack in general?15:15
*** nelsnelson has joined #openstack-meeting15:15
alaskiMikeSpreitzer: in a sense yes.  But with the filter_scheduler it's easy to trace how it made its decision, a solver scheduler was considered a potential black box because there's not that same traceability15:15
*** ryanpetrello has quit IRC15:15
*** colinmcn_ has quit IRC15:16
alaskiit's more about debugging issues when the scheduler doesn't return an answer you expect15:16
MikeSpreitzerah yes, I remember that remark15:16
Yathiexactly.. this issue was raised at the session15:16
Yathitraceability may have to be introduced, probably with some logging if it is possible15:17
MikeSpreitzerBut I'm not sure what to do with it.  Are we to shy away from every computation that is not easy to reproduce in someone's head?15:17
*** herndon has joined #openstack-meeting15:18
alaskiIn my opinion, no.  But it can't be the only, or default, option for Nova15:18
alaskibecause the default is used for gating code changes and traceability is a necessity15:19
MikeSpreitzerwhat exactly do you mean by "traceability"?15:19
*** sarob_ has quit IRC15:19
*** sgordon has left #openstack-meeting15:19
Yathiit believe even with filter scheduler - it is a list of filters15:20
*** sarob has joined #openstack-meeting15:20
Yathiso some filters will fail and log ?15:20
*** schwicht has joined #openstack-meeting15:20
alaskiunderstanding why a scheduling decision was made.  If Jenkins fails a gate check because it couldn't schedule an instance, I want to know why15:20
toan-tranalaski: we have logs on every filter15:20
toan-trancant that help?15:20
MikeSpreitzerIn my group's previous work, we developed a replay framework.  Problem instances can be logged completely, and replayed into a test harness for debugging purposes.15:21
MikeSpreitzerEssentially, a formalized kind of log that can be replayed.15:21
n0anoMikeSpreitzer, but how do you know the exact state that the system was in in order to replay things15:22
*** cfriesen has joined #openstack-meeting15:22
MikeSpreitzerThe log contains all the relevant information.15:22
alaskitoan-tran: I'm not sure if there are logs on every filter, but they can be added.  And there is a blueprint for additional logging in the scheduler being worked on15:22
toan-tranalaski: at least the filter_scheduler says which filter returns which hosts15:23
toan-tranof course' it's inside the filer that we have to add log if we need more details15:23
n0anoalways remembering that logging adds overhead, we're already concerned about scheduler efficiency15:23
toan-tranwe also have Error code, although not every detailed15:23
alaskitoan-tran: right.  The filter_scheduler is fine, the concern is regarding a potential new scheduler which is based on more complicated solving methods, or possibly even hueristics15:24
alaskiand by fine I mean not too bad, it could certainly be better15:24
toan-tranalaski: aggreed15:24
*** sarob has quit IRC15:24
MikeSpreitzerRegardless of decision method, same inputs apply, right?15:24
MikeSpreitzerWould it be OK to have a variable level of logging?  Full in the gate, production might be less?15:25
Yathijust to be clear.. the idea is not yet to replace Filter scheduler.. provide an additional option for a scheduler driver15:25
n0anoMikeSpreitzer, I think that's an absolute requirement15:25
cfriesenis logging really expensive?  I thought the issue was mostly the time to pull the data out of the database?15:25
toan-transo basically we need a framework to write the new scheduler, some steps that it must voice the state?15:26
alaskiYathi: yes.15:26
n0anocfriesen, the logs have to be stored somewhere, we're already concerned about DB access, this would just make it worse15:26
alaskiMikeSpreitzer: variable logging would be great15:26
cfriesenwhy not just stream the logs via syslog?15:27
*** venkatesh has joined #openstack-meeting15:27
YathiI think it is about enhancing a decision making engine to be able to clearly log which of the constraints did not satisfy15:27
MikeSpreitzerYathi: getting a log of complete input is non-trivial15:27
MikeSpreitzerbut necessary to replay and explain.15:27
MikeSpreitzerHowever, note that some serious guys do very extensive logging all the time15:28
n0anocfriesen, possible but one of the ideas is creating multiple schedulers, with multiples a single log point would be helpful although maybe I've overthinking things15:28
MikeSpreitzerDo I recall correctly that Google logs a lot all the time?15:28
*** ivasev has joined #openstack-meeting15:28
*** joesavak has quit IRC15:28
YathiI guess I don't have anything else to add here at this point on the logging aspect15:29
toan-tranlog is not good, we should think about creating info objects15:30
MikeSpreitzerI have experience with IBM products that offer variable level of logging.  Our product guys love it.  I hate it when called in to debug a customer problem, they always logged too little, so it always starts with "turn up the logging to XXX and then reproduce the problem"15:30
toan-tranI think we have a blueprint for that15:30
n0anotoan-tran, not sure I understand what you mean about objects15:30
alaskitoan-tran: https://blueprints.launchpad.net/nova/+spec/record-scheduler-information though it's still under discussion15:30
n0anoMikeSpreitzer, but at least that's an option vs. no or minimal logging15:31
*** sacharya has joined #openstack-meeting15:31
MikeSpreitzerWhat we did at first is to make some of our optional logging have a very precise and parseable format, put all information on scheduler problems in there.15:32
*** DennyZhang has joined #openstack-meeting15:32
n0anowell, one take away from this seems to be a concensus that we need to consider logging, especially variable level15:32
MikeSpreitzerLater the product guys got interested in non-optional binary logging of structured data, but I'm not sure how far they have taken it thus far.15:32
n0anoI don't know if there is any kind of loggin standard in OpenStack, anybody know?15:32
russellbopenstack/common/log.py is what everything uses15:33
toan-tranalaski: this is what I'm talking about: https://blueprints.launchpad.net/nova/+spec/add-missing-notifications15:33
toan-tranI remember it has had more information than current version15:34
*** DennyZhang has quit IRC15:34
n0anorussellb, which I believe puts everything in files on the local machine with not level capability15:34
alaskin0ano: there are level capabilities15:34
toan-tranand this one: https://blueprints.launchpad.net/nova/+spec/notification-compute-scheduler15:35
n0anoalaski, which are setable from configuration files/run time?15:35
russellband can use syslog15:35
russellbyes, you configure what levels you want logged15:35
russellband where you want the logs to go15:35
bauzasn0ano: you just set it explicitely15:35
*** DennyZhang has joined #openstack-meeting15:36
n0anosounds like the infrastructure is there then, we just need to make sure all the filters use the logging services properly15:36
MikeSpreitzerAnd if we want to be able to debug scheduler decision making, "properly" means log all the relevant information at the chosen log level.15:37
n0anoMikeSpreitzer, +215:37
*** fnaval_ has quit IRC15:37
toan-tranMike: +115:38
toan-tranthe question is , how we find "relevant"?15:38
bauzasI only played with a global logger for the whole project, don't know if we can have a special logger for scheduling things15:38
*** alexpilotti has joined #openstack-meeting15:38
bauzasafaik, the logger is global to nova15:38
n0anobauzas, I would hope we don't need anything special, standard loggin services should be fine15:38
toan-tranthe problem of text logging is that the developper of a scheduler can write anything in the log15:39
*** eharney has joined #openstack-meeting15:39
toan-tranwhich is not necessarily meaningful to others15:39
bauzasn0ano: then you're fine15:39
MikeSpreitzertoan-tran: that's why I talk about a precisely defined format for the scheduler problem info15:39
toan-tranMike: agreed!15:39
toan-transhould we create a log class for that?15:40
toan-tranput some structure into what is logged15:40
alaskiThat's probably a good idea, but I think there's more immediate work before that becomes a concern15:40
MikeSpreitzerI agree15:41
n0anosome structure is good as long as there is the freedom to add other things that aren't part of the structure15:41
bauzastoan-tran: there is no need for a log class15:41
*** noslzzp has joined #openstack-meeting15:41
*** dhellmann is now known as dhellmann-afk15:41
bauzasyou just have to explicitely define which logger name you want15:42
n0anoI'm feeling that someone needs to create a BP to propose some standardized logging for the current scheduler filters15:42
MikeSpreitzerIn my group's work, we have an internal API to the solver, and it has simple style: input is a whole problem, output is a whole answer.  It is pretty easy to do complete logging in that case.15:42
MikeSpreitzerWe have not had to worry about alternate solvers or alternate schedulers.15:43
toan-tranMike: is it possible to record the state of the system in the log?15:43
n0anoMikeSpreitzer, the filter scheduler is kind of like that, input is the set of possible nodes and output is the set of acceptable nodes15:43
MikeSpreitzerCurrently we log snapshots of the relevant state info.  Alternatively the log could stream updates.15:43
MikeSpreitzerAs alaski said, I think we have beat this horse enough for now.15:44
*** dguitarbite has quit IRC15:44
YathiMike +115:44
n0anoagreed, since Yahti is here let's switch to15:45
*** rnirmal has joined #openstack-meeting15:45
n0ano#topic instance groups15:45
*** openstack changes topic to "instance groups (Meeting topic: scheduler)"15:45
n0anoYathi, do you have an update on this15:45
Yathigaryk you want to say something15:45
*** sacharya has quit IRC15:46
*** herndon has quit IRC15:46
*** akuznetsov has quit IRC15:46
toan-tranwell, since one one say a word, I have a question :)15:47
Yathino major update as of now.  But the plan after the summit was to continue the implementation on a simpler instance group model15:47
n0anolooks like garyk got called away15:47
toan-tranif we intend to make it into nova15:47
toan-trando we keep edge & policy?15:47
Yathia flat group model15:47
Yathiwe do not keep the edge15:47
toan-tranYathi: +115:48
n0anoYathi, I thought there was work needed on the V3 API, is that ongoing15:48
toan-tranwhat about policy, we don't have policy manager either15:48
Yathiyeah I believe it is part of the plan.. to complete what was pending from Havana time..15:48
Yathiwork is needed for V3 API15:49
n0anodo you think that will be controversial or should it be straight forward15:49
* n0ano always worries about API changes15:49
*** briancline has joined #openstack-meeting15:50
cfriesenI've been playing with the current instance groups CLI and have some comments on usability--where do I send feedback?15:50
Yathiwe will sync up again with others - garyk, debo and discuss on the remaining tasks15:51
MikeSpreitzercfriesen: I'm just a newbie here, my guess is the mailing list15:51
*** MarkAtwood has joined #openstack-meeting15:51
Yathiplease send it to  - the dev mailer is the best15:51
MikeSpreitzerbut you can talk to us now too!15:52
*** rbowen has quit IRC15:52
*** DrBacchus has joined #openstack-meeting15:52
cfriesenthere's a bunch of stuff I ran into...like it would be nice to accept human-readable group names in the commands rather than only the full group UUID15:52
MikeSpreitzer+1 in general on that15:52
cfriesenand to me it doesn't make sense to have an "instance-group-add-members" command where the member argument is optional15:52
*** jtomasek has quit IRC15:53
cfriesenwhat does that even mean?  :)15:53
MikeSpreitzerme steps back, waiting for someone who designed that API to answer15:53
* MikeSpreitzer will eventually remember to type a slash before a command15:54
n0anosounds like no one wants to admit ownership, might need to ask that one on the dev mailing list15:54
YathiI think it is  best to compile an email15:54
cfriesenokay, will do.15:54
*** ociuhandu has joined #openstack-meeting15:55
*** jmontemayor has joined #openstack-meeting15:55
n0anoOK, time running down15:55
n0ano#topic opens15:55
*** openstack changes topic to "opens (Meeting topic: scheduler)"15:55
garyksorry, i had internet problems.15:55
n0anoanybody have any opens they want to raise in the few minutes we have available15:55
garykinstance group updates: have posted scheduler changes. pending api changes - debu will work on these next week\15:55
garyksorry for late update15:55
n0anogaryk, NP, we didn't say too many bad things about you :-)15:55
n0anogaryk, yeah, that's what we got, pretty much WIP15:56
*** aguzikova has joined #openstack-meeting15:56
n0anoany other opens15:56
toan-tranI'd like to discuss on SaaS15:56
*** jtomasek has joined #openstack-meeting15:56
toan-tranwell, discuss on SaaS's discussion :)15:56
Yathiyou mean the external scheduler ?15:57
*** fnaval has joined #openstack-meeting15:57
bauzaswe're running out of time15:57
n0anotoan-tran, I would like to discuss it also but we'll need a full session for that15:57
Yathithat might need a lot of time..15:57
n0anoYathi, no might, it will take a lot of time.15:57
toan-tranthat's what I'm saying :)15:57
toan-tranhow we organise discussion on SaaS15:57
jgallardcan we add this item in 1st for next week?15:58
bauzasI was thinking there was a separate meeting on that point, non ?15:58
bauzasno ?15:58
toan-tranI don't know where Collins live15:58
n0anonext week, if possible, I'd like to get Boris on board to talk about memcached, that's the most important immediate topic, we can put SaaS as the 2nd priority15:58
*** marekd|away is now known as marekd15:58
bauzastoan-tran: he lives in NZ15:58
toan-tranif he lives in UTC+1315:58
*** dhellmann-afk is now known as dhellmann15:58
*** reed has joined #openstack-meeting15:59
alaskin0ano: sounds good15:59
toan-tranok so we need another slot15:59
jgallardn0ano: ok, great :)15:59
bauzasthat's what lifeless proposed15:59
toan-trannot scheduler meeting15:59
n0anowe'll discuss further next week15:59
n0anotnx everyone15:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"15:59
openstackMeeting ended Tue Nov 26 15:59:45 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-11-26-15.01.html15:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-11-26-15.01.txt15:59
openstackLog:            http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-11-26-15.01.log.html15:59
*** michchap has joined #openstack-meeting15:59
*** Yathi has quit IRC16:00
*** BillArnold has quit IRC16:00
*** glikson has joined #openstack-meeting16:00
*** pnavarro has joined #openstack-meeting16:00
*** afazekas has quit IRC16:02
*** jgallard has left #openstack-meeting16:02
*** SumitNaiksatam has quit IRC16:03
*** claytonc has left #openstack-meeting16:03
*** michchap has quit IRC16:04
*** MikeSpreitzer has quit IRC16:06
*** DinaBelova has quit IRC16:06
*** igormarnat__ has joined #openstack-meeting16:07
*** igormarnat_ has quit IRC16:07
*** MikeSpreitzer has joined #openstack-meeting16:08
*** hemanth has joined #openstack-meeting16:08
*** SergeyLukjanov has quit IRC16:08
*** hemanth has quit IRC16:09
*** yamahata_ has quit IRC16:10
*** MikeSpreitzer has quit IRC16:11
*** mrodden has quit IRC16:11
*** markwash has quit IRC16:11
*** toan-tran has quit IRC16:15
*** yaguang has quit IRC16:16
*** hemanth has joined #openstack-meeting16:17
*** hemanth has quit IRC16:17
*** terriyu has joined #openstack-meeting16:17
*** dhellmann is now known as dhellmann-afk16:17
*** sacharya has joined #openstack-meeting16:17
*** dcramer_ has quit IRC16:18
*** joesavak has joined #openstack-meeting16:18
*** akuznetsov has joined #openstack-meeting16:18
*** masayukig has quit IRC16:20
*** dcramer_ has joined #openstack-meeting16:20
*** garyk has quit IRC16:21
*** masayukig has joined #openstack-meeting16:21
*** jtomasek has quit IRC16:21
*** mrodden has joined #openstack-meeting16:21
*** venkatesh has quit IRC16:24
*** branen has joined #openstack-meeting16:24
*** litong has joined #openstack-meeting16:24
*** ttrifonov_zZzz is now known as ttrifonov16:24
*** masayukig has quit IRC16:25
*** sarob has joined #openstack-meeting16:25
*** nprivalova has quit IRC16:28
*** belmoreira has quit IRC16:31
*** danwent has joined #openstack-meeting16:31
*** venkatesh has joined #openstack-meeting16:31
*** paragan has quit IRC16:32
*** SumitNaiksatam has joined #openstack-meeting16:35
*** s3wong has joined #openstack-meeting16:35
*** avishayb has quit IRC16:36
*** s3wong has quit IRC16:38
*** zbitter has joined #openstack-meeting16:40
*** ywu has joined #openstack-meeting16:41
*** markwash has joined #openstack-meeting16:42
*** tnurlygayanov_ has joined #openstack-meeting16:43
*** zaneb has quit IRC16:44
*** MarkAtwood has quit IRC16:44
*** coolsvap_ has joined #openstack-meeting16:45
*** coolsvap has quit IRC16:45
*** beagles has quit IRC16:45
*** beagles has joined #openstack-meeting16:47
*** SergeyLukjanov has joined #openstack-meeting16:47
*** Alexei_987 has joined #openstack-meeting16:47
*** bgorski has quit IRC16:48
*** xga_ has joined #openstack-meeting16:49
*** DinaBelova has joined #openstack-meeting16:50
*** masayukig has joined #openstack-meeting16:51
*** doron is now known as doron_afk16:52
*** pnavarro has quit IRC16:52
*** Adri2000 has quit IRC16:54
*** ttrifonov is now known as ttrifonov_zZzz16:54
*** zbitter is now known as zaneb16:55
*** masayukig has quit IRC16:55
*** mrodden has quit IRC16:56
*** doron_afk has quit IRC16:57
*** boris-42 has joined #openstack-meeting16:58
*** flaper87 is now known as flaper87|afk16:59
*** lexx has quit IRC16:59
boris-42Hi all17:00
boris-42jaypipes harlowja hi17:00
*** michchap has joined #openstack-meeting17:00
*** Adri2000 has joined #openstack-meeting17:00
jaypipesboris-42: afternoon :)17:01
boris-42jaypipes okay finally I back from vacation17:02
boris-42so we will have meeting today=)17:02
openstackboris-42: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'17:02
*** fnaval has quit IRC17:02
jaypipesboris-42: I will try to participate. Unfortunately, I have one conf call after another today :(17:02
boris-42#startmeeting Rally17:02
openstackMeeting started Tue Nov 26 17:02:50 2013 UTC and is due to finish in 60 minutes.  The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot.17:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:02
*** openstack changes topic to " (Meeting topic: Rally)"17:02
openstackThe meeting name has been set to 'rally'17:02
boris-42Alexei_987 ping17:04
boris-42harlowja ping17:04
boris-42#topic profiling status17:04
*** openstack changes topic to "profiling status (Meeting topic: Rally)"17:04
*** coolsvap_ is now known as coolsvap_away17:04
boris-42Alexei_987 could you share our document and ideas around current status and problems17:04
boris-42dhellmann-afk ping17:04
*** michchap has quit IRC17:05
Alexei_987which one? :) https://etherpad.openstack.org/p/tomograph-adjustments ??17:05
*** fnaval has joined #openstack-meeting17:05
boris-42Alexei_987 yep this one17:05
boris-42boden ping17:06
*** mrunge has joined #openstack-meeting17:07
*** msdubov has joined #openstack-meeting17:07
*** lsmola has quit IRC17:07
*** mrodden has joined #openstack-meeting17:07
boris-42Alexei_987 so?17:07
*** romcheg has quit IRC17:08
Alexei_987so today I was working on planning how we can use ceilometer as a data collector/storage for our profiling data17:08
boris-42Alexei_987 did you find the way to use it?17:09
*** lexx has joined #openstack-meeting17:09
Alexei_987well I'm still working on it but I already have a rough idea of how it should be done17:09
boris-42Alexei_987 do we need to make some changes in ceilometer?17:09
Alexei_987no :)17:09
*** markmcclain has joined #openstack-meeting17:09
boris-42Alexei_987 or we could use it out of box17:09
*** aguzikova has quit IRC17:09
Alexei_987we'll use openstack/common/ notification system to send data via RPC17:09
boris-42Alexei_987 oh it's nice17:09
boris-42Alexei_987 to ceilometer?17:10
Alexei_987we'll send raw data to it17:10
Alexei_987and our visualization system we'll fetch data from ceilometer and handle the rest (display correct hierarchy)17:10
boris-42Alexei_987 are we are going to face a problem with to much data in ceilometer?17:11
Alexei_987theoretically we may face it17:11
Alexei_987but it's ceilmeter's job to handle it17:11
Alexei_987since it's supposed to be HA data collector17:11
*** marekd is now known as marekd|away17:12
boris-42jd__ ping17:12
Alexei_987so if we actually face such problem we'll have to work on ceilometer to improve it's performance (which is ok for me)17:12
boris-42Alexei_987 do you have some data about how much data we will send to ceilometer17:12
Alexei_987no since we don't have any working prototype for now :)17:12
*** jpich has joined #openstack-meeting17:12
boris-42Alexei_987 ouch=)17:12
Alexei_987but I'm pretty sure that we won't have any problems with that for a long time17:13
Alexei_987it already handles a lot of data so our load won't be too much for it17:13
boris-42Alexei_987 okay17:13
boris-42Alexei_987 so you are going to write new backend for tomograph?17:14
boris-42Alexei_987 how much it will take time? 1-2 days?17:14
Alexei_987well it won't be a backend for tomograph17:14
Alexei_987it will be a new library + ceilometer backend17:14
boris-42Alexei_987 get rid of tomograph?17:14
Alexei_987since tomograph won't be compatible with new data structure17:14
*** eyerediskin has joined #openstack-meeting17:14
Alexei_987you can consider it as tomograph 2.017:14
boris-42Alexei_987 so we are going to drop all current beckends in tomograph?17:15
boris-42Alexei_987 refactor it, and add our ceilometer?17:15
Alexei_987yes since we won't use them anyway17:15
boris-42harlowja ^17:15
Alexei_987true, true17:15
boris-42Alexei_987 okay17:15
boris-42Alexei_987 I hope Tim won't be against17:16
boris-42Alexei_987 so how much you are going to spend time to implement all this stuff17:16
boris-42Alexei_987 ?17:16
Alexei_987well I've underestimated it a little bit in the morning :)17:16
*** mrunge has quit IRC17:17
Alexei_987but I guess I'll have the working profiler till the end of the week17:17
*** boden has joined #openstack-meeting17:17
boris-42Alexei_987 okay17:17
Alexei_987so 2-3 days for new profiler + ceilometer backend17:17
*** gokrokve has joined #openstack-meeting17:17
*** glikson has quit IRC17:17
*** sandeepr has joined #openstack-meeting17:17
boris-42Okay let's then join other topics17:17
Alexei_987have to do a lot of digging in ceilometer code17:17
*** gyee has joined #openstack-meeting17:18
boris-42#topic rally benchmark egine changes17:18
*** openstack changes topic to "rally benchmark egine changes (Meeting topic: Rally)"17:18
*** ativelkov has joined #openstack-meeting17:18
*** sergmelikyan has joined #openstack-meeting17:18
Alexei_987typo ^17:18
boris-42i can't fix it=)17:18
boris-42There are 2 main areas here17:18
boris-42boden could you share details about generic cleanup?17:19
bodenboris-42 yes... The actual impl is complete, and I'm currently working on the UTs for it. In summary the cleanup runs just prior to deleting the users/projects for the benchmark and will cleanup servers, images, networks, volumes,etc..17:20
boris-42boden when you are going to finish work around UTs for this?17:20
*** ildikov has quit IRC17:21
bodenboris-42 in reality not until next week most likely... its a holiday here this week and today is my last day for the week17:21
*** sarob has quit IRC17:21
boris-42boden ok no problem, so we could expect some patches at next monday?17:21
*** sarob has joined #openstack-meeting17:21
*** david-lyle is now known as david-lyle_afk17:22
bodenmonday or tuesday most likely.. I may be some time over vacation to work on it, but not sure17:22
boris-42boden btw could you just push your patch on review (without tests) just to review it?17:22
*** SergeyLukjanov has quit IRC17:23
bodenboris-42 sure... I can do that before vacation --- need to run tox and clean that up 1st17:23
boris-42boden thank you17:23
*** SergeyLukjanov has joined #openstack-meeting17:23
*** sarob_ has joined #openstack-meeting17:23
boris-42Okay next guys is msdubov he is working on changing config of benchmark, so we will be able to run not only "continuously" task but also "periodicaly". Could you explain this change and our current status?17:23
*** vkozhukalov has joined #openstack-meeting17:23
msdubovboris-42 Hi17:24
msdubovboris-42 So currently Rally executes benchmarks for a given number of times according to the user settings in the benchmark config17:25
msdubovLast week we have changed the format of the config, so it has become more flexible17:25
msdubovand also more transparent to the end-user17:25
msdubovFuther work is concentrated on 2 major features:17:25
*** sarob has quit IRC17:26
msdubov1) Implementing benchmark running for a specified amount of time. E.g. we should be able to ask Rally to load the cloud with the benchmark scenario for booting-deleting servers for 10 minutes17:26
msdubov2) Implementing periodic benchmark run: this should enable the end-user to execute any benchmark scenario with given intervals17:27
*** ygbo has quit IRC17:27
*** jcoufal has quit IRC17:27
*** reaper has joined #openstack-meeting17:27
msdubovE.g. launch the boot-delete server scenario taking 1 minute pause after each run.17:27
*** sarob_ has quit IRC17:28
msdubovFinally we plan to implement running multiple benchmark scenarios in parallel so that we can consider one scenario as the main one, while the other scenario as "noise"17:28
msdubovThe mentioned changes are essential for implementing this stuff17:28
*** reed has quit IRC17:28
boris-42msdubov okay so when you are going to finish all stuff around periodic running test? or is it already finish?17:29
msdubovboris-42 So actually the patches for 1) and 2) seem to be ready and are pending for review17:29
msdubovboris-42 as soon as they get merged I'll concentrate on parallel run17:30
boris-42msdubov okay thnaks17:31
boris-42#topic benchmark engines & server providers17:31
*** openstack changes topic to "benchmark engines & server providers (Meeting topic: Rally)"17:31
*** safchain has quit IRC17:31
*** nermina has joined #openstack-meeting17:31
*** MarkAtwood has joined #openstack-meeting17:32
eyerediskinbenchmark engines?17:32
*** venkatesh has quit IRC17:32
boris-42#topic deployers & server providers17:33
*** openstack changes topic to "deployers & server providers (Meeting topic: Rally)"17:33
boris-42Sorry typo=)17:33
boris-42eyerediskin could you share status of deployers & server providers?17:33
eyerediskinthere is 3 patches on review17:34
eyerediskinand one more coming soon (image downloading for virsh provider)17:34
*** evgenyf has quit IRC17:35
eyerediskinboris-42: this one is done long time ago https://review.openstack.org/#/c/48811/17:35
boris-42eyerediskin so I should review it?)17:36
eyerediskinlxc engine and multihost provider: https://review.openstack.org/#/c/57240/ https://review.openstack.org/#/c/56222/17:36
boris-42eyerediskin did you test LXC providers?)17:36
boris-42eyerediskin I mean in real life?17:36
eyerediskinboris-42: all 3 was tested many times with different configs17:37
eyerediskinand some bugs was fixed since first patchset =)17:37
*** marekd|away is now known as marekd17:38
*** Fdot has quit IRC17:38
*** coolsvap_away has quit IRC17:38
*** markmcclain has quit IRC17:39
*** IlyaE has joined #openstack-meeting17:39
*** anniec has joined #openstack-meeting17:40
*** bknudson has joined #openstack-meeting17:40
boris-42eyerediskin okay I will review them=) msdubov  Alexei_987  you should also review that patches ^17:40
Alexei_987boris-42: I'm reviewing stuff when I have free time :)17:40
boris-42Alexei_987 if I will be such reviewer, I won't made any review=)17:41
*** FallenPegasus has joined #openstack-meeting17:41
msdubovboris-42 Okay will do that tomorrow17:41
boris-42#topic split deploy & benchmark workflow17:42
*** openstack changes topic to "split deploy & benchmark workflow (Meeting topic: Rally)"17:42
Alexei_987boris-42: ok :) I'll spend at least 2 hours each day for reviews :)17:42
boris-42Alexei_987 it is too much I think 1hrs is enough=)17:42
Alexei_987boris-42: multiply all my estimates by the pow of 3.1417:42
boris-42Okay we have critical arch bug, we were not able to use deployment system of Rally for benchamrking17:43
*** dolphm has quit IRC17:43
*** dolphm has joined #openstack-meeting17:43
Alexei_987why not?17:44
*** rongze has quit IRC17:44
boris-42because we should specify it task.conf information about image_uuid, and flavor_id that we are not able to get before we make deployment17:44
boris-42and task.conf is specified before deployment process is started =)17:44
*** fabio has joined #openstack-meeting17:44
Alexei_987hm.. :)17:44
Alexei_987we should have this stuff predefined17:45
boris-42Alexei_987 actually there is a lot of another issues17:45
boris-42e.g. we were not able to deploy openstack and run multiple benchmarks agains it17:45
boris-42So we chose the way to split deploy/benchamrk parts17:46
boris-42And now Rally it 2 click17:46
Alexei_987yeah but it means that we don't need deploy at all17:46
boris-42Alexei_987 hm why?17:46
*** fabio is now known as fabiog17:46
Alexei_987we have tripleO + fuel + devstack17:46
Alexei_987+ any other manual deploy17:46
boris-42Alexei_987 it is not manual at all17:46
boris-42Alexei_987 it is in 1 click17:46
boris-42Alexei_987 like before17:47
Alexei_987no.. I mean that we can just agree that we are already have Openstack running17:47
Alexei_987and delegate deploy part to something else17:47
boris-42Alexei_987 nope17:47
*** mrodden has quit IRC17:47
*** jumper4567 has joined #openstack-meeting17:47
boris-42Alexei_987 try to deploy OpenStack with DevStack in LXC containers on Amazon VMs17:47
Alexei_987why should I?17:48
Alexei_987I mean rally's purpose is profiling not deploy17:48
*** romcheg has joined #openstack-meeting17:48
boris-42Alexei_987 ehmmmm17:48
boris-42Alexei_987 no17:48
boris-42Alexei_987 no17:48
*** jumper4567 has quit IRC17:48
boris-42Alexei_987 it is the system that makes benchmark of openstack at scale simple17:49
Alexei_987ok so profiling + benchmark17:49
boris-42deploy + benchmark + results processing + profling17:49
*** jumper4567 has joined #openstack-meeting17:49
boris-42and there are also now another use case17:49
*** rossella_s has quit IRC17:49
boris-42about generating real workloads17:49
Alexei_987IMHO too many responsibilities17:49
Alexei_987ok forget it17:50
*** jumper4567 has quit IRC17:50
Alexei_987let's get back to the topic17:50
boris-42If I am not able to get 1k servers deployment in one click in venv17:50
*** IlyaE has quit IRC17:50
boris-42I don't need other parts17:51
boris-42I don't need benchmarks and profiling at all17:51
boris-42because deploy process is to complicated even if you are using FUEL/TrippleO/Anvil/Devstack17:51
*** anniec has quit IRC17:51
Alexei_987 boris-42: exactly17:51
boris-42So our goal is not to reinvent and make new deployer for OpenStack17:52
Alexei_987 boris-42: and you want us (2-3 devs) to make something that is more powerfull17:52
boris-42just to use existing17:52
*** masayukig has joined #openstack-meeting17:52
*** sarob has joined #openstack-meeting17:52
boris-42and simplify and unify work with them (so to get good deployment for deployers without any knowledge about how the hell I should deploy openstack)17:53
*** joesavak has quit IRC17:53
ogelbukhboris-42 wants to be able to configure and ignite delployment tool from rally17:53
ogelbukhany deployment tool, eventually17:53
boris-42ogelbukh yep17:53
*** jumper4567 has joined #openstack-meeting17:53
*** masayukig has quit IRC17:53
boris-42ogelbukh by specifying all configurations that could be specifed17:54
boris-42ogelbukh so to make it simple to use17:54
*** masayukig has joined #openstack-meeting17:54
ogelbukhyou need good configuration model then )17:54
boris-42ogelbukh without any knowladge17:54
*** derekh has quit IRC17:54
boris-42ogelbukh I think that current stuff is pretty good17:54
*** tnurlygayanov_ has quit IRC17:54
boris-42ogelbukh we just need to split deploy/benchamrk workflows17:54
*** vipul is now known as vipul-away17:54
ogelbukhthat's for sure17:54
boris-42ogelbukh and I think that during this week we will finish work on that17:54
*** jumper4567 has quit IRC17:55
boris-42ogelbukh there are just few patches that should be merged17:55
ogelbukhlooking forward to it17:55
*** jumper4567 has joined #openstack-meeting17:55
boris-42ogelbukh https://review.openstack.org/#/q/status:open+project:stackforge/rally+branch:master+topic:bp/independent-deploy,n,z17:55
Alexei_987 boris-42: 5 minutes left :)17:55
ogelbukhwe'll need this stuff really soon )17:55
*** shardy has joined #openstack-meeting17:56
*** markpeek has quit IRC17:56
boris-42#topic Okay last topic is make Rally as a Service17:56
*** openstack changes topic to "Okay last topic is make Rally as a Service (Meeting topic: Rally)"17:56
*** markpeek has joined #openstack-meeting17:56
*** hemnafk is now known as hemna17:56
boris-42We should determine API that should provide Rally services17:56
*** FallenPegasus has quit IRC17:56
*** anniec has joined #openstack-meeting17:56
boris-42so we started this ether pad https://etherpad.openstack.org/p/rally-service-api17:57
ogelbukhnice )17:57
boris-42I will also make some email in mailing list about this=)17:57
boris-42so everybody that would like to discuss this will be able to take a part17:57
*** jlibosva has quit IRC17:58
boris-42Service is actually very important17:58
*** twoputt has joined #openstack-meeting17:58
*** twoputt_ has joined #openstack-meeting17:58
boris-42because it is base step to make WEB UI for Rally17:58
*** jlibosva has joined #openstack-meeting17:58
*** nati_ueno has joined #openstack-meeting17:58
boris-42that will be our next major goal17:58
boris-42#topic free discussion17:58
ogelbukhboris-42: and many other things, I dare to say )17:58
*** openstack changes topic to "free discussion (Meeting topic: Rally)"17:58
*** masayukig has quit IRC17:58
boris-42I think that there will be no free discussion today=)17:59
boris-42because we don't have enough time=)17:59
ogelbukhbtw, found this tool for api design: apiary.io17:59
ogelbukhlooks neat17:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:59
*** nati_ueno has quit IRC17:59
openstackMeeting ended Tue Nov 26 17:59:37 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/rally/2013/rally.2013-11-26-17.02.html17:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/rally/2013/rally.2013-11-26-17.02.txt17:59
openstackLog:            http://eavesdrop.openstack.org/meetings/rally/2013/rally.2013-11-26-17.02.log.html17:59
*** jumper4567 has quit IRC17:59
boris-42ogelbukh what is this?)17:59
*** nati_ueno has joined #openstack-meeting18:00
boris-42ayoung lol18:00
morganfainbergayoung, share with the rest of the class?18:00
lbragstadmorganfainberg: +118:00
*** sarob has quit IRC18:00
*** otherwiseguy has joined #openstack-meeting18:00
gyeefree the birds!18:00
*** Alexei_987 has left #openstack-meeting18:00
*** nachi has joined #openstack-meeting18:01
*** jamielennox has joined #openstack-meeting18:01
*** michchap has joined #openstack-meeting18:01
dolphmi assume a few people are MIA this week18:01
*** igormarnat__ has quit IRC18:01
* morganfainberg is mia mentally.18:01
morganfainberg*shifty eyes*18:02
gyeemorganfainberg, same here18:02
dolphmwas hoping henrynash would be here, as filtering is icehouse-m1 targetted18:02
*** mrunge has joined #openstack-meeting18:02
dolphm#startmeeting keystone18:02
openstackMeeting started Tue Nov 26 18:02:47 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.18:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:02
*** openstack changes topic to " (Meeting topic: keystone)"18:02
openstackThe meeting name has been set to 'keystone'18:02
dolphm#topic icehouse-m118:02
*** openstack changes topic to "icehouse-m1 (Meeting topic: keystone)"18:02
dolphmis next week!18:02
*** marekd-mobile has joined #openstack-meeting18:03
dolphmour list of BP's is very short18:03
morganfainbergso soon!18:03
*** bradjones has joined #openstack-meeting18:03
ayoungM1  always catches people by surprise18:03
dolphmi bumped quotas to m2 recently, as warranted by the additional discussions at the summit18:03
morganfainbergayoung, no one expects M1 (eh, it's missing something)18:03
dolphmayoung: ++18:03
*** reed has joined #openstack-meeting18:03
ayoung#link https://launchpad.net/keystone/+milestone/icehouse-118:03
dolphmdstanek is working on two other bp's that i'm hoping to have merged this week18:04
dolphmi think updates are in progress for both, but:18:04
dolphm#link https://review.openstack.org/#/c/50491/18:04
dolphm#link https://review.openstack.org/#/c/52456/18:04
*** colinmcnamara has joined #openstack-meeting18:04
dolphmayoung: danke18:04
ayoungCode review or implemented for all.18:04
dolphmif there are any other blueprints that should be targeting m1 - speak up!18:04
*** ttrifonov_zZzz is now known as ttrifonov18:05
*** eyerediskin has left #openstack-meeting18:05
ayoungseriously, though, it should have been18:05
*** dstanek has joined #openstack-meeting18:05
dolphmthat mailing list discussion is very indecisive -- i thought we had a firm direction on that early last week18:05
jamielennoxyes, well KDS doesn't look like it did at the end of H18:05
dolphmnow it should be in barbican and in keystone and it's own standalone service18:05
*** michchap has quit IRC18:05
morganfainbergdolphm, the decision i'm hearing is, in keystone, move to it's own thing or barbican later18:06
*** cfriesen has left #openstack-meeting18:06
bknudsonI'm still a little confused about KDS -- PKI is no good, but you're going to need PKI anyways for SSL.18:06
*** uaberme has quit IRC18:06
morganfainbergdolphm, otherwise you need to use a non-integrated project to secure messaging18:06
jamielennoxso my understanding is we are going with keystone extension - ?18:06
morganfainbergdolphm, and separate wSGI/port18:06
*** anniec has quit IRC18:06
jamielennoxi disagree on the seperate port18:06
jamielennoxor at least i don't see any reason for it18:06
dolphmmorganfainberg: then it might as well be based on falcon or pecan/wsme18:07
morganfainbergjamielennox, isolation since it'll move out of keystone18:07
ayoungjamielennox and I discussed this.18:07
bknudsonshouldn't need a separate port... that's what resource paths are for.18:07
jamielennoxbut it's still going to have to live in keystone/contrib anyway18:07
morganfainbergdolphm, i guess the last part, port/wsgi is not needed.18:07
ayoungI suggested a separate port to facilitate splitting it of completely18:07
dolphmbknudson: ayoung wants it to be a standalone service18:07
gyeeif its an *internal* service, why does it matter where you stash it as anything internal is subject to change18:07
bknudsonI thought ayoung wanted everything in httpd?18:07
ayoungdolphm, still do...but we have committments to meet18:08
ayoungbknudson, this is tactical, not strategic.  I don;t want KDS in Keystone long term18:08
jamielennoxif the config file is point to the base_url for KDS then it should make no difference if it is KDS=http://localhost:5000/v3/OS-EXT-KDS/v1 or KDS=http://localhost:8888/v118:08
morganfainbergso, short answer, it looks like it should be in keystone until it can be split. - and i'm fine with that.18:08
dolphmbknudson: so, supported and reviewed by keystone-core, but a completely separate standalone service that has nothing to do with identity18:08
ayoungand I sort of agree with jamielennox on his point18:08
dolphmthat means it's own catalog entry, etc18:08
jamielennoxbefore dolphm and ayoung's patch to port it various place i had mostly done a port to it's own service based on pecan/wsme18:09
bknudsonit's a good idea to have a catalog entry if it's going to move.18:09
ayoungbut still think we will have less trouble splitting it if we get people starting from KDS root instead of auth_url...18:09
morganfainbergayoung, dolphm, i think it needs to be in the catalog and be discoverable.18:09
dolphmjamielennox: is that in review somewhere?18:09
ayoungmorganfainberg, hells not18:09
jamielennoxi was hoping that i could just drop it in as an extension using wsme and pecan in a way that it is easily extractable18:09
ayoungno no no no no18:09
morganfainbergayoung, discoverable at least.18:09
jamielennoxdolphm: not finished18:09
ayoungmorganfainberg, not our job to do that18:09
jamielennoxno KDS should not be in the servcie catalog18:09
ayoungyou are lifting up the side of the tent and inviting the camel in18:09
dolphmayoung: you're asking for it to be a separate service, but you don't want it to be discoverable?18:09
morganfainbergayoung, so hard set uri?18:09
ayoungsop many things need to be discoverable in the undercloud....but it is not for us to say how that is to be done18:10
lifelessbauzas: I live in NZ - UTC+1318:10
dolphms/undercloud/meaningful language/g18:10
ayoungdolphm, it is no different than compute figuring out where the RPC server/message broker is.18:10
morganfainbergdolphm, in the triple-o sense, the management layer (e.g. nova processes themselves)18:11
morganfainbergkeystone service, not to be confused by something an end-user would access/consume to make an instance/project/etc18:11
lifelessmorganfainberg: oh man, so thats not the tripleo sense :)18:11
ayoungdolphm, undercloud has come to be a useful term...out of tripleO to distinguish between the services exposed to end users vs those that are Internal to the OS deployment.18:11
lifelessthe undercloud is the openstack infrastructure deploying cloud.18:11
jamielennoxdolphm: KDS is going to be similar to configuring MySQL or AMPQ. It is not a service that is used at a client level18:11
morganfainberglifeless, ok ok fine, in the not-so-triple-o-sense18:11
morganfainberglifeless, in the.  not public consumption sense.18:12
dolphmlifeless: ++18:12
bknudsonI think there's a DBaaS project.18:12
ayoungso my suggesting:  use jamielennox 's pecan approach, but kick it off from keystone-all18:12
*** aguzikova has joined #openstack-meeting18:12
dolphmayoung: why do you want it to be started by keystone-all? why not just bin/keydist or something?18:13
dstanekayoung: in the same process or using a different port?18:13
jamielennoxyou can nest wsgi applications, so there should be no reason that the pecan/wsme app can't live and run as an extension18:13
bknudsonI don't have a problem with it as a different service.18:13
ayoungbknudson, that is for end user consumption...just like Barbican was supposed to be.18:13
morganfainbergif it's a separate service, keystone-all seems like the wrong place to start it.18:13
dolphmmorganfainberg: ++18:13
lifelessmorganfainberg: a key (har har) thing to note is that the nova cloud we deploy - the overcloud - can only use public services from the undercloud (e.g. heat) - so if KDS was 'within the cloud only' we'd deploy one KDS per overcloud.18:13
fabiogmorganfainberg +18:13
bknudsonshouldn't call it keystone-all if it doesn't start everything18:13
lifelessmorganfainberg: rather than one in the undercloud and use it from the overcloud18:13
dolphmmorganfainberg: i'd rather get as much of the separation correct from the beginning18:13
bknudsonchange it to keystone-some18:13
morganfainbergbknudson, but KDS isn't... keystone really.18:13
*** sushils has quit IRC18:13
dolphmbknudson: but it's not keystone-*18:13
morganfainbergdolphm, ++18:13
morganfainberglifeless, as stated above, KDS would be like ZMQ or AMQ18:14
bknudsonso a new bin/kds ?18:14
ayoungdolphm, you know what, that works too.  not keystone-all, but kdsd  or something works for me18:14
*** henrynash has joined #openstack-meeting18:14
* mordred lurking, reading through scrollback - I hear we're talking about fun things18:14
dolphmbknudson: yeah18:15
dstanekso what i'm hearing so far is new start script in bin and new service on a new port18:15
bknudsonI don't have a problem with a separate bin... seems like an impl detail.18:15
dstanekis that right?18:15
ayoungjamielennox, would bin/kdsd make more sense?  And then not an extension?18:15
dolphmdstanek: ++18:15
*** anniec has joined #openstack-meeting18:16
jamielennoxayoung: i'm still advocating the extension makes more sense, but if the consensus is new service then so be it18:16
jamielennoxi just want the consensus part18:16
*** atiwari has joined #openstack-meeting18:16
dstanekjamielennox: why do you think it makes more sense?18:16
bknudsonwhat's the port for kds?18:16
dolphm#agreed kds to have it's own bin/* startup script to run on it's own port18:16
bknudson(default port)18:17
*** DennyZhang has quit IRC18:17
jamielennoxdstanek: the reason for it being a new service is purely so it is easily extractable later - i don't think that this makes any sense as we can already nest all the kds info into the extension18:17
jamielennoxand this is what extensions are for18:17
ayoungjamielennox, new service, with an eye to completely extracting it from the keystone code base.18:17
ayoungbknudson, port 8818:17
dolphmbknudson: random(1025, 32767)18:17
fabiogdolphm: I would like to come to a conclusion with the OS-SHARED-SECRET, please. It has been around for too long ...18:18
* ayoung waits for you all to look in /etc/services for port 8818:18
dolphmfabiog: it's on the agenda18:18
*** gokrokve has quit IRC18:18
dolphmfabiog: kds has been around far longer :)18:18
fabiogdolphm: thanks, just checking we will have time for it ...18:18
*** gokrokve has joined #openstack-meeting18:18
jamielennoxso out of interest where does a new service in keystone live (code wise)18:18
jamielennoxtop level? keystone/kds18:18
morganfainbergjamielennox, there was some talk of a new repo18:19
ayoungjamielennox, we can leave it in contrib for now18:19
jamielennoxmorganfainberg: can't happen for now18:19
morganfainbergbut contrib is the right place18:19
dolphmjamielennox: sure -- it'd be nice if it didn't import anything from outside keystone.kds though :)18:19
dolphmjamielennox: you could also isolate it's testing infrastructure -- keystone.tests.kds.*18:19
ayoungdolphm, it just uses some keystone.common which should be acceptable18:19
bknudsonis there going to be a kds-manage ?18:19
mordreddolphm: well, maybe keystone.openstack.common18:19
mordredayoung: ++ :)18:19
dolphmayoung: --18:19
jamielennoxdolphm: yep that was the idea - openstack.common was the only one i had to share18:19
bknudsonto create the db tables.18:20
dolphmmordred: ++18:20
ayoungbknudson, so far, no.  If we need it, then we will add it.18:20
dolphmjamielennox: cool18:20
mordredtests in kds.tests should work too18:20
dolphmjamielennox: make it as easy as possible to move to a top level project18:20
mordredshoudl be found by test discovery - doesn't matter - we do that in horizon18:20
dolphmjamielennox: or if barbican is the correct home for it, base it on falcon...18:20
ayoungWe have a plan?  Itsounds like we have a plan.18:20
mordredonly thing that can be split split is distribution targets - only one setup.py/tarball output18:21
dolphmmordred: that works for me keystone.kds.tests18:21
mordreddon't base anyhting on falcon please18:21
jamielennoxdolphm: my understanding is that we can mix pecan/wsme and keystone - but falcon is a framework as well18:21
morganfainbergmordred, pecan/wsme?18:21
jamielennoxsorry, falcon is a server as well18:21
morganfainbergmordred, ok18:21
dolphmmordred: fine by me18:21
mordredwe've got to stop having framework wars around here18:21
mordredcause eek18:21
ayoungI thought Barbican was a project, and Cloud Keep was a program.  Did that change?  KDS should stay its own project18:21
dolphmmordred: pecan/wsme is more tempting to me for keystone, long term18:21
*** mrunge has quit IRC18:22
morganfainbergmordred, lets make our own framework, that is subtly different and standardize on that /s (xkcd ref in here somewhewre)18:22
dolphmayoung: that's still the case18:22
ayoungIt can be under the CLoudKeep program then, when it spins up18:22
mordredmorganfainberg: YES! do that18:22
dolphmmorganfainberg: is that not keystone.common.wsgi lol?18:22
mordred(programs usually have descriptive names. /me stop trolling)18:22
morganfainbergdolphm, oh no, we need something new!18:22
*** gokrokve has quit IRC18:23
dolphmmorganfainberg: oh right! keystone.common.superwsgi18:23
morganfainbergdolphm, *stops being snarky / off topic*18:23
*** boris-42 has quit IRC18:23
ayoungjamielennox, do you have enough to execute off of here?18:23
dolphmjamielennox: so, what milestone are we looking at :)18:23
dolphmjamielennox: m2? possible for nova to consume by m3?18:23
bknudsonkds looks like a lot of work18:23
jamielennoxdolphm: well it's not m118:23
bknudsonlots of code18:24
jamielennoxm2 should be fine18:24
morganfainbergjamielennox, m2 would be _very_ good18:24
bknudsonI just hope it doesn't get dumped on us in one big review.18:24
jamielennoxbknudson: 1 for framework, 1 for host keys, 1 for group keys18:24
dolphmjamielennox: do you have a link to the bp for kds?18:24
lbragstadbknudson: +118:24
dolphmi can't find it...18:24
*** herndon has joined #openstack-meeting18:24
ayoungWe have nkinder from RH engaged as well. He is going to take a swipe at the API doc for KDS18:24
morganfainbergayoung, ++ nice.18:25
*** nkinder has joined #openstack-meeting18:25
morganfainbergayoung, hopefully it isn't too much work to get it into shape18:25
ayoungmorganfainberg, he's the Manager for Dogtag, and has a strong crypto background.18:25
dolphmayoung: thank you!18:25
bknudsonjamielennox: 6 for framework, 8 for host keys, 4 for group keys.18:25
nkinderayoung: hi all18:25
morganfainbergayoung, woot!18:25
morganfainbergnkinder, yay!18:25
ayoungnkinder, was just saying...18:25
ayoungWe have nkinder from RH engaged as well. He is going to take a swipe at the API doc for KDS18:25
dolphmalright, let's move on18:25
*** msdubov has quit IRC18:25
jamielennoxbknudson: takes me long enough to get my regular reviews past18:25
dolphmjamielennox: poke me with the bp link if you have it18:26
bknudsonjamielennox: because they're too big!18:26
jamielennoxdolphm: this is the oslo one: https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging18:26
nkinderYep.  It's on my list for the thanksgiving break18:26
morganfainbergnkinder, very awesome.  and thanks!18:26
nkinderI'm curious to know how much belongs in the API doc vs. Keystone docs?18:26
jamielennoxmaybe there isn't one for keystone... /me inheritted a lot of this18:26
dolphm#link https://blueprints.launchpad.net/keystone/+spec/key-distribution-server18:26
nkinderSome of this is really implementation behind the API18:27
bknudsonnkinder: implementation doesn't belong in api doc.18:27
gyeeif you use wsme, you auto generate the docs?18:27
dolphm#topic Password rotation18:27
*** openstack changes topic to "Password rotation (Meeting topic: keystone)"18:27
morganfainbergnkinder, https://review.openstack.org/#/c/40692/ is the original api doc18:27
ayoungnkinder, we were thinking more along the lines of "how would an end user actuall consume this, and what would they expect"18:28
morganfainbergnkinder, if that helps.18:28
dolphmfabiog: o/18:28
ayoungOK, so multiple shared secrets is bad18:28
gyeeayoung, is a business use case18:28
MarkAtwoodbut useful18:28
ayoungI've been reviewing, discussing, and stick to my guns on this one.18:28
ayounggyee, then do it outside of Keystone18:28
ayoungor use the exsitng abstractions differently18:28
gyeeayoung, services needs to integrate with it18:28
ayounggyee, no they don18:29
gyeeits been propose as *an extension*18:29
ayounggyee, no18:29
ayoungit is an end run around security18:29
dolphmgyee: you can always publish extensions out of tree18:29
fabiogayoung: and it is using the same concept as EC2, that is already there18:29
ayoungdo it outside of Keystone altogether if you like18:29
*** vipul-away is now known as vipul18:29
MarkAtwoodand fork the keystone protocol18:29
*** IlyaE has joined #openstack-meeting18:29
bknudsonit's a lot of work to maintain something out of tree...18:30
gyeethis is no different than KDS, Trust, or OAUTH18:30
lbragstadbknudson: +118:30
bknudsonespecially since we have no guarantee of internal API stability18:30
gyeewhy is this an exception?18:30
fabiogbknudson +18:30
dolphmbknudson: it's a lot of work for keystone-core to maintain features that aren't consumed by openstack as well18:30
morganfainbergfabiog, MarkAtwood, really quickly, you want to avoid using the current credential implementation? it seems to already hit the mark, just without the "password" mechanism directly18:30
gyeedolphm, CI/CD and other service are waiting to integrate, so I heard18:30
*** xga__ has joined #openstack-meeting18:31
MarkAtwoodmonty, would CI use it if it was in?18:31
ayoungthe list of potential security concerns with multiple passwords/symetric shared secretes far outweighs the benefits.18:31
gyeeayoung, what security concern? the risk is no different that passwords18:31
gyeedid you read my responses in the review?18:32
ayounggyee, it multiplies the issues with passwrods, and adds in the "oh, I disabled this one, but that one is still active"18:32
dolphmayoung: that seems very backwards to me - do you have reasoning?18:32
MarkAtwoodgoogle does it, amazon does it, fb auth does it18:32
bknudsonone could use an ldap server that supported multiple passwords.18:32
bknudsonnot sure if there are any, but if you had your own ldap implementation...18:32
gyeeayoung, you disable a user, not a password18:32
fabiogmorganfainberg: we need an auth method to leverage the current credential API18:32
*** ruhe has quit IRC18:32
mordredwait - can someone talk to me very shortly like I'm a moron?18:32
nachigyee +18:33
*** acoles has joined #openstack-meeting18:33
dolphmgyee: users aren't much more than passwords anyway :)18:33
mordredis this about the rackspace extension that's not compatible with anything ?18:33
mordredwe stoped using that in infra18:33
mordredbecause it's not in keystone for real18:33
MarkAtwoodmordred, no its about the one that hpcloud is running18:33
mordredwe don't use that either18:33
gyeedolphm, points is once you disabled a user, all his credentials are effectively disabled18:33
bknudsonis hpcloud using this already?18:33
gyeeeasy to contain the risk18:33
MarkAtwoodif it was in keystone, would you use it?18:33
ayounggyee, right now, the "user" object is really an ID and a  password.  There is nothing more to it.  The same thing that you were trying to do with multiple shared secrets can be done with multiple user accounts.  Yes, it complicates external systems mapping one external acount to Keystone, but that is not a keystone issue.18:33
morganfainbergmordred, no. this would be to be able to rotate passwords without eliminating access until it is explicitly revoked18:33
mordredcan anyone explain to me, in very simple terms, why haivng an api key is better than having a password?18:33
MarkAtwoodyes we are, we want to give this work to the community18:34
ayoungI see no benefit to contributing to the mess that is the Keystone password system already18:34
mordredwhen the password gives me access to muck with api keys?18:34
MarkAtwoodbasically ALL of our industrial users are using the feature18:34
*** xga_ has quit IRC18:34
dolphmayoung: agree - the only downside (at minimum) is having to manage group membership to apply authorization18:34
morganfainbergmordred, that is the crux of the argument, but in short the argument is to allow access w/o having to change all systems that use that password at once (rolling auth change)18:34
bknudsonseems like if it's been implemented somewhere already for some time and have found it useful then that's a good candidate to go into keystone proper.18:34
jamielennoxmordred: as i understand it the main benefit would be allowing different api keys on for example different nova hosts but still sharing the same service user18:34
dolphmayoung: multiple 'passwords' per user ID avoids the re-assignment problem18:34
jamielennoxi don't think this is about rotation yet18:34
ayoungdolphm, and, if they use external auth, the logic that they want can be done, without adding anything to keystone18:35
MarkAtwoodour users assign a different "application password" to each app or subsystem18:35
mordredok. I can see why people might want that18:35
mordredwell, some of your users do18:35
*** acoles_ has joined #openstack-meeting18:35
mordredsome of us just use the one password18:35
MarkAtwoodand then can track which ones are being used, and can disable indivual ones, and set expirations for them18:35
morganfainbergmordred, jamielennox, rotation is part-in-parcel of this but it is a side effect.18:35
*** ruhe has joined #openstack-meeting18:35
jamielennoxmorganfainberg: yea, it allows rotation but it's a side effect18:35
morganfainbergwhat MarkAtwood  just described ^18:35
ayoungSo if you want multiple passwords, go for it, but use basic-auth and external, and then map from the credential to the user id in an auth plugin18:35
MarkAtwoodayoung, can you explain basic-auth to me and "external"18:36
gyeeMarkAtwood, means using Apache :)18:36
gyeeor Nginx18:36
MarkAtwoodhttp basic auth cannot be trusted to go through SSL accelerations and load balancers18:36
ayounggyee, or even in Keystone18:36
bknudsondoesn't seem like any clients actually support using basic-auth.18:36
*** acoles has left #openstack-meeting18:36
mordredayoung: I would like for our public clouds to stop having divergent auth methods18:36
*** DinaBelova has quit IRC18:36
mordredayoung: because that's the first thing people interact with18:37
ayoungMarkAtwood, basic auth is the HTTP mechanism for userid and password18:37
*** SergeyLukjanov_ has joined #openstack-meeting18:37
gyeebknudson, nope, not right now18:37
ayoungI have a proof of concept...one sec18:37
mordredand if you have to do something 'special' that's not discoverable18:37
dolphmMarkAtwood: interesting, i've never thought about that18:37
MarkAtwoodayoung, it doesnt work.  i have been down this path when writing OAuth18:37
mordredto conenect to rackspace and to connect to hp18:37
*** SergeyLukjanov has quit IRC18:37
mordredthen we're not interoperable18:37
mordredand all of openstack dies18:37
mordredthis is the reason I'm so generally pissed off about the rackspace auth extension18:37
*** ativelkov has quit IRC18:37
mordredbecause it's TECHNICALLY a legal auth extension18:37
MarkAtwoodbasic auth looks great, excpe that load balancers mangle it, transparent proxys mangle it, ssl accelerators mangle it, and apache does not pass it down to the app18:37
mordredbut it changes the user experience in ways they have to know more than "this is an openstack cloud"18:38
mordredso if this is an issue that we know is going to make all of our public clouds diverge from what openstack is - I think that's a Really Bad Thing18:38
bknudsonmordred: I hope that doesn't mean we're stuck with least-common-denominator (user+password)18:38
mordredTHAT SAID18:38
gyeemordred, we can propose it a core if makes you a happier man :)18:38
dolphmmordred: ++18:38
MarkAtwoodhp's fallback is to stop this merge effort and put it under the HPAPI: extenstion, which just makes it worse18:38
mordredthe public clouds should have more devs working on keystone18:38
gyeecore API I mean18:39
dolphmmordred: working on it!18:39
MarkAtwoodmordred: working on it!18:39
mordredso - I'm a bit more than pissed off at the fac that we have companies in here trying to throw weight behing "we're a big company, listen to us"18:39
ayoungMarkAtwood, you know what, you just argued against doing anything with standard HTTP.18:39
MarkAtwoodayoung yes i know i did.  and it sucks18:39
MarkAtwoodi was on your side of this argument 6 years ago18:40
ayoungI realize Apache does not pass it down to the app, but Apache can handle basic auth for you already18:40
ayoungso that one gets passed through as REMOTE_USER18:40
MarkAtwoodnot all of use run Apache18:40
dstanekMarkAtwood: i have not seen the issues your talking about with basic-auth18:40
MarkAtwooddo you really want to make the web server daemon a dependency18:40
ayoungMarkAtwood, absolutelty18:40
*** ildikov has joined #openstack-meeting18:40
morganfainbergdstanek, i've seen those issues with some SSL accelerators and LB systems18:40
morganfainbergdstanek, they do a lot of mangling at the larger scale implementations ot get their job done18:41
bknudsona web server is better at serving web responses than our basic keystone impl will be.18:41
dstanekmorganfainberg: do they remove the headers?18:41
morganfainbergdstanek, they can.18:41
*** jlibosva has quit IRC18:41
MarkAtwoodand REMOTE_USER doesnt work when you're running apache as a proxy18:41
*** Linz has quit IRC18:41
morganfainbergdstanek, depends on the LB etc18:41
*** SergeyLukjanov has joined #openstack-meeting18:41
dstanekmorganfainberg: that sucks, sounds like broken gear18:41
morganfainbergdstanek, and reverse proxying does lots of odd stuff.18:41
*** Linz has joined #openstack-meeting18:41
dolphmMarkAtwood: i'm in favor of leveraging what we can, and i have yet to see *any* specific pushback against requiring httpd18:42
morganfainbergdstanek, not so much broken, but configured as such because it's needed to leverage the farm behind it.18:42
*** david-lyle_afk is now known as david-lyle18:42
*** fbo is now known as fbo_away18:42
dstanekmorganfainberg: broken in that they are violating the HTTP protocol right?18:42
MarkAtwooddstanek, its not even a violation of protocol18:42
mordredso - is the opposition to the mutliple token thing18:42
morganfainbergdstanek, headers dont have to be passed on. etc.18:42
*** SergeyLukjanov_ has quit IRC18:42
MarkAtwoodthe w3c have beeen rank cowards about it18:42
mordredthe implementaion of managing the tokens?18:43
mordredor being able to expose the consumption one in the protocol?18:43
mordreds/one/of one/18:43
ayoungmordred, multiple tokens?  Or multiple passwords?18:43
gyeeif we are using external auth it means accounts are managed outside of Keystone18:43
mordredayoung: passwords18:43
morganfainbergmordred, correct inverse, mutiple passwords any one of them can issue the same token.18:43
dstanekgyee: do you have a review or bp i can look at?18:43
morganfainbergsame token in this context = same roles/etc in the data (not physically the exact same token)18:43
ayoungmordred, my feeling is that Keystone should never have been attempting to manage passwords in the first place, and we should not attempt to increase its scope.18:44
*** lsmola has joined #openstack-meeting18:44
mordredayoung: honestly, the thing I care about is that there is a consistent user-facing api to access this stuff for cloud consumers - if HP and rax each do a plugin to deal with multi-passsword-mapping-to-user on the admin side, I dont care18:44
gyeedstanek, https://review.openstack.org/#/c/46771/18:44
mordredayoung: well, thing is - it's an interface to the exstence of passwords18:44
mordredwhether it manages them itself or not18:44
gyee#link https://review.openstack.org/#/c/46771/18:44
mordredI mean, the system that actually owns the passwords at HP is not keystone, it's something else - but keystone is the thing that the user talks to18:44
*** rongze has joined #openstack-meeting18:44
ayoung mordred and the use case they are asking for could be done in the existing mechanisms18:45
mordredI imagine at many private clouds it's AD or LDAP that owns the passwords18:45
ayoungmordred, or even a pre-existing SQL database18:45
morganfainbergmordred, one challenge comes from IdP (identity provider such as ldap) and now having passwords that are indepenant/managed separately from it.  you're no longer relying on the IdP for AuthN18:45
*** ryanpetrello has joined #openstack-meeting18:45
dolphmgyee: thanks, i should have linked that at the top18:45
ayoungthat does not map to what SQLAlchemy in Keystone expectes or provides18:45
*** bradjones has quit IRC18:45
MarkAtwooddoes anyone use the idp for passwords at scale?18:45
mordredayoung: by existing mechanism, you mean in the keystone protocol? or using specific things in an apache deployment choice18:46
gyeeplease take a look at the comments in detail in that review18:46
MarkAtwoodi remember watching the rdo demo about how they dont either18:46
* mordred trying to catch up on lots of tech details really quickly18:46
gyeealternatively, we can add the "expried_at" field for a password18:46
dolphmayoung: by your reasoning, all of this should be handled by an alternative password auth plugin, correct?18:46
gyeeso a password is no longer valid after the upgrade18:46
ayoungBTW, there are several other security professionals that have weighed in on that review.  I'll leave it to you guys to read their feedback18:46
MarkAtwoodwe keep the passwords and appkeys in a seperate system because it's keep MUCH more secure against read and access than the IdP18:47
gyeeayoung, I've responded to the security professionals in that review18:47
ayoungdolphm, I would not even feel comfortable agreeing to that18:47
*** ryanpetrello has quit IRC18:47
dolphmayoung: why not?18:47
*** gokrokve has joined #openstack-meeting18:47
morganfainbergMarkAtwood, that argues for a separate auth plugin, that just overloads the current password one.18:47
morganfainbergMarkAtwood, simplest solution?18:47
MarkAtwoodayoung, you want to remove login shared secrets from keystone entirely?18:48
ayoungdolphm, we can do it with the mapping piece from federation18:48
mordredMarkAtwood: that sounds sane to me - no?18:48
mordredthe end user shouldn't need to tell keystone anything new about the tyep of password, no?18:48
dolphmayoung: i don't follow that at all?18:48
dolphmayoung: this is about keystone's idp, not delegated authorization18:48
jamielennoxso would a compromise be to bump the role for installing a SHARED-SECRET to admin (or something new) so that it could be set up for use by services but not be user facing?18:48
morganfainbergand we have agreed internally to maintain internal API stability for 1 cycle (to the best of our ability) so maintaining the plugin shouldn't be too onerous.18:49
gyeethis is not about federation, it a simple case of password rotation for rolling upgrade18:49
MarkAtwoodits useful for user facing18:49
MarkAtwoodusers use it18:49
gyeeplease don't make it any more complicated18:49
dolphmjamielennox: that's entirely user facing18:49
ayoungdolphm, I was saying that they could keep the passwords outside of Keystone using mod_auth_sql  and then map REMOTE_USER to user_Id  and get the same effect18:49
ayoungthat does not require an explicit plugin18:49
dolphmjamielennox: that's just a question of "which" users18:49
mordredMarkAtwood: but where do users use it? and does that require protocol violations?18:49
mordredfor normal auth18:49
ayoungbut that keeps it from being Keystone's problem, and uses a well tested mechanism.18:49
dolphmgyee: and you specifically only care about "service users", correct?18:50
gyeedolphm, yes, but service user is a user18:50
ayoungdolphm, I would allow for an extension that did the same based on the current password plugin18:50
MarkAtwoodusers use it when they are running multiple applications in their account18:50
jamielennoxfair enough, guess my expected usage is different18:50
dolphmgyee: correct- i'm just pointing out that's our agreed long term use case for keystone's own idp18:50
ayoungbut I would not want it installed by default18:50
MarkAtwoodtelling the users and operators to open a new account for each application is a non-starter18:50
ayoungand...no.  Each time I think it htrough, I see a slew of problems.18:50
ayoungMarkAtwood, I thought all of that was handled through your backend CRM system anywa18:51
*** jcoufal has joined #openstack-meeting18:51
gyeeayoung, suspending multiple account in order to suspend a user is pretty complicated18:51
bknudsonayoung: are the problems worse than just having username/password ? How is 2 passwords worse than 1?18:51
*** isviridov has joined #openstack-meeting18:51
ayoungBut password rotation needs two passwords, and unique ways to identify them.  If you want rotation, use two users.18:52
gyeelook, this is being proposed as an extension, means disabled by default18:52
morganfainbergayoung, it's a fair request that a service user can be used for multiple things.18:52
* dolphm 8 minutes remaining18:52
MarkAtwoodno.  the links between CRM and the operations are not deep, for security and auditing reasons18:52
*** xga__ has quit IRC18:52
mordredayoung: so, it has just been pointed out that multi-password would be useful by openstack-infra18:52
lifelessI'm going to pipe up here18:52
gyeemordred, for password rotation, heck yeah!18:52
mordredwe currently maintain 3 different accounts on each cloud so that we can ensure that one of our apps doesn't accidentally delete gerrit18:52
mordredno - not for that18:53
atiwariayoung, can we talk about service scoped roles definition link:https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition?18:53
mordredfor role protection18:53
mordredwe have nodepool, which is very dynamic18:53
lifelessand say this is an important story for ops in TripleO's opinion. There are many ways to slice it but: we want graceful rotations.18:53
*** aguzikova has quit IRC18:53
atiwariI looked at your proposal which is like "keystone:manager" name spacing the role name, does not handle all the issue mentioned in BP.18:53
mordredand then we have some servers which deleting is BAAAAAAD18:53
*** rongze has quit IRC18:53
mordredso we have different accounts18:53
mordredand keep precious servers there and do not put that password anywhere that dynamically creates/destroys nodes18:53
MarkAtwoodhp was able to give CI/CD multiple accounts only because CI/CD is extremely special18:54
lifelessmordred: I think the infra story is not one that maps well here, because an account can generally do anything to itself.18:54
mordredlifeless: righ t- but the thing is18:54
ayoungatiwari, No.  BUt we can talk about mapping nested role definitions to services :)18:54
nkinderayoung: rotation can be performed with an expiration/changeover period.  This is similar to what AD does.18:54
*** Hunner has joined #openstack-meeting18:54
gyeenkinder, but you still have to maintain both new and old passwords right?18:54
*** masayukig has joined #openstack-meeting18:54
*** sarob has joined #openstack-meeting18:55
lifelessgyee: for the changeover period; but password reuse policies mean you are anyway :)18:55
gyeeso isn't that *multiple credentials active* at the same time?18:55
atiwariatiwari, let talk after the meeting18:55
nkindergyee: for a very limited period of time (and you only allow 2 ever - old and current)18:55
atiwariayoung ^^^18:55
ayoungatiwari, I see it18:55
nkindergyee: it's much different than allowing 40 creds to be created for a single account that live that way long-term.18:55
gyeenkinder, so that's essentially what we are proposing, we can add the "expired_at" field in there18:55
gyeeso the old password expired after some time18:56
dolphmmordred: should that just be different tenants, ideally?18:56
gyee40 creds is only allowed if the business process allows it18:56
gyeeusers can't create credentials at well18:56
MarkAtwoodwell, they can, but "too many" trips a security alert and its looked at18:57
*** chuck__ has joined #openstack-meeting18:57
gyeeheck, keystone credential APIs are admin-protected out-of-the-box18:57
dolphmmordred: meh, nvm. i guess i see the use case for a set of credentials not being able to cross tenant boundaries at all18:57
*** chuck__ has quit IRC18:57
morganfainberggyee, fabiog,18:57
bknudsoncan keystone even be configured to allow a user to create their own creds?18:57
dolphmbknudson: revise the policy.json ?18:58
morganfainbergbknudson, i think so?18:58
*** lexx has quit IRC18:58
gyeebknudson, not the default policy18:58
bknudsonyou'd need a mapping from cred to user18:58
morganfainberggyee, ok, but it's just policy.json mangling iirc18:58
gyeebknudson, cred APIs are admin-protected out-of-the-box18:58
*** jlibosva has joined #openstack-meeting18:58
morganfainbergbknudson, thats in the cred table already, afaik18:58
gyeemorganfainberg, correct, but that's a deployment option18:58
*** joesavak has joined #openstack-meeting18:58
bknudsonok, it's got user_id18:58
morganfainbergbknudson, yep18:58
bknudsonbut it's not in the url18:59
ayounggyee, extending the password API to check (current, old)  is way different than what you are proposing.  Allowing simple rotations in the current paradigm is scary, but preferable.18:59
morganfainbergah, fair enough.18:59
*** masayukig has quit IRC18:59
lifelessayoung: what is a 'simple rotation' ?18:59
ayounglifeless, just rotations18:59
lifelessayoung: I need detail.18:59
lifelessayoung: like, do we have nova-compute processes on servers doing their own password updates?18:59
dolphmso -- to meekly summarize in the last couple minutes... password rotation is desirable for service users, the only long term use case for keystone's own idp. for end users, password rotation would likely be managed by a federated or external auth source anyway18:59
nkinderlifeless: the old password is still allowed to be used for some period after it is changed.  This gives a window to go update your services to use the new password.19:00
ayounglifeless, new and old are both valid for a short period of time, as Nathan said.  Not an open ended numer, and not a new API.19:00
lifelessayoung: this is a huge operational thing : auditors and compliance /care/, and if we get it wrong downtime ensues.19:00
lifelessayoung: ok, cool. *that* I love.19:00
nkinderlifeless: That period should be configurable, but ideally short19:00
lifelessayoung: and AFAICT it meets the use case put up.19:00
lifelessnkinder: matter of hours be ok ?19:00
MarkAtwoodthere are more use cases then key rotation19:00
* dolphm (time's up)19:00
dolphmswitching to -dev!19:01
lifelessMarkAtwood: may need to take it to the list19:01
gyeedolphm, we have to give users a bridge in the mean time, which means implementing the extension19:01
nkinderlifeless: yep, that's ideal in my mind, but it's a policy decision19:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"19:01
openstackMeeting ended Tue Nov 26 19:01:07 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone/2013/keystone.2013-11-26-18.02.html19:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone/2013/keystone.2013-11-26-18.02.txt19:01
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone/2013/keystone.2013-11-26-18.02.log.html19:01
*** fabiog has quit IRC19:01
*** arunkant has quit IRC19:01
*** nachi has left #openstack-meeting19:01
* fungi raises an ascii hand19:01
*** nkinder has left #openstack-meeting19:02
jeblairmordred, pleia2: ping19:02
*** michchap has joined #openstack-meeting19:02
* mestery is here lurking and listening.19:02
*** jtomasek has joined #openstack-meeting19:02
*** jtomasek has quit IRC19:02
*** sarob has quit IRC19:02
jeblairoh good those were my other pings!19:02
jeblair#startmeeting infra19:02
openstackMeeting started Tue Nov 26 19:02:48 2013 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.19:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:02
*** openstack changes topic to " (Meeting topic: infra)"19:02
openstackThe meeting name has been set to 'infra'19:02
*** marekd-mobile has left #openstack-meeting19:02
jeblair#topic Actions from last meeting19:02
*** openstack changes topic to "Actions from last meeting (Meeting topic: infra)"19:02
jeblairthis should shock no one19:03
jeblair#action jeblair file bug about cleaning up gerrit-trigger-plugin19:03
*** jtomasek has joined #openstack-meeting19:03
* fungi feigns shock19:03
*** sarob has joined #openstack-meeting19:03
jeblair#action jeblair move tarballs.o.o and include 50gb space for heat/trove images19:03
jeblairpleia2: how do you want to track the work on historical publications?19:03
jeblairpleia2: want to just open a bug about it?19:04
pleia2jeblair: sounds good19:04
pleia2last week was kind of chaos, so I didn't ask anyone to help me get started19:04
jeblairfunzo: how are static volumes?19:04
fungibit of a snag here...19:04
fungi#link http://www.rackspace.com/knowledge_center/product-faq/cloud-block-storage19:05
fungi"What's the maximum number of Cloud Block Storage volumes I can attach to a single server instance?"19:05
jeblairfungi: gee, sorry about your nick there.19:05
fungi"You may have up to 14 Cloud Block Storage volumes attached to a single Server."19:05
fungii like funzo19:05
fungicould be my new friday nick19:05
jeblairyay cloud?19:05
fungiso anyway, yeah. suggestions? slowly migrate some pvs from 0.5t to 1t?19:05
jeblairso we're at 5.5T out of a possible 14T19:06
*** ttrifonov is now known as ttrifonov_zZzz19:06
clarkbthats the best thing I can come up with19:06
fungii can shift data from smaller to larger cinder volumes and replace them until we have enough19:06
jeblairfungi: i think that's the way to go19:06
funginot a possible 14t either, no. see the faq ;)19:06
sorenI think that's a technical limitation.19:06
fungi"The limit for Volumes and storage is 10 TB total stored or 50 volumes per region (whichever is reached first)."19:06
*** michchap has quit IRC19:06
*** colinmcnamara has quit IRC19:06
jeblairalso, jog0 and sdague merged a patch thursday that should _greatly_ reduce the log size19:06
fungisoren: yes, i've seen a lot of references to xen being unable to present more than 16 block devices into a domu19:07
sorenUp to 8 partitions per disk, up to 16 disks, where two are assigned by Nova by default.19:07
fungiat least older xen versions19:07
clarkbjog0: sdague: have a link to that change?19:07
soren...and that's all you get with 256 minor numbers to choose from.19:07
jeblairclarkb: it cleaned up the isomumblemumble log spam19:07
jeblairclarkb: something like 10G -> 2G19:07
clarkbjeblair: nice19:07
mordredso it's possible this might put more fuel on the 'figure out swift' fire?19:07
sorenUnless, of course you know how to do basic arithmetic.19:07
* soren shuts up now before he makes more of an arse of himself.19:08
jeblairmordred: i'm not sure that fire needs more fuel19:08
mordredwell, right :)19:08
* mordred adds fuel to exploding gas bombs...19:08
fungiso anyway, i'm happy to wiggle a few pvs this week, just wanted to make sure there weren't better options to get us short-term gains with minimal additional effort before i pressed ahead on that19:08
jeblairjhesketh is not here, but i hope to get together with him soon to find out if he's planning on working on that and supply him with any help needed19:08
jeblairfungi: i think that's the best thing to do now19:09
fungi#action fungi grow logs and docs-draft volumes so they're 50% full19:09
jeblairand hopefully we'll get on swift before it becomes an issue19:09
sdagueclarkb: https://review.openstack.org/#/c/56471/19:09
clarkb#link https://review.openstack.org/#/c/56471/19:09
*** colinmcnamara has joined #openstack-meeting19:09
sdaguethat's the review on the logs19:09
jeblairand if we don't quite make that, we can start ratcheting down the logs we keep (1 year to 9 months, for instance)19:09
clarkbjeblair: fungi ++ good intermediate fix19:09
mordredjeblair: ++19:10
fungijeblair: don't we already only keep 6 months of logs?19:10
jeblairfungi: maybe update the docs to say to only add 1TB volumes19:10
pleia2fungi: yeah19:10
fungijeblair: will do19:10
jeblairfungi: i thought it was 2 releases or 1 year.  i might be wrong.19:10
pleia2it's 6 months, one release19:10
fungi#action fungi update docs for static to recommend 1t cinder volumes19:10
jeblairnope i'm wrong.19:10
jeblair -type f -mtime +183 -name \*.gz -execdir rm \{\} \; \19:10
fungiyeah, it's a metric crapton of logs19:10
jeblairso, er, 4 months then, i guess.  yeesh.19:11
fungianyway, we've beaten this item to death for now19:11
jeblairhopefully we won't need that.19:11
jeblair#topic Trove testing (mordred, hub_cap)19:11
*** openstack changes topic to "Trove testing (mordred, hub_cap) (Meeting topic: infra)"19:11
jeblairmordred, hub_cap: what's the latest?19:11
mordredjeblair: I have done nothing on this in the last week - hub_cap anything on your end?19:11
*** epim has joined #openstack-meeting19:12
mordredhub_cap: also, I'm a bit cranky that you have someone working on turning on your non-tempest tests when you have not finished getting tempest up and going19:13
mordredhub_cap: in fact, I'm sorry my brain didn't fire on this properly the other day - I believe we should -2 any changes from you that add support for your other thing until you've got tempest wired up19:14
jeblairmordred: is there such a change?19:14
hub_caphey im ok w/ that. i just figured you'd wanted both and id rather he do the legacy tests19:15
mordredjeblair: we told them how to do it a day or two ago19:15
mordredwe want everythig - but you need tempest tests to be integrated19:15
mordredso you sohuld really get those going19:15
hub_capi didnt know there was an order19:15
mordredand I want your legacy tests deleted19:15
hub_capyes mordred i agree19:15
mordredbecause O M G19:15
hub_capi know..... i know :)19:15
mordredso, let's get your tempest stuff wired up, _then_ we can get your additional things added19:15
hub_capgood by me!19:16
jeblairhub_cap, mordred: when do you think that might happen?19:16
mordredhub_cap: what are we blocking on for that for you right now? anything on my end?19:16
*** acoles__ has joined #openstack-meeting19:16
hub_capnothing is blocking other than me not doing the work19:16
hub_capthats the blocker heh19:16
mordredgreat. I'll start poking you more then19:16
*** acoles__ has left #openstack-meeting19:17
mordred#action mordred to harrass hub_cap until he's writen the tempest patches19:17
jeblair#topic Tripleo testing (lifeless, pleia2)19:17
*** openstack changes topic to "Tripleo testing (lifeless, pleia2) (Meeting topic: infra)"19:17
pleia2continuing to patch tripleo for the multi test environments, and working on networking now19:18
lifelessuhm, we just did this in #openstack-meeting-alt19:18
lifelessI wonder if we can dedup the topics somehow19:18
pleia2indeed we did!19:18
pleia2for more, see tripleo meeting :)19:18
jeblairokay, i'm not sure we need that detail19:19
jeblairpleia2: can you relate this to infra?19:19
pleia2no updates for infra at this time19:19
jeblairokay.  so 'still hacking on test-running-infra' is more or less the status19:20
lifelessprogress is being made19:20
lifelessvisibly so19:20
jeblair#topic Savanna testing (SergeyLukjanov)19:21
*** openstack changes topic to "Savanna testing (SergeyLukjanov) (Meeting topic: infra)"19:21
SergeyLukjanovworking on setting up jobs for d-g19:21
mordredI've seen patches for this19:21
jeblairso i think we basically just told SergeyLukjanov to wait just a bit for the savanna devstack tests19:21
jeblairwhich is an unusual thing for us to do!19:21
mordredjeblair: yay us!19:21
jeblairbut clarkb is doing a d-g refactor, and we want to get the savanna jobs into that refactor19:22
SergeyLukjanovI'll rebase my change on clarkb one19:22
clarkbbut there is a good reason for that. I am reasonably happy with how the d-g job refactor turned out and want people building on top of that19:22
jeblairso hopefully it shouldn't be long19:22
jeblairi look forward to reviewing it! :)19:22
SergeyLukjanovand I'm already have some draft code of api tests for savanna19:22
SergeyLukjanovand hope to make a patch later this weel to tempest19:23
SergeyLukjanovlater this week*19:23
jeblairSergeyLukjanov: excellent! sdague ^19:23
*** galstrom_zzz is now known as galstrom19:24
jeblair#topic Goodbye Folsom (ttx, clarkb, fungi)19:24
*** openstack changes topic to "Goodbye Folsom (ttx, clarkb, fungi) (Meeting topic: infra)"19:24
clarkbits gone !19:24
jeblairi bring it up again because we linked to this review last week: https://review.openstack.org/#/c/57066/19:24
fungiyep, folsom is gone, havana tests are all implemented now19:24
jeblairand it's abandoned due to -119:24
jeblairso i wanted to check: is the grenade situation straightened out, or do we have work to do still?19:24
*** jhenner has quit IRC19:25
sdagueit's still in process19:25
fungii think there is more to do. dprince?19:25
fungiahh, right. sdague, you said there was still some grenade code support missing for that change?19:25
sdagueyeh, the first one is maybe merging today19:26
*** nati_uen_ has joined #openstack-meeting19:26
SergeyLukjanovsdague, just to clarify - is it ok to start with only /smth api tests and client?19:26
SergeyLukjanovsdague, I mean with only one 'endpoint'19:26
jeblair#link https://review.openstack.org/#/c/57066/19:27
*** thelorax123 has joined #openstack-meeting19:27
jeblairsdague: can you link the change you're referring to?19:27
sdagueSergeyLukjanov: yeh, I think so, but it will take looking at the patch when it comes in to be sure19:27
SergeyLukjanovsdague, sure, thx19:27
sdaguejeblair: https://review.openstack.org/#/c/57744/19:28
jeblair#link https://review.openstack.org/#/c/57744/19:28
*** nati_ueno has quit IRC19:28
dprincefungi: sorry, too many meetings, let me catch up here...19:28
*** igormarnat__ has joined #openstack-meeting19:29
*** danwent has quit IRC19:29
*** nati_uen_ has quit IRC19:30
dprincefungi: https://review.openstack.org/#/c/57066/19:30
dprincefungi: I was waiting on some other grenade core fixes first though.19:30
*** nati_ueno has joined #openstack-meeting19:30
fungidprince: right, that was the question. sdague caught us up19:30
fungiso i think we're cool on this topic for the moment?19:31
dprincefungi: Cool. FWIW this stuff is actually blocking parts of a Nova patch series for me. So I'll know when its done!19:31
clarkbsounds like it19:31
jeblair#topic Jenkins 1.540 upgrade (zaro, clarkb)19:32
*** openstack changes topic to "Jenkins 1.540 upgrade (zaro, clarkb) (Meeting topic: infra)"19:32
jeblairi think the change to get nodepool up is in progress19:32
clarkbyup zaro pushed that19:32
jeblairso let's check back in on this later19:32
jeblair#topic New devstack job requirements (clarkb)19:32
*** openstack changes topic to "New devstack job requirements (clarkb) (Meeting topic: infra)"19:32
jeblairclarkb: you have a change up, yeah?19:33
clarkbI do19:33
clarkb#link https://review.openstack.org/#/c/58370/19:33
jeblairwhen i find changes to devstack-gate.yaml, i've been suggesting they coordinate with you19:33
jeblairexcept if they are for non-official projects, in which case i think we want those jobs in a different file19:33
clarkbjeblair: thank you ti has been helpful, I have been leaving a long comment on those changes linking back to 58370 with details19:34
jeblair(and in that case, i don't think they need to consider this refactor)19:34
*** igormarnat__ has quit IRC19:34
clarkbjeblair: right I think they can continue to abuse devstack for whatever erason19:34
*** fbo_away is now known as fbo19:34
clarkb58370 is handy because it clearly shows how to write devstack gate job templates that are useful in all the places we want to use them. check, gate, check on stable branch for d-g changes, and periodic bitrot jobs for releases19:35
*** danwent has joined #openstack-meeting19:35
clarkband we cover all of these bases with two templates per logical job. Overall I am pretty happy with it19:35
clarkbalso WSME/Pecan can overload branch-designator to have special jobs just for them that are otherwise identical to the gate jobs19:35
clarkbso this will help us integrate the world19:35
jeblairclarkb: how does that work? (i haven't looked at the change)  what would they set, for example?19:36
clarkbjeblair: the tail end of the jobs names has -{branch-designator} in it. I have been using that to distinguish between stable-grizzly and stable-havana and master for periodic jobs and use -default for things that run against proposed changes on the proposed branch19:37
jeblairgot it19:37
clarkbjeblair: WSME/pecan could put wsme-default in that var instead and get a new job that zuul won't put in the gate with everyone else that is otehrwise identical19:37
*** lexx has joined #openstack-meeting19:38
jeblair#topic  Jenkins Job Builder Release (zaro, clarkb)19:38
*** openstack changes topic to "Jenkins Job Builder Release (zaro, clarkb) (Meeting topic: infra)"19:38
jeblair#link https://pypi.python.org/pypi/jenkins-job-builder/0.6.019:38
jeblairexists ^19:38
clarkboh cool so that got done ++ for doing that19:38
jeblaircut maybe an hour ago19:38
jeblair#topic  Puppetboard (anteaya, Hunner, pleia2)19:38
*** openstack changes topic to "Puppetboard (anteaya, Hunner, pleia2) (Meeting topic: infra)"19:38
clarkbI can update the bug that asked us to cut a release if that hasn't been done yet19:38
jeblairclarkb: ++19:39
pleia2so last week Hunner gave anteaya and I an internal demo of puppetboard19:39
fungiclarkb: and probably need to switch other outstanding bugs from committed to released too19:39
pleia2it's pretty cool, has published logs from servers, basic stats19:39
pleia2faster than dashboard, but does require use of puppetdb (which we don't currently use)19:39
HunnerI have code, but still working out the apache manifest stuff (it's an older module version that my prototype used). So not yet pushed to review19:39
pleia2did we have any other requirements?19:40
jeblairwhere does puppetdb run?19:40
HunnerPuppetdb is essentially swap out the puppet.conf lines that post to the dashboard, and add it the lines for sending to the puppetdb19:40
pleia2puppet master19:40
HunnerCurrently the puppetdb would be running on the puppetboard box, since it's kind of related19:40
jeblairokay, i like keeping the master simple.19:40
HunnerCurrently masters -> dashboard; in the future masters -> puppetdb -> puppetboard19:41
fungithat makes the most sense to me. it's not privileged in any way, right?19:41
HunnerYeah, low impact to masters19:41
*** novas0x2a|laptop has joined #openstack-meeting19:41
HunnerIt's not privileged, no19:41
fungiyeah, better on the puppetboard system then19:41
jeblairHunner: i see that it stores facts and catalogs from each node; does that include hieradata?19:41
clarkbit does run on postgres (which may or may not be a problem)19:42
HunnerOne point to note is: just like mysql running on the dashboard box, postgresql will run on the puppetdb/puppetboard box19:42
jeblairHunner: specifically, i'm wondering if this puts plaintext passwords on more systems.19:42
Hunnerjeblair: It does not store hieradata; just the facts, reports, and compiled catalogs19:42
jeblairHunner: great19:42
HunnerThink of hieradata like manifests... neither of those are outputs19:42
HunnerOnly inputs19:42
Hunnerpuppetdb stores the outputs19:42
Hunner(facts, catalogs, reports)19:43
HunnerAnd is HTTP REST API queryable19:43
HunnerBut that's extra shiny that you don't need to care about19:43
fungii can see caring about it down the road. being able to query system status for other things could be very, very helpful19:43
*** acoles_ has quit IRC19:44
HunnerIt's essentially trying to be a centalized "best guess" at the whole infrastructure19:44
HunnerSo yeah, useful down the road for what you say19:44
*** jecarey has quit IRC19:44
*** mrodden has joined #openstack-meeting19:45
HunnerBut as a gui report server ("What's failing? Oh...") it works great19:45
jeblairthe postgres thing is kind of a bummer, since we're trying to move to cloud databases (which are only mysql right now), but i think we can live with it.19:45
*** jamielennox has left #openstack-meeting19:45
jeblairso what's next?  wait for Hunner to finish apache manifests?19:46
HunnerYep. Hopefully have a review by next meeting19:46
jeblairpleia2: any other questions?19:46
*** sarob has quit IRC19:46
jeblairHunner: thank you very much!19:46
pleia2that's it from me19:47
fungii take it postgres is a hard requirement (substring search or other non-mysql feature)19:47
pleia2thanks Hunner19:47
*** sarob has joined #openstack-meeting19:47
Hunnerfungi: At this time yes. I could ask for the details and share, since I'm curious too19:47
fungicool. thanks!19:47
jeblair#topic Multi-node testing (mestery)19:47
HunnerThe backend is actually swappable, though the only two existing backends are postgres and in-memory19:47
*** openstack changes topic to "Multi-node testing (mestery) (Meeting topic: infra)"19:47
mesterySo, anteaya set me up with this slot to discuss this, mostly wanted to ask some questions and get some direction around this.19:48
*** jbryce has joined #openstack-meeting19:48
mordredgah. had network glich. someone talk to me about hard reqs for postgres at some point please19:48
jeblairHunner: maybe you can pass on what you find to mordred19:49
*** rongze has joined #openstack-meeting19:49
jeblairmestery: what are your questions?19:49
mesteryFor the Neutron ML2 plugin, we would like to do gate testing in a multi-VM environment to test out the tunneling capabilites and new drivers in ML2.19:49
mesterySo a) is that possible today (multi-node testing in the gate)?19:49
mordredHunner: yeah - grab me offline and let's chat about  that - I'll try not to troll you tooo much19:50
mordredmestery: we're working on some solutions aroud that in the tripleo testing workstream19:50
jeblairmestery: a) it's not possible today19:51
mesterymordred: Great!19:51
mordreda) it's not ready yet - but somethign tells me that we'll have to cook up the same things to do it outside of that workstream, so perhaps you guys could lend a hand to that if you have some bandwidth19:51
*** sarob_ has joined #openstack-meeting19:51
mesterymordred: Perfect, I think that would be good!19:51
*** sarob has quit IRC19:51
jeblairmordred: i'm hesitant to suggest that as a solution; i'm not sure it will suffice19:51
mesteryWe have some ML2 folks who could help with this.19:51
fungimestery: i take it it's not feasible to test out tunneling entirely within a single devstack install on one machine19:51
jeblairmordred: afaik, the multi-node tripleo work is focused on a limited set of multi-node hardware environments19:52
fungi(i.e. each network device as a vm in devstack)19:52
mordredjeblair: that is a good point19:52
mesteryfungi: We can test tunneling perhaps, but we need multiple nodes to run agents on each node for testing as well.19:52
mesteryfungi: The thing we want to test is the agent communication as well and that path.19:52
jeblairmordred: and at the moment, the work the tripleo folks are doing is not intended to be reusable in infra19:53
fungiin this case "nodes" means more than one neutron controller instance?19:53
mesteryI apologize, I'm still learning a lot of this infra code as well, so please bear with me. :)19:53
*** adrian_otto has left #openstack-meeting19:53
pleia2mestery: dprince, lifeless, derekh and I are having a status chat on Google+ about our work with tripleo testing in a bit (maybe right after this meeting? I can ping you), you're welcome to be a fly on the wall if you want to see where we are at19:53
mesteryfungi: No, one control node, multiple compute nodes.19:53
*** rongze has quit IRC19:54
jeblairpleia2: any chance you guys could open that up a bit?19:54
fungii wonder if we could set up more than one nova service on one devstack machine19:54
pleia2jeblair: oh yeah, anyone is welcome19:54
jeblairpleia2: we don't use g+ for openstack development19:54
mesterypleia2: Cool! Shoot me the info, if I can make it I will join.19:54
pleia2jeblair: oh, that, maybe we should use the asterisk19:54
jeblairmestery: i'd like to get you some straightforward answers to your question19:55
*** masayukig has joined #openstack-meeting19:55
mesteryjeblair: So it sounds like it's not supported, and it will take some work to make it happen?19:55
*** sarob_ has quit IRC19:55
jeblairmestery: please feel free to check out what the tripleo folks are doing, but i do not want you to be misled into thinking that is the shortest or most certain path to multi-node gate testing.19:56
mesteryjeblair: Understood, I'll do that. Thank you!19:56
fungiand it's also worth exploring whether multi-node testing (in the sense we've been discussing) is necessary for what you want to test too19:56
jeblairmestery: for the at-scale testing we do on virtual machines in the gate, we do need a multi-node solution19:56
*** raghu_rao has joined #openstack-meeting19:56
mesteryjeblair: OK.19:56
mesteryfungi: It is necessary, because we need multiple Neutron nodes, 1 control node and one with neutron agents on it.19:57
*** ijw has joined #openstack-meeting19:57
jeblairmestery: however, it's a few steps away, and probably won't be available for a while.  we need to have non-jenkins test workers running in order for that, and there are still some things to do before we can get even to that point.19:57
HunnerFor multi-node testing with virtual machine groups, there is rspec-system or its rewritten counterpart beaker-rspec. At least that's what we use (if I understand your requirements)19:57
mesteryjeblair: Understood. This came up in our Neutron ML2 meeting last week, thus my interest in talking to everyone here.19:57
*** sparkycollier has joined #openstack-meeting19:57
* ijw sneaks out of the woodwork19:58
*** markmc has joined #openstack-meeting19:58
clarkbHunner: the problem here is we use public cloud resources that intentionally hobble the networking things we can get away with19:58
ijwI've run VM groups for Openstack testing by starting a VM that, in turn, installs and starts others.  I wasn't using devstack, I was using something stackforge-based, but there's no reason why devstack wouldn't also work.19:58
*** twoputt_ has quit IRC19:58
*** twoputt has quit IRC19:58
clarkband we are trying to test networking things19:59
HunnerSounds good. Carry on19:59
mesteryijw: Thanks, will check that out. Some things to think about here, thanks everyone.19:59
jeblairthe problem statement for us is more like: we have a pool of nodes that are all online and connected to zuul -- how do we get a collection of those running a single job.20:00
jeblairwe brainstormed about that a bit at the summit and have some ideas20:00
jeblairbut regardless, they are still a few steps away20:00
*** masayukig has quit IRC20:00
jeblairand our time is up20:00
jeblairso thanks everyone, and sorry about the topics we didn't get to20:01
jeblairif there's something urgent, ping in -infra20:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"20:01
openstackMeeting ended Tue Nov 26 20:01:14 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-11-26-19.02.html20:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-11-26-19.02.txt20:01
openstackLog:            http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-11-26-19.02.log.html20:01
ijwjeblair: yeah, that's hard work compared with what we already have to work with using Openstack itself - which is a system that lets you set up arbitrarily wired networks.20:01
ttxWho is around for the TC meeting ?20:01
*** colinmcnamara has quit IRC20:01
ttxannegentle, mordred, jgriffith, vishy, markmcclain, jeblair, sdague, dhellmann : around ?20:02
jeblairttx: i am indeed20:02
*** ijw has left #openstack-meeting20:02
ttx7 reached, let's get started20:02
ttx#startmeeting tc20:02
openstackMeeting started Tue Nov 26 20:02:24 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.20:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:02
*** openstack changes topic to " (Meeting topic: tc)"20:02
openstackThe meeting name has been set to 'tc'20:02
ttxAgenda is at:20:02
ttx#link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee20:02
ttx#topic Recognize indirect contributions to our code base20:02
*** lsell has joined #openstack-meeting20:02
*** openstack changes topic to "Recognize indirect contributions to our code base (Meeting topic: tc)"20:02
*** michchap has joined #openstack-meeting20:03
ttxWe got a formal request asking us to support a Sponsored-By: commit message header20:03
ttx#link http://lists.openstack.org/pipermail/openstack-tc/2013-November/000389.html20:03
ttxMy reading of the -dev discussion would be that commit messages are not to be turned into a NASCAR car20:03
*** casanch1 has joined #openstack-meeting20:03
ttxAnd complex affiliations / sponsoring can be tracked into analytics repositories if that's something people really care about20:03
jeblair#link http://lists.openstack.org/pipermail/openstack-dev/2013-November/018571.html20:03
jeblairalso that thread on dev ^20:03
*** colinmcnamara has joined #openstack-meeting20:03
ttxjeblair: ah, bad link, thx20:03
markmcwell, also people can consider using different email addresses for work affiliated for different companies20:04
lifelessme too20:04
lifelesswe have a system20:04
markmcand have the analytics tools handle single person, multiple addresses, multiple affiliations20:04
lifelessuse emails.20:04
ttxdoes anyone want to argue *for* Sponsored-by at this point ?20:04
jeblairttx, markmc: i agree with what you have said, and don't feel that this is ripe for tc action20:04
russellbyep, emails seems like a good recommendation20:04
mordredagree- it ials would work with all of the current stats counting things20:04
markmcalso, Co-authored-by: my-alt-email@foobar.com where your work is sponsored by multiple companies20:04
mordredand would not break russel's things20:04
* nijaba can argue if you want ;)20:05
ttxno need to spend more time on this if no member feels like defending it20:05
*** derekh has joined #openstack-meeting20:05
russellbseems like we feel that using email addresses solves this20:05
markmcnijaba, would have been better to reply on-list :)20:05
markmcnijaba, we're just re-stating consensus from the list here20:06
nijabamarkmc: sure, but I think I made my point in the original proposal.  Then wanted to let the debate take place20:06
vishymarkmc: i like the co-authored-by strategy20:06
vishy+ its an easy way to double your line count!20:06
ttxok, I guess we can move on to next topic20:06
ttxunless someone screams now20:06
ttx#topic Add David Chadwick as exceptional ATC (Keystone)20:07
*** openstack changes topic to "Add David Chadwick as exceptional ATC (Keystone) (Meeting topic: tc)"20:07
ttx#link https://review.openstack.org/#/c/57500/20:07
markmcmakes sense to me20:07
ttx+1 ("I'm actually surprised that he isn't a contributor already")20:07
*** michchap has quit IRC20:07
*** rfolco has quit IRC20:07
ttxWill APRV this one as soon as it reaches the bar (probably already has)20:08
* ttx checks20:08
ttxexcept Monty -1ed it :)20:08
sdaguefor alphabetizing20:08
russellbhas 520:08
sdaguehe's that guy20:08
russellbthere's always that guy20:08
ttxjeblair: did you make the +1/+2 change already ?20:08
jeblairttx: yes20:09
*** ociuhandu has quit IRC20:09
ttxok, that explains stuff20:09
jeblairttx: that's why we're all +/-1 now20:09
russellbonly ttx has +2/+A?  and tc has +1/-1?20:09
ttxanyway, will approve once it reaches the approval bar20:09
jeblairrussellb: yes20:09
ttxlsell: around?20:09
jeblairalso, i agree it should be alphabetized, but since we agreed that ttx can self-approve trivial changes, i figure we can fix later.20:09
*** romcheg has left #openstack-meeting20:10
ttxskipping to ceilo / telemetry since Lauren is around20:10
ttx#topic Change Ceilometer from Metering/Monitoring to Telemetry20:10
*** openstack changes topic to "Change Ceilometer from Metering/Monitoring to Telemetry (Meeting topic: tc)"20:10
mordredjeblair: I can change my vote with that - that's a good solution20:10
ttx#link https://review.openstack.org/#/c/56402/20:10
ttxLast week I delayed the decision so that we can get input from the OpenStack marketing folks on this "official name"20:10
ttxI think there is confusion between the program name (which is originally picked by the team itself) and the official OpenStack name (which is more of a marketing / BoD thing)20:10
* vishy wants his +2 back20:10
ttxWe reuse the official names in the program names20:10
*** bknudson has left #openstack-meeting20:11
ttxI guess we could consider that programs are named by their teams and when one of their projects become incubated they engage with the marketing folks to come up with a name for it20:11
*** jlibosva has quit IRC20:11
ttxand if that makes sense, may rename the program to match the official name (may not always make sense)20:11
ttxIn this case, this is the program being renamed20:11
ttxBut also the name we'd suggest as official OpenStack name for Ceilometer20:12
russellbso there's program names, project code names, and project official openstack names, yes?20:12
ttxrussellb: imagine multiple projects under the Compute program20:12
russellbjust making sure i have it straight20:12
ttxyou have Nova and SuperNova20:12
* mordred wants supernova20:12
ttxNova's "openstack name " is "OpenStack Compute" like the program20:13
*** radez is now known as radez_g0n320:13
russellband here we're proposing a program name change (and probably recommending an official project name change too, but technically separate)20:13
*** olaph has joined #openstack-meeting20:13
ttxprogram is "Compute"20:13
ttxSuperNova could be "OpenStack Black Hole"20:13
ttxat which point you may consider renmaing the program to "Computes and Black Holes" if that makes better sense than "Nova"20:13
ttxerr. "Compute".20:13
*** jeckersb_gone is now known as jeckersb20:13
ttxdoes that make sense for everyone ?20:14
*** vipul is now known as vipul-away20:14
*** vipul-away is now known as vipul20:14
russellbgood here!20:14
markmcit's a little contorted, but I get what you mean :)20:14
*** dcramer_ has quit IRC20:14
jeblairttx: yes.  and ideally, we want the program and product names aligned.  thus, lsell is here :)20:14
ttxjeblair: exactly!20:15
lsellsounds good to me too. i just want to make sure we stay aligned where possible as we choose the terms for public comms20:15
ttxalso she could suggest better names !20:15
markmclsell, so how does Telemetry sound? :)20:15
jeblairlsell: so does "OpenStack Telemetry" sound good?  I personally think it sounds awesome20:15
lsellI like that it's accurate, catchy, one-word20:15
lsellI'm a little concerned that a broader audience might not immediately understand the meaning, but we'd like to give it a try and I can circle back with you guys in a few months if we feel like it's not getting traction20:16
lsellso yes...let's try it20:16
* markmc has a pretty decent vocabulary but had to look it up20:16
russellbit struct me as odd at first FWIW20:16
russellbsee my -1 original vote, heh20:16
* mordred just realized we have lsell, markmc, nijaba and himself here - does that mean we're having a joint TC/Board meeting?20:17
ttxit's not as if we didn't move from "OpenStack Networking" to "OpenStack Network service" and back a few times20:17
lsellok, i'm glad i'm not the only one who had to look it up :)20:17
*** julim has quit IRC20:17
jeblairi was familiar with it, but i guess i read different books.  :)20:17
*** ryanpetrello has joined #openstack-meeting20:17
russellbit's quite accurate, but there is some cost to being overly clever, i think20:17
jbrycejeblair: i like missiles and space too20:17
russellbbut i'm still ok with it..20:17
mikalAnd AI supre tanks20:17
jeblairjbryce: right! :)20:17
ttxjbryce: we could shoot missiles for next Foundation team activity.20:18
*** sarob has joined #openstack-meeting20:18
* jeblair plays with the space toys on his desk20:18
sparkycollierit's hard to make something that relates to billing sound exotic, but I think Telemetry just might do it20:18
jbrycei think that clear over clever is usually better too, but in this case the clear option was getting to be a little unwieldy too20:18
markmcsparkycollier, OpenStack ShowMeTheMoney20:18
lselli think it will require additional explanation on our side, where metering and/or monitoring is pretty straight forward20:18
*** nati_uen_ has joined #openstack-meeting20:18
ttxyes, "Monitoring" was both inaccurate and boring20:18
* nijaba thinks that mordred has some fun ideas :)20:19
ttxanyway, let's use that as program name and initial openstack name and see how it goes20:19
mordrednijaba: :)20:19
annegentlewill they also change the IRC channel from -metering?20:19
nijabaannegentle: would make sense...20:19
lsellsounds good. and moving forward we'd love to engage with the PTL and team as soon as a project is incubated to nail down the naming and make sure everyone is on board20:20
ttxWill APRV https://review.openstack.org/#/c/56402/ tomorrow morning if it still has the overwhelming majority in favor20:20
russellblsell: sounds great20:20
russellbthis one decided to change scope and mess up the name :-p20:20
ttxwhich brings us to...20:21
ttx#topic Incubation / Graduation / NewProgram requirements drafts20:21
*** openstack changes topic to "Incubation / Graduation / NewProgram requirements drafts (Meeting topic: tc)"20:21
ttx(we could actually add that engagement to the graduation requirements)20:21
ttx#link http://lists.openstack.org/pipermail/openstack-tc/2013-November/000415.html20:21
*** galstrom is now known as galstrom_zzz20:21
*** nati_ueno has quit IRC20:21
ttxSo the idea here is for us to have a clearer set of guidelines to apply for incubation / new program requests and end-of-cycle graduation review20:21
ttxSo far we've been applying a number of unwritten rules, and I think writing them out would help setting expectations right for candidate projects20:22
jeblair(and they are guidelines; not set in stone)20:22
mordredyes. I think that's very important20:22
mordredwe are, ultimately, humans who can make decisions20:22
*** sushils has joined #openstack-meeting20:22
ttxI would like to turn those etherpads into a resolution and push for discussion to -dev20:23
russellbthat's good to hear confirmed, because i was accused of being a robot recently20:23
jeblairttx: i think we're about at that point...20:23
markmcttx, just added some legal bits - apache license, library licensing, contributors signed the CLA, no trademark violations20:23
ttxso if you have strong ideas that are not reflected yet, please add to that before eod20:23
ttxmarkmc: I appreciate that, thanks20:23
jeblairone thing that might bear discussion is the relative stringency of the transition to incubation vs graduation20:23
markmcalso important that the guidelines will evolve20:23
sdagueyeh, I was pretty happy with what was in the etherpads yesterday, went through them in depth then20:23
annegentlerussellb is a robot?! Who knew20:23
mikalWhat was the etherpad discussion about the two deployments bit?20:24
jeblairthe proposed guidelines for being incubated are quite high -- requiring stackforge, devstack tests, etc.  after seeing the discussion around them, i'm coming to agree that that is a good idea.20:24
russellbI actually don't like the requiring production deployments thing ... i think it's in conflict to wanting to be able to review and influence the architecture if necessary20:24
sdaguettx: just out of curiosity, was there a reason not to put them in one pad with headings? I feel in a lot of ways the flow from one level to the next is an important part of the story20:24
*** hub_cap is now known as pub_tap20:25
mikalrussellb: but it was a requirement for graduation, not incubation20:25
ttxsdague: I thought they would end up in 3 separate documents in the repo20:25
*** anniec has quit IRC20:25
ttxsdague: do you think it makes more sense in a single document ?20:25
sdaguettx: it feels better to me as a single document20:25
ttx"rules-we-apply-for-stuff" ?20:25
russellbi think a single doc makes sense20:25
*** randy_perryman has joined #openstack-meeting20:25
jeblairrussellb: i agree, i think it's almost an anti-requirement (but i don't think we can do that either).  however, it's struck-out, so i take that as a good sign.20:25
annegentlesdague: ttx: I like the single doc as well20:25
russellbproject lifecycle?20:26
russellbor something.20:26
ttxrussellb: well...20:26
mikaljeblair: but why is it an anti requirement?20:26
*** randy_perryman has left #openstack-meeting20:26
ttxthe issue is that new program is not a step in that lifecycle20:26
mikalWhy are we gradutating things people aren't using?20:26
annegentledo we have any time limits already in our governance docs? Such as you don't incubate > integrate until a release passes?20:26
mordredmikal: some things might not get used until they are in a release20:26
russellbttx: true ... programs_and_projects.txt ?20:26
russellbstill seems tightly related20:26
mordreddepending on the space in which it exists20:26
sdaguemikal: well, that would have bounced cinder from graduating20:27
markmcjust added "project must have an elected PTL" to incubation requirements20:27
mikalmordred: couldn't we have dealt with that by making an exception at the time?20:27
sdagueand I think cinder is a model for the right way to get through the process20:27
ttxmaybe two documents. project lifecycle and program lifecycle20:27
russellbmarkmc: +120:27
mordredmikal: well, how about we say "we'd like to see production deployments"20:27
russellbmarkmc: elected from its technical contributors?20:27
mikalI want to block projects which don't have active users.20:27
ttxbecause newprogram can happen before or after incubation request, basically20:27
mikalIf they can't find at least a couple of deployments during incubation, there is a big problem20:28
markmcrussellb, point20:28
mikalHow do we know it meets actual user needs?20:28
jeblairmikal: i would not hold it against operators to avoid deploying incubated projects20:28
mikalHow do we know the design is right?20:28
jeblairmikal: incubation is risky20:28
mikalWhy are we working on this thing no one wants?20:28
*** anniec has joined #openstack-meeting20:28
mordredright. especially the more stable openstack itself gets20:28
jeblairmikal: and if we're not willing to say it's part of openstack, we shouldn't expect other people to behave otherwise.20:28
russellbjeblair: +120:29
mordredI mean, there might be a point where people are only wiling to deploy our integrated projects20:29
russellbthat's my feeling20:29
ttxmikal: yeah, I removed the production deployment requirements when I saw there was no consensus around it. Doesn't mean you can't apply it in your own decision grid20:29
sdaguemikal: so what if it's a should instead of a must, and make it judgement call during vote20:29
mikalttx: I think its stronger than that20:29
mikalttx: I will vote against the proposed requirements as they stand20:29
mikalttx: I'm willing to tweak the language20:29
sdaguemikal: on that single point, or are there others?20:29
mikalttx: But I honestly feel we should have a test that says "people will use this"20:29
mikalsdague: I think this one point is a pretty big deal20:30
mikalWe have at least two virt drivers in nova at the moment that we don't know if _anyone_ uses20:30
mordredmikal: which ones?20:30
mikalI want to stop that happening at the project level as well20:30
sdaguemikal: no, that's fine, it wasn't an accusation, just a question20:30
* mordred not trolling, trying to get context20:30
mikalmordred: virt drivers? powervm and docker are the ones I am thinking of20:31
sdagueyeh, I only know one :)20:31
ttxmikal: the document will never represent the whole set of rules we'll apply, it just strives to document a number of rules that we all agreed on20:31
mordredmikal: k. thanks20:31
*** novas0x2a|laptop has quit IRC20:31
lifelessmikal: you'll vote against a necessary-but-not-sufficient ruleset because it doesn't contain a rule which there isn't consensus on ? :)20:31
markmcmikal, more context ... do you think we've not held projects to this standard so far and it's hurt us? examples?20:31
ttxlifeless: +120:31
jeblairmikal: openstack is not just public cloud software.  i think we should try to only add useful programs, but i also think there's room for being flexible here, and understanding that this isn't just for hpcloud and rax.20:31
vishymikal: not sure if anyone uses lxc either20:31
*** novas0x2a|laptop has joined #openstack-meeting20:31
mikalmarkmc: no, I think we've done a good job at the project level until now20:31
ttxlifeless: you expressed it better than I did :)20:31
mikalmarkmc: I just want to solidify that in the future20:31
mikalSo, rephrase it20:32
mikalWe could require that users have expressed a desire to deploy.20:32
markmcmikal, I'm not sure I feel we've held projects to the bar you describe so far20:32
ttxmikal: "project should have users" ?20:32
markmc"meets a clear user need" ?20:32
russellb"project should be usable" ?20:32
ttxusable is probably not enough20:32
mikal"Project should have planned deployments"/20:32
mordredvishy: I know people use lxc20:33
mikalmordred: good god, that would be horrible20:33
*** jecarey has joined #openstack-meeting20:33
markmcplanned deployments way, way overstates it IMHO20:33
russellbit's easy to wave hands around and say that you plan to deploy it ...20:33
russellbproject should be usable in production at scale in line with other openstack projects?20:33
markmcdo the Heat team have any insights even now to "planned deployments" of Heat?20:33
mikalmarkmc: yes, Rackspace have publicly stated they intend to deploy20:34
mikalmarkmc: I'd say HP has as well via tripleo20:34
sdagueyeh, I was going to say, trove was kind of an exception, looking at Heat and Ceilo20:34
jeblairhorizon wouldn't have made the cut for a long, long time.  but adding it was a GOOD idea.20:34
russellbsame for heat, i think20:34
mordredand now there are deployments20:34
*** denis_makogon_ has joined #openstack-meeting20:34
markmcmikal, ok, knew RAX was involved, hadn't heard about planned deployment20:35
russellband ceilo ..20:35
markmcmikal, but did that come before it was accepted into incubation? (no)20:35
sdaguecan we change the language to *should* - and then make it part of the judgement?20:35
markmcmikal, before graduation?20:35
lifelessRAX have a beta deploy20:35
lifelessyou can ask for access20:35
lifelessits just not GA yet20:35
markmclifeless, coolness, thanks20:35
sdaguehonestly, I think the raised bar on QA requirements will mean anything that gets near this bar, is going to be in a much better place for people to deploy20:35
lifelessso the question is20:36
lifelessto me anyhow :)20:36
annegentlesdague: similar for docs20:36
russellbsdague: and that's something *much* easier for us to measure20:36
russellbsdague: since it's under our control, where as deployments are not20:36
lifelessis incubation the path to integration, or the path to broad acceptance20:36
sdaguerussellb: right, exactly.20:36
lifelessI think it clearly should be the former, not the latter.20:36
lifelessI think there will be some of the latter occuring20:36
mikallifeless: it is often argued by applicants that it is a pre-requisite for the latter20:36
mikallifeless: as in "no one will use my thing until its incubated"20:37
mikallifeless: so we should incubate it and then say "so, does anyone use your thing?"20:37
lifelessmikal: and I accept that argument to a degree. Especially for things that we'd otherwise break willynilly.20:37
mikallifeless: cause if we're working on things people don't want, we should kill those things20:37
lifelessmikal: like hypervisor drivers.20:37
MarkAtwoodthats very frustrating to some projects, they want to get some users before incubation, to get feedback and devs20:37
russellbdrivers are a separate thing from projects ...20:37
lifelessmikal: I agree with killing unwanted projects.20:37
MarkAtwoodbut then are told "we wont run you until your incubated"20:37
lifelessrussellb: it was an allegory :)20:37
ttxmikal: how about you use the ML thread to come up with a vibrant call to take actual usage in account when considering graduation ? I'm pretty sure that won't be the only suggestion we'll receive out there.20:38
MarkAtwoodDesignate was in and somewhat still is in that trap20:38
mikalMarkAtwood: sure, so incubation is the time to prove your market. Not integration.20:38
sdagueI thought designate was in the trap of single vendor20:38
russellbMarkAtwood: designate's problem was nobody else working on it20:38
annegentleMarkAtwood: I don't like groups coming to us for resources, they should bring them.20:38
russellband you sohuldn't need to be able to production deploy it to join in to build the thing20:38
mikalttx: sure, is there an existing thread for these proposals?20:38
mikalttx: or are you about to send one?20:39
ttxmikal: I plan to start one based on the curret etherpads. Probably tomorrow20:39
mikalttx: sure, I will reply when it goes out20:39
mordredannegentle: I don't think that's teh designate issue20:39
MarkAtwoodrussellb, i personally got told by several large private cloud operators that the wouldnt start using or contributing to designate until other people did...  it was... frustrating20:39
russellbdesignate wants to apply again btw, i encouraged them to wait until we have these docs finished20:39
ttxI think that's something that will benefit from carefully-worded argument, rather than IRC discussion20:39
markmcttx, take a look over https://etherpad.openstack.org/p/incubation-and-integration-requirements as you're doing that20:39
annegentlemordred: yeah that oversimplifies it20:39
mordredannegentle: the designate issue is that the other companies kept waiting for us to 'bless' designate before starting projects to throw out their current dns aas20:39
markmcttx, I tried to dig up past threads, docs, etc. and summarize20:39
russellbMarkAtwood: then that's their broken approach, not ours20:39
mikalLook, I'm no trying to be a dick here... I just feel very strongly we should have users for our projects, especially before we devalue our brand by associating things people don't want with it.20:39
mordredwith several of them having declared they would, but none of them having done it yet20:40
markmcttx, not sure if we've gotten everything in your etherpads yet20:40
lifelessmikal: ack, I get that too20:40
ttxmarkmc: ncie20:40
ttxnice even20:40
jbrycejust as an extra data point, by the time heat and ceilometer were fully integrated, we had dozens of catalogued deployments for each from the user committees data20:40
jbryce40+ for heat and 70+ for ceilometer20:40
ttxmarkmc: i can wait until you turned that into the etherpad before starting up -dev discussion20:40
russellbjbryce: nice!20:40
annegentlemordred: then they're probably putting their interests first and not OpenStack's? That's at the heart of my line of questioning.20:40
MarkAtwoodrussellb: agreee that its there broken process not openstacks, but just be aware its a very common breakage20:41
*** epim has quit IRC20:41
mordredjbryce: it's possible that those are numbers we might want to be able to see when doing graduation review20:41
russellbMarkAtwood: common, as in 1 case?20:41
mordredjbryce: I did not know that20:41
markmcttx, nah, don't wait for me - I posted that etherpad here and on the list a couple of weeks ago20:41
lifelessannegentle: perhaps, but the problem is that 'they' in your sentence and 'they' in designates devs are different groups20:41
MarkAtwoodcommon as i see it many places, not just openstack world20:41
jbrycemordred: yeah...we can share the aggregate at any time whenever you're having those reviews20:41
*** denis_makogon_ is now known as denis_makogon20:41
*** vipul is now known as vipul-away20:41
markmcjbryce, was that at the end of the Havana cycle, or the start?20:41
MarkAtwoodpeople waiting for the crowd to move so they dont have to be in front20:41
mordredannegentle: of course they are - we're tyring to teach them - sometimes we have to leverage them into contributing to openstack20:41
mordredand sometimes they are companies who are already part of openstack but have alternate things that predate openstack20:42
markmcjbryce, Heat graduated at the start20:42
mordredso they're caught in chicken-and-egg problems20:42
annegentleAlso we still haven't seen much of a "food fight" in terms of competing solutions, does that scenario change any of our criteria?20:42
ttxmarkmc: everyone graduates before the start, actually20:42
annegentlemordred: yep, agreed20:42
russellbannegentle: good point20:42
markmcttx, right - just trying to get to whether that survey came before or after graduation20:42
ttxi.e. it's been 8 months that everyone knew it would be in Icehouse20:42
russellbannegentle: probably the incubation criteria20:42
markmcttx, i.e. did graduation trigger deployments, or did we have deployments before20:43
ttxmarkmc: I'm pretty sure adoption ramped up after graduation, before integration :)20:43
jbrycewe also have 7 trove and 8 ironic users catalogued currently20:43
mordredmarkmc: yah. interesting question20:43
lifelessthis suggests another concern20:43
lifelessif we push back too hard20:43
lifelessdo we make projects create their own brand20:43
mordredjbryce: dude. you have 8 ironic users catalogued?20:43
lifelessin order to get users20:43
jbrycemarkmc: those were numbers shortly pre-havana release20:43
markmcmordred, heh :)20:43
*** dprince has quit IRC20:43
lifelessso they they are less likely to really integrate?20:43
ttxok, let's push this to the ML thread that will start soon, or for open discussion at the end of meeting if there is time there20:43
mordredjbryce: that's both awesome and terrifying20:43
mordredttx: ++20:43
russellbannegentle: something like ... in the case that there are competing implementations, there is consensus that this implementation is the way forward for OpenStack ... or something20:43
sdaguettx: +120:44
ttxI have a few quick other things to cover20:44
ttx#topic Other governance changes in progress20:44
*** openstack changes topic to "Other governance changes in progress (Meeting topic: tc)"20:44
annegentlerussellb: or can we handle two at once?20:44
markmcjbryce, ironic doesn't (or didn't at the time of the survey) work at all, really :)20:44
ttxMission statement for Compute program: https://review.openstack.org/5798120:44
ttxI'll approve this one once it gets YES from the majority of voters20:44
* russellb just trying to catch up on program paperwork20:44
ttxI think a version with "including but not limited to" would be ok for everyone20:44
mordredannegentle, russellb there's also, comapnies that don't want to ditch their private thing, but _will_ once there is an official openstack thing20:44
ttxMake election times less ambiguous: https://review.openstack.org/#/c/57396/20:44
lifelesscough, HP, cough.20:44
*** dhellmann-afk is now known as dhellmann20:44
ttxI'll approve this one now as a factual/cleanup one, unless someone objects20:44
jeblairi +1d because i never think 'including' means 'including AND limited to'.20:45
jbrycemarkmc: the survey's always open. the ironic and trove numbers are current not pre-havana20:45
jeblairbut either wfm20:45
ttxjeblair: same here, but then I'm French20:45
markmcjbryce, ah20:45
*** DennyZhang has joined #openstack-meeting20:45
* russellb is fine either way too ... but generally prefers more well defined scope over open ended20:45
devanandajbryce: I'm assuming that you meant "8 catalogued nova-baremetal deployments" ?20:46
ttx#topic Open discussion20:46
*** openstack changes topic to "Open discussion (Meeting topic: tc)"20:46
sdaguejbryce: yeh, it would be nice to time bucket it so we could see evolution over time20:46
ttxi had one last thing:20:46
ttxlifeless suggested we should rule on the critical state for non-deterministic bugs20:46
ttxI replied on the TC list saying it's probably better handled a ML / wiki level unless there is a fight about it20:46
ttxdo you generally agree to keep it on ML/wiki rather than imposed by TC at this point ?20:46
lifelessso I'm torn20:46
russellbanyone fighting it?20:46
lifelesson the one hand yes - light weight TC is better20:47
jbrycesdague: we can, just the easiest view for me is a real-time report20:47
mordredyah. dolphm didn't like the use of critical20:47
lifelesson the other hand, this seems to be a bit of a bikeshedding thing already20:47
jgriffithrussellb: not sure how I feel on it yet TBH20:47
jeblairttx, lifeless: maybe we can bring it up at the project meeting next, and if there is disagreement, come back to tc?20:47
lifelessthe main reason I flagged it now on the tc list20:47
lifelessis the week lead time20:47
ttxjeblair: yes, probably a good bet20:47
lifelessif consensus happens by next week, then take it off the agenda.20:47
jgriffithrussellb: if the triage is accurate fine, but still wayyy too many incorrectly diagnosed20:47
lifelessthere is no project meeting now is there? I thought it was canceleld20:47
sdagueyeh, I like it being brought to the project meeting first20:47
mordredand while I agree with lifeless on the intent, I think dolphm also has a good point about that - perhaps that's a UI feature we can fix in storyboard...20:47
ttxlifeless: cacelled ? NEVER20:48
lifelessmordred: folk will never agree on the definition of critical I fear.20:48
jeblairjgriffith: er, i think the qa team has a really good track record on triaging gate-blocking bugs20:48
*** xga has joined #openstack-meeting20:48
sdaguemordred: yeh, maybe. fwiw, on projects that I have bug access I push all the race bugs to critical when I triage them20:48
jeblairjgriffith: to be clear, we're not at all suggesting any random person be able to do it.20:48
lifelessmordred: better to get out of the game entirely and just say 'this is the order we care about'20:48
ttxI don't really mind which way it's tracked. I just want to make sure however we track it, people react to it20:48
jgriffithjeblair: fair20:48
*** hartsocks has joined #openstack-meeting20:48
ttx"Critical" is a way to make it appear on my radar, which makes sure I pester people about it20:49
lifelessThe suggestion is two part: a) QA should have triage rights everywhere. b) gate affecting bugs should be top of the queue of work.20:49
* jgriffith is fine then... he can always change it :)20:49
mordredI agree with a and b20:49
lifelessThe bikeshed seems to be about how b is represented.20:49
mordreddetails about shed color bleh20:49
lifelessI am going to let it stew for a day or so before replying to whatever is said20:49
lifelesssince I've been around this many many times before20:50
sdaguehonestly, there are non QA core folks that should have this right too, as they do lots of awesome here, like clarkb and jog020:50
ttxlet's mention it at the project meeting after this one20:50
russellband also, not all "gate affecting" bugs are created equal ...20:50
*** rongze has joined #openstack-meeting20:50
mordredperhaps have an 'uber-triage' group that people can be in ?20:50
russellbit failed a few times may really not be the most valuable thing to work on today20:50
sdagueso if we are defining a subset, vs. open tracker, we might want to define a new group of folks that are responsible enough to have this priv20:50
ttxI'm just concerned about proliferation of TC edicts where none is actually necessary20:50
markmclifeless, I think it's more about building a culture of jumping on these issues20:50
mordredsdague: jinx20:50
russellbmarkmc: +120:50
*** sarob has quit IRC20:50
markmclifeless, setting bugs to critical isn't going to help it much20:50
dims"gate-keepers" :)20:50
russellbwhich i think is already getting better20:51
jeblairmost teams are open20:51
markmclifeless, what jog0 did this week is much more effective20:51
mordredttx: I'm not sure we need an edict here - I think a lot of times even just the tc talking about it can be useful for coordination20:51
sdaguemarkmc: I agree20:51
ttxyes, I think that task could benefit from some branding20:51
jgriffithwhen all bugs are critical, what does critical mean20:51
russellbwe need a jog0 for every project that is looking after stuff and making lots of noise when necessary20:51
jgriffithjust sayin20:51
sdagueand I think we are moving the culture, which is great20:51
lifelessmarkmc: I agree to an extent. Part of changing culture is making the desired thing super easy.20:51
lifelessmarkmc: 'bug is critical' is very easy for any contributor to see without needing a special search.20:51
mordredrussellb: we should put out a tc edict that every project provide infra/qa with a jog020:51
mordredrussellb: :)20:51
lifelessmarkmc: 'bug is high but tagged and you should search for those first' -> nowhere near as easy20:52
russellba gate czar!20:52
sdaguenice :)20:52
ttxlike the VMT is pursuing people to get things patched, the GateCrashSquad is after non-deterministic bugs and chase people down to make them care20:52
jgriffithalthough I do agree anything holding up gates is critical20:52
ttxlifeless: interesting to note that the VMT doesn't need to set bugs to critical to get them prioritized20:52
ttxalthough security bugs are arguably all critical too20:52
mordredhonestly - even just a "gate affecting" tag would allow people find gate affecting bugs20:52
jgriffithmordred: +120:52
jeblairmordred: but not raise visibility20:52
jgriffiththat would be the best solution IMO20:52
mordredbecause that's the main thing - 'how do I find a list of BLAH"20:52
jeblairmordred: no, i don't think that's the main thing20:53
mordredlifeless: vulnerability management team20:53
sdaguemordred: it's not quite the main thing20:53
lifelessventro medial..20:53
ttxmordred: yes, but I think you actually need to have a team chsaing people to make them all care, critical/tagged or not20:53
*** xga has quit IRC20:53
lifelessso the VMT is a specific team, and they have one search they do right ?20:53
jeblairmordred: i think the main thing is that there is a group of people who are good at identifying bugs that are stopping development work on the project20:53
jgriffithisnt' that what the PTL's should be doing?20:53
jeblairmordred: we need to make sure their work is visible20:53
ttxlifeless: vulnerability management team20:53
lifelessif we're going to build a dedicated gate tackling team, then having a tag is sufficient20:53
mordredjeblair: how is that different from what I said?20:53
lifelessIt's not clear to me that that is what we were going to do20:53
jeblairmordred: tagging a bug does not make it visible, except to people looking for it, and there are not very many people looking for it20:54
ttxlifeless: I think we already have the team, it just needs branding and to build awareness20:54
jeblairttx: who is the team?20:54
sdaguettx: I don't think we have a team20:54
markmcmaking these issues more visible - why not improve on http://status.openstack.org/rechecks/ ?20:54
mordredI also don't think we have the team20:54
lifelessttx: we do? Cool... links or it doesn't exist :P20:54
jeblairi think we need these bugs marked as critical, and active participation from project ptls, specifically because we don't have that team.20:54
sdaguewe have a few people that dropped the things they should have been doing to tackle it this time20:54
ttxjeblair: those people who worked on the recent gate break report look pretty well-organized to me20:55
sdaguettx: most of those people need to go back onto other stuff20:55
jeblairttx: no, sdague is right, they have other jobs20:55
lifelessmarkmc: again, if there is a group of folk tracking that specifically, its fine. But if we want to harvest the broad set of 'find a bug and work on it' - that fails to surface the information to the folk that I want to harvest20:55
* russellb views it as a function of the QA team, honestly ... to at least organize around the current issues20:55
russellband then yell at the right people to get their attention as necessary20:55
ttxjeblair: ok, fair enough. I'mjust unsure that will work. Whatever the way you mark those bugs20:55
sdaguettx: so I think from a triage perspective, to flag something as critical, we might be able to cover it20:56
sdaguebut to drive those fixes, that needs to come back from the project teams20:56
ttxjeblair: in my experience, marking bugs critical is no substitute for chasing people down. tha's what I do all the time20:56
*** masayukig has joined #openstack-meeting20:56
sdaguewhich is why flagging as critical is an important signaling mechanism20:56
*** rongze has quit IRC20:56
*** bknudson has joined #openstack-meeting20:56
ttxflagging things as critical lets you piggyback on ME to raise awareness in PTLs20:56
sdagueand making it culturally acceptable for people outside of a project team to do that for gate bugs is really the thing I'd like to make sure we're cool with20:56
*** jcoufal has quit IRC20:57
jeblairttx: that's why my suggestion is specifically that when the qa team marking something as critical, the project/ptl/dev-community should be notified, and we should expect someone to be assigned to it.20:57
markmcwhat rate of occurrence would a bug need for it to jump to Critical ?20:57
lifelessttx: do you have a problem with that ? :)20:57
*** masayukig has quit IRC20:57
russellbmarkmc: i'd like to know that too20:57
ttxlifeless: only works until I get bored about it20:57
russellbbecause not every failure is automatically a top priority IMO20:57
*** masayukig has joined #openstack-meeting20:57
russellbit's just not that simple20:57
sdaguemarkmc: honestly, any race in the gate I think is critical. It's non deterministic behavior that's able to be created in a relatively low concurent environment20:57
russellbwhat about the 800 other bugs already reported, that are more clearly defined than the gate failure bug?20:58
ttxinteresting as we'll have that discussion in the next meeting !20:58
markmcsdague, we're saying it's critical because it's holding up development - there are degrees of "blocking development"20:58
russellbthey're both things we know that are broken20:58
ttxwas there anything else somebody wanted to mention before we jump into the next meeting ?20:58
sdaguemarkmc: it's not critical because it's holding up development, it's critical because it's a race in openstack20:59
markmcsdague, "once every 10 years" is not Critical, "happens 50% of the time" is Critical ... so there's a boundary20:59
markmcsdague, it could be a race in unit tests, doesn't affect deployments20:59
sdaguemarkmc: fair, though we've not flagged any of those20:59
russellbwould like it defined20:59
sdagueonly devstack-gate20:59
russellbbecause if i get a bunch of critical bugs for something that failed twice and nobody knows why, i'm just going to get seriously annoyed21:00
markmcwell >50% of the time in unit tests *is* Critical21:00
sdaguewell, it will be at least a month before we've got enough stats to give yuo hard numbers21:00
*** mriedem has joined #openstack-meeting21:00
ttxok, we'll continue this ons in 40 min21:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"21:00
russellbin 40 min?21:00
openstackMeeting ended Tue Nov 26 21:00:27 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-11-26-20.02.html21:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-11-26-20.02.txt21:00
openstackLog:            http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-11-26-20.02.log.html21:00
russellbdoesn't the next meeting start now?21:00
russellbor you mean in open discussion :)21:00
sdagueI think that's where he put the discussion :)21:00
ttxrussellb: there are a few other topics to discuss first21:00
sdaguettx: but the iron is hot...21:00
ttxsdague: a bit of coolig down (and inclusion of PTLs) will help21:01
ttxdhellmann, dolphm, notmyname, jd__, markwash, jgriffith, russellb, stevebaker, david-lyle, markmcclain, hub_cap: around ?21:01
*** ndipanov has quit IRC21:01
ttxsalv-orlando replaces markmcclain I think21:01
*** olaph has left #openstack-meeting21:01
stevebakerttx: #startmeeting?21:01
ttxstevebaker: don't be impatient21:02
russellbstevebaker: no meeting for you!21:02
ttx#startmeeting project21:02
openstackMeeting started Tue Nov 26 21:02:19 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:02
*** openstack changes topic to " (Meeting topic: project)"21:02
*** sandywalsh has quit IRC21:02
openstackThe meeting name has been set to 'project'21:02
ttx#link http://wiki.openstack.org/Meetings/ProjectMeeting21:02
ttx#topic Icehouse-1 progress21:02
*** openstack changes topic to "Icehouse-1 progress (Meeting topic: project)"21:02
ttxicehouse-1 looks mostly on track from my 1-to-1s today, and not as empty as you'd think21:03
ttxWe should also have a Swift 1.11.0 next week21:03
*** masayukig has quit IRC21:03
*** boris-42 has joined #openstack-meeting21:03
* russellb resists obligatory "why is swift different" question ...21:03
*** michchap has joined #openstack-meeting21:03
ttxheat and horizon still have a lot to land21:04
ttxbut otherwise everyone else is on track21:04
ttx#topic Icehouse cycle roadmapping21:04
*** openstack changes topic to "Icehouse cycle roadmapping (Meeting topic: project)"21:04
ttxwe now have release status for icehouse at:21:04
lifelessttx: any release concerns about the proposed scheduler split out?21:04
ttx#link http://status.openstack.org/release/21:04
ttxlifeless: could you summarize your plans ?21:05
*** sarob has joined #openstack-meeting21:05
ttxWe have 172 tracked blueprints (Medium priority or above) in Icehouse so far21:05
ttxI'd like to have this basic roadmap to be complete by the end of the week21:05
*** vipul-away is now known as vipul21:05
ttxIt doesn't have to be "final" in any way.21:05
ttxIt just have to be a fair reflection of what you know will be worked on and when you expect that work to hit21:05
lifelessttx: https://etherpad.openstack.org/p/icehouse-external-scheduler line 38 down for three sections; BP is coming later today21:06
ttx(this is a coordination and communication tool)21:06
ttxSo please add missing blueprints to cover what you know should happen, and set an assignee and priority for them.21:06
russellbsince we're doing more in depth blueprint reviews for nova, there will still be a batch in the process, and not prioritized, but we'll have them all reviewed and at least under discussion21:06
ttxlifeless: so this causes a number of issues21:06
russellb(for nova)21:06
russellblifeless: i think we should just go off and do the technical bits that are right21:06
russellblifeless: and come back when we have something working, and a more well defined upgrade / deprecation plan21:07
lifelessrussellb: ack21:07
russellbthat we think are right, at least21:07
ttxlifeless: in theory a new project can't be integrated until J, supposing you fast-track incubation21:07
*** rakhmerov has quit IRC21:07
russellbttx: ack21:07
russellblooking at taking a cinder-like approach ... minimizing divergence from what it's replacing21:08
ttxso marking it deprecated supposes you have the alternate project well lined up to replace it21:08
russellbso that we can get to usable ASAP21:08
*** michchap has quit IRC21:08
ttxbut I guess overall that's doable. Cinder-style21:08
russellbearly, but i think it's doable :)21:08
ttxlifeless: i'll have to go deeper in that etherpad :)21:09
*** banix has quit IRC21:09
ttxrussellb: the trick is to avoid doing it ironic-style21:09
*** litong has quit IRC21:09
russellbwell ironic-style is closer to neutron style21:10
ttxrussellb: i.e. deprecating in icehouse and not replacing it in J21:10
russellbbut yes, with you on that21:10
russellbwon't deprecate until we know the replacement is well established21:10
lifelessso, if we start with it as a nova project in a new tree we'll have the technical room to do what we need.21:10
russellbcompute program project you mean?21:10
russellbIMO, yes, compute program until it starts growing real legs to do something more21:11
russellbbut it's a ways before it can get that far21:11
* annegentle sends lifeless some turkey and gravy21:11
ttxlifeless: you should still file for incubation asap. There are some pretty harsh requirements for incub/graduation now :)21:11
russellbthere's not even a repo yet :)21:11
lifelessso, lets move on21:11
lifelessI have what I need21:11
ttxother questions on icehouse-1 / icehouse roadmap before we discuss cross-project issues ?21:12
ttxmriedem: around ?21:12
mriedemttx: yup21:12
ttx#topic Oslo sync (mriedem)21:12
*** openstack changes topic to "Oslo sync (mriedem) (Meeting topic: project)"21:12
ttxmriedem: not yet! i'll let you introduce the discussion21:12
mriedemso i just brought up the oslo sync debate in the nova meeting last week,21:12
mriedemrussellb said it should come here since it's cross-project21:13
mriedemsince then the ML blew up a bit more but i haven't stayed up to date21:13
russellblet's not boil the ocean on this ... but basically, i was saying it wasn't a nova issue specifically21:13
mriedemthat's why dhellmann, bnemec, lbragstad and lifeless are here21:13
russellband that we should engage with dhellmann, and other oslo folks21:13
mriedemfrom what i gathered quickly from the ML was there is general consensus on improving update.py a bit?21:13
mriedemrussellb: right, that's what i meant to say :)21:14
ttxmriedem: that was my interpretation of that thread as well21:14
lifelessso the thing I really want to see21:14
lifelessis all the oslo bits that aren't evolving weekly21:14
lifelessreleased as libraries21:14
lifelesstheir special incubation period is over21:14
dhellmannwe are working on that21:15
lifelessand we'd avoid a raft of overhead keeping up with hacking format changes and stuff21:15
markmcmriedem, yeah, improving update.py would help21:15
lifelessdhellmann: I know - not criticising, just saying that thats what I really want to see21:15
dhellmannhowever, there are some unfortunate cross-dependencies21:15
markmclifeless, mostly agree, but there are some we'd regret taking that approach with when we struggle with future API changes21:15
lifelessdhellmann: because the other angle I'd go is aiming at making the incubator /be/ a library.21:15
dhellmannyes, I would prefer time spent on graduating code over gold-plating update.py21:15
markmclifeless, but I dig your point that if the APIs haven't changed for a long time, let's just bite the bullet21:16
lifelessmarkmc: AIUI the point of oslo is to go from 'production in one project to production in > one'21:16
lifelessmarkmc: the incubator I mean.21:16
*** jbryce has quit IRC21:16
* markwash loves the improvements we've been making before promoting to libs21:16
markmclifeless, point of incubator is to evolve towards API stability21:16
dhellmannlifeless: yes, but not "as is" -- we also try to make the code actually usable21:16
lifelessmarkmc: How do we measure that?21:16
dhellmannright, what markmc said21:16
markmclifeless, you feel the truthiness in your gut21:17
markwashlifeless: gut check?21:17
russellband i think oslo generally attracts people with a good gut for such things21:17
ttxone mornign I woke up and FELT that rootwrap was stable.21:17
lifelessmarkmc: but if noone is evoling the thing21:17
* dhellmann thanks russellb for complimenting his gut21:17
russellbhas worked well so far i think21:17
markmcAPIs in oslo-incubator are resting here temporarily until they have been21:17
markmccleaned up sufficiently so that we can make a commitment to backwards21:17
markmccompatibility and release the API in a properly published library.21:17
annegentledhellmann: snort21:17
lifelessmarkmc: we're stuck with manual integration rather than continual integration21:18
markmclifeless, incompatible API churn is painful too21:18
russellbwas afraid of this same discussion again, i feel like we've had it 100 times21:18
markmclifeless, basically, I think the incubation process is evolving, we'll see libraries released more quickly now21:18
ttxthe update.py pain is a good motivator for cleaning up APIs21:19
markmclifeless, but the principle of evolving towards API stability still makes sense21:19
dhellmannright, I think we figured out how to do it with oslo.config and oslo.messaging21:19
dhellmannthat's going to make the next few easier21:19
lifelessI'm not disputing the principle - thats a different discussion.21:19
lifelessI'm worried that we're not executing effectively, and I'd like to know how I and the community can help that happen.21:19
ttxOK, we've been havgin that discussion at least 10 times already, and I don't want to spend all this meeting on it21:19
markmcone thing that can help get libraries out more quickly21:20
markmcmore people helping!21:20
ttxespecially since we all know that markmc always wins the argument in the end21:20
*** yassine has quit IRC21:20
markmclifeless, seriously, pick a random API, turn it into a library ... see if anyone objects :)21:20
*** sandywalsh has joined #openstack-meeting21:20
bnemecHave we decided what to do with the pieces of Oslo that don't fit nicely into a library?21:20
dhellmannbnemec: which are those?21:20
dhellmannbnemec: maybe we should take that up after the meeting21:21
markmcttx, I dunno, lifeless does alright on that front :)21:21
ttxyes, anyone needing convincing can talk to dhellmann and markmc off-meeting, let's move on21:21
bnemecI don't have any off the top of my head, but I recall from previous discussions that there were things that didn't fit nicely.21:21
bnemecBut +1 to after the meeting.21:21
lifeless-> list21:21
ttx#topic Nova PowerVM Driver Removal (mriedem)21:21
*** openstack changes topic to "Nova PowerVM Driver Removal (mriedem) (Meeting topic: project)"21:21
lifeless'how can we move it faster'21:21
* jd__ agrees with ttx 21:21
ttxYou again :)21:21
mriedemso i don't have much else to say about the powervm driver removal21:21
ttxSo, on this one... I'm OK with a fast deprecation path if we don't screw any user in the process21:22
ttxWe got some reassuring comments from the User committee that this driver may not be in use21:22
mriedemttx: russellb's idea was just move it to stackforge21:22
russellbno users have shown up, one possible future user21:22
ttxBut then we had this guy: http://lists.openstack.org/pipermail/openstack/2013-November/003370.html21:22
mriedemwhich i think we're OK with21:22
*** sarob has quit IRC21:22
ttxthat said, if he is in POC -> Prod mode, choosing the PowerVM driver at this point might not be the best option, if IBM loses interest in maintaining it21:22
mroddeni am in favor of the stackforge move21:22
dims+1 to stackforge move21:22
ttxso we might just save him by encouraging him to not go on tat road21:22
mriedemttx: russellb: yeah, i think what the one user was saying is as long as it's freely available (stackforge), he's ok with it21:22
dhellmannwhat is the point of keeping the code without any maintainers?21:23
*** marekd is now known as marekd|away21:23
russellbyep ... but honestly, you guys have already said you're not interested21:23
ttxmriedem: I think he said (ubuntu) but meh :)21:23
russellbso i'm not sure why anyone would21:23
mriedemrussellb: not interested in what? stackforge?21:23
russellbnot interested in maintaining it long term21:23
ttxmriedem: you should probably engage with that specific person and make sure he moves to powervc when ready21:23
russellbso it seems like a dead end for someone to be looking to deploy in the next year21:23
russellband let's not confuse this with powervc21:24
russellbnone of this means we'd accept a powervc driver necessarily21:24
mriedemttx: yeah, that's what we plan on doing, there are some key people out to be in that discussion though this week (thanksgiving holiday)21:24
mriedemrussellb: right, that's understood21:24
russellbwe may or may not, but it would be evaluated based on its own merits21:24
dimsrussellb, what's your thought here? delete from nova and not move to it to stackforge?21:24
russellbit keeps getting brought up, and i really want to separate it21:24
mroddenwe will be maintain the powervm driver internally for some time until the powervc one is 'ready'ish21:24
russellbdims: delete from nova, and then you guys (IBM) do what you want21:24
ttxmriedem: so at this point I'm fine with fast deprecation + stackforge if there is some personal advice given to that one user who has mentioned wanting to use it21:24
russellbbut stackforge is an option21:25
mriedemmy only question about stackforge is if we can use the same gerrit and CI for running unit tests? i wasn't sure how that works.21:25
russellbsame infrastructure21:25
*** safchain has joined #openstack-meeting21:25
mriedemok, good to know21:25
russellb so actions21:25
mriedemas a fallback plan basically21:25
russellb1) approve the removal21:26
dimsrussellb, cool let's stick with that then "Delete from Nova, Move to Stackforge"21:26
lifelessso whats the difference between powervm and powervc21:26
russellb2) mriedem respond to the openstack post giving some recommendation to the one guy21:26
*** sarob has joined #openstack-meeting21:26
lifelessis one free with the hardware and one commercial ?21:26
mriedemlifeless: powervc is vcenter on power21:26
dhellmannas a note, there is currently a hold on creating new stackforge projects because of a zuul issue21:26
russellb3) move to stackforge21:26
*** julim has joined #openstack-meeting21:26
russellbmriedem: um, but not vcenter at all right?21:26
dhellmannso be aware of that when making scheduling plans21:26
russellbit's your own thing21:26
ttxrussellb: +121:26
mriedemrussellb: right21:26
lifelessdhellmann: is that a short or long hold?21:26
mriedemrussellb: i agree with your action plan21:26
russellbok thanks21:27
dhellmannlifeless: there's a bug they need to fix, so it depends on that21:27
russellbi think we can move on then21:27
dhellmann#link https://bugs.launchpad.net/openstack-ci/+bug/124256921:27
uvirtbotLaunchpad bug 1242569 in openstack-ci "manage-projects error on new project creation" [Critical,Triaged]21:27
ttxjeblair: do we have an ETA for the fix on this one ?21:27
* ttx has a icehouse-1 blueprint blokced on it)21:27
jeblairttx: mordred is working on it21:28
jeblairalso, totally not a zuul issue :)21:28
dhellmannttx, no, yours went through because it's not a stackforge repo21:28
jeblairit is a manage-projects issue21:28
russellb[infra magic] issue21:28
mordredyes. I will fix this in a few hours21:28
dhellmannjeblair: sorry, didn't mean to mischaracterize it21:28
ttxdhellmann: oh. nice. stops complaining21:28
mordredthe fix is well identified - I just need about an hour to actually do it21:28
* dhellmann would give mordred and hour if he had one21:28
mordredas soon as I'm done with these powerpoint slides...21:29
ttxok, let's move on21:29
ttxrussell did summarize the plan quite well21:29
ttx#topic flake8 (notmyname)21:29
*** openstack changes topic to "flake8 (notmyname) (Meeting topic: project)"21:29
ttxnotmyname: you mentioned getting pushback that forces you to ignore a check ?21:29
ttxbut then you were using a phone keyboard21:30
notmyname(maybe there has been process since)21:30
notmynameso swift has a few cases where a bare except is needed. so we offered a patch to hacking to support #noqa on bare excepts21:30
jeblair#link https://review.openstack.org/#/c/57334/21:31
*** banix has joined #openstack-meeting21:31
*** rnirmal has quit IRC21:31
lifelessnotmyname: thats surprising. Do you run on python2.4 ?21:31
notmynameit got some pushpack (https://review.openstack.org/#/c/57334/) which caused us to simply ignore the check https://review.openstack.org/#/c/56712/21:31
jeblairnotmyname: i don't see pushback21:31
jeblairnotmyname: except for a suggestion that the commit message have an explanation21:32
jog0notmyname: neither do I21:32
jog0in fact this hasn't got approved yet just do to review backlog21:32
lifelessnotmyname: I realise thats a side issue, but bare except: only difference from except BaseException in that it catches string exceptions21:32
*** casanch1 has quit IRC21:32
*** ArxCruz has quit IRC21:32
lifelessnotmyname: which are thorughly deprecated and dead upstream21:32
notmynamelike I said, seems perhaps there was movement yesterday that I hadn't seen21:32
notmynameso perhaps a non issue today (not that I have more info than when I was on my phone with ttx this morning)21:33
jog0so no feedback in a few days is pushback?21:33
dolphmnotmyname: is there a discussion somewhere regarding the need for bare excepts?21:33
*** masayukig has joined #openstack-meeting21:33
*** macjack has joined #openstack-meeting21:33
lifelessnotmyname: on a purely technical basis I'm fascinated :)21:33
* dhellmann wonders why each hacking rule has to look for noqa independently21:33
notmynamedhellmann: great question :-)21:34
dolphmnotmyname: (just found clay's comment on Nov 19 https://review.openstack.org/#/c/57334/ citing PEP8; reading)21:34
notmynamethere was other discussions in IRC earlier in the week that caused us to believe the hacking patch wouldn't land.21:34
ttxnotmyname: I think that patch is not blocked, so you should be able to remove your workaround21:34
notmynamettx: then we can move on21:34
ttx(when it lands)21:35
mordreddhellmann: each hacking rule parses the line using a few different methods - and there is not a global line parser for a line21:35
*** anniec has quit IRC21:35
notmynameI don't want to be blocked on that21:35
notmynameand simply wanted to raise it here to ensure it goes (based on IRC conversations more than review comments)21:35
ttxok, looks like this is a non-issue, next topic21:35
ttx#topic Proper tracking for non-deterministic bugs affecting gate21:35
*** devlaps has joined #openstack-meeting21:35
*** openstack changes topic to "Proper tracking for non-deterministic bugs affecting gate (Meeting topic: project)"21:35
*** yamahata_ has joined #openstack-meeting21:36
ttxThat one should be more bikeshedding21:36
ttxlifeless: want to introduce this one ?21:36
lifelessoh yay21:36
*** ArxCruz has joined #openstack-meeting21:36
russellbbtw, cross project topic for the queue ... checking in on neutron vs nova-network status21:36
lifelessso 40 minutes ago we were gathered here21:36
*** ArxCruz has quit IRC21:36
lifelessand talking about how to get gate bugs attention21:36
jeblairttx: NICE time estimate, btw!21:36
lifelessand the various tradeoffs between using the well known hammer of critical21:36
*** banix has quit IRC21:37
ttxjeblair: I'm a pro.21:37
lifeless(actually 38, but 40 was a h/t to ttx)21:37
lifelessor some gate-thing-specific search (e.g. /rechecks, a canned bug search - e.g. tag, etc etc)21:37
ttxlifeless: I thought notmyname's topic would create more flames.21:37
lifelessgo to it21:37
*** masayukig has quit IRC21:37
lifelessttx: well if my technical question was answered, maybe:P21:37
markmchow about we start by figuring out how to decide which non-deterministic failures are really critical?21:38
lifelesslets not use the word critical - overloaded.21:38
ttxmarkmc: I think sdague's point is that they all are21:38
*** rakhmerov has joined #openstack-meeting21:38
lifelessLets say - things we want 24 hour fast focus on21:38
ttxmarkmc: as they just add up21:38
sdaguemarkmc: so up until this point it's been the judgement of the group of us that flag it21:38
lifelessand things we want ahead of other bug fixes21:38
lifelessand things we want in the general mix of bugfixes21:38
lifelessbecause those are I think the three effective categories we have21:38
*** atiwari has quit IRC21:39
lifeless'drop everything', 'front of the regular queue', 'whenever'21:39
sdagueand I guess the question is if we're going to continue with a small group of folks with that power (either explicitly or by cultural construct), do we trust those folks to make good judgements there21:39
markmcthey sound like they should be marked as critical, yes :)21:39
markmchowever, if we have say 30 non-deterministic bugs right now ... they don't all qualify under that criteria21:39
ttxlifeless: some busy projects only have two ('drop everything' and 'whenever')21:39
*** dims has quit IRC21:40
dolphmare we also proposing that 'critical' bug fixes get priority in the gate queue?21:40
sdaguebecause the reality is, until the race shows up a few times it doesn't pop up21:40
ttxbut that's arguably a failure21:40
lifelessttx: degenerate case of front of the queue ;P21:40
sdaguemarkmc: so here's the thing, it's not 2 giant races21:40
russellbdolphm: have to be careful with doing that kind of thing, if it's automatic it'll get abused :(21:40
lifelessfrom collections import set as deque21:40
sdagueit's actually 30 little races that all interact21:40
markmcsdague, "trust to make good judgement" does not start with "all non-deterministic bugs, no matter how rare, are automatically Critcial" IMHO :)21:40
russellbmarkmc: big +121:40
dolphmrussellb: understood, that's why i'm asking! might affect my opinion on the larger issue21:40
lifelessso perhaps, if its the set of things that is the problem21:41
sdaguemarkmc: ok, well I've been staring at this one for a while. And the problem is we're actually getting killed by a thousand paper cuts.21:41
lifelesswe can talk about the criticality of making that set be below some threshold21:41
sdaguehowever, it will take some more time to be able to easily visualize that fact21:41
lifelessand if we agree about that, then we can say - whenever it's over that threshold, *all the members* count as critical until it's below the threshold.21:41
sdaguewhich is basically my top dev priority at this point21:41
markmcsdague, making them a thousand Critical bugs won't fix it :)21:41
dolphmmarkmc: ++21:42
lifelessmarkmc: what do you think will fix it?21:42
ttxlifeless: I think we could use Tag + High/Critical (as a way to prioritize amongst them)21:42
dhellmannhow many of these things do we actually have open right now?21:42
lifelessmarkmc: also it's 100 bugs spread over a dozen code bases.21:42
russellbi think we should focus on the goal ... making people want to work on this21:42
sdaguemarkmc: well let me reverse it. Do you think that what myself, jog0, and clarkb have done so far has made things better or worse?21:42
ttxi.e. if all critical, it might be hard to prioritize which one should be fixed first21:42
markmclifeless, the kind of work and awareness raising going on this week21:42
lifelessmarkmc: thats what - 10 per code base.21:42
jeblairfor those that haven't seen it, i imagine these bugs would be a subset of the bugs here: http://status.openstack.org/elastic-recheck/21:42
*** mrunge has joined #openstack-meeting21:42
jeblairi don't think it's 100 bugs...21:42
lifelessSo lets not extrapolate out to infinity on the data we have21:42
jog0right now we are tracking 9 gate bugs with e-r http://status.openstack.org/elastic-recheck/21:42
dolphmnot all bugs on /rechecks/ are actually transient issues at all21:42
lifelessjog0: we have 110 tracked rechecks today, if I counted right21:43
russellbwhat gets more people interested in helping with these things?21:43
dolphm(maybe they are at the moment, but it's not always true)21:43
sdaguedolphm: these aren't trusting the user provided bugs21:43
jog0lifeless: recehck vs elastic-recheck21:43
dhellmannjeblair: I count about 1821:43
jgriffithTBF it's not just 3 or 4 individuals making things better21:43
jeblairlifeless: the rechecks page has a lot of garbage data21:43
lifelessjeblair: ok!21:43
jgriffithand it's not just 3 or 4 that are going to address it21:43
markwashif they are critical, is there a good way to get help understanding and duplicating the bugs? I often cannot make heads or tails of the bug reports for things in the rechecks list21:43
lifelessso elastic-recheck is our source of truth?21:43
jgriffithit's a scaling problem21:43
sdaguethis is elastic recheck21:43
jeblairdhellmann: and at looks like 5 of them are ready to be removed21:43
jgriffithtags, priorities etc aside21:43
dhellmannjeblair: progress!21:43
markmcsdague, oh, far better ... totally - my input is basically that bumping a big number of bugs to Critical will hurt your progress21:43
sdaguewhich means that a set of us have found a fingerprint, and found that it shows up more than once21:43
dhellmannmarkwash: +121:44
jeblairso that puts us at about a dozen or so on the e-r page, but if jog0  says 9 i believe him :)21:44
jeblairlifeless: for this conversation, i think so.  elastic-recheck is made up of bugs that have gone through human review and we know are gate-affecting21:44
*** ArxCruz has joined #openstack-meeting21:45
*** fkak_ has joined #openstack-meeting21:45
russellbis there a good dashboard of the e-r bugs?21:45
jeblairlifeless: /recheck is sadly full of people rechecking things against nonsense bugs.  it will eventually be replaced with the e-r page21:45
russellbnm i see the URL now21:45
sdaguemarkmc: ok, fair. :) But we are talking about a finite set here - http://status.openstack.org/elastic-recheck/21:45
jeblairrussellb: that's sdague's big project for the next bit, to improve http://status.openstack.org/elastic-recheck/ and make it more dashboardy21:45
dolphmsdague: cool! this is new to me21:45
jd__so problem number one is people, noted. :)21:45
mriedemsdague: jog0: the elastic-recheck page is only for those that are in the yaml query file though right?21:46
russellbi think the improved dashboard will make a *much* bigger impact than changing bug priorities21:46
sdaguerussellb: I 100% agree21:46
russellbk :)21:46
sdagueunfortunately, had these other things take the last two weeks of my time21:46
*** joesavak has quit IRC21:46
sdagueso diving back in right after thanksgiving ont hat21:46
jeblairrussellb: here's the problem i want to solve -- we are able to fix these bugs only when we get people aware of them and working on them.  i'm trying to find the best process to do that.21:46
russellbthere was just a whole lot of focus on bug priority ...21:46
russellbjeblair: a good dashboard, and people regularly reporting status to the -dev list, and in meetings21:47
mriedemjeblair: i think it might help to show people how easy it is to get a bug into the e-r query.yaml file21:47
mriedemjeblair: once the bug is in the query and e-r is checking and reporting on it, you should stop seeing so many 'recheck no bug'21:47
russellblike jog0's report recently ... would love to see that regularly21:47
mriedemand it's pretty easy to push patches to add queries to -er21:47
russellbhere are the current issues and their status21:47
dhellmannrussellb: I think the point is giving devs a whole other place to look when deciding what to work on might be less effective than just setting the priority so they show up at the top of the list in the usual place21:47
sdaguerussellb: agreed, honestly, the sequence would have been better to hit this first21:47
russellband which ones need more attention21:47
sdaguerussellb: yes, that's completely the intention21:47
jeblairrussellb: i'm not sure we should wait for a good dashboard.  i anticipate that's a while out yet, and it depends on people incorporating 'wake up and check the dashboard' into their workflow21:47
*** dcramer_ has joined #openstack-meeting21:48
lifelessdhellmann: +121:48
lifelessdhellmann: thats precisely my point21:48
*** rakhmerov has quit IRC21:48
ttxfrankly, I think we are getting better at this, not worse.21:48
lifelessfolk are bad at pulling together widely disparate information sources in their inner loop of 'what to work on next'21:48
russellba weekly email then21:48
dolphmcould elastic-recheck leave comments on bugs as a starting point?21:48
salv-orlandoI think it already does?21:48
russellbor more frequent when there are severe issues21:48
sdaguedolphm: it already does21:48
markmcsdague, cool stuff - that page looks far more useful to people want to help with this than bug priorities21:48
jog0russellb: we plan on it21:48
dhellmannI like the weekly email and I like a tag ("gate"?) and I like setting the priority21:48
russellbok all good stuff21:48
ttxthe recent events have been quite well communicated imho21:48
dolphmi guess i'm lucky in that i haven't experience that yet lol21:49
russellbttx: yep21:49
markwashcritical isn't quite "where I look for stuff to work on" its more like "oh crap what is ttx gonna yell at me about?"21:49
jeblairmarkmc: thank you.21:49
sdaguedolphm: yeh, honestly, keystone isn't really subject to this much by not having an rpc bus21:49
dhellmannmarkwash: +121:49
lifelessmarkmc: I don't understand why you (seem to) think bug priorities aren't helpful21:49
lifelessmarkmc: but we can sidebar that if you like21:49
jog0so the recent gate issues have shown that we were just two bugs away from a massive gate wedge -- something we never want to have again21:49
ttxmarkwash: that's one benefit/problem of using "critical" for that. That reuses my nagging21:49
russellbi think markmc's point is to be careful not to dilute the value of bug priorities21:50
russellbmarking a ton of stuff critical is counter-productive21:50
sdagueso, honestly, I'm completely ok with the resolution of "go make the dashboard better first" and if it's not working talk about bug priorities later21:50
jeblairand we've only been able to fix these issues by getting people on it.21:50
russellbso just want some reasonable line21:50
lifelessso there are 18 such bugs21:50
russellband then i'd be Ok with it21:50
markmclifeless, just that marking obviously not-obviously-critical bugs as critical will be (yeah, as russellb says) counter-productive21:50
*** maxdml has quit IRC21:50
jeblairsdague: i don't see how getting a better dashboard will get people to commit to fixing bugs21:50
lifelessmaybe 14 once fixed ones are gc'd21:50
ttxhow about we use tag + high / critical depending on how urgent the fix is ?21:50
markwashttx: lol :-)21:50
russellbi don't see how marking bugs will either on its own21:50
lifelessmarkmc: russellb: ok, understood on dilution.21:50
jeblairsdague: right now, sdague and jog0 go and bother people until someone starts working on it21:50
ttx(that's already what we do, btw)21:51
jeblairthere has to be a better way to communicate21:51
markmcsdague, easy to use the dashboard as data to ask bug triage teams to bump the priority of bugs21:51
lifelessso the bug database is our shared understanding of defects21:51
russellbi think we'll always need people making this a higher priority on their list to look afer21:51
sdagueI guess here's the question - what is the right and consistent signaling mechanism to the PTLs to get people to look at bugs21:51
dolphmttx: and i think that's a sane approach!21:51
russellband then report status to the rest of the community21:51
lifelessmy point is that storing stuff elsewhere is a bit crazy21:51
jeblairsdague: exactly21:51
russellbsdague: more regular reports21:51
russellblist posts21:51
russellbmeeting topics21:51
lifelessbecause it dminishes the authority of the shared database of bugs.21:51
ttxsdague: how about raising them at this meeting weekly ?21:51
sdagueand the answer can't involve me or jog0 having to ping people regularly, because it doesn't scale21:52
*** alexpilotti has quit IRC21:52
lifelesshow about each project has an item to touch on them ?21:52
russellbneed to scale a team that makes this a priority to look after21:52
jeblairrussellb: these can't wait a week.  they need people working on them quickly.21:52
russellblist post for the critical ones21:52
sdaguerussellb: so I disagree, I think we need folks from the core teams that make it a priority21:52
markmcmark critical ones as critical :)21:52
russellbsomeone needs to take ownership over tracking it and pushing toward the solution, sort of like a VMT member does for a vulnerability21:52
ttxsdague: (if setting them High/Critical didn't trigger the right response)21:52
lifelessjeblair: all of them? AIUI there are 'zomg this alone is a killer' + 'we have a background level of noise that is a real problem'21:52
stevebakerlifeless: a sharp pointy item to touch on them? ;)21:52
*** vkozhukalov has quit IRC21:52
mriedemis it fair to say that all bugs on http://status.openstack.org/rechecks/ should have checks on http://status.openstack.org/elastic-recheck/ ?21:52
*** rongze has joined #openstack-meeting21:52
sdaguemriedem: /rechecks/ is kind of broken right now21:53
lifelessjeblair: It seems to me that 'zomg X' is drop-everything, and handled already, and 'background noise' is what we're trying to solve here21:53
ttxOK, we ahve a couple of other points to touch in this meeting. There is a calm thread on the ML, please hit it now21:53
jeblairlifeless: a lot of them, certainly.  i mostly want to indicate that many can't wait a week.21:53
russellbwish i had time for all the threads i'm interested in :(21:53
mriedemsdague: ok, point is, i think people have gotten used to finding a bug or opening one to recheck against, but not to adding e-r queries on them21:53
lifelessjeblair: ack21:53
russellbtough to keep up21:53
ttxmoving on21:53
sdaguemriedem: yes, that's true, we'll get better at this.21:54
mriedemif we have e-r queries on these things, they show up in patches and the e-r page21:54
russellbso each project could have a gate czar that is making this a priority?21:54
ttx#topic Red Flag District / Blocked blueprints21:54
*** openstack changes topic to "Red Flag District / Blocked blueprints (Meeting topic: project)"21:54
sdaguerussellb: +121:54
russellbwhat a naughty topic this is.21:54
ttxWe have no blocked blueprints that I know about21:54
ttxAny blocked work that this meeting could help unblock ?21:54
russellb(is what i think when ttx says red flag district)21:54
*** dims has joined #openstack-meeting21:54
*** ildikov has quit IRC21:54
russellbhrm, could consider deprecating nova-network as a blocked thing ... but that could be deserving of its own meeting topic each week21:54
ttxrussellb, salv-orlando: I haven't looked carefully into the neutron roadmap, do we have anything there to hope for icehouse ?21:55
russellbsummary of blockers: feature parity (there are icehouse plans, but then again, there were havana plans, and grizzly plans ...)21:56
russellband CI / general quality parity21:56
*** Toshi has joined #openstack-meeting21:56
russellbnot sure on the progress there21:56
salv-orlandoon the deprecation issues, that goes far beyond my reach. On the specific parity items21:56
ttxneutron suffers a bit from too much tactical, not enough strategic contributions yet21:56
russellband to be clear, i've started saying that i'd like to re-evaluate nova-network's status after icehouse-221:57
ttxand the very few that do strategic contributions are totally overwhelmed21:57
russellbdepending on progress, i may propose un-freezing nova-network21:57
ttxand get a lot of blame21:57
russellbttx: yep ...21:57
salv-orlandottx: don't understand what you mean by tactical and strategic. Can you explain?21:57
ttxso that do not encourage other people to go all in21:57
*** dcramer_ has quit IRC21:58
ttxsalv-orlando: tactical = feature in a vendor plugin21:58
ttxstrategic = test coverage, feature gap21:58
russellbstrategic = anything beneficial to the project overall21:58
*** rongze has quit IRC21:59
salv-orlandocool I get it - I think we're all aware of this issue. Thankfully the strategic contributor team is gathering new members21:59
ttxoldie but still relevant: http://fnords.wordpress.com/2011/09/28/the-next-step-for-openstack/21:59
ttx#topic Open discussion21:59
*** openstack changes topic to "Open discussion (Meeting topic: project)"21:59
ttxmarkwash: wanted to quickly raise the client lib thread ?22:00
markwash#link http://lists.openstack.org/pipermail/openstack-dev/2013-November/019911.html22:00
*** DennyZhang has quit IRC22:00
ttxsorry not much time left22:00
russellbso no updates on that?  :(22:00
*** yamahata_ has quit IRC22:00
markwashjust wanted to mention, we've got some rough consensus approaching there I think22:00
markwashin case folks want to (struggle to) review the thread22:00
ttxrussellb: we might want to make it a full topic at another meeting22:00
markwashI can summarize what it seems to me later today22:01
*** markvoelker1 has quit IRC22:01
ttxrussellb: although markmcclain might be traveling a lot on next Tuesdays22:01
ttxmarkwash: yeah, maybe summarize what you intend to do basd on the outcome of that thread... that might trigger new answers22:01
markwashttx: deal22:01
*** pub_tap is now known as hub_cap22:01
*** sparkycollier has quit IRC22:01
ttxmarkwash: "WAT! defintely DONT do that"22:01
*** lsell has quit IRC22:01
*** twoputt has joined #openstack-meeting22:02
*** twoputt_ has joined #openstack-meeting22:02
ttxAnd we are out of time22:02
dolphmregarding QA team having triaging abilities on LP, is there someway PTL's can opt into that short of making all those people *-core?22:02
jeblairopen bug teams22:02
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"22:02
openstackMeeting ended Tue Nov 26 22:02:37 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:02
markmcdolphm, well, e.g. nova-bugs is an open team22:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/project/2013/project.2013-11-26-21.02.html22:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/project/2013/project.2013-11-26-21.02.txt22:02
openstackLog:            http://eavesdrop.openstack.org/meetings/project/2013/project.2013-11-26-21.02.log.html22:02
jeblairmost projects have open bug teams already :)22:02
*** bknudson has left #openstack-meeting22:02
*** markmc has quit IRC22:02
jeblairkeystone does not22:03
ttxand all should have. There was some silly resistance last time I proposed it22:03
jeblairand neutron does not22:03
markwashglance does22:03
dolphmttx: why doesn't keystone?22:03
markwash(very recently, thanks jeblair)22:03
jeblairmarkwash: thank you!22:03
sdaguemarkwash: yes, thanks !22:03
*** matty_dubs has joined #openstack-meeting22:04
*** michchap has joined #openstack-meeting22:04
sdaguedolphm: because you haven't set the permissions. you've got the power.22:04
*** derekh has quit IRC22:04
hub_capttx is a mail history ninja :)22:04
ttxsdague: see my proposal in the link there22:04
jeblairdolphm: or i can do it if you want, i have the page open. :)22:04
ttxdavid-lyle: feel free to kick us out and start your meeting22:04
david-lyle#startmeeting Horizon22:04
openstackMeeting started Tue Nov 26 22:04:44 2013 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.22:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.22:04
*** openstack changes topic to " (Meeting topic: Horizon)"22:04
openstackThe meeting name has been set to 'horizon'22:04
david-lyleHello Horizon folks!22:05
jomarahello everyone22:05
* stevebaker lurks if needed22:05
*** pdmars has quit IRC22:05
david-lyleIcehouse-1 feature freezes on Dec 3, everything scheduled for it is up for review.22:06
*** boden has quit IRC22:06
david-lyleand only 2 have been merged22:06
david-lyleso reviews are needed, by all22:06
david-lyle#topic Review IA proposal22:07
*** openstack changes topic to "Review IA proposal (Meeting topic: Horizon)"22:07
*** IlyaE has quit IRC22:07
david-lyleSo, I don't want to do the review today, but Jarda and I have spent a little time collaborating on an IA diagram based on the summit talks22:08
*** ruhe has quit IRC22:08
david-lyleThis is still a proposal and feedback is requested in the ux askbot tool22:08
*** IlyaE has joined #openstack-meeting22:09
*** macjack has left #openstack-meeting22:09
david-lyleThere will be actual documentation that goes along with this once finalized and some blueprints to support reorganization22:09
*** michchap has quit IRC22:09
*** dperaza has quit IRC22:10
*** ArxCruz has quit IRC22:10
*** ArxCruz has joined #openstack-meeting22:10
david-lyle#topic (lsmola)Deleting of resource usage page tables: https://bugs.launchpad.net/horizon/+bug/124927922:10
*** openstack changes topic to "(lsmola)Deleting of resource usage page tables: https://bugs.launchpad.net/horizon/+bug/1249279 (Meeting topic: Horizon)"22:10
uvirtbotLaunchpad bug 1249279 in horizon "Resource Usage Page table views shows statistics in a wrong way" [Medium,In progress]22:10
lsmolaso it is described here https://bugs.launchpad.net/horizon/+bug/124927922:10
lsmolathing is, the tables were very buggy, so I am deleting them22:11
lsmolaif anybody thinks they should stay, speak now :-)22:11
david-lylein the review you are not only deleting the view, but the API calls as well?22:12
*** michchap has joined #openstack-meeting22:12
lsmolaplan is to rather spread those stats through all dashboards table as sparklines22:12
jpichHaving tried to explain what "Network duration" meant in the table context, I agree they are hard to understand and confusing at the moment. Removing them until the improved version (tm) makes sense to me22:12
jomarasparklines are fancy!22:12
mrungeso why are you removing API calls as well22:13
lsmoladavid-lyle, the basic api call stayed, just the concrete were deleted22:13
david-lyleok, so what's left in the page, some charts?22:13
lsmoladavid-lyle, yes, linechart showin all stats22:13
lsmoladavid-lyle, that could be moved somewhere else, if it should be only thing left there, like a tab of overview page22:14
*** yamahata_ has joined #openstack-meeting22:14
david-lylelsmola: ok.  if the data is incorrect or buggy anyway, I don't see a reason to keep them22:14
jpichWe've usually not included API calls if they're not used anywhere in our codebase, which makes sense to me. The ones that make sense can be brought back later if needed22:14
lsmolamrunge, those were specialized API calls for the tables, it doesn make sense to keep without the tables22:14
lsmolajpich, yes22:15
mrungelsmola, yeah. got that22:15
mrungelsmola, still I'd love to see replacements22:15
lsmolasomebody needs to step in, and document all Ceilometer metrics on ceilometer side, apparently each metric is special22:15
lsmolathat somebody will probably be me22:15
lsmolathough feel free to sign up :-)22:16
lsmolamrunge, well the point is whether we need it centralized into one table22:16
*** IlyaE has quit IRC22:16
lsmolamrunge, or rather spread as sparklines22:16
*** mrodden has quit IRC22:17
lsmolamrunge, so e.g. table with instances will also contain sparklines like cpu_util, memory use, etc.22:17
lsmolamrunge, so the data that was originally here22:17
mrungelsmola, we agreed in Portland in April, we don't want graphics centralized, but spread throughout the dashboard22:17
lsmolamrunge, not in the form of sparklines though22:17
lsmolamrunge, yes22:17
mrungelsmola, yes, got that ;-)22:17
lsmolamrunge, it will make the whole dashboard more beautiful22:18
david-lyleand are page loads blocked on the api calls to ceilmeter for each sparkline?22:18
mrungelsmola, we had a proposal back in April, just showing all graphics on one page. Somehow that was not appreciated22:19
lsmoladavid-lyle, nope22:19
*** casanch1 has joined #openstack-meeting22:19
lsmoladavid-lyle, right now, each chart take care of itself via ajax22:19
david-lylelsmola: very good22:19
mrungeyupp, great!22:19
lsmoladavid-lyle, later there will be manager that will group them, with some enhancements of Ceilometer and API. I can make more queries in one using group by22:20
david-lyleI think the understanding was the existing ceilometer page was a first pass at integration to have something to show for the Havana efforts in that direction22:20
*** banix has joined #openstack-meeting22:20
lsmoladavid-lyle, yes22:20
david-lylesince the integration is maturing, we want to move it to the proper location22:20
*** anniec has joined #openstack-meeting22:21
david-lyleThe remaining meters are cross-project measurements then22:21
david-lyleerr, I guess global22:21
david-lylecross cloud?22:22
lsmolawhat do you mean by remain ing meters?22:22
*** mriedem has left #openstack-meeting22:22
*** vipul is now known as vipul-away22:22
*** vipul-away is now known as vipul22:22
david-lyleon the existing view if you remove the table22:22
*** maxdml has joined #openstack-meeting22:22
lsmoladavid-lyle, yeah those vere aggregates, grouped by project22:23
lsmoladavid-lyle, though they are tracked per resource22:23
lsmoladavid-lyle, so I think implementation of sparklines will start on project tab, as it shows the resources22:24
david-lylethe latter thing you said scales, how does the first?22:24
*** fkak_ has quit IRC22:24
lsmoladavid-lyle, then we will see how to show the agregates for admin22:24
david-lyleaggregate per project?22:24
*** epim has joined #openstack-meeting22:24
david-lyle10000 projects?22:24
*** SergeyLukjanov has quit IRC22:25
lsmolawell, that is the other thing, we will probably have to paginate the chart22:25
lsmolafor sparklines, tables will be paginated22:25
david-lylealright, we can take the second part offline, but it worries me22:26
david-lyleI think removing the existing tables and concentrating on spark lines is a valid approach22:26
lsmolayeah we were speaking with jcoufal and other how to scale the resource usage page linechart for more projects22:26
david-lyleanyone disagree?22:26
lsmoladavid-lyle, yes itÅ› a good start22:27
david-lylealright, sounds good22:27
david-lyle#topic Updates from I18N team22:27
*** openstack changes topic to "Updates from I18N team (Meeting topic: Horizon)"22:27
*** SumitNaiksatam has quit IRC22:28
*** SumitNaiksatam_ has joined #openstack-meeting22:28
amotokias i wrote on wiki, i18n team plans to update translations for 2013.2.122:28
*** danwent has quit IRC22:28
jpichwhich is awesome :)22:28
amotokithere are some patches to fix strings. I hope they are merged soon :-)22:29
david-lylelooks like 1 is merged and 3 are still pending22:29
*** anniec has quit IRC22:29
amotokifor havana update, i don't propose POT files update patch . Instead i directly update transifex.22:30
* jpich didn't know one could do that22:31
jpichamotoki: Does that mean the strings can be changed ahead of the patch landing?22:31
amotokijpich: it can, but we need to maintain private branch to do that :-(22:31
*** dperaza has joined #openstack-meeting22:32
amotokii think it is not a good idea.22:32
david-lyleok, so we need to find another stable branch maintainer other than mrunge22:32
david-lyleI can work on that22:32
*** dvarga has quit IRC22:33
mrungedavid-lyle, I'd love to see someone from another company, different to Red Hat22:33
jpichamotoki: Probably - I'm not sure what you are proposing then? Also, did we create the new horizon_havana repo yet? (Sorry I didn't follow the latest updates)22:33
*** thedodd has quit IRC22:33
*** danwent has joined #openstack-meeting22:33
mrungedavid-lyle, if it's urgent, I know who to contact22:33
* david-lyle totally oblivious to process22:33
david-lyleof course there's a wiki page :)22:34
jpichPeople interested in joining should start including a comment on "why this is an appropriate, safe backport" when +1ing stable patches22:34
jpich...though it's actually a good habit to pick up for everyone :)22:34
jpichthere's always a wiki page22:34
* david-lyle enlightened22:35
david-lyleif only there was a search on the wiki...  oh wait22:35
amotokijpich: to update transifex before landing a patch, we need to collect proposed patches. this is "private branch" i mean.22:36
david-lyleamotoki: ok, we'll work to get those merged22:36
*** Swami has joined #openstack-meeting22:36
jpichamotoki: Ok! Hopefully we can avoid this. Thank you :)22:36
amotokithat's all from me.22:36
amotokijpich:  any addition?22:37
david-lylethanks for tracking this amotoki22:37
jpichNope... You mentioned the timeline, we should have a translation patch up before Dec 5th when the stable branch will be frozen and the latest patches merged22:37
*** lexx has quit IRC22:37
jpichYes, thanks a lot amotoki!22:38
*** yamahata_ has quit IRC22:38
david-lyle#topic Open Discussion22:38
*** openstack changes topic to "Open Discussion (Meeting topic: Horizon)"22:38
david-lylebtw: really enjoying agendas, thanks for posting them ahead of time22:38
jpichdavid-lyle: I was wondering: if there a keystone bug or blueprint you know of, for tracking read access to RBAC policies?22:39
jpichWe might want to include the meeting date in the agenda, I always wonder first if it's last week's or next... maybe just me :-) Still love having them!22:39
mrunge+1 for having agendas!22:40
david-lylenot that I am aware of, had conversations with ayoung in Hong Kong, but I haven't made it beyond that22:40
ayoungwhat are we talking about?22:40
lsmolajpich, true, I havent noticed date is missing22:41
*** radsy has joined #openstack-meeting22:41
david-lylepolicy read access22:41
david-lylepolicy management in general22:41
ayoungdavid-lyle, as I recall, the real issue was figuring out which policy to hand to which endpoint. Who can read it is probably a related but different problem.22:42
ayoungAnd..since horizon does everything as the end user...22:42
david-lyleayoung: yes, making the policy available to horizon22:43
ayoungno bug that I am aware of.  BUt I'm heads down in other things ATM22:43
ayoungplease file.22:43
*** rakhmerov has joined #openstack-meeting22:43
*** kevinconway has quit IRC22:43
david-lyleayoung: will do22:43
jpichdavid-lyle: Please send me the bug # afterwards so I can subscribe too :-)22:44
david-lyleand the date was missing out of laziness :)22:44
david-lyleso much to update22:45
david-lyleany other items22:45
*** rdxc has joined #openstack-meeting22:45
casanch1hi, I'm new in the community and have been working in a couple of bugs to add client-side validations22:45
dolphmjpich: GET /v3/policies <-- but we don't have a policy engine to consume from that API, yet22:46
*** galstrom_zzz is now known as galstrom22:47
uvirtbotLaunchpad bug 1125232 in horizon "Object Upload is validated after object upload" [Medium,In progress]22:47
david-lyledolphm: we just wanted read access to the blobs, that noone is uploading22:47
devlapscasanch1: thanks for doing this. would also be useful for this bug: https://bugs.launchpad.net/horizon/+bug/125379122:48
uvirtbotLaunchpad bug 1253791 in horizon "create an image leaks tmp file if name not specified" [Undecided,In progress]22:48
david-lyleand a way to tie it to the endpoint22:48
*** dkranz has quit IRC22:48
jpichdolphm: Oh, thank you! Is the related work tracked/documented somewhere?22:48
casanch1I've noticed that there's no client-side validations, but in cases like that bug, I think it make sense, so to avoid file uploads22:48
dolphmjpich: it would be in oslo, if anything -- but i'm not aware of it22:48
david-lylecasanch1: I agree a client side check makes sense22:49
dolphmjpich: it'd be an extension of the existing policy engine that pulls the policy blob from keystone and caches it rather than from disk22:49
david-lylecasanch1: will definitely take a look at your approach22:50
dolphmjpich: keystone doesn't pretend to understand the policy documents though -- and doesn't dictate the use of JSON or a particular language22:50
casanch1so, I proposed a quick fix by adding HTML5 required attribute to some fields. This might be enough for now, but for sure it'll be needed a common approach for that kind of validations22:50
casanch1david-lyle: ok, thanks22:50
dolphmjpich: so what you pull from keystone might be service/PEP specific22:50
david-lyledolphm: are your referring to the mailing list item re: policy as a service?22:51
david-lyleor a third thing?22:51
dolphmdavid-lyle: oh no, there's that too!22:51
jpichdolphm: Interesting, thanks. Obviously I need to do some more reading around policies22:51
dolphmdavid-lyle: i haven't gotten my head around congress at all22:51
david-lyledolphm: an endpoint specific policy blob is fine22:51
jtomasekcasanch1, david-lyle: Angular has good means for client side validations, I think there is a good reason to check that out, once angular is in...22:52
*** mrunge has quit IRC22:52
*** hartsocks1 has joined #openstack-meeting22:52
dolphmjpich: keystone's policy API is intentionally lightly defined... https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#policy22:52
lsmolajtomasek, yeah22:52
david-lylebut, if it's not based on the json rules that the oslo policy engine uses, we're lost22:53
dolphmjpich: there's no relation to services, endpoints or domains because we didn't have a strong use case to dictate any of that22:53
dolphmjpich: so a new policy engine would basically have to know the policy ID, or really just URL, to fetch the policy from22:53
casanch1jtomasek: I agree, but if angular is not in... I think it's worth it to have a temporal solution which will prevent waste of resources to upload unnecessary files22:53
jtomasekcasanch1: definitely agree22:54
david-lyledolphm: which makes it unusable by Horizon, unless we want to upload our own policy blob to store and read, as an admin22:54
*** jdurgin has quit IRC22:55
*** medberry is now known as med_22:55
david-lylebut it seems our use case came late to the party22:55
*** rongze has joined #openstack-meeting22:55
*** hartsocks has quit IRC22:55
lsmolacasanch1, yes, as long as it is a few lines patch, it is alright to have it as temporary solution22:55
*** thomasem has quit IRC22:55
*** denis_makogon has quit IRC22:56
*** lsell has joined #openstack-meeting22:56
*** vijendar has quit IRC22:56
jpichdolphm: I see. There's lot of things I forgot to consider, thanks for the extra information22:56
*** galstrom is now known as galstrom_zzz22:56
lsmolacasanch1, jtomasek I guess proper general client side vaidations in angular, integrated to horizon framework will take some time :-)22:56
*** yamahata_ has joined #openstack-meeting22:57
casanch1lsmola: it's only one line patch for each field to be marked as required with HTML5 attributes22:57
jomaranot that much time22:57
*** danwent has quit IRC22:57
lsmolacasanch1, yes, I have just checked, thank you for that patch :-)22:57
jpichdavid-lyle: I need to level up my grasp of policy before I try to review your patches again :-) I forgot about the headaches around e.g. different policy files on different compute nodes22:57
jomaraangular is just one core review away from being in right?22:58
lsmolajomara, sooner the better :-)22:58
*** jcooley_ has joined #openstack-meeting22:58
jomaraprobably not worth implementing a stop gap before that22:58
lsmolajomara, not sure, this is really like few lines of code, that can be easily wiped out22:59
david-lylejpich: yes, there are lots of potential holes, but I designed in a fail safe in the settings files to just ignore policy22:59
lsmolajomara, yep angular should be in very soon22:59
*** jmontemayor has quit IRC22:59
*** rongze has quit IRC22:59
*** tims has joined #openstack-meeting23:00
*** dolphm is now known as dolphm_afk23:00
david-lylejomara: thanks for the angular jump start23:00
lsmoladavid-lyle, do i see client side validations as a topic for the next meeting?23:01
lsmolajomara, casanch1 ^23:01
*** burt has quit IRC23:01
david-lylelsmola: I think so23:01
casanch1when angular is in, I can for sure work on another implementation to add those client-side validations23:01
jomaradavid-lyle: np23:01
david-lylelooks like times up23:01
david-lylethanks everyone23:01
jomaracasanch1: just stay tuned, itll be soon:)23:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"23:01
openstackMeeting ended Tue Nov 26 23:01:49 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)23:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/horizon/2013/horizon.2013-11-26-22.04.html23:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/horizon/2013/horizon.2013-11-26-22.04.txt23:01
openstackLog:            http://eavesdrop.openstack.org/meetings/horizon/2013/horizon.2013-11-26-22.04.log.html23:01
*** tims has left #openstack-meeting23:01
lsmolathanks everyone, have a good night23:02
jpichThanks everyone, enjoy the rest of the day23:02
devlapsthanks all!23:02
*** raghu_rao has quit IRC23:02
casanch1thanks all23:02
david-lylebtw: holiday in US this Thurs so less activity from my end later this week23:02
amotokibye all, thanks23:02
david-lyleif that was possible23:02
jpichEnjoy the holiday :)23:02
*** matty_dubs has left #openstack-meeting23:03
jtomasekthanks all23:03
*** hartsocks1 has quit IRC23:03
*** hemna is now known as hemnafk23:04
*** jpich has quit IRC23:04
jomaralater guys23:06
*** lsell has quit IRC23:06
*** lsmola has quit IRC23:06
*** neelashah has quit IRC23:07
*** jtomasek has quit IRC23:08
*** kspear has joined #openstack-meeting23:08
*** hartsocks has joined #openstack-meeting23:08
*** amotoki has quit IRC23:09
*** casanch1 has quit IRC23:09
*** pcm_ has quit IRC23:10
*** lsell has joined #openstack-meeting23:10
*** oubiwann_ has quit IRC23:10
*** ivasev has quit IRC23:12
*** gokrokve has quit IRC23:12
*** nono1_ has joined #openstack-meeting23:12
*** gokrokve has joined #openstack-meeting23:12
*** julim has quit IRC23:16
*** banix has quit IRC23:17
*** Swami has quit IRC23:17
*** rakhmerov has quit IRC23:17
*** otherwiseguy has quit IRC23:18
*** eharney has quit IRC23:18
*** lsell has quit IRC23:19
*** yamahata_ has quit IRC23:20
*** ryanpetrello has quit IRC23:22
*** epim has quit IRC23:22
*** nono1_ has quit IRC23:23
*** jdurgin has joined #openstack-meeting23:24
*** reaper has quit IRC23:26
*** epim has joined #openstack-meeting23:26
*** armax has left #openstack-meeting23:28
*** ryanpetrello has joined #openstack-meeting23:28
*** cyclicflux has joined #openstack-meeting23:29
*** cyclicflux is now known as Guest5025523:30
*** sacharya has quit IRC23:30
*** Guest50255 has quit IRC23:31
*** kspear has quit IRC23:31
*** Guest50255 has joined #openstack-meeting23:31
*** otherwiseguy has joined #openstack-meeting23:31
*** boris-42 has quit IRC23:32
*** Guest50255 has quit IRC23:32
*** cyclicflux_ has joined #openstack-meeting23:32
*** Linz has quit IRC23:34
*** Linz has joined #openstack-meeting23:34
*** cyclicflux_ is now known as CyclicFlux23:36
*** vipul has quit IRC23:43
*** vipul has joined #openstack-meeting23:44
*** vkmc has quit IRC23:45
*** ryanpetrello has quit IRC23:47
*** epim has quit IRC23:47
*** danwent has joined #openstack-meeting23:47
*** weshay has quit IRC23:51
*** MarkAtwood has quit IRC23:54
*** rongze has joined #openstack-meeting23:56
*** epim has joined #openstack-meeting23:56
*** jcooley_ has quit IRC23:56
*** oubiwann has joined #openstack-meeting23:56

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