Monday, 2013-10-21

*** pjd2 has quit IRC00:05
*** pjd2 has joined #openstack-dev00:08
*** xarses has joined #openstack-dev00:09
*** SlickNik has quit IRC00:13
*** SlickNik has joined #openstack-dev00:13
*** buzztroll has joined #openstack-dev00:15
*** senk has joined #openstack-dev00:16
*** pjd2 has quit IRC00:17
*** senk has left #openstack-dev00:18
*** buzztroll has quit IRC00:19
*** dot has quit IRC00:21
*** matsuhashi has joined #openstack-dev00:25
*** nati_ueno has joined #openstack-dev00:30
*** jamielennox|away is now known as jamielennox00:32
*** stevemar has quit IRC00:33
*** schwicht has joined #openstack-dev00:40
*** buzztroll has joined #openstack-dev00:44
*** buzztroll has joined #openstack-dev00:45
*** adalbas has joined #openstack-dev00:48
*** buzztroll has quit IRC00:49
*** faramir has joined #openstack-dev00:52
*** ArcTanSusan has quit IRC00:52
*** nosnos has joined #openstack-dev00:56
*** pjd2 has joined #openstack-dev01:00
*** ArcTanSusan has joined #openstack-dev01:01
*** senk has joined #openstack-dev01:08
*** SlickNik has quit IRC01:08
*** oubiwann has quit IRC01:09
*** SlickNik has joined #openstack-dev01:09
*** oubiwann has joined #openstack-dev01:09
*** nosnos has quit IRC01:10
*** nosnos has joined #openstack-dev01:11
*** senk has left #openstack-dev01:11
*** dkranz has quit IRC01:17
*** ArcTanSusan has quit IRC01:17
*** erkules_ has joined #openstack-dev01:18
*** schwicht has quit IRC01:19
*** erkules has quit IRC01:21
*** juice has quit IRC01:23
*** juice has joined #openstack-dev01:23
*** juice has quit IRC01:23
*** juice has joined #openstack-dev01:24
*** juice has quit IRC01:24
*** juice has joined #openstack-dev01:24
*** juice has quit IRC01:24
*** juice has joined #openstack-dev01:25
*** juice has quit IRC01:25
*** juice has joined #openstack-dev01:26
*** juice has quit IRC01:26
*** juice has joined #openstack-dev01:26
*** bmelande_ has joined #openstack-dev01:27
*** ericw has joined #openstack-dev01:28
*** bmelande has quit IRC01:30
*** amotoki has quit IRC01:32
*** yolanda has quit IRC01:36
*** ericw has quit IRC01:41
*** kui has joined #openstack-dev01:44
*** xchu has joined #openstack-dev01:45
*** buzztroll has joined #openstack-dev01:45
*** kui has quit IRC01:46
*** ljjjustin has joined #openstack-dev01:49
*** ericw has joined #openstack-dev01:49
*** buzztroll has quit IRC01:50
*** buzztroll has joined #openstack-dev01:55
*** Guest25369 has joined #openstack-dev01:59
*** Guest25369 has quit IRC01:59
*** buzztroll has quit IRC02:00
*** faramir has quit IRC02:02
*** Mandell has joined #openstack-dev02:10
*** Shaan7 has quit IRC02:14
*** faramir has joined #openstack-dev02:15
*** xingchao has joined #openstack-dev02:16
*** ilyashakhat has quit IRC02:16
*** ilyashakhat has joined #openstack-dev02:18
*** adalbas has quit IRC02:19
*** danwent has joined #openstack-dev02:21
*** nermina has joined #openstack-dev02:27
*** sdake has joined #openstack-dev02:28
*** sdake has joined #openstack-dev02:28
*** angdraug has quit IRC02:28
*** rongze has joined #openstack-dev02:32
*** rongze has joined #openstack-dev02:32
*** dims has quit IRC02:34
*** neelashah has joined #openstack-dev02:36
*** pjd2 has quit IRC02:39
*** erfanian has joined #openstack-dev02:39
*** ericw has quit IRC02:41
*** buzztroll has joined #openstack-dev02:52
*** buzztroll has quit IRC02:54
*** buzztroll has joined #openstack-dev02:55
*** sandywalsh has quit IRC02:56
*** shakayumi has quit IRC02:59
*** buzztroll has quit IRC02:59
*** pjd2 has joined #openstack-dev03:02
*** paragan has joined #openstack-dev03:04
*** colinmcnamara has quit IRC03:04
*** colinmcnamara has joined #openstack-dev03:05
*** dkranz has joined #openstack-dev03:09
*** paragan has quit IRC03:09
*** colinmcnamara has quit IRC03:09
*** tomoe_ has joined #openstack-dev03:15
*** alexxu has joined #openstack-dev03:17
*** alexxu is now known as Guest4105003:18
*** faramir has quit IRC03:18
*** dkranz has quit IRC03:20
*** djinni has quit IRC03:24
*** jdurgin has quit IRC03:24
*** ftcjeff_ has joined #openstack-dev03:24
*** jdurgin has joined #openstack-dev03:24
*** xchu has quit IRC03:25
*** jeremyb has quit IRC03:25
*** ftcjeff__ has quit IRC03:25
*** xchu has joined #openstack-dev03:25
*** jeremyb has joined #openstack-dev03:26
*** djinni has joined #openstack-dev03:27
*** Guest41050 has quit IRC03:29
*** chandankumar has joined #openstack-dev03:32
*** ljjjustin has quit IRC03:33
*** neelashah has quit IRC03:36
*** senk has joined #openstack-dev03:38
*** bswartz has joined #openstack-dev03:39
*** sumanth has joined #openstack-dev03:45
*** Guest41050 has joined #openstack-dev03:47
*** networkstatic has joined #openstack-dev03:48
*** ericw has joined #openstack-dev03:49
*** comay has quit IRC03:49
*** networkstatic has quit IRC03:50
*** networkstatic has joined #openstack-dev03:50
*** comay has joined #openstack-dev03:51
*** xchu has quit IRC03:54
*** buzztroll has joined #openstack-dev03:55
*** yaguang has joined #openstack-dev03:58
*** yaguang has quit IRC03:58
*** steven-weston has quit IRC03:59
*** yaguang has joined #openstack-dev03:59
*** buzztroll has quit IRC03:59
*** buzztroll has joined #openstack-dev04:00
*** xchu has joined #openstack-dev04:06
*** radsy has quit IRC04:10
*** basha has joined #openstack-dev04:11
*** erfanian has quit IRC04:14
*** ArcTanSusan has joined #openstack-dev04:16
*** yaguang has quit IRC04:19
*** yaguang has joined #openstack-dev04:19
*** buzztroll has quit IRC04:22
*** shakayumi has joined #openstack-dev04:23
*** buzztroll has joined #openstack-dev04:23
*** jeremyb has quit IRC04:24
*** jeremyb has joined #openstack-dev04:24
*** senk has quit IRC04:24
*** shakayumi has quit IRC04:27
*** buzztroll has quit IRC04:28
*** basha has quit IRC04:28
*** shakayumi has joined #openstack-dev04:29
*** haomaiwang has quit IRC04:30
*** xchu has quit IRC04:37
*** shakayumi has quit IRC04:39
*** paragan has joined #openstack-dev04:40
*** oubiwann has quit IRC04:42
*** oubiwann has joined #openstack-dev04:43
*** enmand has quit IRC04:48
*** terriyu has quit IRC04:51
*** ArcTanSusan has quit IRC04:51
*** Guest41050 has quit IRC04:52
*** xchu has joined #openstack-dev04:54
*** senk has joined #openstack-dev04:56
*** aditirav has joined #openstack-dev04:56
*** kumaranvram has joined #openstack-dev04:57
*** senk has left #openstack-dev04:58
*** faramir has joined #openstack-dev04:58
*** erkules_ is now known as erkules05:06
*** alexxu has joined #openstack-dev05:12
*** yamahata has joined #openstack-dev05:12
*** alexxu is now known as Guest3859305:12
*** marun has joined #openstack-dev05:18
*** matsuhashi has quit IRC05:20
*** yaguang has quit IRC05:21
*** matsuhashi has joined #openstack-dev05:21
*** ericw has quit IRC05:21
*** mjbright_ has joined #openstack-dev05:23
*** jasdeepH has quit IRC05:23
*** aditirav has quit IRC05:25
*** tpodowd has quit IRC05:26
*** aditirav has joined #openstack-dev05:26
*** raies has quit IRC05:28
*** jasdeepH has joined #openstack-dev05:29
*** ArcTanSusan has joined #openstack-dev05:31
*** Guest38593 has quit IRC05:33
*** kushal has joined #openstack-dev05:35
*** stevemar has joined #openstack-dev05:36
mjbright_*anyone*: Can someone advise me on adding new unit tests for #1224453 around quota checking (Don't know how - see comments here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/017032.html) ? I'm new to OpenStack tests, mox.05:37
*** gongysh has joined #openstack-dev05:38
*** sdake has quit IRC05:41
*** networks_ has joined #openstack-dev05:42
*** networkstatic has quit IRC05:43
*** basha has joined #openstack-dev05:43
*** yeylon_ has joined #openstack-dev05:47
*** gongysh has quit IRC05:47
*** prekarat has joined #openstack-dev05:48
*** jasdeepH has quit IRC05:51
*** boris-42 has joined #openstack-dev05:52
*** yeylon_ has quit IRC05:53
*** soulxu1304_ has joined #openstack-dev05:54
*** stevemar has quit IRC05:56
*** nosnos has quit IRC06:00
*** nosnos_ has joined #openstack-dev06:00
*** matsuhas_ has joined #openstack-dev06:01
*** matsuhashi has quit IRC06:01
*** vartom8 has joined #openstack-dev06:01
*** anniec has joined #openstack-dev06:04
*** paragan has quit IRC06:06
*** rohitk has joined #openstack-dev06:07
*** networks_ is now known as networkstatic06:07
*** networkstatic is now known as networkstatic_aw06:08
*** networkstatic_aw is now known as networkstatic06:08
*** tomoe__ has joined #openstack-dev06:09
*** networkstatic is now known as networkstatic_aw06:09
*** networkstatic_aw is now known as networkstatic_Zz06:10
*** networkstatic_Zz is now known as networkstatic06:10
*** networkstatic is now known as networkstatic_aw06:10
*** networkstatic_aw is now known as networkstatic06:10
*** networkstatic is now known as networkstatic_Zz06:10
*** tomoe_ has quit IRC06:11
*** mirrorbox has joined #openstack-dev06:11
mirrorboxwhat's the reason of nova having its own implementation of context.py (on par with oslo)?06:12
*** pjd2 has quit IRC06:12
mirrorboxi mean, is there a reason for it or it's just historical leftover06:12
*** MaxV has joined #openstack-dev06:12
*** mrunge has joined #openstack-dev06:15
*** jcoufal has joined #openstack-dev06:16
*** mosulica has joined #openstack-dev06:17
*** odyssey4me has joined #openstack-dev06:19
*** paragan has joined #openstack-dev06:23
*** paragan has joined #openstack-dev06:23
*** odyssey4me has quit IRC06:23
*** sdake has joined #openstack-dev06:29
*** nati_ueno has quit IRC06:30
*** nati_ueno has joined #openstack-dev06:31
*** MaxV has quit IRC06:34
*** paragan_ has joined #openstack-dev06:34
*** MaxV has joined #openstack-dev06:35
*** davidhadas has joined #openstack-dev06:36
*** nati_ueno has quit IRC06:36
*** yamahata has quit IRC06:36
*** paragan has quit IRC06:36
*** neeti has joined #openstack-dev06:36
*** anniec_ has joined #openstack-dev06:37
*** MaxV has quit IRC06:39
*** anniec has quit IRC06:40
*** anniec_ is now known as anniec06:40
*** jprovazn has joined #openstack-dev06:40
*** rushiagr2 has joined #openstack-dev06:41
*** bvandenh has joined #openstack-dev06:42
*** rushiagr2 is now known as rushiagr06:42
*** rongze has quit IRC06:44
*** matsuhas_ has quit IRC06:44
*** matsuhashi has joined #openstack-dev06:45
*** soulxu1304_ has quit IRC06:47
*** nosnos has joined #openstack-dev06:47
*** gongysh has joined #openstack-dev06:48
*** sdake has quit IRC06:48
*** boris-42 has quit IRC06:48
*** nosnos_ has quit IRC06:48
*** matsuhashi has quit IRC06:49
*** eglynn has joined #openstack-dev06:52
*** soulxu1304_ has joined #openstack-dev06:52
*** gongysh__ has joined #openstack-dev06:52
*** gongysh has quit IRC06:53
*** matiu has quit IRC06:53
*** marios has quit IRC06:53
*** marios has joined #openstack-dev06:53
*** nshaikh has joined #openstack-dev06:55
ekarlsojamielennox: here dude? How's your effort going for the auth-plugins stuff ?06:57
*** xchu has quit IRC06:57
*** pabelanger has quit IRC06:57
*** zul has quit IRC06:58
jamielennoxekarlso: it's coming, it's a part of a larger change though so it's a big job06:58
ekarlsojamielennox: any eta ? ;)06:58
jamielennoxthere is still some discussion about it and it might not be until the summit we can decide on the final design06:58
ekarlsoi'm wantign to consume !06:58
jamielennox:(06:58
*** MaxV has joined #openstack-dev06:58
jamielennoxme too06:59
jamielennoxclient side doesn't get the same love as keystone06:59
ekarlsohow is your code compared to the apiclient stuff in oslo ?06:59
jamielennoxekarlso: fairly similar07:00
*** basha has quit IRC07:00
jamielennoxthe problem is it's based around a communication object07:00
ekarlsook ?07:00
jamielennoxand it's still a bit of a talked about topic07:00
ekarlsohmmms07:01
ekarlsoso the recommended way atm is just to do it the old way?07:01
*** matsuhashi has joined #openstack-dev07:02
jamielennoxyea,07:02
ekarlsokinda sad :p07:02
jamielennoxi don't want to add the auth_plugin stuff just ot have a new deprecated api to support in a month or so07:02
ekarlsofair enough..07:02
*** MaxV has quit IRC07:02
*** rushiagr2 has joined #openstack-dev07:03
*** MaxV has joined #openstack-dev07:03
jamielennoxsorry, pushing it as hard as i can07:04
*** rushiagr has quit IRC07:05
*** arezmerita has joined #openstack-dev07:05
*** lsmola has joined #openstack-dev07:05
*** reidrac has joined #openstack-dev07:05
ekarlsojamielennox: do you think it will look pretty similar to the stuff in oslo ?07:06
*** MaxV has quit IRC07:06
jamielennoxekarlso: i think so, possibly a little differently named07:06
jamielennoxekarlso: also see: http://www.jamielennox.net/blog/2013/09/27/apiclient-communications/07:06
*** afazekas_ has joined #openstack-dev07:07
*** MaxV has joined #openstack-dev07:08
*** garyk has joined #openstack-dev07:09
*** MaxV has joined #openstack-dev07:09
*** pabelanger has joined #openstack-dev07:09
*** zul has joined #openstack-dev07:11
*** basha has joined #openstack-dev07:11
*** BrianYuan has joined #openstack-dev07:12
*** flaper87|afk is now known as flaper8707:13
*** MaxV has quit IRC07:13
*** rpodolyaka has left #openstack-dev07:13
*** egallen has joined #openstack-dev07:14
*** xchu has joined #openstack-dev07:16
*** guohliu has joined #openstack-dev07:18
*** basha has quit IRC07:21
*** rushiagr2 has quit IRC07:21
*** ArcTanSusan has quit IRC07:23
*** eglynn has quit IRC07:23
*** SlickNik has quit IRC07:24
*** bugsduggan has quit IRC07:24
*** bugsduggan has joined #openstack-dev07:24
*** rushiagr2 has joined #openstack-dev07:24
*** SlickNik has joined #openstack-dev07:24
*** gmurphy has joined #openstack-dev07:26
*** basha has joined #openstack-dev07:26
*** aditirav has quit IRC07:27
*** aditirav has joined #openstack-dev07:28
*** xqueralt has joined #openstack-dev07:28
*** danwent has quit IRC07:28
*** Alssi has joined #openstack-dev07:30
*** rushiagr2 has quit IRC07:31
*** xga has joined #openstack-dev07:31
*** AnilV4 has joined #openstack-dev07:33
*** JordanP has joined #openstack-dev07:36
*** Alexei_987 has joined #openstack-dev07:37
*** MaxV has joined #openstack-dev07:38
*** gszasz has joined #openstack-dev07:41
*** rushiagr2 has joined #openstack-dev07:41
*** Alssi has quit IRC07:44
*** avishay has joined #openstack-dev07:45
*** Alssi has joined #openstack-dev07:45
*** soulxu1304_ has quit IRC07:48
*** rongze has joined #openstack-dev07:48
*** cdub_ has quit IRC07:49
*** corXi has joined #openstack-dev07:50
*** pixelb has joined #openstack-dev07:51
*** rongze has quit IRC07:52
*** cdub_ has joined #openstack-dev07:53
*** sivanov has joined #openstack-dev07:54
alogaayoung: ping ?07:54
*** vartom9 has joined #openstack-dev07:55
*** vartom8 has quit IRC07:55
*** jtomasek has joined #openstack-dev07:56
*** eglynn has joined #openstack-dev07:59
*** bashok has joined #openstack-dev08:01
*** soulxu1304_ has joined #openstack-dev08:01
*** xga_ has joined #openstack-dev08:02
*** cdub_ has quit IRC08:02
*** xga_ has quit IRC08:03
*** xga has quit IRC08:03
*** boden has joined #openstack-dev08:03
*** mmagr has joined #openstack-dev08:04
*** ygbo has joined #openstack-dev08:05
*** jistr has joined #openstack-dev08:05
*** xga has joined #openstack-dev08:05
*** avishay has quit IRC08:05
*** exed has joined #openstack-dev08:07
*** exed has quit IRC08:09
*** ifarkas has joined #openstack-dev08:09
*** zaneb has joined #openstack-dev08:09
*** exed has joined #openstack-dev08:10
*** derekh has joined #openstack-dev08:11
*** ericw has joined #openstack-dev08:13
*** athomas has joined #openstack-dev08:17
*** max_lobur has joined #openstack-dev08:17
*** rushiagr2 is now known as rushiagr08:17
*** Mandell has quit IRC08:17
*** yeylon_ has joined #openstack-dev08:18
*** Mandell has joined #openstack-dev08:18
*** jpich has joined #openstack-dev08:19
*** yassine has joined #openstack-dev08:20
*** rushiagr has quit IRC08:20
*** tomoe__ has quit IRC08:23
*** Mandell has quit IRC08:23
*** tomoe_ has joined #openstack-dev08:23
*** xavious has joined #openstack-dev08:23
*** basha has joined #openstack-dev08:26
*** sushils has joined #openstack-dev08:26
*** safchain has joined #openstack-dev08:27
*** matsuhashi has quit IRC08:27
*** xavioux has joined #openstack-dev08:28
*** matsuhashi has joined #openstack-dev08:28
*** cdub_ has joined #openstack-dev08:28
*** tomoe__ has joined #openstack-dev08:30
*** henrynash has joined #openstack-dev08:31
*** DeeJay1 has joined #openstack-dev08:31
*** YorikSar has joined #openstack-dev08:32
*** fbo_away is now known as fbo08:33
*** xga has quit IRC08:33
*** tomoe_ has quit IRC08:34
*** alexpilotti has joined #openstack-dev08:34
*** prekarat has quit IRC08:34
xaviouxA quick neutron question, help anybody?08:35
*** sahid has joined #openstack-dev08:36
*** CaptTofu has quit IRC08:37
*** Ryan_Lane has quit IRC08:38
*** xavious has quit IRC08:39
*** xavioux has quit IRC08:39
*** CaptTofu has joined #openstack-dev08:39
*** sahid has quit IRC08:43
*** tomoe__ has quit IRC08:44
*** yeylon_ has quit IRC08:44
*** sahid has joined #openstack-dev08:44
sgranI'm seeing glance failing in interesting ways in havana at the moment08:44
*** tomoe_ has joined #openstack-dev08:44
*** avishay has joined #openstack-dev08:44
sgranIn an api request, the internal registry client is raising a type error08:45
sgranI've tracked this down to the header dict being passed to encode_headers08:45
sgranheaders: {'X-Service-Catalog': 'null', 'X-Tenant-Id': None, 'X-User-Id': None, 'X-Identity-Status': 'Confirmed', 'X-Roles': ''}08:45
sgranbut I don't see immediately where that's coming from08:45
sgrancan anyone lend a hand?08:45
*** henrynash_ has joined #openstack-dev08:46
*** basha has quit IRC08:48
*** lucasagomes has joined #openstack-dev08:49
*** tomoe_ has quit IRC08:49
*** henrynash has quit IRC08:49
*** henrynash_ is now known as henrynash08:49
*** bmelande_ has quit IRC08:49
*** johnthetubaguy has joined #openstack-dev08:50
*** dot has joined #openstack-dev08:51
*** exed has quit IRC08:52
*** boris-42 has joined #openstack-dev08:53
dothello anyone here ?08:53
*** xavioux has joined #openstack-dev08:53
xaviouxHi dot08:54
*** xga has joined #openstack-dev08:54
*** prekarat has joined #openstack-dev08:55
*** e0ne has joined #openstack-dev08:57
*** yeylon_ has joined #openstack-dev08:58
*** che-arne has joined #openstack-dev08:59
*** HenryG_ has joined #openstack-dev08:59
*** basha has joined #openstack-dev08:59
*** cdub_ has quit IRC09:01
*** nosnos has quit IRC09:01
*** xga_ has joined #openstack-dev09:01
*** johnthetubaguy1 has joined #openstack-dev09:01
*** xavioux has quit IRC09:01
*** nosnos has joined #openstack-dev09:01
*** HenryG has quit IRC09:01
*** xga has quit IRC09:03
*** asalkeld has quit IRC09:04
*** asalkeld has joined #openstack-dev09:04
*** johnthetubaguy has quit IRC09:05
*** basha has quit IRC09:07
*** tomoe_ has joined #openstack-dev09:08
*** tomoe_ has quit IRC09:08
*** Ryan_Lane has joined #openstack-dev09:08
*** tomoe_ has joined #openstack-dev09:09
*** irimi has joined #openstack-dev09:09
*** mosulica_ has joined #openstack-dev09:11
*** basha has joined #openstack-dev09:12
*** mosulica has quit IRC09:13
*** tomoe_ has quit IRC09:13
*** rushiagr has joined #openstack-dev09:14
*** Ryan_Lane has quit IRC09:15
*** avishay has quit IRC09:17
sgranah, I think I see09:17
*** exed has joined #openstack-dev09:18
*** nermina has quit IRC09:18
*** wink has joined #openstack-dev09:19
*** pasquier-s has joined #openstack-dev09:19
*** prekarat has quit IRC09:20
*** rushiagr has quit IRC09:20
*** rushiagr2 has joined #openstack-dev09:20
*** markmc has joined #openstack-dev09:22
*** rushiagr3 has joined #openstack-dev09:23
*** tomoe_ has joined #openstack-dev09:23
*** rushiagr2 has quit IRC09:24
*** sridevi has joined #openstack-dev09:29
*** soulxu1304_ has quit IRC09:30
*** prekarat has joined #openstack-dev09:31
*** xga_ has quit IRC09:31
*** faramir has quit IRC09:31
*** xga_ has joined #openstack-dev09:32
sivanovHello,  I want to add a new attribute to my server with an extension, anyone can help?09:32
*** martyntaylor has joined #openstack-dev09:35
*** rushiagr3 has quit IRC09:37
*** tomoe_ has quit IRC09:40
*** tomoe_ has joined #openstack-dev09:40
*** avishay has joined #openstack-dev09:43
*** Ryan_Lane has joined #openstack-dev09:43
*** xchu has quit IRC09:44
*** gongysh__ has quit IRC09:44
*** tomoe_ has quit IRC09:45
*** e0ne_ has joined #openstack-dev09:45
*** e0ne has quit IRC09:48
*** Ryan_Lane has quit IRC09:51
*** gmurphy has quit IRC09:55
*** henrynash has quit IRC09:59
*** egallen has quit IRC10:00
*** mosulica has joined #openstack-dev10:01
*** rpodolyaka has joined #openstack-dev10:01
*** viktors has joined #openstack-dev10:01
*** mosulica_ has quit IRC10:02
*** d34dh0r53 has joined #openstack-dev10:05
*** basha has quit IRC10:09
*** d34dh0r53 has quit IRC10:09
*** gszasz has quit IRC10:11
*** cdub_ has joined #openstack-dev10:12
*** YorikSar has quit IRC10:13
*** YorikSar has joined #openstack-dev10:13
*** Ryan_Lane has joined #openstack-dev10:19
*** guohliu has quit IRC10:20
*** prekarat has quit IRC10:22
*** Ryan_Lane has quit IRC10:23
*** sergmelikyan has quit IRC10:24
*** romcheg has joined #openstack-dev10:26
*** cdub_ has quit IRC10:27
*** paragan_ has quit IRC10:30
*** matsuhashi has quit IRC10:32
sivanovHello, I want to create extension that adds a new attribute to an instance, can anyone help me?10:32
*** matsuhashi has joined #openstack-dev10:32
*** Anticimex has quit IRC10:33
*** flaper87 is now known as flaper87|afk10:33
*** Anticimex has joined #openstack-dev10:33
*** iartarisi has joined #openstack-dev10:37
*** matsuhashi has quit IRC10:37
*** exed has quit IRC10:40
*** CaptTofu has quit IRC10:44
*** schwicht has joined #openstack-dev10:44
*** HenryG_ has quit IRC10:45
*** HenryG has joined #openstack-dev10:46
*** Ryan_Lane has joined #openstack-dev10:49
*** fifieldt has quit IRC10:49
*** ccorrigan has joined #openstack-dev10:51
*** cdub_ has joined #openstack-dev10:51
*** Ryan_Lane has quit IRC10:54
*** cdub_ has quit IRC10:56
*** mmagr has quit IRC10:56
*** egallen has joined #openstack-dev10:58
*** exed has joined #openstack-dev11:00
*** mmagr has joined #openstack-dev11:00
*** cdub_ has joined #openstack-dev11:01
*** jruzicka has joined #openstack-dev11:03
*** cdub_ has quit IRC11:07
*** Ryan_Lane has joined #openstack-dev11:20
*** irimi has quit IRC11:21
*** rushiagr has joined #openstack-dev11:22
*** mjbright has quit IRC11:22
*** dims has joined #openstack-dev11:22
*** flaper87|afk is now known as flaper8711:24
*** Ryan_Lane has quit IRC11:24
*** mkollaro has joined #openstack-dev11:25
*** reidrac has quit IRC11:26
*** bmelande has joined #openstack-dev11:29
*** giulivo has joined #openstack-dev11:32
*** tiamar has quit IRC11:33
*** mpavlase has joined #openstack-dev11:33
*** FunnyLookinHat has joined #openstack-dev11:37
*** adalbas has joined #openstack-dev11:41
*** enmand has joined #openstack-dev11:41
*** tmclaugh[work] has joined #openstack-dev11:41
*** avishay has quit IRC11:42
*** kaushikc has joined #openstack-dev11:45
*** rushiagr has quit IRC11:46
*** gmurphy has joined #openstack-dev11:47
*** ruhe has joined #openstack-dev11:48
*** samuelqueiroz has quit IRC11:48
*** ifarkas has quit IRC11:49
*** gordc has joined #openstack-dev11:50
*** Ryan_Lane has joined #openstack-dev11:50
*** Ryan_Lane has quit IRC11:50
*** Ryan_Lane has joined #openstack-dev11:50
*** enmand has quit IRC11:51
*** dot has quit IRC11:51
*** davidhadas has quit IRC11:52
*** jcoufal has quit IRC11:53
*** jcoufal has joined #openstack-dev11:53
*** ifarkas has joined #openstack-dev11:54
*** Ryan_Lane has quit IRC11:55
*** jcoufal has quit IRC11:56
*** rongze has joined #openstack-dev11:56
*** jcoufal has joined #openstack-dev11:56
*** dkranz has joined #openstack-dev11:56
*** bcrochet|wknd is now known as bcrochet11:57
*** egallen has quit IRC11:59
*** rongze has quit IRC12:01
*** egallen has joined #openstack-dev12:03
*** kaushikc has quit IRC12:04
*** e0ne_ has quit IRC12:05
*** blamar has quit IRC12:05
*** READ10 has joined #openstack-dev12:05
*** e0ne has joined #openstack-dev12:06
*** enmand has joined #openstack-dev12:08
*** yeylon_ has quit IRC12:08
*** sridevi has quit IRC12:09
*** dims has quit IRC12:09
*** e0ne has quit IRC12:10
*** markvoelker has quit IRC12:12
*** exed has quit IRC12:12
*** exed has joined #openstack-dev12:13
*** vladikr has quit IRC12:14
*** amotoki has joined #openstack-dev12:14
*** ilyashakhat has quit IRC12:17
*** thomasm has joined #openstack-dev12:17
*** thomasm is now known as Guest2069012:17
*** sgordon has joined #openstack-dev12:19
*** sgordon has joined #openstack-dev12:19
*** enmand has quit IRC12:21
*** Ryan_Lane has joined #openstack-dev12:21
*** gszasz has joined #openstack-dev12:22
*** enmand has joined #openstack-dev12:22
*** ruhe has quit IRC12:22
*** dims has joined #openstack-dev12:22
*** radez_g0n3 is now known as radez12:23
*** bashok has quit IRC12:23
*** radez is now known as radez_g0n312:23
*** pjd2 has joined #openstack-dev12:25
*** jistr has quit IRC12:25
*** Ryan_Lane has quit IRC12:26
*** markvoelker has joined #openstack-dev12:26
*** jistr has joined #openstack-dev12:28
*** mpavlase has quit IRC12:28
*** ruhe has joined #openstack-dev12:29
*** radez_g0n3 is now known as radez12:29
*** ruhe has quit IRC12:29
*** dolphm has joined #openstack-dev12:29
*** bswartz has quit IRC12:29
*** bpokorny has quit IRC12:29
*** dstanek has joined #openstack-dev12:29
*** enmand has quit IRC12:29
*** davidhadas has joined #openstack-dev12:31
*** anteaya has joined #openstack-dev12:32
*** e0ne has joined #openstack-dev12:32
*** kumaranvram has quit IRC12:32
*** egallen has quit IRC12:34
*** johnthetubaguy1 has quit IRC12:34
*** johnthetubaguy has joined #openstack-dev12:35
*** egallen has joined #openstack-dev12:36
*** johnthetubaguy1 has joined #openstack-dev12:37
*** johnthetubaguy1 has quit IRC12:37
*** yeylon_ has joined #openstack-dev12:37
*** johnthetubaguy has quit IRC12:37
*** Ryan_Lane has joined #openstack-dev12:38
*** alunch has quit IRC12:41
*** Ryan_Lane has quit IRC12:43
*** tomoe_ has joined #openstack-dev12:43
*** exed has quit IRC12:44
*** dot has joined #openstack-dev12:44
*** davidhadas has quit IRC12:44
*** davidhadas has joined #openstack-dev12:45
*** aditirav has quit IRC12:46
*** stevemar has joined #openstack-dev12:47
*** lucasagomes is now known as lucas-afk12:47
*** ruhe has joined #openstack-dev12:48
*** dprince has joined #openstack-dev12:51
*** bpokorny has joined #openstack-dev12:53
*** bpokorny1 has joined #openstack-dev12:53
*** exed has joined #openstack-dev12:54
*** dkranz has quit IRC12:54
*** johnthetubaguy has joined #openstack-dev12:55
*** davidhadas has quit IRC12:57
*** davidhadas has joined #openstack-dev12:57
*** bpokorny has quit IRC12:57
*** bvandenh has quit IRC12:58
*** cooldharma06 has joined #openstack-dev12:58
*** cooldharma06 has left #openstack-dev12:58
*** BrianYuan has quit IRC12:59
*** dsirrine has joined #openstack-dev13:00
*** amotoki has quit IRC13:00
*** mpavlase has joined #openstack-dev13:00
*** rkukura has joined #openstack-dev13:01
*** BrianYuan has joined #openstack-dev13:02
*** ilyashakhat has joined #openstack-dev13:02
*** READ10 has quit IRC13:03
*** dolphm has quit IRC13:04
*** bswartz has joined #openstack-dev13:05
*** rushiagr has joined #openstack-dev13:05
*** vladikr has joined #openstack-dev13:06
*** pschaef has joined #openstack-dev13:06
*** joesavak has joined #openstack-dev13:06
*** dolphm has joined #openstack-dev13:07
*** romcheg has quit IRC13:07
*** dolphm has joined #openstack-dev13:08
*** pablosan has joined #openstack-dev13:09
*** nosnos has quit IRC13:09
*** nosnos has joined #openstack-dev13:10
*** kbringard has joined #openstack-dev13:10
*** READ10 has joined #openstack-dev13:10
*** rushiagr has quit IRC13:10
*** rushiagr has joined #openstack-dev13:10
*** rushiagr has quit IRC13:10
*** larsbutler has joined #openstack-dev13:11
*** sergmelikyan has joined #openstack-dev13:12
*** jayg|g0n3 is now known as jayg13:12
*** steven-weston has joined #openstack-dev13:13
*** athomas has quit IRC13:13
*** nosnos has quit IRC13:14
*** vartom9 has quit IRC13:15
*** rohitk has quit IRC13:15
*** rushiagr has joined #openstack-dev13:15
*** BrianYuan has quit IRC13:15
*** sergmelikyan has quit IRC13:15
*** rushiagr has quit IRC13:15
*** buzztroll has joined #openstack-dev13:16
*** BrianYuan has joined #openstack-dev13:16
*** Mandell has joined #openstack-dev13:17
*** steven-weston has quit IRC13:17
*** steven-weston has joined #openstack-dev13:18
*** morazi has joined #openstack-dev13:18
*** bknudson1 has quit IRC13:18
*** sergmelikyan has joined #openstack-dev13:18
*** exed has quit IRC13:18
*** rushiagr has joined #openstack-dev13:19
*** pablosan has quit IRC13:19
*** athomas has joined #openstack-dev13:20
*** sergmelikyan has quit IRC13:21
*** Mandell has quit IRC13:21
*** blamar has joined #openstack-dev13:22
*** rushiagr has quit IRC13:23
*** sgordon has quit IRC13:24
*** reidrac has joined #openstack-dev13:24
*** sgordon has joined #openstack-dev13:25
*** CaptTofu has joined #openstack-dev13:26
*** romcheg has joined #openstack-dev13:26
*** dvarga has joined #openstack-dev13:26
*** READ10 has quit IRC13:27
CaptTofuHi all!13:28
CaptTofuanyone here use LVM for volumes with Nova?13:28
*** terriyu has joined #openstack-dev13:29
*** exed has joined #openstack-dev13:30
*** rushiagr2 has joined #openstack-dev13:30
*** davidhadas_ has joined #openstack-dev13:34
*** davidhadas has quit IRC13:34
*** stevemar has quit IRC13:34
*** rushiagr2 has quit IRC13:35
*** neeti has quit IRC13:36
*** dolphm_ has joined #openstack-dev13:37
*** alunch has joined #openstack-dev13:37
*** bvandenh has joined #openstack-dev13:38
*** dolphm_ has joined #openstack-dev13:38
*** rushiagr2 has joined #openstack-dev13:39
*** bknudson has joined #openstack-dev13:40
*** dolphm has quit IRC13:40
*** burt has joined #openstack-dev13:41
*** neelashah has joined #openstack-dev13:41
*** lbragstad has joined #openstack-dev13:42
*** rushiagr2 is now known as rushiagr13:42
*** haomaiwang has joined #openstack-dev13:42
*** davidhadas_ has quit IRC13:42
*** dperaza has joined #openstack-dev13:45
*** stevemar has joined #openstack-dev13:45
*** alunduil_ has quit IRC13:45
*** che-arne has quit IRC13:46
*** sergmelikyan has joined #openstack-dev13:47
*** ruhe has quit IRC13:48
*** BrianYuan has quit IRC13:48
*** macjack has joined #openstack-dev13:48
*** dperaza has left #openstack-dev13:48
*** prekarat has joined #openstack-dev13:48
*** FunnyLookinHat has quit IRC13:50
*** rushiagr2 has joined #openstack-dev13:51
*** paragan has joined #openstack-dev13:51
*** rushiagr has quit IRC13:51
*** lucas-afk is now known as lucasagomes13:52
*** dkranz has joined #openstack-dev13:54
*** kumaranvram has joined #openstack-dev13:55
*** prad_ has joined #openstack-dev13:55
*** rushiagr3 has joined #openstack-dev13:55
*** rushiagr2 has quit IRC13:56
*** DennyZhang has joined #openstack-dev13:56
*** litong has joined #openstack-dev13:56
*** alexpilotti_ has joined #openstack-dev13:57
*** kumaranv_ has joined #openstack-dev13:57
*** rongze has joined #openstack-dev13:57
*** yeylon__ has joined #openstack-dev13:57
*** kevinconway has quit IRC13:57
*** tellesnobrega has joined #openstack-dev13:58
*** tellesnobrega has left #openstack-dev13:58
*** kumaranv_ has quit IRC13:59
*** che-arne has joined #openstack-dev13:59
*** alexpilotti has quit IRC14:00
*** alexpilotti_ is now known as alexpilotti14:00
*** yeylon_ has quit IRC14:00
*** jimfehlig has joined #openstack-dev14:01
*** shakayumi has joined #openstack-dev14:01
*** stevemar has quit IRC14:02
*** rongze has quit IRC14:03
*** luhrs1 has joined #openstack-dev14:03
*** egallen has quit IRC14:03
*** luhrs1 has quit IRC14:03
*** ruhe has joined #openstack-dev14:04
*** jruzicka has quit IRC14:04
*** egallen has joined #openstack-dev14:05
*** exed has quit IRC14:05
*** exed has joined #openstack-dev14:06
*** davidhadas has joined #openstack-dev14:06
*** datsun180b has joined #openstack-dev14:07
*** kevinconway has joined #openstack-dev14:07
*** m0nk_ has joined #openstack-dev14:08
*** ianw has quit IRC14:08
*** thedodd has joined #openstack-dev14:08
*** jamielennox has quit IRC14:08
*** nermina has joined #openstack-dev14:09
*** kumaranvram has left #openstack-dev14:09
*** jamielennox has joined #openstack-dev14:09
*** rwsu-away is now known as rwsu14:09
*** jaypipes has joined #openstack-dev14:09
*** m0nk_ has quit IRC14:10
*** networkstatic_Zz has quit IRC14:10
*** m0nk_ has joined #openstack-dev14:10
*** jruzicka has joined #openstack-dev14:10
*** networkstatic has joined #openstack-dev14:11
*** ianw has joined #openstack-dev14:11
*** m0nk_ has quit IRC14:11
*** kumaranvram has joined #openstack-dev14:11
*** dstufft has quit IRC14:11
*** rushiagr3 has quit IRC14:11
*** dstufft has joined #openstack-dev14:12
*** eharney has joined #openstack-dev14:12
*** pjd2 has quit IRC14:13
*** jamielennox is now known as jamielennox|away14:13
*** yeylon__ has quit IRC14:13
*** dkranz has quit IRC14:14
*** haomaiwang has quit IRC14:14
*** haomaiwang has joined #openstack-dev14:14
*** changbl has quit IRC14:17
*** sumanthns has joined #openstack-dev14:19
*** carl_baldwin has joined #openstack-dev14:21
*** aditirav has joined #openstack-dev14:22
*** dolphm_ has quit IRC14:25
*** xqueralt has quit IRC14:25
*** armax has joined #openstack-dev14:25
*** jruzicka has quit IRC14:25
*** jruzicka has joined #openstack-dev14:26
*** FunnyLookinHat has joined #openstack-dev14:26
*** dolphm has joined #openstack-dev14:26
*** galstrom_zzz is now known as galstrom14:26
*** haomaiwa_ has joined #openstack-dev14:26
*** rushiagr3 has joined #openstack-dev14:27
*** aditirav has quit IRC14:27
*** aditirav has joined #openstack-dev14:27
*** haomaiwa_ has quit IRC14:27
*** dolphm has quit IRC14:28
*** xqueralt has joined #openstack-dev14:28
*** haomaiwa_ has joined #openstack-dev14:29
*** stevemar has joined #openstack-dev14:30
*** rongze has joined #openstack-dev14:30
*** sumansn_ has joined #openstack-dev14:30
*** haomaiwang has quit IRC14:30
*** kpavel has joined #openstack-dev14:31
*** yeylon__ has joined #openstack-dev14:31
*** sumanthns has quit IRC14:32
*** JordanP has quit IRC14:33
*** mmagr has quit IRC14:33
larsksCaptTofu: Sure.14:33
CaptTofuhi!14:33
*** jcoufal has quit IRC14:33
CaptTofularsks: do you do resizes at all?14:34
larsksYou mean the underlying volume group?  Or indidivudal volumes?14:34
*** dolphm has joined #openstack-dev14:35
*** avishay has joined #openstack-dev14:37
*** rnirmal has joined #openstack-dev14:37
*** cdub_ has joined #openstack-dev14:39
*** pjd2 has joined #openstack-dev14:39
*** dubsquared has joined #openstack-dev14:39
*** rcleere has joined #openstack-dev14:40
*** pjd2 has quit IRC14:41
*** alunduil has joined #openstack-dev14:41
*** rushiagr4 has joined #openstack-dev14:41
*** fungi has quit IRC14:41
*** rushiagr3 has quit IRC14:41
*** noslzzp has joined #openstack-dev14:42
*** jdurgin1 has joined #openstack-dev14:42
*** xingchao has quit IRC14:42
*** mpavlase has quit IRC14:43
*** pjd2 has joined #openstack-dev14:43
*** jprovazn has quit IRC14:43
*** rongze has quit IRC14:43
*** rushiagr has joined #openstack-dev14:44
*** spzala has joined #openstack-dev14:45
*** rushiagr4 has quit IRC14:45
*** aditirav_ has joined #openstack-dev14:46
*** sumansn__ has joined #openstack-dev14:46
*** rpodolyaka has quit IRC14:46
*** rushiagr has quit IRC14:47
*** kumaranvram has quit IRC14:47
*** guohliu has joined #openstack-dev14:47
*** JordanP has joined #openstack-dev14:47
*** sumansn_ has quit IRC14:49
*** aditirav has quit IRC14:49
*** aditirav_ is now known as aditirav14:49
*** mmagr has joined #openstack-dev14:50
*** shakayumi has quit IRC14:50
*** thedodd has quit IRC14:51
*** mjbright has joined #openstack-dev14:51
*** thedodd has joined #openstack-dev14:51
*** ygbo has quit IRC14:52
*** colinmcnamara has joined #openstack-dev14:52
*** ygbo has joined #openstack-dev14:52
*** shakayumi has joined #openstack-dev14:53
*** amotoki has joined #openstack-dev14:54
*** vkmc has joined #openstack-dev14:55
*** vkmc has quit IRC14:55
*** vkmc has joined #openstack-dev14:55
*** morazi has quit IRC14:55
*** kumaranvram has joined #openstack-dev14:55
*** matiu has joined #openstack-dev14:56
*** rongze has joined #openstack-dev14:57
*** morazi has joined #openstack-dev14:57
*** kenperkins has joined #openstack-dev14:59
*** xqueralt has quit IRC14:59
*** garyk has quit IRC14:59
*** tonix has joined #openstack-dev15:00
*** pjd2 has quit IRC15:01
*** fungi has joined #openstack-dev15:02
*** mmagr has quit IRC15:03
*** jruzicka has quit IRC15:04
stevemardolphm, get joesavak out of whatever meeting he is in, so he can have a meeting with me, please?15:04
*** imsurit has joined #openstack-dev15:04
viktorsmarkwash: hi15:04
*** pberis has joined #openstack-dev15:05
*** romcheg has quit IRC15:05
*** kumaranvram has quit IRC15:05
*** reidrac has quit IRC15:05
*** kbringard has quit IRC15:06
*** mrodden has quit IRC15:06
*** kbringard1 has joined #openstack-dev15:06
*** kbringard1 has quit IRC15:06
*** kbringard has joined #openstack-dev15:07
*** aditirav has quit IRC15:07
*** muehsi has joined #openstack-dev15:07
*** imsurit has quit IRC15:08
*** Chicago has joined #openstack-dev15:08
*** imsurit has joined #openstack-dev15:09
*** sumanth has quit IRC15:09
*** DeeJay1 has quit IRC15:10
*** martyntaylor has quit IRC15:11
*** networkstatic has quit IRC15:12
*** martyntaylor has joined #openstack-dev15:13
*** marun has quit IRC15:14
*** mosulica has quit IRC15:15
*** sahid has quit IRC15:15
*** marun has joined #openstack-dev15:15
*** jprovazn has joined #openstack-dev15:15
*** jruzicka has joined #openstack-dev15:16
*** xqueralt has joined #openstack-dev15:16
*** exed has quit IRC15:16
*** mmagr has joined #openstack-dev15:17
*** exed has joined #openstack-dev15:17
*** chandankumar has quit IRC15:17
*** marun has quit IRC15:19
*** mrodden has joined #openstack-dev15:19
*** guohliu has quit IRC15:19
*** kumaranvram has joined #openstack-dev15:20
*** luisg has joined #openstack-dev15:21
*** radez is now known as radez_g0n315:21
*** ygbo has quit IRC15:21
*** pberis has quit IRC15:22
*** senk has joined #openstack-dev15:22
*** thedodd has quit IRC15:23
*** thedodd has joined #openstack-dev15:24
*** changbl has joined #openstack-dev15:24
*** sdake has joined #openstack-dev15:25
*** mlavalle has joined #openstack-dev15:25
*** sdake has quit IRC15:25
*** sdake has joined #openstack-dev15:25
*** YorikSar has quit IRC15:26
*** YorikSar has joined #openstack-dev15:27
*** romcheg has joined #openstack-dev15:27
*** dkranz has joined #openstack-dev15:28
*** marun has joined #openstack-dev15:28
*** sahid has joined #openstack-dev15:29
*** jprovazn has quit IRC15:29
joesavakstevemar - lol. I'm prepping for our noon meeting.15:29
*** tanisdl has joined #openstack-dev15:30
*** yaguang has joined #openstack-dev15:30
*** pberis has joined #openstack-dev15:30
*** aeperezt has joined #openstack-dev15:32
*** dscannell has joined #openstack-dev15:32
*** ruhe has quit IRC15:32
*** ruhe has joined #openstack-dev15:33
*** sahid has quit IRC15:34
*** xga_ has quit IRC15:35
*** dkranz has quit IRC15:36
*** xga has joined #openstack-dev15:36
*** xga_ has joined #openstack-dev15:36
*** aditirav has joined #openstack-dev15:36
*** sthaha has quit IRC15:37
*** exed has quit IRC15:39
stevemarjoesavak yo15:39
*** READ10 has joined #openstack-dev15:40
*** hartsocks has joined #openstack-dev15:44
*** jvrbanac has joined #openstack-dev15:45
*** hartsocks has quit IRC15:45
*** hartsocks has joined #openstack-dev15:46
CaptTofularsks: sorry, got pulled away. Individual volumes, as ephemeral disks15:47
*** chuck_ has joined #openstack-dev15:48
*** aditirav has quit IRC15:48
*** rushiagr has joined #openstack-dev15:49
*** senk has left #openstack-dev15:49
*** changbl has quit IRC15:49
*** garyk has joined #openstack-dev15:50
larsksCaptTofu: I haven't tried that with my openstack instances, but I have with virtual instances started by hand.  I usually reboot them to make the new size visible to the guest.15:50
*** garyk has quit IRC15:52
*** schwicht has quit IRC15:52
*** steven-weston has quit IRC15:52
*** nshaikh has left #openstack-dev15:53
*** ruhe has quit IRC15:53
*** rushiagr2 has joined #openstack-dev15:55
*** bvandenh has quit IRC15:55
*** Mandell has joined #openstack-dev15:55
*** rushiagr has quit IRC15:55
*** ruhe has joined #openstack-dev15:55
*** rushiagr2 has quit IRC15:56
CaptTofularsks: you mean just with kvm itself? Are you transferring to running a given instance on another host at a different size?15:56
*** abdul has joined #openstack-dev15:57
*** markmc has quit IRC15:58
*** zhiyan1 has joined #openstack-dev15:58
*** garyk has joined #openstack-dev15:58
*** henrynash has joined #openstack-dev15:58
*** steven-weston has joined #openstack-dev15:59
*** devoid has joined #openstack-dev15:59
*** mmagr has quit IRC16:00
*** egallen has quit IRC16:00
zhiyan1hi, who knows where should I go for ask a requirement bump question?16:00
*** dubsquar_ has joined #openstack-dev16:00
*** jmontemayor has joined #openstack-dev16:00
*** rushiagr2 has joined #openstack-dev16:00
*** Ruetobas has quit IRC16:01
*** utlemming has joined #openstack-dev16:02
*** iartarisi has quit IRC16:03
*** Ruetobas has joined #openstack-dev16:03
*** dubsquared has quit IRC16:03
*** ruhe has quit IRC16:04
*** gyee has joined #openstack-dev16:04
*** henrynash has quit IRC16:05
*** pjd2 has joined #openstack-dev16:05
*** xarses has quit IRC16:05
*** boris-42 has quit IRC16:06
*** YorikSar has quit IRC16:06
*** morazi has quit IRC16:07
*** ngoracke has joined #openstack-dev16:08
*** Ruetobas has quit IRC16:08
*** rushiagr3 has joined #openstack-dev16:08
*** corXi has quit IRC16:08
*** egallen has joined #openstack-dev16:08
larsksCaptTofu: Yes, I mean instances started manually using, e.g., virt-install.  I haven't tried resizing the underlying volumes in openstack. What sort of problems are you having?16:08
*** Ruetobas has joined #openstack-dev16:08
*** pmathews has joined #openstack-dev16:08
*** rushiagr3 has quit IRC16:08
*** YorikSar has joined #openstack-dev16:08
*** ngoracke has left #openstack-dev16:08
*** ArcTanSusan has joined #openstack-dev16:08
*** mrunge has quit IRC16:08
*** ngoracke has joined #openstack-dev16:09
*** rushiagr2 has quit IRC16:09
*** devoid has left #openstack-dev16:09
*** qiren has quit IRC16:09
*** ArcTanSusan has quit IRC16:11
*** exed has joined #openstack-dev16:11
*** xga_ has quit IRC16:11
*** xga has quit IRC16:11
*** haomaiwa_ has quit IRC16:12
*** rushiagr3 has joined #openstack-dev16:12
*** haomaiwang has joined #openstack-dev16:12
*** bvandenh has joined #openstack-dev16:12
CaptTofularsks: https://bugs.launchpad.net/nova/+bug/115047916:12
uvirtbotLaunchpad bug 1150479 in nova "Data from LVM backed VMs not copied on resize" [Wishlist,Confirmed]16:12
CaptTofugah, didn't mean to have the bot bring it up16:13
*** egallen has quit IRC16:13
*** jtomasek has quit IRC16:13
*** rushiagr3 has quit IRC16:13
*** ygbo has joined #openstack-dev16:14
*** rnirmal_ has joined #openstack-dev16:15
*** tellesnobrega has joined #openstack-dev16:15
*** paragan has quit IRC16:16
*** haomaiwang has quit IRC16:16
*** egallen has joined #openstack-dev16:17
*** fbo is now known as fbo_away16:18
*** DennyZhang has quit IRC16:18
*** pjd2 has quit IRC16:18
*** Guest20690 is now known as thomasem16:18
*** herndon_ has joined #openstack-dev16:19
*** bearhands is now known as comstud16:19
*** jistr has quit IRC16:20
*** Shaan7 has joined #openstack-dev16:20
*** rnirmal_ has quit IRC16:20
*** rnirmal has quit IRC16:20
*** dot has quit IRC16:20
*** raildo has joined #openstack-dev16:20
*** rnirmal has joined #openstack-dev16:20
*** nermina has quit IRC16:21
*** morazi has joined #openstack-dev16:21
*** xga has joined #openstack-dev16:22
*** xga_ has joined #openstack-dev16:22
*** markwash has quit IRC16:23
*** moted has quit IRC16:24
*** rushiagr3 has joined #openstack-dev16:24
*** rushiagr3 has quit IRC16:25
*** markwash has joined #openstack-dev16:25
*** alunch has quit IRC16:26
*** alop has joined #openstack-dev16:26
*** utlemming has quit IRC16:26
*** kushal has quit IRC16:26
*** mkerrin has quit IRC16:27
*** moted has joined #openstack-dev16:29
*** zaitcev has joined #openstack-dev16:29
*** cdub_ has quit IRC16:30
*** MaxV has quit IRC16:31
*** derekh has quit IRC16:31
*** MaxV has joined #openstack-dev16:31
*** alunch has joined #openstack-dev16:31
*** dubsquar_ has quit IRC16:31
*** dubsquared has joined #openstack-dev16:31
*** davidhadas has quit IRC16:32
*** martyntaylor has quit IRC16:33
*** singhs has joined #openstack-dev16:33
*** prekarat has quit IRC16:33
*** dkranz has joined #openstack-dev16:34
*** viktors has left #openstack-dev16:34
*** kbrierly has joined #openstack-dev16:35
*** READ10 has quit IRC16:35
*** macjack has quit IRC16:36
*** MaxV has quit IRC16:36
*** macjack has joined #openstack-dev16:37
*** markwash has quit IRC16:37
*** cdub_ has joined #openstack-dev16:38
*** eharney has quit IRC16:38
*** jpich has quit IRC16:38
*** yassine has quit IRC16:38
*** imsurit has quit IRC16:38
*** eharney has joined #openstack-dev16:39
*** topol has joined #openstack-dev16:39
*** CaptTofu_ has joined #openstack-dev16:40
*** xarses has joined #openstack-dev16:40
*** safchain has quit IRC16:41
ayoungdolphm, jaypipes what are we going to do about regions?  https://review.openstack.org/#/c/27563/1/openstack-identity-api/src/markdown/identity-api-v3.md16:41
*** ruhe has joined #openstack-dev16:41
dolphmayoung: i was pretty happy with it the last time i looked at it; it would need to either be revised as "new in v3.2" now or we talked about making it an extension16:43
*** CaptTofu has quit IRC16:43
*** chuck_ is now known as zul_16:44
ayoungdolphm, does adding a hierarchical container as an extension make sense?  I know we are looking for "everything as an extension first"16:44
*** Alexei_987 has quit IRC16:45
dolphmayoung: what does the hierarchical aspect of it have to do with being an extension?16:45
ayoungdolphm, that region is a way of organizaing endpoints.  I kindof think of the current approach as the degenerate case of "no organization"16:45
ayoungsop...does it make sesne to split the organization mechanism from what it is organizing?16:46
*** nermina has joined #openstack-dev16:46
ayoungit seems like we want to have a reasonable default "for this user requesting a token, here is what we show them"16:46
ayoungthat is primarily from the Token api, although it calls into the catalog API16:47
*** ygbo has quit IRC16:47
*** rnirmal_ has joined #openstack-dev16:47
ayoungso, if we add regions as an extension, we want to make it something that the token api can optionally use, right?16:47
*** changbl has joined #openstack-dev16:47
*** Ryan_Lane has joined #openstack-dev16:47
*** pberis has quit IRC16:47
dolphmayoung: how does this affect the token api?16:48
ayoungdolphm, whereas, if it is core, the token/auth api will use it by default.16:48
ayoungdolphm, in selecting what catalog to show when a user requests a token16:48
*** shredder12 has joined #openstack-dev16:48
ayoungdolphm, most use cases come from there, not direct access of the catalog api directly16:48
shredder12 hi everyone. I am wondering if its possible to create and download a keypair using python-novaclient.16:48
shredder12The only method I've come across is by creating one using public_key import.16:48
dolphmayoung: i think you're missing the overall use case-- it's basically a catalog of auth endpoints (multiple keystones)16:49
*** pberis has joined #openstack-dev16:49
ayoungdolphm, and we don't want to drive back towards the usage pattern of multiple calls to keystone for every operation16:49
dolphmayoung: one keystone deployment would only be serving one region / one sub region16:49
ayoungdolphm, I get the overall use case.  But I don't think your last statement is correct16:50
ayoungI think keystone will end up being aware of multiple regions16:50
dolphmayoung: but that's not a part of this spec16:50
*** rnirmal has quit IRC16:50
*** rnirmal_ is now known as rnirmal16:50
ayoungAnd endpoints for multiple regions will come out of one keystone16:50
dolphmright16:50
ayoungdolphm, and it was -2ed becauyse the solution was not broad enough.  I am trying to grasp if that -2 was justified,16:51
ayoungI suspect that it should have been a -1, and we could work within  the structure given16:51
dolphmayoung: it would be broader if a region didn't have an explicit "auth_uri"16:51
*** changbl has quit IRC16:51
ayoungdolphm, what if we remove that?  What would break>16:52
ayoung?16:52
jaypipesayoung: reading back...16:52
dolphmayoung: it just means you'd have to attach identity endpoints to regions the way we do today16:52
dolphmjaypipes: \o/16:53
ayoungdolphm, so...maybe a user should have a default region, and we give them endpoints for that region, but they can specify a different region when requesting a token.16:53
*** yeylon__ has quit IRC16:53
*** JordanP has quit IRC16:54
ayoungkindof the same logic as we have with projects.  And we could, in theory, associate the region with the project, or the domain.16:54
*** angdraug has joined #openstack-dev16:54
*** mrunge has joined #openstack-dev16:55
*** ruhe has quit IRC16:55
ayoungand all of that kind of points to regions being a core concept.  Or, at least, if the region extension is activated, it is used across multiple backend services16:55
jaypipesdolphm, ayoung: right, so auth_uri is actually already an optional attribute in the model...16:56
jaypipesdolphm, ayoung: at least, it's listed under "Optional attributes"16:57
*** qiren has joined #openstack-dev16:57
ayoungI think I like that last approach:  Make it an extension.  If it is enabled, the other backends detect that and use it as an implicit filter on calls referring to the catalog API16:57
jaypipesayoung: I don't understand that last point...16:57
dolphmneither do i16:57
dolphmi don't understand why other backends should care16:58
jaypipesayoung: a keystone server can serve >1 region...16:58
ayoungjaypipes dolphm regions are an organizational mechanism.  If there is no region support, and I say "give me all endpoint for service "nova"" I get all of them.  But if there is region support, I get back only that subset associated with a region.  WHat region?  well, it dpends on the contextf from whicdh it is called16:58
ayoungjaypipes, yes, but at some point we need to determine which region is appropriate16:59
jaypipesayoung: I'd prefer explicit filtering, not implicit, so, for example, if a particular keystone server only served the catalog of one region, then the endpoints URIs in that Keystone server's service catalog should have /regions/<MYREGION/ in them....16:59
*** 17WAAEJ0O has joined #openstack-dev16:59
*** twoputt has joined #openstack-dev16:59
*** FunnyLookinHat has quit IRC16:59
ayoungjaypipes, the issue is what service catalog to associate with  return with a token.  Direct calls will be rare16:59
*** riskable has joined #openstack-dev17:00
*** abdul has left #openstack-dev17:00
*** booga has joined #openstack-dev17:00
jaypipesayoung: not really. let me explan..17:00
ayoungjaypipes, a token is scoped as narrowly as possible, and I suspect that in practice, the region used is scoped at the same time17:00
*** zul_ has quit IRC17:00
ayoungjaypipes, please do17:00
jaypipesayoung: assume three regions, in a hierarchy, with region A containing regions X and Y.17:01
*** kumaranvram has quit IRC17:01
ayoungUS:  east and west?17:01
jaypipesayoung: now assume that a user is trying to use the compute service in region X17:01
joesavakstevemar - joining now17:01
jaypipesayoung: sure, US, and east and west...17:01
*** devvesa has joined #openstack-dev17:01
stevemarjoesavak - i sent you an email!17:01
ayoungso a user wants to get access to a resource, and explicitly in the US east17:01
ayoungalthough they have access to both east and west17:02
stevemarjoesavak - i messed up the TZ conversion :(, is 1:30 pm CST still okay?17:02
jaypipesayoung: now, if a user is trying to use the compute service in the US-East region, then the user will "hit" a compute endpoint URI in that region... let's say "https://compute.east.us.example.com"17:02
joesavakyup! Thanks17:02
*** max_lobur has quit IRC17:03
ayoungjaypipes, so, would a single project tend to have VMs in both east and west?17:03
jaypipesayoung: the authentication mechanism of that compute endpoint could be connected to **either** a global keystone server or maybe a keystone server that only serves the US-East region.17:03
jaypipesayoung: yes, definitely.17:03
stevemarjoesavak - sorry about that :\ i was in a rush in the morning and went an hour ahead instead of behind ..17:03
* stevemar is silly17:03
jaypipesayoung: back to the example here...17:03
joesavak: )17:03
ayoungjaypipes, hold on17:03
*** FunnyLookinHat has joined #openstack-dev17:03
jaypipesayoung: ok.17:03
*** changbl has joined #openstack-dev17:04
ayoungjaypipes, let me understand where we are so far, there is a lot you have assumed here17:04
ayoungand I need to make it explicit to understand it17:04
*** sarob has joined #openstack-dev17:04
*** zul_ has joined #openstack-dev17:04
*** colinmcnamara has quit IRC17:04
*** aeperezt has quit IRC17:04
jaypipesayoung: not a prob17:04
ayoungthe service has multiple regions.  Now, we are talking about a user that can access resources in both of them, but It is my understanding that regions as a concept are also going to be used for a wide array of issues17:05
*** aeperezt has joined #openstack-dev17:05
ayoungsay a company has a "secret" region for high payibng clients17:05
jaypipesayoung: let's focus on the example at hand, eh? :)17:05
ayoungor say that there are different classes of service for a single company.  From the talk at the last summit, it sounds like this is one of the dominant ways people want to use regions17:06
jaypipesa region is simply a set of resources that a user may use17:06
*** networkstatic has joined #openstack-dev17:06
ayoung"simply"  is one of those "uh oh " words17:06
ayoung:)17:06
jaypipesayoung: sure, but there's nothing in the proposed API extension that indicates any of that.17:06
jaypipesayoung: a region is just a set of resources that are related17:06
*** rnirmal has quit IRC17:06
*** yeylon__ has joined #openstack-dev17:06
*** rnirmal has joined #openstack-dev17:06
*** mrunge has quit IRC17:06
ayoungjaypipes, yes, but our abstraction has to handle the set of use cases that people are asking for, or we are going to have duplication or something17:07
*** amotoki has quit IRC17:07
jaypipesayoung: sure, understood. but the abstraction is general enough to handle those specializations of it.17:07
*** ruhe has joined #openstack-dev17:07
ayoungjaypipes, so, it seems like the issue is "when a user ask for an endpoint, which ones do I show them"  and sometimes the user is not explicitly asking with region in mind17:07
jaypipesayoung: the proposed API extension has no connotations around geography17:08
dolphmi think the api proposal is way simpler than how ayoung is reading into it17:08
*** colinmcnamara has joined #openstack-dev17:08
jaypipesayoung: the answer to that last question is implementation-dependent17:08
ayoungjaypipes, I understand that two  Region  might just be the top half and bnottom half of the same rack17:08
dolphmayoung: sure17:09
dolphmayoung: it's up to the deployer to define regions as they see fit17:09
jaypipesayoung: sure, a region could be anything really... it's just a way of dividing resources (any resources, not just compute, otherwise I would have just used Cells/HostAggregates)17:09
ayoungjaypipes, OK,   so you were walking through the example where a user has access to two regions, and wishes to explicitly access resources in one of those regions17:09
yaguangjog0, ping17:09
jaypipesayoung: correct. (this is identical to the AWS example, BTW, where a user targets a particular AWS region)17:10
*** buzztroll has quit IRC17:10
ayoungjaypipes, so I would state that there is two levels of filtering.  And implicit first level of filter, and an explicit select afterwards.17:10
*** tomoe_ has quit IRC17:10
*** buzztroll has joined #openstack-dev17:10
*** tomoe_ has joined #openstack-dev17:10
*** networkstatic has quit IRC17:11
jaypipesayoung: I'm not quite following that last question/remark. could you elaborate pls?17:11
* ayoung sounds like a hillbilly17:11
*** sumanth has joined #openstack-dev17:11
ayoungjaypipes, before the user can select east or west, he knows, either a-prioir or explicitly that there are two reqions17:11
ayoungbut there might be more17:11
ayoungSo the user lists the regions and sees a list appropriate for the scope of his problem17:12
ayoungnow, that may be determined by domain, by project, or by group17:12
*** dkranz has quit IRC17:12
ayounguser group17:12
jaypipesayoung: he could either know ahead of time or he might have queried the service catalog (or in the new API proposed /regions resource) of the "US" region keystone server17:12
*** eglynn has quit IRC17:12
jaypipesayoung: the "US" region catalog would list resource endpoints for both the east and west regions17:12
jaypipesayoung: and he may have followed one of those links to find the "US-East" region.17:13
*** flaper87 is now known as flaper87|afk17:13
ayoungjaypipes, and that might be different for a spook coming in that would also see the "secret" US region...or maybe one level up would show it, but at some point there is information hiding17:13
jaypipesayoung: the "US" region's service catalog would not expose compute service endpoints for itself, however, this the compute service endpoints are actually in the "US" region's subregions...17:13
*** boris-42 has joined #openstack-dev17:13
jaypipesayoung: I don't understand that, sorry :( what information is being hidden?17:14
*** davidhadas has joined #openstack-dev17:14
jaypipess/this the/since the17:14
ayoungjaypipes, your design says hiereachy.  Lets say that it is a tree.  A user can start at the root and drill down.  So  "gloabl->contry->region" is the norm17:14
jaypipesyes17:15
jaypipesayoung: thuogh there is no geogrpahic connotation remember...17:15
ayoungbut what about the filtering based on the contract the user has with the organization?  At some point, we need to say " a user can see this region" or "no they can't"17:15
ayoungunderstood, just extending our example17:15
jaypipesayoung: that is entirely up to the implementor.'17:15
*** e0ne_ has joined #openstack-dev17:15
ayoungactually, "secret" is a cross cutting concern here, right?  Maybe there is an "illuminatit" region that is exposed only to, well, you know17:16
*** e0ne_ has joined #openstack-dev17:16
ayoungcompletely global17:16
jaypipesayoung: when a user asks for the service catalog of a region, all the API specifies is that the service catalog shall be a set of endpoints, with a specific structure. It says nothing about which endpoints a user has access to.17:16
jaypipesayoung: none of that is in the API proposal :)17:16
*** rongze has quit IRC17:16
jaypipesayoung: and doesn't need to be. it's implementation, not API.17:16
ayoungjaypipes, I know.  But the solution needs to account for all the use cases.17:16
ekarlsodevananda: yo, you around dude ? :)17:17
ekarlsogot a question on some stuff17:17
ayoungNo, filtering affects that api17:17
jaypipesayoung: whether a particular region is exposed to a user is implementation specifics.17:17
jaypipesayoung: there is no filtering going on in the API itself.17:17
ayoungbut specifying that aregion is or is not exposed requires an API call.17:17
jaypipesayoung: no it does not.17:17
jaypipesayoung: the API call is GET /regions and GET /catalog. The structure of the results returned by those calls are defined by the API's response structure, but not the result contents themselves.17:18
*** senk has joined #openstack-dev17:18
*** markwash has joined #openstack-dev17:18
NobodyCamekarlso: devananda will be back in about 20 minutes17:19
*** e0ne has quit IRC17:19
ayoungjaypipes, I'd rather not assume-away filtering right now17:19
*** zhiyan1 has quit IRC17:20
ayoungjaypipes, we are going to need an admin API to affect what to show.  Filtering needs to be accounted for there17:20
jaypipesayoung: we can add filtering just fine.17:20
ayoungEven if it is not used in the query level.17:20
*** e0ne_ has quit IRC17:21
*** rongze_ has joined #openstack-dev17:21
*** mlavalle has quit IRC17:21
ayoungjaypipes, So, expanding  the discussion a bit beyond the API doc,  I want to identify how Keystone itself is going to use it17:21
*** athomas has quit IRC17:21
jaypipesayoung: I'm ready for your questions :)17:21
ayoungjaypipes, ok...(and this is not a question, but a statement)17:22
jaypipeshehe17:22
ayoungI think we make regions into an extension17:22
*** sushils has quit IRC17:22
ayoungwe make the token API aware of the extension17:22
*** chandankumar has joined #openstack-dev17:22
ayoungand, potentailly, we have internal, implicit filters for calls to the catalog17:22
*** larsbutler has quit IRC17:22
jaypipesayoung: ok with me.17:22
ayoungthose filters can be specified at multiple levels17:22
ayoung1.  Global:  here is the catalog that people see by default17:23
ayoung2.  Per domain or per proejct17:23
ayoung3.  Per group17:23
ayoungThere may be others in the future, but I suspect that the above is sufficient17:24
jaypipesok.17:24
*** romcheg has quit IRC17:24
jaypipesayoung, dolphm: so, bottom line... you want me to move a) the original proposed API work into an extension, b) add the plumbing up front for filtering possibilities in the API extension spec17:25
jaypipesayoung, dolphm: would you prefer I create a brand new patch or amend the existing one?17:25
ayoungjaypipes, make it a new patch17:25
dolphmjaypipes: i'd actually vote for the basic regions stuff to be core api17:25
ayoungdolphm, can we do that in 4.017:26
ayoungAnd start with it as an extension, so it can be optional, and we can work out the kinks?17:26
*** shredder12 has quit IRC17:27
*** senk has quit IRC17:27
dolphmthe only "non-core" behavior in that api i see is that id's are user defined, which i'd like to do across the entire v3 API at some point17:28
ayoungdolphm, I agree that long term it is a core concept.  But having it as an extension makes more sense in a case of a client talking to a server in the near future and trying to determine if that server supports regions.  With extensions we have a mechanism for that.17:28
dolphmayoung: with versioned API's, we have a mechanism for that as well17:29
dolphmand ideally we'd just have a link from GET /v3/ to GET /v3/regions17:29
ayoungTrue.  Its a little more "oh, they have 3.3, so that must support Regions"17:30
*** kpavel has quit IRC17:30
ayoungdolphm, actually, I have a patch for that kind of thing17:30
dolphmhow is it more than that (also, it'd be 3.2)17:30
*** rnirmal has quit IRC17:30
*** alop_ has joined #openstack-dev17:30
*** alop has quit IRC17:30
*** alop_ is now known as alop17:30
ayoungsorry, didn't finish the thought17:31
*** rnirmal has joined #openstack-dev17:31
ayoung...where as I was proposing "I see the have v3/extensions/OS-REGIONS"17:31
ayoungbut then you got me excited about the idea of the link patch17:31
ayoungand I went looking for it17:31
*** dvarga_ has joined #openstack-dev17:32
*** zul_ has quit IRC17:32
dolphmayoung: oh lol -- that's just on my wishlist for icehouse17:33
*** dvarga has quit IRC17:33
*** gmurphy has quit IRC17:33
*** SumitNaiksatam has quit IRC17:33
*** mriedem has joined #openstack-dev17:33
ayoungdolphm, https://github.com/admiyo/keystone/commit/9bf1c13ccba68609135bcf426e284b9e57bacd39  but that is on top of my HTML changes. I was going to auto-generate it, but the URL scheme is too all-over-the-place to do so reliably17:34
*** topol has quit IRC17:36
dolphmayoung: is that appending the multiple choice response?17:36
ayoungdolphm, the v2 is a subset of the v3 values17:36
ayoungjust links17:36
*** vartom9 has joined #openstack-dev17:37
*** YorikSar has quit IRC17:37
*** topol_ has joined #openstack-dev17:37
*** topol_ is now known as topol17:37
ayoungdolphm, the idea is that the links on the version pages will should the modules underneath, just like it has the extensions, but a direct link to the landing url.  So that would generat e link like https://hostname:35357/v3.0/users17:37
ayoungwlell ,v317:37
*** YorikSar has joined #openstack-dev17:38
dolphmayoung: i wasn't going to bother with v2, and the only thing i wanted to add was calling into policy to find out if the requrestor has access to list_whatever17:38
ayoungactually it would generate both https://hostname:35357/v2.0/users  and https://hostname:35357/v3/users17:38
ayoungoh, policy call is a good idea17:38
jaypipesayoung, dolphm: so, guys, can I get a decision on the regions endpoint thing? new patch, yes? extension, yes?17:39
*** MaxV has joined #openstack-dev17:39
ayoungjaypipes, I'll defer to dolphm .17:39
dolphmjaypipes: new patch i think is necessary with the -2 :)17:39
*** topol has quit IRC17:39
*** dvarga_ is now known as dvarga17:39
jaypipesdolphm: ok, no worries. extension, yes?17:39
dolphmjaypipes: first let me clarify...17:39
dolphmjaypipes: when you said add plumbing for filtering -- you mean at the api level?17:40
*** topol has joined #openstack-dev17:40
dolphmi think i missed a bit of conversation (filtering what on what calls?)17:40
jaypipesdolphm: yes, to satisfy ayoung's request above... the only attribute I can see to filter on, however, would be parent_region_id17:41
*** networkstatic has joined #openstack-dev17:41
ayoungjaypipes, well, more than that.17:41
jaypipesayoung: there are no other fields.17:41
ayoungparent-reqion_id would be the normal scope of a query17:41
*** jvrbanac has quit IRC17:41
*** exed_ has joined #openstack-dev17:42
ayoungthe additional filter would be "attribute=value"  for an array of flags not yet determined17:42
*** exed_ has quit IRC17:42
jaypipesayoung: I think you are thinking of some future OS-REGION-EXT extension... that would add some sort of extra attributes to a region.17:42
dolphmayoung: in other words, parent_region_id would be the only filter in the spec?17:42
*** pschaef has quit IRC17:43
*** jvrbanac has joined #openstack-dev17:43
ayoungdolphm, I would almost say "no" that that.  We can say "a region can have an attribute" and  a filter can be "attribute matches value "17:43
ayoungwe would leave the set of attributes to be defined by the user17:43
*** rushiagr3 has joined #openstack-dev17:44
ayoungI'm thinking LDAPishly admittedly17:44
dolphmayoung: in other words, this is totally out of scope for this spec proposal?17:44
ayoungbut we are discussing a hierarchical database17:44
ayoungdolphm, No17:44
ayoungdolphm, this is the kind of things that were in the region discussion last summit17:44
*** exed has quit IRC17:44
*** topol_ has joined #openstack-dev17:44
ayoungand the reason why he-who-must-not-be-named-on-irc -2d the patch17:44
*** colinmcnamara has quit IRC17:45
*** topol has quit IRC17:45
*** topol_ is now known as topol17:45
ayoungdolphm, let me see what we have from the old etherpad17:45
*** ruhe has quit IRC17:45
ayounghttps://etherpad.openstack.org/p/havana-availability-zone-and-region-management17:45
jaypipesayoung: but what dolphm and I are saying is that we could easily add that functionality as a later extension (OS-REGION-EXTRA?)17:46
jaypipesayoung: no reason to do it all at once, IMO17:46
dolphmhttps://etherpad.openstack.org/p/havana-endpoint-filtering ?17:46
dolphmthat was a different session ^17:46
ayoungdolphm, ah17:46
ayoungyep17:46
devanandaekarlso: pong17:46
dolphmhttps://etherpad.openstack.org/p/havana-availability-zone-and-region-management17:46
ayoungand that is an extension17:46
dolphmthis was jaypipes ^17:46
*** burt has quit IRC17:47
ayoungdolphm, so...regions goes core, and filtering is optional?17:47
ayoungOK, I think that works for the use cases I can think of17:47
*** yaguang has quit IRC17:47
ayoungno need to duplicate the filtering mechanism17:48
*** rushiagr4 has joined #openstack-dev17:48
dolphmcool, so continue as core / v3.2 then17:48
ayoungdolphm, we should extend the filtering mechanism to contain regions17:48
dolphmjaypipes: i *just* made a comment on region / region_id on the last review as well... i don't know if i agree with my own comment. we're in a weird spot there17:49
*** Chicago has quit IRC17:49
*** rushiagr3 has quit IRC17:49
dolphmjaypipes: clients refer to "region_name", the current api just refers to it as "region", and now we're introducing region "id" which is not system-defined, as all other ID's are (and behaves like "name" attributes across the rest of the api)17:50
jaypipesdolphm: well, the problem is that the clients refer to region_name because Nova has a "region" concept -- borrowed directly from AWS...17:51
ekarlsodevananda: care for a hipchat ?17:52
jaypipesdolphm: that said, I don't know whether/if the Nova "region" concept is even used anywhere in the Nova code, or whether it passes region on as the availability zone...17:52
dolphmgood question17:52
*** colinmcnamara has joined #openstack-dev17:52
dolphmjaypipes: do you want to see the clients change their api? (to region_id or just region?)17:52
ayoungjaypipes, OK, so, to start, new review with a rebase of your old one.17:53
jaypipesdolphm: I could go either way... if we co-opt the existing "region" params to be the Keystone OS-REGIONS API extension "region", then yes, we should probably change region_id to region_name (or alternately change "description" to "name" and allow matcghing on either an ID or the region_name passwed by the clients today)17:54
*** devvesa has quit IRC17:55
*** vkmc has quit IRC17:55
*** SumitNaiksatam has joined #openstack-dev17:56
*** ruhe has joined #openstack-dev17:57
*** yolanda has joined #openstack-dev17:57
dolphmjaypipes: third option- cheat. give region objects both an "id" and a "name". allow the api user to define the "name" and the system to define the "id", used in URL's17:58
*** jprovazn has joined #openstack-dev17:58
dolphmjaypipes: so, just as done in the rest of the api, except...17:58
*** chuck_ has joined #openstack-dev17:58
dolphmjaypipes: region.id = urlencoded(region.name) in the implementation17:58
dolphmand then we can just recommend that region names be specified as url safe, such that region.id == region.name17:59
ayoungdolphm, I like that17:59
ayoungdolphm, and region names must be globally unique17:59
*** ruhe has quit IRC18:00
*** yaguang has joined #openstack-dev18:00
*** neelashah has quit IRC18:00
dolphmyou'd get that for "free" by "generating" the id's and checking for uniqueness there18:00
*** markmcclain has joined #openstack-dev18:00
*** CaptTofu_ has quit IRC18:00
*** zul has quit IRC18:00
*** chuck_ is now known as zul18:01
*** zul has quit IRC18:01
*** zul has joined #openstack-dev18:01
*** sarob has quit IRC18:01
*** dubsquared has quit IRC18:01
*** sarob has joined #openstack-dev18:01
*** chuck_ has joined #openstack-dev18:01
*** dubsquared has joined #openstack-dev18:01
*** twoputt has quit IRC18:02
jaypipesdolphm: ok, sounds good.18:02
*** twoputt has joined #openstack-dev18:02
ayoungdolphm, lets make region names readable.  No uuids18:04
*** changbl has quit IRC18:04
ayoungI don't think UUIDs or some other auto generated scheme makes sense for regions.18:04
dolphmayoung: we could actually take this approach for everything? id = urlencoded(name)18:04
dolphminstead of uuid's18:04
ayoungdolphm, oh, that would make me so happy18:05
ayoungdolphm, for users,  I would like18:05
dolphmayoung: that would be way easier than what i had in my head as an api revision18:05
*** dkehn is now known as dkehn_lunch18:05
ayounguser.id =  user.domain + separateor + user.username18:05
*** dot has joined #openstack-dev18:05
*** sarob has quit IRC18:06
dolphmayoung: bah, i forgot about scope there18:06
ayoungand then just have the rule that username must be unique within domains18:06
ayoungdolphm, for regions, the name should be the short name, and the id the full URL18:06
dolphmayoung: user.domain and user.name would have to be encoded to avoid using the separator18:06
*** rushiagr4 has quit IRC18:06
ayoungsince it is hierarchical18:06
*** dubsquared has quit IRC18:06
ayoungregions/US/West/California/Business  vs regions/US/East/NewYork/Business18:07
*** CaptTofu has joined #openstack-dev18:07
*** chandankumar has quit IRC18:08
*** jvrbanac has quit IRC18:08
*** pjd2 has joined #openstack-dev18:09
*** rushiagr4 has joined #openstack-dev18:10
*** chandankumar has joined #openstack-dev18:11
*** rnirmal has quit IRC18:12
*** rnirmal has joined #openstack-dev18:12
*** rushiagr4 has quit IRC18:13
dolphmayoung: id="regions%2FUS%2FWest%2FCalifornia%2FBusiness"18:13
*** pjd2 has quit IRC18:13
jaypipesayoung: I'm not a fan of the above region id approach. it's inflexible... what happens when I want to move a region from one parent to another? now I need to change the IDs of the regions.18:14
ayoungjaypipes, oh, come on, how often does that happen?18:15
jaypipesayoung: what if I wanted to move region A, which I defined as having some better SLA, from region X into region Y?18:15
jaypipesayoung: you are assuming geographic regions.18:16
*** dubsquared has joined #openstack-dev18:16
ayoungjaypipes, did you really think I was serious.  You should know me better than that by now.18:16
*** rushiagr4 has joined #openstack-dev18:16
ayoungI see your point18:16
jaypipesayoung: the nice thing about UUIDs is that they are unique and disconnected from other elements.18:16
jaypipesthey are what they are... with no connotation of any other piece of data18:17
ayoungjaypipes, so what you are saing is that the hierarchy is like a Dentry scheme, but the ID is like the INODE18:17
jaypipes(or at least, UUIDs how we've used them :)18:17
jaypipesyes.18:17
jaypipesquite similar indeed.18:17
ayoungjaypipes, so when we refer to region, are we talking the full path or the local path with an assumed scope?18:17
ayoungregionname that is18:18
*** colinmcnamara has quit IRC18:18
*** yolanda has quit IRC18:19
*** changbl has joined #openstack-dev18:19
jaypipesayoung: I'm recommending that we change the proposed "description" field in the regions/ resource to be "name" and enforce uniqueness on that field. and then the clients can provide the region name as they have been doing, or a region_id if they have it.18:20
*** markmcclain has quit IRC18:20
morganfainbergdolphm, ayoung ++ on the urlencode(name)18:20
jaypipesayoung: in other words, then exact same as we do for tenant_name vs. tenant_id18:20
morganfainbergthat would make users _much_ happier (catching up_18:20
morganfainbergjaypipes, would a similar semantic as we use now simply interchangeable names/uuids for referencing work?18:22
*** sarob has joined #openstack-dev18:22
*** sarob has quit IRC18:22
morganfainbergoh i think thats kind of what you're describing18:22
*** sarob has joined #openstack-dev18:23
*** utlemming has joined #openstack-dev18:23
*** sarob has quit IRC18:24
*** alexpilotti_ has joined #openstack-dev18:24
*** rushiagr4 is now known as rushiagr_away18:24
*** egallen has quit IRC18:24
*** rushiagr_away is now known as rushiagr418:24
*** rushiagr4 is now known as rushiagr18:24
*** sarob has joined #openstack-dev18:24
markwashjeblair: not sure if you're the right person to bug, but I'd love it if glance-core members could be accepted here https://launchpad.net/~glance-bugs/+members#proposed18:25
*** dprince has quit IRC18:25
*** marun has quit IRC18:26
clarkbmarkwash: I think any member of OpenStack Administrators can do it, however it might be better to make the Glance security contacts team admin for glance-bugs18:26
jeblairmarkwash: oh, i think we made most of the bug teams 'open' teams so anyone could join18:26
*** alexpilotti has quit IRC18:26
*** alexpilotti_ is now known as alexpilotti18:26
*** sushils has joined #openstack-dev18:26
*** jcoufal has joined #openstack-dev18:27
clarkbor that18:27
jeblairmarkwash: (regardless, we should probably make glance-drivers an admin of that team.  also what clarkb suggests if you want)18:27
marekdjoesavak: hi!18:28
joesavakhiya marekd!18:28
joesavakhow are you?18:28
marekdfine, how are you18:28
marekddo you have a minute?18:29
joesavakgood. Still sifting out the contract - about to do a call with steve to discuss18:29
*** eglynn has joined #openstack-dev18:29
*** sarob has quit IRC18:29
joesavakwant to join?18:29
jeblairmarkwash, clarkb: i have made glance-drivers an admin; markwash you should be able to do what you need with the group.18:29
markwashjeblair: thanks!18:29
*** utlemming has quit IRC18:30
marekdjoesavak: when exactly?18:30
*** macjack has quit IRC18:32
*** macjack_ has joined #openstack-dev18:32
*** exed has joined #openstack-dev18:33
*** pberis has quit IRC18:33
*** SumitNaiksatam has quit IRC18:34
*** steven-weston has quit IRC18:34
*** CaptTofu has quit IRC18:35
*** CaptTofu has joined #openstack-dev18:35
*** romcheg has joined #openstack-dev18:36
*** ruhe has joined #openstack-dev18:38
*** rongze_ has quit IRC18:39
*** changbl has quit IRC18:39
*** dvarga has quit IRC18:39
*** rongze has joined #openstack-dev18:39
*** CaptTofu has quit IRC18:40
*** rushiagr2 has joined #openstack-dev18:40
*** rushiagr has quit IRC18:40
dothello i am trying to disable csrftoken but it still request this token18:41
*** rnirmal has quit IRC18:41
doti tried like this: from django.views.decorators.csrf import csrf_exempt18:41
dot@csrf_exempt18:41
*** rnirmal has joined #openstack-dev18:41
*** dvarga has joined #openstack-dev18:41
*** jprovazn has quit IRC18:41
*** jistr has joined #openstack-dev18:43
*** ruhe has quit IRC18:43
*** jistr has quit IRC18:43
*** dkehn_lunch is now known as dkehn18:43
*** rongze has quit IRC18:44
*** zul has quit IRC18:45
*** dstanek has quit IRC18:47
*** johnthetubaguy has quit IRC18:48
*** yolanda has joined #openstack-dev18:48
*** jamespage_ has joined #openstack-dev18:52
*** senk has joined #openstack-dev18:53
*** pberis has joined #openstack-dev18:53
*** SumitNaiksatam has joined #openstack-dev18:55
*** sarob has joined #openstack-dev18:55
*** sarob has quit IRC18:56
*** sarob has joined #openstack-dev18:56
*** nati_ueno has joined #openstack-dev18:56
*** vartom9 has quit IRC18:57
*** singhs has quit IRC18:58
*** jruzicka has quit IRC18:58
*** senk has quit IRC18:58
*** changbl has joined #openstack-dev18:59
*** litong has quit IRC18:59
*** CaptTofu has joined #openstack-dev19:00
*** romcheg has quit IRC19:00
*** neelashah has joined #openstack-dev19:00
jswarrendhellmann: wanted to chat about i18n in Oslo if you have time.19:00
*** romcheg has joined #openstack-dev19:00
dhellmannjswarren: sure19:01
*** xqueralt has quit IRC19:01
jswarrenAs I understand it, you don't like the approach of extending unicode.  Can you provide some insight?19:01
dhellmannYes, that's right.19:02
*** rnirmal_ has joined #openstack-dev19:02
dhellmannI don't think a Message *is* a unicode object, I think that the string is one property of the Message19:02
dhellmannso we don't need something to *be* a unicode, we need something we can turn into a unicode string on demand, in one of 2 ways19:02
*** rnirmal_ has quit IRC19:03
larsksIs anyone around who is familiar with the openstack-puppet modules?  I'm seeing what look like parsing problems in the keystone module and would appreciate a second opinion.19:03
dhellmann(with an explicit locale, or an implicit locale)19:03
*** rnirmal_ has joined #openstack-dev19:03
dhellmannjswarren: is that more clear?19:03
*** rushiagr3 has joined #openstack-dev19:03
jswarrenIf Message extends unicode, which wouldn't an instance of it be an instance of unicode?19:03
*** rnirmal has quit IRC19:03
*** rnirmal_ is now known as rnirmal19:03
jswarrenwhich = why19:03
*** singhs has joined #openstack-dev19:04
dhellmannwell, if you force it to subclass from unicode then it does have to be a unicode object, but when I think about Message that's now the relationship I see between those types19:04
*** rushiagr2 has quit IRC19:04
dhellmannMessage is an object that knows how to translate a string into another language. That's not the same thing as saying Message is a string.19:04
jswarrenWhat if Message were a unicode object with some attributes and the translation happens outside that class?19:05
dhellmannthat would break the encapsulation of Message19:06
dhellmannat that point, why bother having Message at all?19:06
jswarren...in order to house the attributes, since base unicode can't have attributes.19:06
dhellmannjust have _() return its argument as a real unicode object, and let the translation happen at a different point19:06
jswarrenOnce you've lost the message ID, you can't translate.19:07
dhellmannah, right, %19:07
*** afazekas_ has quit IRC19:07
dhellmannso we definitely need Message, we just need to agree on what Message is19:07
*** ykhodork has joined #openstack-dev19:07
jswarrenRight.19:07
dhellmannok, well I'm worried about 2 things19:07
jswarrenHaving Message extend unicode is going to be much less disruptive to the consuming projects.19:07
*** nati_ueno has quit IRC19:08
dhellmannhow so?19:08
*** nati_ueno has joined #openstack-dev19:08
jswarrenIn some cases, the string in the system locale can be used and is being used.  In other words, the logic doesn't translate Message unless it's necessary.19:08
dothello i am trying to disable csrftoken but it still request this token19:09
dhellmannwhich cases are those?19:09
doti tried like this: from django.views.decorators.csrf import csrf_exempt19:09
dot@csrf_exempt19:09
dhellmannjswarren: is there a case other than logging?19:10
jswarrenFor instance: https://github.com/openstack/glance/blob/master/glance/api/v2/images.py line 62919:10
* dhellmann looks19:10
*** mlavalle has joined #openstack-dev19:10
jswarrenAlso, with exceptions, the unaltered string is used if the client did not specify a locale.19:11
dhellmannwell, whether or not the client specifies a locale isn't really a detail I think Message should care about19:12
dhellmannthat's up to the caller19:12
*** novas0x2a|laptop has joined #openstack-dev19:12
jswarrenRight, but the way the logic is now Message is used as-is unless the locale has been specified.19:12
dhellmannto be clear, I think Message should support __mod__ to save args from string interpolation and __unicode__ for default rendering19:13
dhellmannI just don't think it should *be* a unicode object19:13
jswarrenWhy not?19:13
dhellmannI don't understand "the way the logic is now"19:13
dhellmannwhere?19:13
*** CaptTofu has quit IRC19:13
*** dolphm is now known as dolphm_food19:14
* jswarren looks19:14
*** CaptTofu has joined #openstack-dev19:14
*** zul has joined #openstack-dev19:14
*** rushiagr4 has joined #openstack-dev19:16
*** rushiagr3 has quit IRC19:16
*** cpallares has joined #openstack-dev19:16
*** singhs has quit IRC19:16
jswarrenWhile I'm looking, can you explain why Message should not be a unicode object?  I understand that you don't view the relationship that way.  What keeps you from viewing the relationship that way?19:17
dhellmannThe way the Message is used19:17
dhellmannmore coming...19:17
dhellmannAt every point where we might want to emit a translated string, we will have to look at the input argument to see if it is a Message that we can translate19:18
dhellmannSometimes, like when a client does not pass a locale, we don't necessarily need to translate, but we will need the code present to do it for the times when we do19:18
*** dubsquared has quit IRC19:18
dhellmannSo, we will unavoidably have code in a few places that knows "When I get a Message instance, translate it by calling .translate() instead of using it directly"19:19
*** CaptTofu has quit IRC19:19
dimsdhellmann, what would "_()" return? since people expect a simple 'print (_("hello world"))' to work?19:19
*** dubsquared has joined #openstack-dev19:19
dhellmannIn the very few places where we do not need to translate, we could just call unicode() on the Message instance to get a default value (either the untranslated string or a value using the system's default locale)19:19
mroddendims: that would fail if _("hello world") returns a unicode with utf8 encoded bytes19:19
dhellmannbut there is only one place I've been shown where that is possible (loggingh)19:19
dhellmann*logging19:20
*** rushiagr has joined #openstack-dev19:20
*** rushiagr4 has quit IRC19:20
*** singhs has joined #openstack-dev19:20
luisgmrodden, it woudl only fail if it has non-ascii utf-encoded bytes, but that is expected19:21
dhellmannsince we have those explicit checks, we can have Message just explicitly present those 2 functions in its API, and not try to implicitly handle translation magically19:21
mroddenluisg: right, i guess thats what i meant19:21
*** reed has joined #openstack-dev19:21
dhellmannluisg: no, Message would have a __unicode__ method and maybe even a __repr__ method, so some of those implicit cases would still work19:21
dhellmannan object does not have to subclass unicode in order to present itself for printing19:21
*** sumansn_ has joined #openstack-dev19:22
dimsdhellmann, gotcha19:22
mroddenthat makes sense19:22
dimsmrodden, gotcha19:22
*** lbragstad has quit IRC19:22
dhellmannalthough it may be better for __repr__ to return something that included the untranslated string19:23
dhellmannthat needs more thought19:23
*** yamahata has joined #openstack-dev19:23
*** dubsquared has quit IRC19:23
luisgdhellmann, i thought u had suggested __unicode__ to raise a runtimeerror19:24
*** SumitNaiksatam has quit IRC19:24
jswarrenI would think that we would not want the __unicode__ method to work, because then we can't be sure that Message isn't being used directly, like being modded into a string.19:24
dhellmannluisg: I thought that was __str__?19:24
jswarren..if we don't extend unicode.19:24
*** hartsocks has left #openstack-dev19:24
mroddenyeah we only really need to do __str__19:24
luisg2013-10-11T14:28:04  <dhellmann> luisg_: no, I am suggesting that both __str__ and __unicode__ should raise a RuntimeError19:24
*** sumansn__ has quit IRC19:25
luisgat least that is progress, b/c it woudl have been very painful to use that Message class19:25
dhellmannluisg: ok, I think I changed my mind later on (I think you convinced me to allow __unicode__)19:25
*** lbragstad has joined #openstack-dev19:25
*** SumitNaiksatam has joined #openstack-dev19:25
*** marekd is now known as marekd|away19:25
*** singhs has quit IRC19:25
jswarrenI don't think allowing __unicode__ is a good idea, if you're not extending unicode.19:25
dhellmannmrodden: no, we should *never* allow __str__ -- all of this should be done in unicode, and the code writing the output should encode the results19:25
dhellmannjswarren: why?19:26
mroddendhellmann: right, thats what i was trying to say, only need to raise RuntimeError in __str__19:26
jswarrenIf you allow __unicode__, then Message might be misused without the programmer being aware.19:26
dhellmannmrodden: ok, I misunderstood19:26
mroddennp19:26
dhellmannjswarren: yes, I think that's why I originally wanted it to raise, too19:26
jswarren"My String: %s" % _("hello")19:26
dhellmanndoes that happen anywhere?19:27
mroddenseems like a bad idea to do that19:27
jswarrenI think so.  Problem is that it *could* happen.19:28
*** neelashah has quit IRC19:28
*** singhs has joined #openstack-dev19:28
*** zul has quit IRC19:28
luisgso dhellmann i understand that u are not comfortable with the model of Messaging as unicode, but we are just suggesting "decorate" unicode with the ability to translate itself: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016953.html19:28
jswarrenThe biggest concern I have about _() returning something that isn't unicode is what future developers might do and the hours they might spend debugging.19:28
luisgs/Messaging/Message/ ^19:28
*** macjack_ has quit IRC19:29
dhellmannjswarren: and I want them to be aware that they shouldn't be messing with the translatable strings in ways that make it look like their app works, when in fact it doesn't because it isn't handling the translatable strings properly19:29
luisgand yeah the major concern is just b/c of the fact that we ran into some of these problems by having places treat the outcome of _() as unicode, rightly so, but it not being19:29
dhellmannso I want a nice big clear "DO NOT TREAT THIS LIKE A STRING" error message19:29
*** rushiagr has quit IRC19:29
jswarrenAh!19:30
dhellmannbecause if we don't do that, then some of the translations aren't being translated, and you end up with a mix of languages in the output, which is even *harder* to debug19:30
jswarrenIf you include remediation:  "DO NOT TREAT THIS LIKE A STRING--CALL ITS TRANSLATE METHOD", that would make it clearer.19:30
mroddenyeah i think we ran into a few cases of that19:30
dhellmannjswarren: yes, right, it's all about the error message :-)19:30
mroddenU CAN HAZ STRING IF translate()19:31
luisgi just want to point out that the reason we ran into cases like that was bc we were trying to encode and decode in different encodings19:31
*** gmurphy has joined #openstack-dev19:31
dhellmannluisg: right, Message should not be dealing with encoding19:31
dhellmannMessage should only work on unicode text19:31
mrodden++19:31
luisgyeah +1 to that19:32
luisgso that is why the approach opf the TranslatableUnicode19:32
*** singhs has quit IRC19:32
dhellmannlet me turn this around19:32
dhellmannwhy is it so important to allow implicit string handling of Message objects?19:32
*** melwitt has joined #openstack-dev19:33
*** melwitt has quit IRC19:33
jswarrenIt is the expected and documented behavior of _() to return unicode objects.19:33
*** melwitt has joined #openstack-dev19:34
*** chandankumar has quit IRC19:34
dhellmannwell, sure, but it's also the documented behavior that those messages are translated into the "current locale" -- we aren't doing that19:34
dhellmannshould we change the translation decorator to something other than _()?19:34
jswarrenActually, we are.19:34
dhellmannI thought we were translating them into the locale of the API caller19:35
luisgno yeah we always return the default locale out of _()19:35
luisgthen on the way out we translate19:35
*** egallen has joined #openstack-dev19:35
*** burt has joined #openstack-dev19:35
luisgso we would be honoring the documented api for _()19:35
luisgunicode in the current locale19:35
*** gyee has quit IRC19:35
luisgjust with the ability to translate19:35
dhellmannI'm not convinced it is important for our _() to behave that way. Why do we need that?19:36
*** neelashah has joined #openstack-dev19:37
jswarrenIt's a bit like having len() not returning an integer.  Yes, it can be done, but it is a good idea?19:37
luisgb/c it is used in a lot of places with the assumption that stuff that works with unicode will still work, e.g. when they do; ex = _('Error: %s) % ex.message, or passing in the outcome of _() to a log Formatter, or trying to jsonify the output of _()19:37
*** stugs has joined #openstack-dev19:38
dhellmannyou're arguing from "what ifs" though -- what if a developer used Message in a way we don't want them to. Well, we *don't want them to* so why not be explicit about that?19:38
dhellmannright, we need __mod__19:38
luisgthat just covers the 1st example19:38
dhellmannlogging is handled in our adapter already19:39
jswarrenWell, for logging, for instance.  What if someone wants to use their own configuration, i.e. without our adapter.19:39
jswarren?19:39
*** singhs has joined #openstack-dev19:39
dhellmannjsonification will need to call translate() explicitly19:39
luisgand then we'll have to have another workaround for jsonify19:39
luisginstead of stuff just working b/c we are using unicode objects19:39
luisgthey do anythig people expect them to19:39
dhellmannjswarren: I don't think it's possible for them to get a logger without our adapter on it from any OpenStack code19:39
*** gszasz has quit IRC19:39
luisgbut we can also translate them in the special cases when we need to19:40
dhellmannluisg: but we must call translate() explicitly for json because we need to provide the right locale19:40
jswarrenI guess the real question is whether translating must be obligatory in all cases.19:40
luisgdhellmann, u see though how we have to add workarounds everywhere though to convert to unicode, instead of the thing just being unicode19:40
dhellmannjswarren: explicit translation is required for the API, and implicit using the system locale is ok for logging19:40
dhellmannluisg: yes, that is unavoidable -- it's not just enough to return the right type, we have to return the right contents in the string, too19:41
*** jamespage_ has quit IRC19:41
luisgthe argument is that it is avoidable if the object is unicode19:41
jswarrenWe can make Message from _() look exactly like unicode coming from gettext _(), that's not a problem.19:42
*** stugs has left #openstack-dev19:42
luisgeverybody that expects _() to return unicode, will continue to work just fine19:42
dhellmannhow can I write english source strings and have them translated to french automatically in the api if I do not call translate()?19:42
jswarren...it goes back to whether we really want to force translation of these objects all the time.19:42
luisgoh, we are talking about the explici translation cases19:42
jswarrendhellman, yes, if the system locale is french.19:42
luisgim talkng aobut the implciit ones i guess19:42
jswarrendhellmann ^19:42
dhellmannjswarren: my system locale is english and my API user is french19:43
dhellmannI've already said we can have __unicode__ for the implicit case for logging19:43
jswarrenthen you'll have to call translate.19:43
*** dscannell has left #openstack-dev19:43
dhellmannthe other part is the API side19:43
dhellmannyes, right19:43
jswarren..but __unicode__ won't work.19:43
dhellmannright, the API will call translate() and anything that doesn't care about translation can call unicode() and we're all happy, no?19:44
jswarrenhow about translate(None) instead of unicode()..  We already covered why we don't want that method to work.19:45
dhellmannjswarren: I love it. I thought I gave up on that argument. :-)19:45
dhellmannwe should figure out whether None returns the original string or the version for the system locale (it might be useful to have access to both)19:47
*** nati_ueno has quit IRC19:47
jswarrenI'd use a different method for the original string.19:47
dhellmannmaybe we require them to call locale.getlocale()19:47
dhellmannthat works, too19:47
*** nati_ueno has joined #openstack-dev19:47
dhellmannjswarren, luisg, mrodden, dims : do we agree, then?19:48
jswarrenNot allowing direct use of Message as a string does have a case, then.  I just don't know whether the consuming projects won't be disrupted too much.  We have not "broken" Message yet, so we don't know what we'll find.19:49
jswarrenThe people in charge of the consuming project might balk at how much code they need to change.19:49
*** rraja has joined #openstack-dev19:49
luisgim still worried about the approach tbh for two reasons 1) we don't know all the uses of _() outputs across all projects, and 2) the expected error out of str() for problems is UnicodeError and then handling that19:49
luisgat least that is what the log. Formatters do and it is actually a sensible approach19:50
luisgbut im ok if people are ok with these issues19:50
dhellmannjswarren: we should quantify the changes, then. I don't expect to find any cases where code needs to change where it is not currently doing the wrong thing in some way.19:50
*** jcoufal has quit IRC19:50
jswarren"If it breaks, it was already broken"19:51
dhellmannluisg: for (1) we will have to do research and for (2) I think always using unicode instead of a byte string will protect us19:51
dhellmannjswarren: right :-)19:51
luisgkk19:51
mroddensorry, being office interrupted atm19:51
dhellmannmrodden: np19:51
*** rraja has quit IRC19:52
dimsdhellmann, +1 from me - we have to give it a shot against glance/nova/cinder jenkins jobs i guess19:52
*** nati_ueno has quit IRC19:52
*** CaptTofu has joined #openstack-dev19:52
dhellmanndims: right19:52
luisgso wait did we say that __unicode__() was not goign to work?19:53
*** gordc has quit IRC19:53
jswarrenRight..  otherwise people would be able to use it inappropriate ways.19:54
luisgso across all the code base, anybody that ever does _('hi') needs to translate explicitely?19:54
*** sushils has quit IRC19:54
*** epopt37 has quit IRC19:54
jswarrenYes.19:54
luisgbasically creating your most basic string went from u'a' to _('a').translate('en')19:55
jswarren_('hi').translate(None) for the default locale.19:55
luisgok sure that19:55
*** senk has joined #openstack-dev19:55
luisgi am not sure that is developer friendly enough tbh19:55
dhellmannluisg: what is a case where someone would actually do that, though?19:55
dhellmannwouldn't they usually just call _('a') and then pass it somewhere else? (maybe after using %)19:56
*** carl_baldwin has quit IRC19:56
*** jdennis has quit IRC19:56
luisgidk i think u know just writing code playing with stuff, like dims said, debgging and doing print ex.message19:56
dhellmannI'm not sure we should optimize for that case. it seems more important to find ways in which _() messages are not being used correctly in production code.19:57
dhellmannthe developer can always turn off lazy translation for that case, too19:57
*** sushils has joined #openstack-dev19:58
jswarrenAlright..  I'm fine with giving this approach a try.19:58
luisgbut u could not even write somethign like this in: log.info(_('my msg'))19:58
luisgwithout making sure that u have the right log adapter and what not19:59
dhellmannluisg: if log comes from the oslo logging module, you could do that19:59
dhellmannagain, turn off lazy translation19:59
luisghow will ppl know that though?19:59
*** topol has quit IRC20:00
*** senk has quit IRC20:00
luisgok another example, you have a very common case20:00
*** networkstatic has quit IRC20:00
*** dstanek has joined #openstack-dev20:00
luisglog.error('API error: " % ex.message)20:00
luisgwe would have to change every where we do that20:00
luisgb/c we areno logging a Message, we are logging a message moded with a string20:01
luisgwell nm i guess not it would be moded with another message20:01
dhellmann"API error:" needs to be translated, right?20:01
dotanyone here ?20:02
*** dkranz has joined #openstack-dev20:02
luisgstill i think it's better for the M class to be selfsuficient, in the sense that it does not need asistance even for getting logged20:02
doti am wondering why this is not working @csrf_exempt20:02
doti set this before login20:02
luisgbut seems like a lost cause, even jswarren has converted :)20:03
dotbut still require csrf token?20:03
luisglet the record show that i don'tl ike the approach, but we gotta start moving on to impl :)20:03
jswarrenIt's a good way to root out improper use of Message.20:03
dhellmannluisg: let's at least try it and see what happens. We can adjust our approach if we run into major issues.20:03
*** READ10 has joined #openstack-dev20:03
luisgimproper use of message is basically using stR() and we can impl str() to raise an error even if we extedn fro unicode20:03
*** hartsocks has joined #openstack-dev20:03
*** CaptTofu has quit IRC20:04
*** hartsocks has left #openstack-dev20:04
luisgdhellmann, sounds good20:04
jswarrenImproper use is never calling translate()20:04
dhellmannluisg: cool, thanks20:04
*** spzala has quit IRC20:04
*** CaptTofu has joined #openstack-dev20:04
mroddenso we aren't going to allow implicit translation with __unicode__20:05
mrodden?20:05
luisghaha20:05
mroddeni have no opinion on it20:05
mroddenjust clarifying20:05
jswarrenImplicit translation is done via translate(None)20:05
lifelessmrodden: I sure hope not20:05
luisgyeah  no not allwoed20:05
lifelessthat would be super super super surprising20:05
mroddenok20:05
*** vkmc has joined #openstack-dev20:05
dhellmannmrodden: right, initially we won't, but if that breaks way too much code we can allow it for now to give time to fix the code in smaller batches20:05
mroddentranslation to default locale20:05
mroddenanyways20:05
mroddenok20:06
*** tanisdl has quit IRC20:06
jswarrentranslation to default locale: Message.tranlsate(None)20:06
mroddentaking notes here https://etherpad.openstack.org/p/i18nmessages20:06
lifelessdhellmann: huh, when would unicode(thing) invokes translation be a good idea?20:06
*** prad_ has quit IRC20:06
*** jamespage_ has joined #openstack-dev20:07
*** epopt37 has joined #openstack-dev20:07
dimshere's a weird use case from https://bugs.launchpad.net/nova/+bug/124282020:07
dims296 msg = _('Image name "{0}" does not exist, fetching it...')20:07
dims297 LOG.info(msg.format(image_name))20:07
uvirtbotLaunchpad bug 1242820 in oslo "Nova docker virt driver triggers - AttributeError: 'Message' object has no attribute 'format'" [Undecided,New]20:07
dhellmannlifeless: it isn't, but we're trying to break things a little at a time, so if we have a lot of code treating the return value from _() as a unicode object right now we don't want to break it all at one time20:07
*** steven-weston has joined #openstack-dev20:07
dhellmanndims: good one, we'll need a format() method, too20:07
lifelessdhellmann: ok; what type will the return from _() be?20:08
*** exed has quit IRC20:08
dhellmanna reimplemented version of a Message class20:08
dhellmannwe have one in oslo-incubator now, but we're working out how to fix it20:08
lifelessok cool20:08
lifeless-much- less zomgy20:08
dhellmannyep, we're getting there20:09
*** CaptTofu has quit IRC20:09
*** exed has joined #openstack-dev20:09
mroddeni'm pretty sure thats violating the hacking doc20:09
mroddeni thought it said that we are supposed to use _() %20:09
*** dubsquared has joined #openstack-dev20:09
mroddennot .format20:09
dhellmannmrodden: hacking says to not use format()?20:09
*** neelashah has quit IRC20:10
mroddeni thought i read that somewhere20:10
dhellmannI guess that's not being enforced yet?20:10
*** vipul is now known as vipul-away20:10
*** vipul-away is now known as vipul20:10
*** CaptTofu has joined #openstack-dev20:10
mroddenyeah i would have to double check i guess20:10
dhellmannwell, .format() isn't much harder than __mod__(), so we can just add it to be safe, too20:10
mroddenyeah20:10
mroddenits basically the same20:11
luisgthat is one of the things that i think will continue happening, ^.. eventualy we'll find a msg = _('Error: ") + "oh gosh"20:11
luisgand we'll have to impl +20:11
luisg...20:11
luisghopefully we won't end up back in current Message20:12
*** alunduil has quit IRC20:12
*** bmelande_ has joined #openstack-dev20:12
jswarrenBecause word order differs in languages, concatenating translated strings doesn't seem like a good idea.20:13
*** boden has quit IRC20:13
bknudsoncould do the same with _(' %s')20:13
*** MaxV has quit IRC20:13
*** senk has joined #openstack-dev20:13
dhellmannluisg: __add__ and __radd__ feel like cases that should raise explicit exceptions20:13
*** MaxV has joined #openstack-dev20:13
mroddenwe do implement + actually...20:13
mrodden:)20:14
dhellmannwe do now, but should we continue to allow it?20:14
*** jdennis has joined #openstack-dev20:14
dhellmannwas it added because it was actually needed, or because we thought it was needed?20:14
mroddeni dont think people shoudl be tacking things on to Message objects20:14
dhellmannI agree20:14
mroddenbut i think it might be people concatenating with empty strings for some reason20:14
mroddenwhich again, is kind of wrong20:14
*** bmelande has quit IRC20:15
dhellmannright20:15
*** jamespage__ has joined #openstack-dev20:15
mroddenguess we are just going to have to fix all the bad string handling smell20:15
luisgyeah agree not saying it's right, just i think we'llfind places like format() where we'll need to fix stuff20:15
mroddenwhich will now be Message handling20:15
luisgyeah20:15
dimsmrodden, we should enforce a limited set of behaviors and not keep adding to it20:15
luisg+120:16
mroddenagreed20:16
dhellmann+120:16
*** jamespage_ has quit IRC20:16
mroddenhttp://docs.openstack.org/developer/hacking/#internationalization-i18n-strings it doesn't explicitly say % vs format20:17
mroddenbut the example uses %20:17
*** singhs has quit IRC20:17
dhellmannok, let's go ahead and support format() then, to be safe20:18
*** MaxV has quit IRC20:18
mroddenk20:18
*** colinmcnamara has joined #openstack-dev20:18
*** jamespage__ has quit IRC20:19
*** utlemming has joined #openstack-dev20:19
dhellmannthanks guys, I'm glad we're coming to agreement on the plan :-)20:19
*** colinmcnamara has quit IRC20:19
mroddenme too, now we can get to coding, which is the fun part20:20
dhellmannyes!20:20
dhellmannok, I'm going to go see if I can fit 10 pounds of summit sessions in a 5 pound sack20:21
luisgdhellmann, thank you :)20:21
dhellmannthank *you* :-)20:21
*** aelkikhia has joined #openstack-dev20:21
*** dsantos_ has joined #openstack-dev20:22
*** aelkikhia has left #openstack-dev20:22
*** prad has joined #openstack-dev20:22
*** ykhodork has quit IRC20:23
*** jamielennox|away is now known as jamielennox20:23
*** burt has quit IRC20:24
*** senk has left #openstack-dev20:25
*** jamespage__ has joined #openstack-dev20:25
*** vipul is now known as vipul-away20:25
*** CaptTofu has quit IRC20:26
*** tanisdl has joined #openstack-dev20:26
*** morazi has quit IRC20:26
*** CaptTofu has joined #openstack-dev20:26
dolphm_fooddstanek: i just reviewed the @deprecated patch again (cc dhellmann)20:27
*** dolphm_food is now known as dolphm20:27
*** melwitt has quit IRC20:28
dolphmhttps://review.openstack.org/#/c/50486/20:28
dolphmdstanek: i really like the if callable() flexibility, btw20:28
*** atiwari has joined #openstack-dev20:28
*** dubsquared has quit IRC20:29
*** nati_ueno has joined #openstack-dev20:29
*** dubsquared has joined #openstack-dev20:29
*** e0ne has joined #openstack-dev20:29
atiwariayoung, I have added my comments on https://review.openstack.org/#/c/37141/ please take a look20:30
*** CaptTofu has quit IRC20:31
atiwaridolphm and  jamielennox, I would appreciate your thoughts on https://review.openstack.org/#/c/37141/ too20:31
*** zul has joined #openstack-dev20:32
*** jmontemayor has quit IRC20:33
*** dubsquared has quit IRC20:34
*** CaptTofu has joined #openstack-dev20:34
*** gordc has joined #openstack-dev20:34
*** spzala has joined #openstack-dev20:35
*** yamahata has quit IRC20:35
dolphmatiwari: p.s. change the extension name to something more unique, OS-ROLES provides no indicates of what it does20:35
dolphmand openstack already supports roles at the core, so it's confusing20:35
*** dvarga has quit IRC20:36
*** lucasagomes has quit IRC20:36
*** jmontemayor has joined #openstack-dev20:36
*** nermina has quit IRC20:38
atiwaridolphm, wondering can it be part of core :), I gave more explanation and use case in the comment20:39
*** giulivo has quit IRC20:39
*** colinmcnamara has joined #openstack-dev20:41
bknudsondolphm: design summit schedule link on https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting gives me a 40320:41
*** e0ne has quit IRC20:43
*** sumansn_ has quit IRC20:43
*** sumanthns has joined #openstack-dev20:43
*** e0ne has joined #openstack-dev20:43
dolphmbknudson: my bad, fixed20:43
*** hartsocks1 has joined #openstack-dev20:44
*** hartsocks1 has quit IRC20:44
bknudsondolphm: the new link works for me20:44
*** hartsocks1 has joined #openstack-dev20:44
dolphmbknudson: i had a direct link to just 'keystone' sessions, but you can sort the main page to the same effect20:44
*** gordc1 has joined #openstack-dev20:45
bknudsonnot very RESTful20:45
*** gordc has quit IRC20:45
*** hartsocks1 has quit IRC20:45
*** hartsocks1 has joined #openstack-dev20:45
*** hartsocks1 has quit IRC20:45
*** dot has quit IRC20:46
*** CaptTofu has quit IRC20:46
*** CaptTofu has joined #openstack-dev20:46
dolphmbknudson: it might be http://bit.ly/1a8V95320:46
*** gyee has joined #openstack-dev20:47
*** jamespage__ has quit IRC20:47
*** e0ne has quit IRC20:48
*** dot has joined #openstack-dev20:48
*** vipul-away is now known as vipul20:50
*** CaptTofu has quit IRC20:51
dolphmatiwari: your use case sounds like a user (or maybe domain) should own roles, not services?20:51
jamielennoxbknudson, dolphm: whilst we're asking for reviews can you both have a look at: https://review.openstack.org/#/c/38414/20:51
jamielennoxatiwari: looking20:51
*** yamahata has joined #openstack-dev20:52
atiwaridolphm, all I wan to say is role should be treated as endpoint templates20:52
dolphmatiwari: ?20:53
*** giulivo has joined #openstack-dev20:53
*** singhs has joined #openstack-dev20:54
atiwaridolphm, as per my use case service should control the roles, same as endpoint templates20:56
*** eglynn has quit IRC20:56
jamielennoxatiwari: is it possible to not use the core API /roles?20:56
*** carl_baldwin has joined #openstack-dev20:56
atiwariand that is why I was  "service_id": "ee057c",  in roles too. exactly same as endpoint template20:57
jamielennoxi would generally like extensions to use there own routes rather than overload the core ones, but i'm not sure if it this case the GET /roles must be used20:57
*** melwitt has joined #openstack-dev20:57
*** dsantos_ has left #openstack-dev20:57
atiwarijamielennox. I am OK with core20:57
*** jtomasek has joined #openstack-dev20:57
atiwari{20:58
atiwari    "endpoint": {20:58
atiwari        "enabled": true,20:58
atiwari        "id": "6fedc0",20:58
atiwari        "interface": "internal",20:58
atiwari        "links": {20:58
jamielennoxatiwari: i'm not20:58
atiwari            "self": "http://identity:35357/v3/endpoints/6fedc0"20:58
atiwari        },20:58
atiwari        "region": "north",20:58
atiwari        "service_id": "ee057c",20:58
atiwari        "url": "http://identity:35357/"20:58
atiwari    }20:58
dolphmatiwari: please don't paste into the channel paste.openstack.org20:58
atiwari}20:58
atiwaridolphm, sorry20:58
atiwarihttp://paste.openstack.org/show/48901/20:59
*** nplanel has quit IRC20:59
*** dot has quit IRC21:00
*** gmurphy has quit IRC21:00
*** emagana has joined #openstack-dev21:00
*** markmcclain has joined #openstack-dev21:00
dolphmjamielennox: one of the previous patchsets was on /OS-ROLES/roles and i asked him to remove the URI prefix since he was only adding attributes to existing resources21:01
*** markmcclain has quit IRC21:01
*** jswarren is now known as jswarren_21:01
atiwarithe endpoint template has certain attributes which is controlled by a service, same way role should also also be managed per service21:01
*** gordc1 has quit IRC21:01
dolphmatiwari: you know we're working to kill endpoint "templates", right?21:01
atiwaridolphm, no21:02
*** markmcclain has joined #openstack-dev21:02
*** giulivo has quit IRC21:02
dolphmatiwari: and "templates" are not controlled by the service at all... they're managed and consumed by keystone21:02
*** yamahata has quit IRC21:03
*** anteaya_ has joined #openstack-dev21:03
atiwaricorrect, they are just managed by keystone but they are defined and make sense for a service21:03
*** yamahata has joined #openstack-dev21:03
*** jtomasek has quit IRC21:03
dolphmatiwari: but the service doesn't do any work in that scenario21:03
*** yeylon__ has quit IRC21:04
atiwariwhen I say service, I mean service team who built the service21:04
*** martyntaylor has joined #openstack-dev21:05
atiwaritell me whois going to use service and endpoint template apis21:05
dolphmatiwari: in other words, a user or a group21:05
atiwariyes, lets call them something different21:05
dolphmatiwari: call what different from what?21:06
*** neoXsys has joined #openstack-dev21:06
*** anteaya has quit IRC21:06
*** mlavalle has quit IRC21:07
*** rha has quit IRC21:08
*** yamahata has quit IRC21:08
*** rha has joined #openstack-dev21:08
*** dsirrine has quit IRC21:08
atiwaridolphm, I am trying to differentiate between user (who uses Nova/Swift as a service) and user who deploy Nova/Swift in the cloud21:08
*** bswartz has quit IRC21:09
notmynamedeployer vs end-user21:09
*** noslzzp has quit IRC21:09
*** martyntaylor has left #openstack-dev21:09
ayoungatiwari, what you are doing is fragmenting the role namespace.  Right now if you create a role named Admin, it is admin everywhere.  If you add in your BP,  then you can have mulitple "Admin" roles, just with different role ids, and each is bound to a different sevice.  But what does thatreally gain you?  Role is not any more naturally scoped to service than it is to anything else21:09
*** mlavalle has joined #openstack-dev21:09
ayoungit is the assignment that needs to be scoped. You have a real problem ,but a flawed solution.21:10
atiwariayoung, did you see my comments21:10
atiwari?21:10
ayoungatiwari, yes.  I did.  And I still stand by my feedback.  I am not looking to block you, but you need to take a different tack21:11
*** eglynn has joined #openstack-dev21:11
*** spzala has quit IRC21:11
gyeeayoung, right now role assignment is a threesome21:11
*** egallen has quit IRC21:11
*** gyee has quit IRC21:12
ayoungatiwari, so, dolphm and I had a discussion earlier about Regions where we discussed that fact that the Id would be much better served as an url safe version of the name.  THat is not really true for Regions, it turns out, but it is true for Roles21:12
ayoungYou don't want two roles named "admin"  with different IDs and different connotations.  The policy is enforcing thing based on the string name, not the id21:13
*** nermina has joined #openstack-dev21:13
ayoungSo  Saying we will have two things called admin, just one scoped to Nova and one scoped to Glance doesn't really buy us anything21:13
atiwariayoung, how do you address21:13
atiwari foo service temporarily want to stop any further role assignment with "Admin" role?21:13
atiwarifoo service want to hide "Admin" role from public consumption?21:13
*** luisg has quit IRC21:14
dolphmatiwari: the "foo" services revises it's policy enforcement mechanism to deny that role21:14
*** utlemming has quit IRC21:14
*** gyee has joined #openstack-dev21:14
atiwariservice means deplorer21:14
*** luisg has joined #openstack-dev21:14
ayoungatiwari, That is not foo's decisions..;ah crud dolph beat me to it21:14
*** tmclaugh[work] has quit IRC21:14
*** ykhodork has joined #openstack-dev21:14
gyeeayoung, are you proposing to make role assignment a foursome?21:14
ayounggyee, yep21:15
ayounggyee, his proposal was doing that already21:15
gyeehow do we answer questions like give me all the roles who have access to Swift?21:15
ayoungjust he was enforcing it at the Role definition level, and that doesn't make sense21:15
*** nplanel has joined #openstack-dev21:15
gyeewithout iteration through all the assignments21:15
*** networkstatic has joined #openstack-dev21:15
ayounggyee, so...that is a different question.  Really, the answer is policy21:15
*** kbrierly has quit IRC21:15
*** giulivo has joined #openstack-dev21:16
dolphmreally role definitions are already owned by remote services, not by keystone -- keystone just owns the mapping21:16
ayounglook at the policy file and you will see what is granted access21:16
atiwaridolphm, in current keystone a service cananot make any change in role def21:16
dolphmif roles weren't a first class resource in keystone, then your problem goes away21:16
atiwarithat does not mean ownership21:16
gyeeand the service would returned as part of token data?21:16
*** enmand has joined #openstack-dev21:16
gyeeservice_id21:17
ayounggyee, so, allowing a role assignement to be scoped to something less than "everything"  makes a lot of sense, but *forcing* it to be scoped to a specific service does not21:17
atiwariwe are not providing management capability on role definition entity21:18
ayoungatiwari, as I said, you have definied a real problem.  I am not debating that.  What I am telling you is that your solution shows an incomplete grasp of the mechanisms at play.21:18
*** jecarey has joined #openstack-dev21:18
gyeeatiwari, they may solve your problem as the roles comes back from token creation/validation have the scope information21:19
ayoungatiwari, but the issue is that policy is a blob.  In order to do anything real, we have to provide an API for understanding what a given policy blob really exposes21:19
atiwariayoung, what will be potential solution in your view?21:19
gyeelike tenand_id, service_id21:19
dolphmatiwari: keystone provides a policy json around role CRUD calls. if the deployer wanted to grant authorization to some user or group to manage roles, then they could do so21:19
*** enmand has quit IRC21:19
gyeeproject_id I mean21:19
*** luisg has quit IRC21:19
*** ykhodork has quit IRC21:21
*** sgordon has quit IRC21:21
atiwaridolphm, you are look at only one issue21:21
atiwariwhat about the "1. The 'foo' service has certain role assignments made with shared global 'Admin' roles the way you are proposing. 2. At certain point of time foo service decided to rename 'Admin' role to 'foo-admin'" 3. They can request IDM team to define a new role with name 'foo-admin' and all further assignment will be made with this role. 4. They can also request IDM team to do data migration on their behalf, so that previous role21:21
atiwariassignments reflect 'foo-admin'."21:21
ayoungatiwari, the simplest step is to allow scoping a role assignment to  a service.  Beyond that, we need to start enforcing that policy.json files are served out of Keystone, and not just shipped with the services the way that they are now.  We need mechanism to query the policy  that can be used to answer the kinds of questions that gyee is proposing.  Keystone doesn't need to perform the ananlysis, that can be done offline, I hti21:21
ayoungnk21:21
atiwarithe manageability aspects21:21
*** ykhodork has joined #openstack-dev21:22
gyeeayoung, atiwari have a valid point, renaing a role name will be PITA to say the least21:22
gyeerenaming21:22
ayounggyee, actually, I think that argument is  a red herring21:22
atiwarigyee, there are some more21:22
atiwari foo service temporarily want to stop any further role assignment with "Admin" role?21:22
atiwarifoo service want to hide "Admin" role from public consumption?21:22
*** enmand has joined #openstack-dev21:23
dolphmatiwari: the service does their own policy enforcement. the service is free to change the name of the role that it accepts. it doesn't need to care what roles are available for assignment in keystone21:23
atiwaridolphm, what about the previous assignments made21:24
gyeeayoung, yeah, the 'auditing' aspect needs some work21:24
*** yamahata has joined #openstack-dev21:24
*** MaxV has joined #openstack-dev21:24
dolphmayoung: on https://review.openstack.org/#/c/38414/ -- what was holding you back from a +2?21:24
dolphmatiwari: those assignments are no longer relevant to your service; your service doesn't need to care21:25
*** networkstatic is now known as networkstatic_Zz21:25
ayounggyee, atiwari I think what you are getting at is "Growing Pains" for a deployment. They started out with a global admin pool, but now they want to winnow the pool down to users that are experts in each of the services.  But that can be done automatically even with role renaming.  You need to identify users  based on criteria in order to decide what role to assign them, and for which service21:25
atiwaridolphm, those assignment do relevent but with different role name21:25
*** gyee has quit IRC21:26
dolphmatiwari: if a single entity is going to own roles in keystone, it makes the most sense for it to be domains, since domains it makes the most sense for domains to own policies (that way, they own both sides of the equation)21:26
ayoungdolphm, just that there were multiple outstanding comments by other reviewers that I thought were worth addressing.  One of those is not a core reviewer21:26
*** vladikr has quit IRC21:26
dolphmayoung: ah, on a previous patchset21:26
*** gyee has joined #openstack-dev21:26
ayoungdolphm, right.  ON 17, and I think they were addresses with 18, but would rather let jamielennox make that decision, and then I'll; back him up21:27
*** READ10 has quit IRC21:27
gyeeman this is unreal, just upgrade ubuntu this morning and my VM died on me 3 times since!21:27
gyeeupgraded21:27
ayoungatiwari, take a step back, and think it through.  I think we can do what you want in a less intrusive manner, and with a wider applicability.21:27
ayoungI have a meeting in 2 minutes.  We can discuss later on tonight or tomorrow if you want21:28
*** enmand has quit IRC21:28
*** dot has joined #openstack-dev21:28
*** MaxV has quit IRC21:28
*** changbl has quit IRC21:28
atiwariayoung, sure21:28
atiwariyou can also put you thoughts in review21:29
ayoungatiwari, thought I did....21:29
*** marun has joined #openstack-dev21:29
jamielennoxayoung: i haven't been watching the channel - did i miss something in a previous review or are you just waiting for others to confirm that their concerns were addressed/21:30
dolphmjamielennox: either, i believe21:30
bknudsonjamielennox: I'm a little confused by the version discovery...21:32
bknudsonso we've got the identity API versions21:32
bknudsonand we've got client API versions21:32
bknudsonso we've got, say, a 3.1 identity API provided by the keystone server21:33
bknudsonbut that doesn't match exactly with the v3 client api?21:33
*** enmand has joined #openstack-dev21:33
bknudsonthe client might only support 3.0 , or might support 3.221:33
bknudsonof the identity api21:33
bknudsonso what version am I supplying to version discovery, is it the client API or the identity API?21:34
dolphmbknudson: if the client supports v3.0, then it should be compatible with a v3.4 service21:34
dolphmand by "should be" i mean "must be"21:34
*** mjbright_ has quit IRC21:34
*** dkranz has quit IRC21:35
*** enmand has quit IRC21:35
bknudsonok, but if the client supports 3.4 then it'll have extra stuff. Is that OK?21:35
bknudsonis that what the user is expecting?21:35
bknudsonclient supports 3.4 but identity service is 3.221:36
dolphmbknudson: to answer your last question, the version you're specifying to the client indicates "hey, as a library user i'm aware of feature X and want to use it, which is only available in >=3.4, so abort if that's not available"21:36
dolphmjamielennox: correct? ^21:36
bknudsonwe don't have that information in the client.21:36
*** dot has quit IRC21:36
bknudsondo we?21:36
dolphmbknudson: (today)21:36
jamielennoxsorry, have a meeting21:36
dolphmbknudson: as we add new minor versioned features to the client, the client needs to be aware of what version of the service it's talking to, so it can hide features that aren't available21:37
bknudsonso that's where I'm confused on the discovery review.21:37
jamielennoxbknudson: we are looking for specific API versions21:37
bknudsondolphm: that seems somewhat reasonable, although if the client is newer the server will just return 404 or 403.21:38
jamielennoxthe expectation wouuld be that if you need eg 3.2 API version then you probably need to have a specific version of the client installed21:38
dolphmbknudson: if the client is newer than the server, the client should realize that and not make the call (produce a client-side exception)21:38
*** vipul is now known as vipul-away21:39
dolphmbknudson: or hide the python api (not load a manager, or whatever)21:39
dolphmi don't have a strong opinion on how the UX in the client happens in that scenario, as long as it's predictable21:39
*** eharney has quit IRC21:40
bknudsondolphm: I don't think that's what jamielennox's change does.21:40
*** vipul-away is now known as vipul21:40
*** yolanda has quit IRC21:41
*** sarob has quit IRC21:41
dolphmbknudson: it doesn't go that far, no21:41
*** sarob has joined #openstack-dev21:41
*** gmurphy has joined #openstack-dev21:41
bknudsonjamielennox: regarding 3.2 API version, the problem is that the keystoneclient lib doesn't even have everything in 3.0 (e.g., trusts was just added)21:42
dolphmi have yet to make it through an entire patchset in this review, but AFAIK this is the first step in that equation -- the client being aware of what version is available on the service-side21:42
bknudsonThe first step of this should probably be an api that returns which versions the server supports.21:43
dolphmbknudson: we already have that... GET /21:43
bknudsondolphm: not a REST API, a python API21:43
dolphmbknudson: that's a private API in this patch, but i like the way you think21:44
dstanekdolphm, bknudson: just for fun i was playing with a simple implementation for explicitly importing _   https://review.openstack.org/#/c/52985/21:45
dolphmdstanek: "We steam a reference to it" ? "steam"?21:45
dolphmsteal?21:45
bknudsondstanek: we're supposed to use lazy=False for the Keystone server, due to some problems in oslo-incubator21:46
*** rongze has joined #openstack-dev21:46
dolphmbknudson: i thought we removed lazy=False21:46
dstanekdolphm: yup steal21:46
*** sarob has quit IRC21:46
bknudsondolphm: the default is False, we remove lazy=True21:46
*** mriedem has quit IRC21:46
dolphmah, my bad21:46
dstanekbknudson: is there already a patch to change that?21:47
*** exed has quit IRC21:47
dolphmdstanek: merged21:47
bknudsondstanek: the problem with importing exceptions.py was because it was incorrectly coupled to some middleware21:47
bknudsondstanek: so the fix is to decouple the middleware from exceptions.21:47
dstanekdolphm: ah, i think keystone.tests.core was missed21:47
bknudsonby moving it to the client.21:48
bknudsonhttps://review.openstack.org/#/c/52702/21:48
dolphmdstanek: https://review.openstack.org/#/c/49285/21:48
dolphmdstanek: yeah it was intentionally skipped21:48
dstanekbknudson: not exactly;  i chose exceptions.py because of the bug report, but many of our tests don't run properly (or at least as you would expect using testr)21:48
*** kbrierly has joined #openstack-dev21:49
bknudsondstanek: which ones? If they fail it's because it's skipping "import keystone.tests" for some reason.21:49
dolphmdstanek: "from keystone.common.gettext import _" <-- does that pass flake8?21:50
dstanekbknudson: yes, that's because a common way to run tests using testr it to do something like 'tox -epy27 -- test_wsgi'21:50
bknudsondstanek: "tox -e py27 test_wsgi" worked for me (TM)21:51
*** MaxV has joined #openstack-dev21:51
dstanekbknudson: but not all of them do :)21:51
dstanekbknudson: i'm not pushing for this change because I don't think enough people would go for it; i was just playing inbetween doing other things21:52
*** rongze has quit IRC21:52
bknudsondstanek: "python -m subunit.run discover --list" outputs the tests like "keystone.tests.test_associate_project_..." , so the switch to testr should have fixed that problem.21:52
*** emagana has quit IRC21:53
*** singhs has quit IRC21:54
*** e0ne has joined #openstack-dev21:54
dstanekbknudson: if you don't specify the filename then you are fine, but the testr docs and other OS projects show examples of running a test module by itself21:55
dstanekbknudson: http://docs.openstack.org/developer/nova/devref/unit_tests.html#running-a-subset-of-tests21:55
dstanekbknudson: we may want to find a way to prevent that and tell the user that our tests can't be run like that21:55
*** nermina has quit IRC21:55
*** galstrom is now known as galstrom_zzz21:56
dstanekbknudson: unless there is a way to tell testr to always import our test package even if not explicitly told21:56
bknudsondstanek: it always does discover to find the matches.21:57
*** kbrierly has quit IRC21:57
bknudsondstanek: can you point me to one that fails? I thought test_wsgi did.21:57
dstanekbknudson: yeah as soon as my current test run finishes21:57
*** luhrs1 has joined #openstack-dev21:58
*** giulivo has quit IRC21:58
*** shardy is now known as shardy_afk21:58
*** yamahata has quit IRC21:58
*** e0ne has quit IRC21:58
*** radix has quit IRC21:59
*** radix has joined #openstack-dev21:59
dstanekdolphm: you around?22:00
*** che-arne has quit IRC22:00
*** che-arne has joined #openstack-dev22:00
*** kbringard has quit IRC22:00
*** Loquacity has quit IRC22:00
*** bpokorny1 has quit IRC22:01
*** datsun180b has quit IRC22:02
*** carl_baldwin has quit IRC22:02
*** luhrs1 has quit IRC22:02
*** kbrierly has joined #openstack-dev22:03
*** xqueralt has joined #openstack-dev22:03
dolphmdstanek: yep22:03
*** nkinder has joined #openstack-dev22:03
dstaneklifeless: have you started looking into 1203728 (number of test cases calculated incorrectly)?22:04
*** eglynn has quit IRC22:04
dstanekdolphm: for the deprecated_in_release decorator22:05
*** prad has quit IRC22:05
*** alop has quit IRC22:05
dstanekdolphm: should i get rid of having two decorators then?  i was thinking 'deprecated' was sort of a building block for other decorators22:05
*** MaxV has quit IRC22:06
*** alop has joined #openstack-dev22:06
*** MaxV has joined #openstack-dev22:06
dolphmdstanek: i saw deprecated as a building block as well, i just don't see it being used by itself22:06
*** dubsquared has joined #openstack-dev22:06
dstanekdolphm: so you just renaming it to _deprecated be good enough for that point?22:07
*** tonix has quit IRC22:07
dolphmdstanek: good enough, yes22:07
dstanekdolphm: i like your idea about being able to specify a release where something was deprecated22:08
dolphmdstanek: but then deprecated_in_release could just be deprecated() :P22:08
*** neelashah has joined #openstack-dev22:09
dstanekdolphm: yeah, i think i just made up other usecases in my mind22:09
dolphmdstanek: that could also control the severity of the warning (very old deprecation warnings could be critical in --debug or something)22:09
lifelessdstanek: not yet, no. Been stupidly busy with TripleO22:09
lifelessdstanek: and I keep forgetting to look at it when I do have time slices22:10
dstaneklifeless: i may start poking at it tonight then; i spent a little time last week and it looked like there was a recursive call to addFailure22:10
*** lbragstad has quit IRC22:10
*** MaxV has quit IRC22:11
*** neoXsys has quit IRC22:11
*** utlemming has joined #openstack-dev22:11
*** anteaya_ has quit IRC22:12
*** galstrom_zzz is now known as galstrom22:13
*** ngoracke has quit IRC22:16
*** thomasem has quit IRC22:16
*** noslzzp has joined #openstack-dev22:17
*** neelashah has quit IRC22:18
*** buzztroll has quit IRC22:18
*** buzztrol_ has joined #openstack-dev22:18
*** senk has joined #openstack-dev22:19
*** bknudson has quit IRC22:20
dolphmdstanek: will a fix need to be applied to keystone for bug 1203728?22:21
uvirtbotLaunchpad bug 1203728 in testrepository "Total number of run test  cases is calculated incorrectly" [Critical,Triaged] https://launchpad.net/bugs/120372822:21
*** atiwari has quit IRC22:21
*** cdub_ has quit IRC22:22
*** xqueralt has quit IRC22:23
*** cdub_ has joined #openstack-dev22:24
*** sarob has joined #openstack-dev22:24
*** alunch has quit IRC22:25
*** dolphm is now known as dolphm_afk22:27
*** CaptTofu has joined #openstack-dev22:28
*** sarob has quit IRC22:29
*** galstrom is now known as galstrom_zzz22:31
*** galstrom_zzz is now known as galstrom22:32
dstanekdolphm_afk: i don't think so22:33
*** markmcclain has quit IRC22:34
*** dims has quit IRC22:38
*** galstrom is now known as galstrom_zzz22:39
*** gmurphy has quit IRC22:41
*** dhellmann is now known as dhellmann-afk22:41
*** tanisdl has quit IRC22:41
*** vkmc has quit IRC22:42
*** nkinder has quit IRC22:42
*** FunnyLookinHat has quit IRC22:42
*** networkstatic_Zz is now known as networkstatic22:43
*** dhellmann-afk is now known as dhellmann22:44
*** dhellmann is now known as dhellmann-afk22:46
*** colinmcnamara has quit IRC22:46
*** joesavak has quit IRC22:47
*** thedodd has quit IRC22:49
*** dstanek has quit IRC22:49
*** blamar has quit IRC22:50
*** rongze has joined #openstack-dev22:51
*** armax has left #openstack-dev22:51
*** yolanda has joined #openstack-dev22:51
*** mkollaro has quit IRC22:52
*** rcleere has quit IRC22:54
*** tanisdl has joined #openstack-dev22:54
*** dims has joined #openstack-dev22:55
*** vuil has joined #openstack-dev22:55
*** neoXsys has joined #openstack-dev22:57
*** asalkeld is now known as asalkeld_lunch22:58
*** rongze has quit IRC22:59
*** rnirmal has quit IRC23:01
*** herndon_ has quit IRC23:02
*** steven-weston has quit IRC23:04
*** pjd2 has joined #openstack-dev23:04
*** yamahata has joined #openstack-dev23:04
*** jmontemayor has quit IRC23:04
*** vuil has quit IRC23:05
*** dubsquared has quit IRC23:06
*** neoXsys has quit IRC23:06
*** vipul is now known as vipul-away23:06
*** dubsquared has joined #openstack-dev23:07
*** colinmcnamara has joined #openstack-dev23:07
*** pjd2 has quit IRC23:08
*** senk has quit IRC23:09
*** alunch has joined #openstack-dev23:11
*** dubsquared has quit IRC23:12
*** romcheg has quit IRC23:13
*** romcheg has joined #openstack-dev23:14
*** mlavalle has left #openstack-dev23:14
*** pjd2 has joined #openstack-dev23:16
*** xga has quit IRC23:16
*** xga_ has quit IRC23:17
*** pjd3 has joined #openstack-dev23:17
*** neoXsys has joined #openstack-dev23:19
*** alunduil has joined #openstack-dev23:20
*** vipul-away is now known as vipul23:20
*** pjd2 has quit IRC23:21
*** Loquacity has joined #openstack-dev23:21
*** changbl has joined #openstack-dev23:22
*** alop has quit IRC23:23
*** utlemming has quit IRC23:23
*** utlemming has joined #openstack-dev23:23
*** utlemming has quit IRC23:24
*** sarob has joined #openstack-dev23:25
*** singhs has joined #openstack-dev23:27
*** stevemar has quit IRC23:28
*** alexpilotti has quit IRC23:29
*** CaptTofu has quit IRC23:29
*** singhs_ has joined #openstack-dev23:29
*** CaptTofu has joined #openstack-dev23:29
*** sarob has quit IRC23:30
*** noslzzp has quit IRC23:30
*** boris-42 has quit IRC23:30
*** singhs has quit IRC23:31
*** singhs_ is now known as singhs23:31
*** senk has joined #openstack-dev23:32
*** markmcclain has joined #openstack-dev23:33
*** sthaha has joined #openstack-dev23:33
*** dot has joined #openstack-dev23:34
*** colinmcnamara has quit IRC23:35
*** spzala has joined #openstack-dev23:35
*** dot has quit IRC23:42
*** bswartz has joined #openstack-dev23:42
*** markmcclain has quit IRC23:43
*** spzala has quit IRC23:44
*** danwent has joined #openstack-dev23:44
*** Alssi has quit IRC23:49
*** hemna is now known as hemnafk23:49
*** jayg is now known as jayg|g0n323:50
*** danwent has quit IRC23:50
*** pjd3 has quit IRC23:50
*** nermina has joined #openstack-dev23:50
*** romcheg has left #openstack-dev23:51
*** Alssi has joined #openstack-dev23:51
*** vipul is now known as vipul-away23:52
*** pjd2 has joined #openstack-dev23:52
*** rongze has joined #openstack-dev23:56
*** pjd2 has quit IRC23:56
*** bknudson has joined #openstack-dev23:56
*** jamespage_ has joined #openstack-dev23:57
*** senk has left #openstack-dev23:59
*** senk has quit IRC23:59

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