14:00:04 #startmeeting glance 14:00:04 Meeting started Thu Mar 23 14:00:04 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:08 The meeting name has been set to 'glance' 14:00:15 #topic roll call 14:00:41 kind of quiet in here this morning 14:00:57 hello dharinic 14:01:10 Good Morning rosmaita 14:01:19 o/ 14:01:35 hi alex 14:01:56 o/ 14:02:08 o/ 14:03:18 ok, guess we can get started 14:03:56 i'm starting with general openstack updates anyway 14:04:02 #topic updates 14:04:21 #topic update - R release naming 14:04:35 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114436.html 14:04:44 that email give you the info about the rules 14:05:17 so if you'd like to be immortalized, you can suggest an R name and maybe make the cut for the big vote 14:05:40 that's all about that 14:05:52 #topic update - quotas action 14:06:11 this is for awareness of what's happening right now 14:06:25 sean dague has proposed a "unified limits" conceptual spec 14:06:38 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114230.html 14:06:42 that email gives some info 14:06:46 key things are: 14:06:56 aiming for 2-week comment cycle so that it will be clear whether this can happen in Pike or not 14:07:06 and, comments close 30 March 14:07:16 here's the actual spec link 14:07:20 #link https://review.openstack.org/#/c/440815/ 14:07:42 i think nikhil is the glancer most interested in this, but i don't seem him around atm 14:08:23 anyway, the quotas work will eventually impact glance, so take a look at the spec if you want to provide input on the ground floor 14:08:36 #topic update - log messages 14:08:53 in case you haven't followed the discussion on the ML, log messages are no longer translated 14:09:14 there's a patch up to remove the _L* from glance code: 14:09:23 #link https://review.openstack.org/447970 14:09:38 so I have to admit, I haven't followed ... is this permanent? 14:09:52 the rationale for removal is that most people google log messages to figure out what they mean 14:10:01 as those translation rules seems to change every second cycle 14:10:07 so keeping them all in english means less fragmentation and better results 14:10:12 jokke__: good point 14:10:20 i believe this is meant to be permanent 14:10:34 I also thought the discussion was still ongoing 14:10:40 but i was wondering whether it would be better to make the _L* no-ops instead of removing 14:11:00 but it would make the coder harder to read 14:11:06 yeah, that has been discussed a lot exactly for that reason and the rationale has always been that the localization people have been super agains that specially around the more dominant languages 14:11:08 though, no harder than it is presently 14:11:31 alex_bash: i thought it had concluded, but maybe not 14:11:48 rosmaita: you mean redefine them ourselves or within i18n? 14:12:00 lets hold off with that patch, please ... I have a look on that discussion and probe for more info if needed 14:12:05 there are refs to the ML in the commit message of that patch 14:12:12 cheers 14:12:13 ok, that's a good idea 14:12:31 #action rosmaita determine actual status of i18n for log messages 14:12:39 I endorse this action 14:12:51 i'll put a note on the patch to that effect 14:13:07 translating logs was always flawed for this reason but let's be sure 14:13:07 alex_bash: i was thinking within glance for the _L* no-ops 14:13:23 i must admit 14:13:35 my reading of the discussion was that it was trending to non-translation 14:13:46 and then i saw the patch and figured it was a done deal 14:13:52 but that was an inference, not a fact 14:13:55 so i will check 14:14:03 and report back next week 14:14:48 ok, jokke__ , make sure you are seated comfortably before the next one 14:14:58 #update - microversioning in glance 14:15:05 oops 14:15:18 #topic update - microversioning in glance 14:15:29 i need to write some macros or something 14:15:30 oh this is quick topic ;) 14:15:41 -2 ... neext 14:15:43 draft API compatibility/stability "guidelines" (actually requirements for asserting the proposed 'assert:supports-api-compatibility' tag 14:15:59 #link https://review.openstack.org/#/c/421846/ 14:16:15 changes will require version changes, and the only acceptable versioning scheme satisfying the guidelines is microversions 14:16:28 so, without microversions 14:16:33 we either don't make changes 14:16:38 or don't assert the tag 14:16:42 so I really love what Graham has been saying on that guideline 14:17:05 stevelle: tell us more, i haven't looked in about a week 14:17:07 I want glance to work toward the tag by simply not changing the API 14:17:23 Graham is suggesting the alternative to microversions is "stop changing stuff" 14:17:37 when an API goes into Supported, no changes as all 14:17:48 rosmaita: so easy, we don't assert the tag 14:17:52 ;) 14:18:07 when it's time to change that resource, you make a new version and he is trying to carve space for experimental apis 14:18:09 I haven't read that stuff yet, but what's a "change" here? 14:18:28 hemanthm: anything that can be seen is a change 14:18:28 stevelle: well, not quite - but we shouild get api's right before saying users can rely on them 14:18:44 change to url, change to resource representation, change to response codes, etc 14:18:49 basically, anything 14:18:59 that you can see through the api 14:19:00 a bug fix too? 14:19:07 yep 14:19:09 mugsie: o/ ... totally agree on that one ;) 14:19:17 only serious security ones will be allowed 14:19:35 so basically, all our ocata changes are impossible under the guideline 14:19:37 I agree mugsie, which is why I'm enthusiastic about that line of discussion on the guideline 14:19:43 yeah, I'm just happy not asserting that tag 14:19:51 for now 14:19:57 yeah - I hope people come on board to back me up :) 14:19:58 lets say next 6 or 7 cycles 14:20:04 comments welcome 14:20:25 my hope is that Glance can bundle intended API changes for 2y at a time and just increment major versions 14:20:44 i had a bunch of early comments, but have really nothing more to say 14:21:22 just want this to be a point of information for everyone to cogitate upon 14:21:37 and as mugsie points out, leave comments if you have an opinion 14:22:03 any other comments about that? 14:22:29 I do but I don't want to derail the meeting :) 14:22:43 maybe we can discuss in #openstack-glance after this 14:22:45 ok, hold 'em for open discussion 14:22:52 or what stevelle said 14:22:57 ok, moving along, last update 14:23:09 #topic update - farewell to Ian 14:23:23 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114462.html 14:23:23 =( 14:23:25 -2 14:23:35 sigmavirus is moving on 14:23:39 :( 14:23:49 yes, i am bummed, too 14:23:53 * stevelle is now an abandoned change set 14:24:28 =/ 14:24:50 I'm not thrilled either, but c'est la vie 14:25:11 All the very best to you! 14:25:16 sigmavirus: thank you for all your service to glance, you will be missed a lot! 14:25:22 Glance was so much fun and lively with sigmavirus/roosevirus around. 14:25:28 fair speed and don't take any wooden nickels, sigmavirus 14:26:04 and as ttx pointed out, openstack expects to expand to encompass the entire universe of software, so we should meet again 14:26:18 Thank you for all the motivation sigmavirus. All the best. :) 14:26:21 sigmavirus: I was afraid this will come 14:26:22 rosmaita++ 14:26:37 but, the sad departure of sigmavirus does leave us with some holes to fill 14:26:48 #topic volunteers and responsibilities 14:26:54 y'all better step up... or else... my Rooseghost will haunt y'all 14:27:01 * stevelle hides 14:27:03 #link https://etherpad.openstack.org/p/glance-pike-volunteers 14:27:06 sigmavirus: Thanks a million and keep in touch! If we ever land to same area, lets get drunk as ducks. ;) 14:27:29 i didn't realize ducks were big drinkers 14:27:34 me neither 14:27:46 rosmaita: they are not, thus they get very drunk ;) 14:27:47 * hemanthm was about to google drunk ducks 14:27:59 jokke__: thanks, that explains it 14:28:08 ok, please open that etherpad 14:28:26 i've asked hemanthm to become release czar 14:28:43 ian's departure also leaves an opening on glance coresec 14:28:53 for which i propose stevelle 14:29:21 i have a question about stable branch liason 14:29:48 which i think jokke__ is answering "live" on the etherpad 14:30:04 ok, great 14:30:27 i like having different ptl - release czar - and stable branch people 14:30:43 i think it keeps a healthy balance of opinions on impacting issues 14:30:45 ok, cool 14:31:04 alex_bash is doing documentation 14:31:20 * jokke__ is still also part of the glance release team, and happy to keep it so and help out 14:31:25 asettle has enhanced the expections of the docs liason, so he'll be busy 14:31:38 I've been following the OS release side pretty closely anyways 14:32:06 jokke__: great, you will provide some continuity 14:32:35 key unfilled slots are: infra, which i am filling in for now, but i'm open to let someone else take over 14:33:05 key thing about infra CPL is that the infra team wants a +1 from infra CPL before they approve changes 14:33:13 so that slot *must* be filled 14:33:20 but i'll do it for now 14:33:30 for that, I'm not willing to step in :P 14:33:33 i was thinking of volunteering dharinic for oslo CPL 14:33:45 Voluntold :) 14:33:48 since she has some commits into oslo 14:33:50 I would love that. :) 14:34:09 dharinic: that's great if you are serious, i don't want to make you do it 14:34:27 rosmaita: you already did :) 14:34:35 well, i meant it to be a hint 14:34:43 i used the wrong font, i guess 14:34:54 I was serious. 14:34:55 it all looks alike in irc! 14:35:07 dharinic: great, happy to have you do that 14:35:14 I have contributed to oslo and would love to do this. 14:35:27 Thanks for volunteering me rosmaita 14:35:28 everyone: please review the expectations on https://wiki.openstack.org/wiki/CrossProjectLiaisons 14:35:33 #link https://wiki.openstack.org/wiki/CrossProjectLiaisons 14:35:58 OK, a key unfilled CPL is QA 14:36:14 but we can look for someone later on that 14:37:00 hehe 14:37:15 my thought is that once everyone is confirmed, i will move this etherpad into the priorities for pike page in teh specs repo, which i'll put up after the spec freeze 14:37:28 which reminds me, the spec proposal freeze is soon 14:37:33 that will be fun position to take on ... it's shame sigmavirus is leaving ... would love to have his character dealing with them ;) 14:37:41 :) 14:38:13 jokke__: I think you're a good character fit too :P 14:38:24 #info spec proposal freeze - patch with spec must be up before 13:59 UTC on Thursday 30 March 2017 14:38:39 ok, moving on 14:38:44 hemanthm: _if_ I would understand anything about testing :P 14:38:55 #topic "owned" topics reports 14:39:12 ok, dharinic has been active on removing deprecated options 14:39:22 hemanthm has a patch up for E-m-C docs 14:39:24 here is my update 14:39:26 The important opt: “show_multiple_locations”. 
We would be removing it in favor of RBAC (Role Based Access Control) from policy.json. nikhil, rosmaita and I had some discussions on few combinations for the property rules and nikhil will be putting up a spec for it. 14:39:35 I have a patch up with code changes for one such combination for review and opinions (https://review.openstack.org/#/c/444540/) 14:39:59 thank you 14:40:06 Another set of opts was the swift store auth opts like “swift_store_auth_address”, “swift_store_user” etc. There were to be removed in favor of reading related information from the swift store config file. This requires considerable code change with respect to swift store in multi-tenant mode (we are currently not allowing a swift conf file to be given if multi-tenant mode is on). I am working on this and will 14:40:40 dharinic: just a reminder ... do we have the policy options in place for the multiple locations yet? 14:40:41 I assume we do not need a spec/lite-spec for this ^ 14:40:59 nikhil said he'd have a patch up soon for the removal spec, not sure if it's there yet, though i did see an early draft on an etherpad 14:41:04 jokke__: Currently they are open. 14:41:08 dharinic: for the swift-opts, you mean? 14:41:21 jokke__: yes, we have policies, but the default is "" 14:41:31 rosmaita: yeah, i meant spec/lite-sepc fopr swift auth opts. 14:41:37 it's a problem, as you'll see from nikhil 's spec 14:41:47 for the show_multiple_locations, nikhil will be putting up a patch soon 14:41:58 dharinic: were they the ones i said do release notes first? 14:42:07 (i am not fully caffeinated this morning) 14:42:10 ok ... so we need to document the change well in release notes and make sure we do not open that up by anyone upgrading 14:42:24 jokke__: exactly! 14:42:32 yes rosmaita. I have the release note: https://review.openstack.org/#/c/448316/ 14:42:38 dharinic: ty 14:42:54 so, instead of a lite spec, i asked dharinic to put up the release note 14:43:09 we can review it to see what hte impact looks like 14:43:24 hopefully, won;t need a spec, but i haven't looked yet 14:43:38 #action everyone review https://review.openstack.org/#/c/448316/ 14:43:43 please feel free to help me edit the release note for the swift store auth opts. Wordings are not great.. Want to make sure things are conveyed correctly. 14:43:44 #link https://review.openstack.org/#/c/448316/ 14:43:55 ok, thanks 14:44:03 jokke__: i owe you reviews on your patches 14:44:22 i intend to go offline and do nothing but that this afternoon 14:44:32 go to get you unblocked 14:44:32 And the last opt which i also started work on: https://review.openstack.org/#/c/447172/ 14:44:54 ok, thanks to all the "owners" for keeping things moving! 14:45:06 rosmaita: cheers ... there is some gate failures still down in that chain I haven't been able to figure out ... any help would be great 14:45:09 next topic is a fun one, show and tell 14:45:22 #topic docs update -- discuss for 5 minutes and then we will vote 14:45:37 Shinya Kawabata has a POC patch up for improving one of our docs pages, which right now is really hard to read because of the way the options and there descriptions are all jammed in together 14:45:51 he put together a POC giving us 2 options 14:46:05 so please opent the next link in your browser: 14:46:16 #link http://docs-draft.openstack.org/80/423880/6/check/gate-glance-docs-ubuntu-xenial/628a2af//doc/build/html/configuring.html 14:46:31 options: headings ("Configuring multiple swift accounts/stores") vs. definition list ("Configuring the RBD storage backend") 14:46:33 and this patch is a rework before the lift and shift of this section to the proper place in openstack-manuals, right? 14:46:43 correct 14:46:54 this is a readability issue on this page 14:47:08 so, if you open that page 14:47:17 I like the latter 14:47:21 look at the OTC in the left bar 14:47:28 i mean the TOC 14:47:32 that readability issue will be fixed by `git rm` :) 14:48:01 not a choice atm, though 14:48:24 +1 #2 14:48:33 ok, so the problem is that the options have bullets and it's hard to see what description goes with what option 14:48:49 so the http://docs-draft.openstack.org/80/423880/6/check/gate-glance-docs-ubuntu-xenial/628a2af//doc/build/html/configuring.html#configuring-multiple-swift-accounts-stores 14:48:58 makes each option a heading 14:49:05 pro: it also shows up in the TOC 14:49:20 con: it's going to fill up the TOC when all these are headings 14:49:26 I prefer the "multiple swift " formatting but I would love to see the option titles bolded or bumped in size one step 14:49:27 but, it does make stuff easy to find 14:49:51 rosmaita: please no :( 14:50:02 ok, other option is like the RBD 14:50:07 a simple definition list 14:50:10 that toc becomes totally unusable if we make every option being heading and crapping it out 14:50:15 http://docs-draft.openstack.org/80/423880/6/check/gate-glance-docs-ubuntu-xenial/628a2af//doc/build/html/configuring.html#configuring-the-rbd-storage-backend 14:50:22 jokke__: that's my worry too 14:50:28 there should be a way to limit the depth of the toc 14:50:31 Yes, TOC won't be TOC any more with all the noise 14:50:48 stevelle: there is, we can keep stuff out of the toc 14:51:01 if we can exclude those headings from toc that makes that formatting work 14:51:10 don't have control over the size without hacking the styles, though 14:51:13 it's already long as it is and if you're looking just for specific option and it's documentation you can always use search on that page 14:51:36 everyone ready to vote? 14:51:43 aye 14:51:46 its the HRs that help for me, we could add HRs without the use of headings too 14:52:03 stevelle: ++ 14:52:11 hmmm ... i tend to not like HRs 14:52:20 i prefer the indentation like the RBD stuff 14:52:33 anyway, that's why we can vote and just go with the majority 14:52:54 rosmaita: that is more pythonic tbh 14:53:04 believe it or not this is my first vote, so let 14:53:09 's see what happens 14:53:20 but the question is which one is more convenient for the non-developer reader 14:53:37 so many questions, jokke__ 14:53:47 #startvote (how to markup the config page) ? headings, definition-list 14:53:48 Begin voting on: (how to markup the config page) ? Valid vote options are headings, definition-list. 14:53:50 Vote using '#vote OPTION'. Only your last vote counts. 14:53:59 stevelle: information is key to right decisions 14:53:59 #vote definition-list 14:54:11 #vote definition-list 14:54:15 #vote definition-list 14:54:42
14:54:47 #vote definition-list 14:54:59 #vote definition-list 14:55:07 * stevelle is swayed 14:55:18 anyone else? 14:55:30 alex_bash: mentioned #2 earlier 14:55:42 alex_bash: ?? 14:55:58 option 2 has already carried, my vote is meaningless 14:56:01 I demand a recount 14:56:09 no vote is meaningless! 14:56:14 some just have less meaning than others 14:56:18 so that I can vote first 14:56:21 alex_bash: get your disagreement recorded if you have one so you can bitch about the "wrong" decision later ;) 14:56:26 alex_bash: you're just reading the exit polls 14:56:33 #vote definition-list 14:56:36 ok 14:56:40 #endvote 14:56:41 Voted on "(how to markup the config page) ?" Results are 14:56:42 definition-list (6): jokke__, dharinic, stevelle, alex_bash, hemanthm, rosmaita 14:56:59 and it appears to be stuck 14:57:12 anyway, it's a landslide for definition-list 14:57:17 ok, next topic 14:57:27 be quick ... we have 3 left 14:57:34 3 min I mean 14:57:36 #topic technical debt - time bomb 14:57:45 #link https://review.openstack.org/#/c/419074/ 14:57:51 we merged that last week, and 14:58:03 tick, tick, boom: https://review.openstack.org/#/c/448653/ 14:58:14 just a point of awareness 14:58:26 #topic - looking for owners 14:58:39 i'm going to solicit for these on the ML 14:58:51 both require some expertise we don't currently have, anyway 14:59:01 #topic open discussion 14:59:08 50 seconds! 14:59:16 shameless own patch plug: https://review.openstack.org/#/c/436257/ & https://review.openstack.org/#/c/436258/ were +A, but had to rebase because of the time bomb 14:59:30 so close 14:59:33 more talk of api stability and other topics in glance channel 14:59:48 Thanks everyone! 15:00:01 thanks! 15:00:04 #endmeeting