14:00:07 #startmeeting glance 14:00:08 Meeting started Thu Oct 12 14:00:07 2017 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:12 The meeting name has been set to 'glance' 14:00:15 #topic roll call 14:00:17 o/ 14:00:21 o/ 14:00:25 whats up everyone 14:00:25 o/ 14:00:31 ./ 14:01:08 o/ 14:01:29 good turnout, hello everyone! 14:01:40 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:42 \o 14:02:18 #topic updates 14:02:29 ok, only one update 14:02:40 namely, that the Q-1 milestone is next week 14:03:10 so priorities for the week are to review patches associated with Q-1 bugs and specs 14:03:14 the bug list: 14:03:25 #link https://launchpad.net/glance/+milestone/queens-1 14:03:47 and there are two spec-related patches underway: 14:04:01 #link https://review.openstack.org/#/c/509154/ 14:04:15 #link https://review.openstack.org/#/c/510449/ 14:04:33 first one is the registry deprecation 14:04:39 second one is scrubber refactor 14:05:01 i have a question about the deprecation patch 14:05:10 how to handle a reference to a spec 14:05:25 current patch has a ref to the gerrit review 14:05:40 a link to the spec might be more useful to operators 14:05:41 but 14:05:59 once the patch lands, the spec will be moved from 'approved' to 'implemented' 14:06:19 looks like zuul is having fun time again, so please have a look on the changes even there's gate failure 14:06:20 lp blueprint (adding all links there) 14:07:05 bp has a field for spec as well 14:07:11 nikhil_k i see, that way we can update the link in the lp bp when the spec moves from accepted to implemented 14:07:24 yeah, exactly 14:07:35 yeah, that's better than my thought which i won't even say now 14:07:50 ok, issue resolved 14:07:59 now, one thing that makes that bit etchy is the question how long lp will be there to track those references 14:08:40 good question 14:08:44 the nice thing about gerrit or spec link is that at least those are hosted by OS and will likely stick around 14:08:51 jokke_: You mean as far as migrating to storyboard? 14:08:58 smcginnis: yup 14:09:07 and lp actually going away 14:09:19 jokke_: I believe the plan is to do a full migration, and lp won't actually go away for quite awhile. 14:09:21 which has been in rumour mill for a while 14:09:26 So the linkage should still work. 14:09:46 yeah, but lp is "launchpad.net" not "openstack.org" 14:10:01 so sort-of out of our control 14:10:04 Not sure if they'll try to do any redirect linking, but we should still be able to track things down. 14:10:13 afaik, nova uses lp heavily 14:10:29 agree with rosmaita 14:10:40 but I'd almost propose that we link to the spec in specs.openstack.org and instead moving from approved to implemented we symlink it and once release we just don't include approved to the index 14:11:00 ha! that was my idea i didn't want to say 14:11:04 :) 14:11:29 i think we keep all specs in approved, and the implemented ones beome symlinks in the implemented directory 14:11:39 ++ 14:11:42 easy to do now that the spec-lites are individual files 14:11:58 i have a weird memory .. 14:12:06 so, the downside is that the patch will have a non-existent url 14:12:16 There isn't any confirmation lp is going away right? Or is there 14:12:17 that way the reference in commit message points to actual document, not a place where you might find link to that document 14:12:20 this idea had a throwback a couple cycles back 14:12:59 you mean throwback as in "was rejected" ? 14:13:04 McClymontS: Not that I'm aware of. Just that we plan on using storyboard going forward. 14:13:20 * nikhil_k stops bothering finding the link to the convo :P 14:13:33 rosmaita: yep 14:13:44 McClymontS: smcginnis: There is reasonably backed rumours that LP would be going away 14:13:54 ah okay thanks smcginnis I still think future proof it any way you can 14:14:10 If so, it's going to be a community-wide issue. Nothing I think we should be overly concerned with for now. 14:14:13 that would be enough for me jokke_ 14:14:14 though i think that would be "going away" as in "no longer used", not "going away" as in "cease to exist" 14:14:22 right, migrating away from 14:14:23 people were saying, 'you are proposing linking a doc which doesnt exist yet' 14:14:34 McClymontS: thus, I'd like not to rely on it either ;) 14:14:52 'that's confusing/misleading blah blah..' 14:15:01 * nikhil_k just having fun 14:15:23 yes, but nikhil_k you have a good point that the link can't be tested in the patch 14:15:30 nikhil_k: well the patch pointing to the spec should not land before the spec lands so that _should_ never be the case 14:15:31 i mean, tested out by reviewers 14:15:46 jokke_ ok, i misunderstood 14:15:47 yeah, spec should land first 14:15:59 so, the patch will have a link to 'accepted' 14:16:01 the spec will remain there 14:16:01 but I think the spec.o.o link isn't generated real time 14:16:07 sometimes the gate is stuck etc 14:16:24 but eventually, there will be a symlink to the spec in the 'implemented' directory 14:16:46 i like that 14:16:50 rosmaita: that was my proposal, so that link will always work even if we do not include them in the index page after release 14:17:11 sounds good 14:17:22 everyone clear on what we just decided? 14:17:31 yeah 14:17:33 and symlinking we will never break those references vs. moving it from folder to another 14:17:40 yeah but theres value in restating for the transcript I think rosmaita 14:17:52 ok, here goes: 14:18:26 A code patch that references a spec will contain a reference to the spec at specs.o.o 14:18:26 nikhil_k: the specs not showing up has been just issue very lately when the publish job was broken around zuul v3 migration. Normally the publish job is ran as post merge 14:19:01 ... the spec will reside in the 'approved' directory for the appropriate cycle and project 14:19:47 sounds good 14:19:50 ... the spec will not be physically moved, but will be marked as implemented by there being a symlink from the 'implemented' directory to the 'approved' directory 14:20:05 #agreed A code patch that references a spec will contain a reference to the spec at specs.o.o. The spec will reside in the 'approved' directory for the appropriate cycle and project and symlinked to "implemented" folder afterwards 14:20:21 awesome, nice summary 14:20:32 #undo 14:20:59 #agreed A code patch that references a spec will contain a reference to the spec at specs.o.o. The spec will reside in the 'approved' directory for the appropriate cycle and project and the spec will not be physically moved, but will be marked as implemented by there being a symlink from the 'implemented' directory to the 'approved' directory 14:21:04 there we go 14:21:22 ty, looks good 14:21:48 great 14:22:03 rosmaita: mind actually copy-paste that? I think that did not go to the logs as the bot did not ack the undo 14:22:18 might be restricted to chair 14:22:24 ok, i will try 14:23:28 #agreed A code patch that references a spec will contain a reference to the spec at specs.o.o. The spec will reside in the 'approved' directory for the appropriate cycle and project and the spec will not be physically moved, but will be marked as implemented by there being a symlink from the 'implemented' directory to the 'approved' directory 14:23:34 hmmm 14:23:44 we don;'t get acks for links either, though 14:24:00 in any case, it will be in the log transcipt if not the summary 14:24:02 and I will change the link on that deprecation patch ... good way to retrigger the gate that's needed anyways 14:24:06 agreed dont get acks I think 14:24:07 rosmaita: sure 14:24:16 undo does tho 14:24:33 nikhil_k: I don't think so either but the undo should have, thus I assumed the bot did not take it from me 14:24:50 ok, then the priorities for the week are Q-1 bug patches, and the 2 reviews linked above 14:25:18 jokke_ i guess that's a security feature, otherwise some wiseguy could undo everything in the meeting! 14:25:29 * nikhil_k sneaks out for another mtg 14:25:38 bye nikhil_k 14:25:44 I'll try to push myself to get the copy-from taskflow patch up for review even it does not look like making for the Q-1 target it was planned 14:26:11 yeah, and i still don;'t have a patch up for non-eventlet taskflow 14:26:13 ack 14:26:26 rosmaita: I've seen the bot acking undo for link (they are allowed from any participant) ... 14:26:37 * jokke_ really should look into the meetbot bit more carefully 14:27:14 ok, that's all for updates 14:27:37 #topic Glance Bug for Oslo.policy authorization reques 14:27:53 s/reques/request/ 14:28:00 anyone here to talk about that one? 14:28:03 we have checked it again 14:28:24 #link https://bugs.launchpad.net/glance/+bug/1720354 14:28:25 Launchpad bug 1720354 in oslo.policy "Glance doesn't send correctly authorization request to Oslo policy" [Low,In progress] - Assigned to Doug Hellmann (doug-hellmann) 14:28:39 I wonder what infos people expect to get from us through the dict-like object 14:28:41 we think it is due to the fact that Glance doesn't well construct the request to oslo policy 14:29:03 http://paste.debian.net/989066/ 14:29:38 http_check is an existing feature, just no one has checked it 14:32:35 any comments? 14:32:44 so are we sure we want to "improve" the ImageTarget class so that it can be deepcopied, json dumped, etc. ? 14:33:03 I hope so 14:33:10 This is a bug from one of my users, si I'm also trying to see what they were expecting 14:33:20 Not sure what keys their script would try to access, etc. 14:34:40 from Oslo side, we wait a standard dict object, we have tested Nova ans Swift, they work well 14:36:26 yep 14:36:41 any comments? I should switch to another meeting 14:36:46 so we probably want to be abled to access all the fields from ImageTarget through a dict-like object 14:36:59 yes, this will be perfect 14:37:00 * croelandt is good 14:37:09 I think croelandt got it there 14:37:32 great! 14:37:40 I understand as well now I think 14:37:47 i don't think that will break anything 14:38:05 I agree rosmaita 14:38:11 So what oslo_policy is doing differently with the http_check then that the normal file enforcement works just fine? 14:38:28 that is a good question 14:38:31 I think its about what the endpoint expects 14:38:47 i also hope we have some tests around the scenario abhishekk outlined in comment #2 on the bug 14:39:20 because i think that's the primary use of the ImageTarget 14:39:40 rosmaita: yes we do have 14:39:45 so, croelandt sounds like you want to work on this one? 14:41:39 when we fix this, I'd like to see tests that it addresses all the cases from https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L40-L57 so we don't need to wonder what happened again when someone tries to use one of the other ones we haven't specifically been testing 14:44:32 jokke_ good point 14:45:20 did we scare croelandt away? 14:45:33 we clearly haven't refreshed our policy code for a while ;) 14:45:55 rosmaita: kind of :) 14:46:11 I've already written the paste in the bug report 14:46:26 so I'm going to look at how json.dumps work and see what can be done 14:47:02 ok, cool 14:47:15 i take it you saw doug's comment on the bug? 14:48:54 moving along 14:49:04 yep 14:49:07 #topic open discussion 14:49:28 anyone? 14:49:38 o/ 14:50:41 I just want to flag it here as well. I started to looking into how we migrate oslo_context user -> user_id and tenant -> project_id as they are deprecated and about half of our test output is those deprecation messages 14:50:52 I hit a problem I do not understand: 14:51:10 File "glance/context.py", line 31, in __init__ 14:51:22 super(RequestContext, self).__init__(**kwargs) 14:51:36 TypeError: __init__() got an unexpected keyword argument 'project_id' 14:51:53 any help to make sense out of that would be amazing 14:52:42 will take a look at this one 14:52:52 that trace is printed from anywhere where the tenant was replaced by project_id in the code and our own RequestContext does not handle that originally either 14:53:30 McClymontS: cheers ... I'll give you pointer how to replicate that after the meeting so you have easy place to start with 14:53:57 if required I will trace further during my day time 14:54:02 awesome sounds good, have a feeling I may know whats going on there 14:54:16 McClymontS: nice 14:54:23 I hope you're right 14:54:24 jokke_ do you have a bug for that? 14:54:34 jokke_: oslo_context 2.19.1 is blocked. 14:54:34 rosmaita: nope 14:54:35 just thinking about how we can communicate our findings 14:54:46 jokke_: That's the version you'll need for project_id. 14:54:52 https://github.com/openstack/oslo.context/commit/d78cf592e1e3e7aa0fc99bfdd655e82f5c44dfe3 14:55:04 https://github.com/openstack/requirements/commit/ef35779f4e1a47dca3d113f1c6987a8764956af2 14:55:16 So might just need to wait. 14:55:28 smcginnis: why the deprecation messages are pushing through since 2.6 then? 14:55:35 smcginnis nice, I was suspecting downstream misalignment 14:55:50 jokke_: Poor planning? :) 14:55:59 smcginnis: are you saying that oslo deprecated them with rename without providing migration path? 14:56:16 I bet that is exactly what happened 14:56:20 jokke_: I haven't looked into it enough, but that might be the case. 14:56:46 gr8 ... only 13 releases of that shait in and no way to get around it 14:57:21 dang 14:57:26 well that would certainly explain my frustration trying to fix it ;) 14:57:40 Haha, yep. ;) 14:57:49 looks like smcginnis found the right patches 14:57:52 * jokke_ is glad to bring it on the table 14:58:35 yeah, glad you brought it up, we would have been banging our heads for a while 14:58:46 nice, solid that we located it so quickly nice job smcginnis 14:58:52 thanks a million smcginnis and McClymontS 14:59:05 Hah, no problem. 14:59:17 ok, so looks like we postpone jokke_ 's change until oslo context makes that change available 14:59:28 ok, 30 seconds 14:59:32 anything else? 14:59:36 Im good 14:59:48 thank you all! 14:59:49 yeah, I will never again try to facilitate any oslo deprecations :P 14:59:53 Thanks all 14:59:54 thank you all 14:59:59 ok, thanks everyone! 15:00:03 #endmeeting