Thursday, 2017-03-16

*** edtubill has quit IRC00:51
*** rderose_ has quit IRC01:00
*** edtubill has joined #openstack-meeting-cp01:56
*** gouthamr has quit IRC01:59
*** raj_sing- has joined #openstack-meeting-cp02:02
*** knangia has quit IRC03:11
*** lamt has joined #openstack-meeting-cp03:34
*** raj_sing- has quit IRC03:59
*** knangia has joined #openstack-meeting-cp04:19
*** aunnam has joined #openstack-meeting-cp04:25
*** lamt has quit IRC04:41
*** lamt has joined #openstack-meeting-cp04:48
*** edtubill has quit IRC04:53
*** brault_ has joined #openstack-meeting-cp05:15
*** lamt has quit IRC05:15
*** brault has quit IRC05:17
*** david-lyle_ has joined #openstack-meeting-cp06:26
*** david-lyle has quit IRC06:26
*** david-lyle_ has quit IRC08:58
*** sdague has joined #openstack-meeting-cp10:11
*** MarkBaker has joined #openstack-meeting-cp10:19
*** knangia has quit IRC10:31
*** MarkBaker has quit IRC11:48
*** raj_singh has quit IRC11:49
*** gouthamr has joined #openstack-meeting-cp12:17
*** edtubill has joined #openstack-meeting-cp12:48
*** lamt has joined #openstack-meeting-cp13:21
*** raj_sing- has joined #openstack-meeting-cp13:40
*** lamt has quit IRC14:00
*** jaugustine has joined #openstack-meeting-cp14:22
*** lamt has joined #openstack-meeting-cp14:36
*** scottda has joined #openstack-meeting-cp15:10
*** ayoung has quit IRC15:21
*** MarkBaker has joined #openstack-meeting-cp15:38
*** lamt has quit IRC15:41
*** knangia has joined #openstack-meeting-cp15:44
*** lamt has joined #openstack-meeting-cp15:51
*** david-lyle has joined #openstack-meeting-cp15:52
*** david-lyle_ has joined #openstack-meeting-cp15:55
*** david-lyle has quit IRC15:55
*** david-lyle__ has joined #openstack-meeting-cp15:57
*** david-lyle has joined #openstack-meeting-cp15:59
*** stvnoyes has joined #openstack-meeting-cp15:59
*** david-lyle__ has quit IRC15:59
*** david-lyle_ has quit IRC16:00
*** MarkBaker has quit IRC16:05
*** david-lyle has quit IRC16:05
*** lamt has quit IRC16:10
*** lamt has joined #openstack-meeting-cp16:11
*** steve-noyes has joined #openstack-meeting-cp16:22
*** lamt has quit IRC16:31
*** stvnoyes has quit IRC16:51
*** stvnoyes has joined #openstack-meeting-cp16:53
*** bmace has joined #openstack-meeting-cp16:56
*** stvnoyes has quit IRC16:56
*** mriedem has joined #openstack-meeting-cp16:57
*** stvnoyes has joined #openstack-meeting-cp17:00
ildikov#startmeeting cinder-nova-api-changes17:00
openstackMeeting started Thu Mar 16 17:00:20 2017 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.17:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
*** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)"17:00
openstackThe meeting name has been set to 'cinder_nova_api_changes'17:00
lyarwoodo/17:00
mriedemo/17:00
ildikovDuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis  xyang1 raj_singh lyarwood breitz17:00
jungleboyjo/17:00
johnthetubaguyo/17:01
jgriffitho/17:01
hemna\o17:01
ildikovhi All :)17:01
jungleboyjIn two meetings at the moment.  So, will do what I can.  :-)17:01
ildikovlet's start17:01
ildikovjungleboyj: noted, tnx17:01
ildikovso news on action items17:01
ildikovSwitch to Cinder v3 merged successfully17:02
jungleboyjYay!17:02
ildikov#info Switch to Cinder v3 merged successfully in Nova17:02
ildikov#info Cinder client 2.0.1 is released17:02
mriedemhas g-r been bumped?17:02
ildikov#info global-requirements is bumped to use 2.0.117:02
ildikovmriedem: the patch was on the gate an hour ago, when I checked17:03
mriedemno it hasn't https://github.com/openstack/requirements/blob/master/global-requirements.txt#L22217:03
mriedemoh17:03
mriedemok17:03
ildikovmriedem: so it should land any minute, but will double check after the meeting17:03
ildikovI have the patch up to mark Cinder v2 support deprecated in Nova17:03
ildikovsmall item, does not block anything17:04
ildikovjgriffith has a patch up for version detection: https://review.openstack.org/#/c/444465/17:04
ildikovmriedem: johnthetubaguy: lyarwood: please take a look whether the direction looks good ^^17:04
johnthetubaguynon of these were listed in here: https://etherpad.openstack.org/p/pike-nova-priorities-tracking17:05
mriedemwe don't want the latest17:05
mriedemi'll leave a comment17:05
johnthetubaguyso it was hard to find17:05
johnthetubaguyI added that one17:05
ildikovbasically we need to agree whether we are fine with the highest available microversion or not17:05
ildikovjohnthetubaguy: tnx17:06
mriedemwe do not want the latest17:06
jgriffithmriedem ?17:06
mriedemthe client opts in to the version it knows how to understand17:06
mriedemi'm leaving a comment17:06
ildikovI wonder what can go wrong with the latest mv17:07
ildikovas if it's not high enough we will fall back to the old flow anyhow17:07
mriedemi left a comment17:07
mriedemthe client always opts in to a microversion17:07
mriedemnot the latest17:07
mriedembecause my client side code could know how to deal with a 3.26 response, but not a 3.40 response if the server changes something in 3.4017:08
jgriffithmriedem yeah, that's fine17:08
johnthetubaguyright I was expecting us to use either 3.0 or 3.2717:08
jgriffithmriedem it's 3.2717:08
mriedemjohnthetubaguy: ok, yeah17:08
mriedemright, 3.0 or 3.2717:08
mriedemif at some point we need something higher than 3.27, we deal with that on a case by case basis17:08
jgriffithI'll adjust the patch17:08
ildikovmriedem: fair enough17:08
mriedemthanks17:08
ildikovI think that was the only question to this one17:09
jgriffithmriedem note that that patch doesn't actually "set" any version anyway :)17:09
jungleboyjI commented on the spec that 3.27 is the one you are looking for.17:09
jgriffithit just gives a way to determine what's available17:09
jgriffithThe actual set/use is left for when we add "new" methods17:10
mriedemjgriffith: it creates the cinderclient with that version though17:10
johnthetubaguyyeah, spec is all updated now17:10
mriedemversion = _MAX_AVAILABLE_CINDER_VERSION17:10
mriedemreturn cinder_client.Client(version,17:10
johnthetubaguyso right now I assume we just hit the attribute error in the gate, so we always use v2 or somethhing?17:11
johnthetubaguyI was expecting it to pick 2.27, then have everything break I guess17:11
johnthetubaguy3.27 oops17:11
*** edtubill has quit IRC17:12
jgriffithmriedem johnthetubaguy ok.. so I think the best course is to set to 3.0 and specify requested higher mv if supported in the calls we need/want it explicity17:12
jgriffithmriedem johnthetubaguy agree/disagree?17:12
johnthetubaguyso lets wind forward17:13
jgriffithmriedem johnthetubaguy my point being that we don't want 3.0 - 3.27 for every possible interaction17:13
johnthetubaguyif the code supports both 3.27 and 3.017:13
johnthetubaguywe would check which code path was required, based on the cloud we were pointing at17:13
johnthetubaguythen every call is either 3.0 or 3.2717:13
jgriffithjohnthetubaguy I don't think you want that17:14
johnthetubaguyactually we went through this in the spec17:14
jgriffithok17:14
johnthetubaguyit depends on the BDM17:14
mriedemjgriffith: i assume the plan was to check the global and if it's >=3.27, use new volume_api methods like create_attachment, else fallback to old stuff17:14
johnthetubaguyso yeah, each call needs to opt into the version, ideally after checking if that version is available17:14
jgriffithmriedem that's correct17:14
johnthetubaguymriedem: thats what I am trying to say, and failing17:14
jungleboyjI didn't particularly like that part of the spec, but don't have a better idea there.17:15
mriedemjungleboyj: what's not to like?17:15
jgriffithmriedem my intention was "use 3.0". if 3.27 use new attach and explicitly call3.27 for just those attach/detach methods17:15
mriedemthe client needs to know if it can make a certain request17:15
mriedemjgriffith: but we still need to know if 3.27 is available, right?17:15
jgriffithmriedem and add for additional calls as needed/desired as we go in the future17:15
jungleboyjThe fact that we can't count on all the compute nodes being able to support doing 3.27 and having to check it.17:16
jgriffithok... yes, I think we're on the same page then17:16
mriedemjungleboyj: it's not the computes, it's the cinder api17:16
mriedemjungleboyj: plus, rolling upgrades17:16
jgriffithhaven't we had this debate a couple times already?17:16
jungleboyjmriedem:  Ok.17:16
johnthetubaguyjgriffith: maybe rebase your detach API patch on top, that might clear this up17:16
mriedemwe don't 'count' on everything in the deployment being the latest and greatest when the code runs17:16
jgriffithjohnthetubaguy good idea17:17
mriedemjgriffith: yes, but jungleboyj wasn't around then17:17
jgriffithahh.. history lesson :)17:17
mriedemyeah so we're on the same page i think17:17
mriedemwe can move ahead17:17
* jungleboyj will be quiet.17:17
jungleboyj:-)17:17
johnthetubaguythere is a bit we punted on in the spec17:17
jgriffithjungleboyj nah, better to raise the questions17:17
johnthetubaguymigrating old style BDMs to the new API17:17
jgriffithjohnthetubaguy damn you! :)17:17
mriedemjohnthetubaguy: we said we'd not handle that in pike17:17
johnthetubaguyso right now all old attachments need to use the old API17:17
mriedemat the PTG17:17
jgriffithmriedem correct, and we can easily idenfity those17:18
johnthetubaguywhat I mean is, its per attachment right now for detach17:18
jgriffithso long as our detach is compatible we're safe17:18
johnthetubaguybased on whats in the BDM17:18
mriedemold attachments won't have the attachment_id17:18
mriedemright17:18
*** steve-noyes has left #openstack-meeting-cp17:18
johnthetubaguythe create attachment is where it decides if its a new server, and all the compute are upgraded, that it might use 3.2717:18
mriedemyes17:18
ildikovmriedem: the old detach code tries to get it from Cinder17:19
johnthetubaguythats the last bit of code we will write, also17:19
ildikovmriedem: so for volumes that are not too old we can get attachment_id17:19
mriedemildikov: i'm not sure what you're talking about, i'm not talking about the cinder data model <havana17:19
mriedemi'm talking about bdm.attachment_id in nova17:19
mriedemwhich is >=pike17:20
johnthetubaguyildikov: thats not the point, old BDMs always use the old API, missing connector and all that17:20
mriedemyes17:20
mriedemagree with tubaman17:20
* johnthetubaguy makes tuba noises17:20
ildikovI know, sorry for the side track17:20
jungleboyj*bum bum, bum bum"17:20
johnthetubaguyheh17:20
ildikovjust kinda "funny" that the current detach is trying to get the attachment_id as well17:21
mriedemis there anything new we need to cover?17:21
ildikovanyway, will use the old flow as is, all good17:21
mriedemb/c we talk about this same stuff every week17:21
jgriffithmriedem :)17:21
mriedemseriously this shouldn't be a full hour each week17:21
mriedemwhat's next?17:21
jgriffithmriedem just the discover thing (done) and the attach id changes lyarwood had up in place of my abandoned ones17:22
ildikovmriedem: if it's all in johnthetubaguy's spec and we all agree we don't need to talk about this again :)17:22
lyarwoodthe db/object changes for nova haven't landed yet17:22
johnthetubaguyseems like next step is the BDM uuid17:22
ildikovlyarwood: tnx, just wanted to bring that up17:22
johnthetubaguyright, lyarwood's patches are needed next17:22
mriedemwe're taking out the bdm uuid from the series17:22
lyarwoodjohnthetubaguy: so we are going to drop the uuid changes to speed this up17:22
lyarwoodyeah that's done and posted17:22
mriedemi'll review the attachment_id changes today17:22
mriedemmdbooth already went over them17:22
johnthetubaguyI would also love lots more +1s on my spec, if everyone agrees with what is in there now17:22
mriedemjohnthetubaguy: yes i need to get back on it17:22
mriedemsomeone was bugging me about reviewing a policy docs spec yesterday17:22
johnthetubaguylyarwood: so I am starting at the wrong end of the chain I guess17:23
jgriffithmriedem lyarwood ildikov once lyarwood 's stuff merges let me know and I'll get my detach changes rebased and resubmitted17:23
ildikovis the UUID change something we would need to depend on here at some point or that's independent?17:23
jgriffiththat's all for me :)17:23
johnthetubaguymriedem: yeah, that bloke is a pain17:23
mriedemildikov: independent17:23
lyarwoodildikov: it's independent17:23
ildikovmriedem: lyarwood: cool, tnx17:23
ildikovmriedem: lyarwood: I guess we're still planning with the detach refactor though17:23
lyarwoodjgriffith: ack I will, I'm out for a week from next Thursday so I'd like to get things done by then17:23
johnthetubaguyah, so we start on this one now: https://review.openstack.org/#/c/437597/17:23
ildikovlyarwood: +117:24
lyarwoodat the latest17:24
lyarwoodjohnthetubaguy: yes17:24
mriedemyup i'll look at those today17:24
lyarwoodthanks17:24
johnthetubaguyme to17:25
johnthetubaguyso reivew specs, review bdms, jgriffith to add detach on top of his patch that uses lyarwood's patches to get the bdm uuid17:25
johnthetubaguythat looks like everything for next week?17:25
mriedemjohnthetubaguy: no bdm uuid,17:25
mriedembdm attachment_id17:25
lyarwoodattachment_id17:25
mriedemotherwise yes17:25
johnthetubaguyoops, yes, that17:26
johnthetubaguyto many ids17:26
mriedemplus jgriffith can address comments in the discovery patch and add tests17:26
ildikovjohnthetubaguy: and jgriffith to update the client microversion patch17:26
ildikovmriedem: +117:26
johnthetubaguyyep, thats that last bit17:26
mriedemok, sounds good17:26
mriedemare we done here? :)17:26
johnthetubaguydetach on top of microversion patch, so we know its good17:26
ildikovjohnthetubaguy: when do you think your spec will be ready for wider review?17:26
mriedemildikov: it is already17:26
johnthetubaguyits been ready since the week after the PTG17:26
mriedemit has been i think17:26
ildikovjohnthetubaguy: ok, then I'll move it up on the etherpad :)17:27
jungleboyjLooked pretty good to me.17:27
jungleboyjAt least the important stuff I remembered from the PTG.17:27
johnthetubaguyildikov: its not moved because we (the subteam) haven't all +1ed it17:27
mriedemand we have other stuff going on...17:27
mriedembut beside the point17:27
mriedemanyway17:27
mriedemend meeting?17:28
* jungleboyj gets out his rubber stamp17:28
johnthetubaguycool, I saw comments from lyarwood, jgriffith, jungleboyj and mdbooth recently, they seem mostly on board on the spec now17:28
ildikovjohnthetubaguy: ah ok17:28
johnthetubaguyyup, seems we are done17:28
mriedem...17:28
mriedemend it17:28
ildikovok, if nothing else to discuss thank you all for this short and crisp one17:28
mriedemyay17:28
ildikovwe all have our action points17:28
ildikovsee you all next week!17:28
hemnasweet.17:29
mriedemttyl17:29
ildikov#endmeeting17:29
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:29
jungleboyjThanks!17:29
openstackMeeting ended Thu Mar 16 17:29:07 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:29
openstackMinutes:        http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-03-16-17.00.html17:29
lyarwoodthanks all17:29
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-03-16-17.00.txt17:29
openstackLog:            http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-03-16-17.00.log.html17:29
*** bmace has left #openstack-meeting-cp17:29
*** mriedem has left #openstack-meeting-cp17:30
*** david-lyle has joined #openstack-meeting-cp18:05
*** edtubill has joined #openstack-meeting-cp18:13
*** lamt has joined #openstack-meeting-cp18:27
*** edtubill has quit IRC18:35
*** lamt has quit IRC19:39
*** lamt has joined #openstack-meeting-cp19:46
*** lamt has quit IRC19:46
*** lamt has joined #openstack-meeting-cp19:48
*** rderose has joined #openstack-meeting-cp19:58
robcresswell#startmeeting keystone_horizon20:00
openstackMeeting started Thu Mar 16 20:00:19 2017 UTC and is due to finish in 60 minutes.  The chair is robcresswell. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
*** openstack changes topic to " (Meeting topic: keystone_horizon)"20:00
openstackThe meeting name has been set to 'keystone_horizon'20:00
robcresswellAnyone around/20:01
robcresswell?*20:01
knikollao/20:01
cmurphyo/20:01
david-lyleo/20:01
robcresswell#link https://etherpad.openstack.org/p/keystone-horizon20:02
robcresswellHi everyone20:02
robcresswellSo, updates for the past week20:03
*** r1chardj0n3s has joined #openstack-meeting-cp20:03
robcresswellWe've had a couple of reviews on Horizon patches, but things are moving slowly20:03
robcresswellWe've also started moving away from cookie based sessions with https://review.openstack.org/#/c/444266/20:04
robcresswellI need to update that and figure out why tempest is complaining20:04
*** jaugustine has quit IRC20:04
robcresswellThe patch itself is relatively simple though. That will allow us to default to V3 and start deprecating our V2 auth handling20:04
rderoseo/20:05
robcresswellDid anyone get chance to look at https://review.openstack.org/#/c/339487/ and see if they could recreate it?20:05
robcresswellhttps://bugs.launchpad.net/horizon/+bug/1600195 is the relevant bug report20:05
openstackLaunchpad bug 1600195 in OpenStack Dashboard (Horizon) "Domain admin cannot manage user, group and domain in own domain" [Undecided,In progress] - Assigned to Kenji Ishii (ken-ishii)20:05
r1chardj0n3sI tried, but I failed at setting up a domain admin :-)20:06
robcresswell:D20:07
robcresswellrderose: Any progress on 8.2.6?20:07
rderoserobcresswell: not yet20:08
*** jaugustine has joined #openstack-meeting-cp20:08
robcresswellCool20:09
*** lamt has quit IRC20:09
david-lyler1chardj0n3s, you have to set up domain admin via openstack client20:09
robcresswellI *think* thats everything in progress20:09
david-lylehmm, wait20:09
r1chardj0n3sdavid-lyle: yep, I followed some instructions from somewhere, but failed somehow20:09
david-lylenevermind, that's cloud admin20:09
robcresswellAny other changes anyone would like to highlight?20:09
david-lyledomain admin you should be able to set up in Horizon20:09
*** lamt has joined #openstack-meeting-cp20:11
robcresswellCool, looks like we can end there20:12
robcresswellThanks everyone!20:12
robcresswell#endmeeting20:12
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"20:12
openstackMeeting ended Thu Mar 16 20:12:29 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:12
*** r1chardj0n3s has left #openstack-meeting-cp20:12
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone_horizon/2017/keystone_horizon.2017-03-16-20.00.html20:12
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone_horizon/2017/keystone_horizon.2017-03-16-20.00.txt20:12
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone_horizon/2017/keystone_horizon.2017-03-16-20.00.log.html20:12
*** antwash has joined #openstack-meeting-cp20:31
*** antwash has left #openstack-meeting-cp20:32
*** lamt has quit IRC20:32
*** lamt has joined #openstack-meeting-cp20:34
*** amrith has quit IRC20:42
*** amrith has joined #openstack-meeting-cp20:43
*** gouthamr has quit IRC21:40
*** jaugustine has quit IRC21:57
*** kbyrne has quit IRC23:34
*** kbyrne has joined #openstack-meeting-cp23:38
*** lamt has quit IRC23:41
*** diablo_rojo has quit IRC23:43

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