15:00:29 <bnemec> #startmeeting oslo 15:00:31 <openstack> Meeting started Mon Mar 19 15:00:29 2018 UTC and is due to finish in 60 minutes. The chair is bnemec. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:34 <openstack> The meeting name has been set to 'oslo' 15:00:39 <bnemec> courtesy ping for amotoki, amrith, bknudson, bnemec, crushil, dansmith, dhellmann 15:00:39 <bnemec> courtesy ping for dims, dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb 15:00:39 <bnemec> courtesy ping for GheRivero, haypo, jd__, jecarey, johnsom, jungleboyj, kgiusti 15:00:39 <bnemec> courtesy ping for kragniz, lhx_, lifeless, lxsli, Nakato, ozamiatin, raildo 15:00:39 <bnemec> courtesy ping for rbradfor, redrobot, rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak 15:00:41 <bnemec> courtesy ping for stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zxy 15:00:43 <bnemec> courtesy ping for zzzeek 15:00:47 <e0ne> hi 15:00:59 <crushil> \o 15:01:04 <namnh> ]o 15:01:08 <namnh> \o 15:01:11 <daidv> o/ 15:01:17 <kgiusti> o/ 15:01:20 <ansmith> o/ 15:02:42 <jungleboyj> o/ 15:03:02 <bnemec> #topic Red flags for/from liaisons 15:03:17 <bnemec> We had an issue with the latest oslo.db release. 15:03:19 <bnemec> #link https://bugs.launchpad.net/oslo.db/+bug/1756352 15:03:21 <openstack> Launchpad bug 1756352 in oslo.db "removal of testresources from setup.cfg has broken this dependency for oslo.db 4.34" [Undecided,Fix released] - Assigned to Mike Bayer (zzzeek) 15:03:32 <zzzeek> it's going well ! 15:03:41 <bnemec> It affected a number of projects that consumed the oslo.db test fixtures. 15:03:57 <bnemec> Yeah, it should be fixed now. The new release with the fix was approved. 15:04:03 <zzzeek> yep 15:04:15 <jungleboyj> I addressed the config concern from last week. 15:04:30 <bnemec> jungleboyj: Yeah, I saw that. Thanks! 15:04:40 <jungleboyj> bnemec: No problem. 15:05:01 <bnemec> So a few issues this week, but I think they've all been addressed. 15:05:05 <bnemec> Anything else? 15:06:25 <bnemec> #topic Releases for Rocky 15:06:38 <bnemec> Initial releases for anything with changes are done. 15:06:40 <bnemec> #link https://review.openstack.org/#/c/552943/ 15:07:12 <bnemec> Then the followup oslo.db release, as mentioned earlier. 15:07:37 <bnemec> I held off on releasing oslo.config for now pending dhellmann's patch series, which we'll discuss in the topics. 15:07:54 <bnemec> Once that finishes merging I'll go ahead with that release. 15:08:28 <bnemec> There was also a request to release sphinx-feature-classification. 15:08:53 <bnemec> It's a 0.1.0 so we're not committing to anything forever and always yet, but I thought I'd mention it in case anyone has concerns. 15:09:03 <bnemec> If not I'll ack the request today. 15:09:56 <bnemec> That should be it for releases. 15:10:07 <bnemec> #topic Action items from last meeting 15:10:31 <bnemec> Looks like everything was done. 15:10:41 <jungleboyj> Woot woot 15:10:51 <bnemec> I got up to speed on releases, scheduled the onboarding session, and lbragstad sent the email about oslo.limit. 15:11:20 <bnemec> Nothing more on that topic then. 15:11:30 <bnemec> #topic There are 2 more changes in the series of oslo.config changes to let an app detect whether a user has changed a config value (dhellmann) 15:11:38 <bnemec> #link https://review.openstack.org/#/c/537400/ 15:11:44 <bnemec> #link https://review.openstack.org/#/c/537401/ 15:11:54 <bnemec> I believe I've +2'd both already. 15:12:43 <bnemec> Anyone with core on oslo.config please take a look. Those are the patches I was waiting the Rocky oslo.config release on, since that series has partially merged already. 15:13:52 <bnemec> #topic oslo.limit addition followup 15:14:06 <bnemec> As noted, lbragstad sent an email and created a spec review for this. 15:14:17 * lbragstad lingers 15:14:25 <bnemec> #link https://review.openstack.org/552907 15:14:44 <bnemec> Seems like there is consensus that we want to do this. 15:15:06 <lbragstad> wxy mentioned he wants to contribute - should i respin the patch to add him to the list of contributors? 15:15:17 <lbragstad> (it'll clear all the +2s) 15:15:24 <lbragstad> which is why i was hesitant 15:15:26 <bnemec> lbragstad: Sure, for an addition like that we don't need to wait for everyone to vote again. 15:15:34 <lbragstad> ack 15:15:59 <bnemec> If you want to push a new PS I can go ahead and merge it. I don't anticipate any further feedback beyond what you've already gotten on the ML and spec. 15:17:04 <openstackgerrit> Lance Bragstad proposed openstack/oslo-specs master: Propose specification for oslo.limit library https://review.openstack.org/552907 15:17:06 <lbragstad> ^ done 15:17:09 <bnemec> So if anyone has strong objections to the new oslo.limit library contact me ASAP. 15:17:16 <bnemec> Otherwise I'll plan to merge that today. 15:17:20 <lbragstad> sweet 15:17:38 <lbragstad> i appreciate all the help with the process 15:18:01 <lbragstad> i assume once that is done, i can move forward with the whole project creation bits and getting the repository created 15:18:06 <bnemec> I'm excited to finally have common quota code for OpenStack. :-) 15:18:17 <lbragstad> hah you and me both bnemec 15:18:32 <bnemec> Yeah, I've actually got a todo item for myself to follow up on whether our new library process needs some updating. 15:18:54 <bnemec> AFAIK, the only place we document it is the graduation wiki page, which isn't entirely relevant now that incubator is gone. 15:18:58 <openstackgerrit> Merged openstack/oslo.log master: Increase sleep time in testsuite to make it more robust https://review.openstack.org/554180 15:19:13 <lbragstad> sure - i did notice that 15:19:19 <lbragstad> as i was reading the doc 15:19:24 <bnemec> So unless there is a document I don't know about we need to make some updates here. 15:20:02 <bnemec> This is probably a good opportunity to clear some of the graduation cruft. 15:20:31 <bnemec> So I guess I have a couple of followup items from this. 15:20:36 <bnemec> #action bnemec to approve oslo.limit spec 15:20:52 <bnemec> #action bnemec to investigate/update new library process docs 15:21:58 <bnemec> #topic Configuration change handling over releases (namnh) 15:22:07 <bnemec> I'm afraid I haven't revisited this recently. 15:22:15 <namnh> :) 15:22:20 <bnemec> namnh: The floor is yours 15:22:30 <bnemec> #link https://review.openstack.org/#/c/520043 15:22:36 <bnemec> #link https://review.openstack.org/#/c/526314 15:22:56 <namnh> yes, I and daidv are doing this feature 15:23:27 <namnh> could you please review the spec and coding for me. 15:24:42 <bnemec> Okay, so the main thing at this point is just reviews? 15:25:51 <namnh> yead, and hope you can give us some advices because we have a problem with a option called "transport_url" 15:26:25 <bnemec> I think at the PTG we agreed that the initial version of this tooling might not handle complex deprecations like transport_url. 15:26:36 <namnh> basically, the feature can update from old-config to new-config. 15:26:40 <namnh> oh, really? 15:26:46 <bnemec> Basically we would raise a warning when we hit something like that and tell the user they need to handle it manually. 15:26:49 <namnh> i did not join the PTG 15:27:19 <bnemec> As a followup improvement, we might be able to provide some sort of templating feature or in-project hooks to handle complex migrations. 15:28:07 <bnemec> But in the interest of getting to a usable tool quickly, we decided to focus on the simpler ones that will cover 95% of the deprecated opt cases first. 15:28:40 <bnemec> Basically create the tool, prove that it is useful and works, then iterate on it to handle the harder stuff. 15:29:04 <bnemec> Does that work for you? 15:29:41 <namnh> yead, as i wrote the spec, we have four cases which need to solve. For now, the tool can solve 3 cases. 15:30:00 <namnh> yes, it does 15:30:06 <bnemec> For the initial version of the tool that might be enough. 15:30:43 <bnemec> I did mention this in my (long) PTG summary email. 15:30:45 <bnemec> #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/128055.html 15:30:54 <bnemec> Under the "automatic configuration migration on upgrade" heading. 15:30:57 <namnh> thanks, 15:31:12 <bnemec> I'll try to leave some further comments on the spec. 15:31:16 <namnh> here is a patch set, I tried testing with cinder: https://review.openstack.org/#/c/549672/ 15:31:35 <namnh> bnemec: thanks in advange. 15:32:26 <bnemec> #action review the config migration spec: https://review.openstack.org/#/c/520043/ 15:32:39 <namnh> great :) 15:32:53 <daidv> Nice, so we will start with a simple tool first and solve the transport_url and dynamic section case after 15:33:04 <bnemec> Exactly 15:33:17 <bnemec> It was kind of a theme of the PTG for Oslo. 15:33:26 <namnh> :)) 15:33:57 <bnemec> Write a simpler version of a tool that handles most of the cases, and then solve the harder ones later. 15:34:00 <namnh> i will update a doc how to setup an environment for testing 15:34:17 <bnemec> That would be helpful, thanks. 15:34:54 <bnemec> #action namnh to update config migration testing doc 15:35:37 <bnemec> Okay, anything else on that topic? 15:36:08 <namnh> ok, it is enough for me 15:36:23 <bnemec> Cool, moving on then. 15:36:29 <bnemec> #topic MultiConfigParser removal 15:36:47 <bnemec> This came up when I was reviewing dhellmann's oslo.config changes. 15:37:04 <bnemec> They affected MultiConfigParser, but it's a deprecated class that was supposed to have been removed several releases ago. 15:37:25 <bnemec> I took a look at what it would take to remove it, and found only two projects still using it in OpenStack. 15:37:36 <dhellmann> it looks like networking-cisco still uses it :-( 15:37:39 <dhellmann> oh, which is the other? 15:37:50 <bnemec> The other I already fixed. 15:37:54 <dhellmann> ah :-) 15:38:03 <bnemec> They had deprecated the feature that was using it and it was marked for removal in Pike. 15:38:37 * dhellmann doesn't even remember what MultiConfigParser does 15:38:56 <bnemec> The thing I'm struggling with is that the replacement functionality in the docstring is all private to oslo.config. 15:39:01 <bnemec> https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2017 15:39:32 <bnemec> So it's not really suitable for external consumers. :-/ 15:39:50 <dhellmann> is that saying the class reads multiple config files? or that it handles options with multiple values? 15:39:55 <dhellmann> because I think ConfigOpts does both of those now 15:40:08 <dhellmann> I think they can just replace their use of this class with ConfigOpts? 15:40:34 <bnemec> Possibly? I'm also not terribly familiar with this which is why I added it to the agenda. :-) 15:41:33 <dhellmann> yeah, I'm not either 15:42:53 <dhellmann> ah, they're using the parser but not ConfigOpts 15:43:03 <dhellmann> so they aren't registering options, but they're using the same code to parse a bunch of files 15:43:58 <dhellmann> they could probably just use the built-in module configparser 15:44:09 <bnemec> Yeah, and the patch related to http://git.openstack.org/cgit/openstack/networking-cisco/tree/releasenotes/notes/elim_MultiConfigParser_fr_nexus-6a50c543949d1ca4.yaml was quite extensive. 15:44:25 <bnemec> I'm _hoping_ there's a simpler way for the other two uses in that project. 15:45:11 <dhellmann> well, MultiConfigParser doesn't use any private implementation details, so worst case we could just move that class 15:45:53 <bnemec> Ah, that's a thought. 15:46:08 <dhellmann> looking at how they're using it, that might be "best case" rather than "worst" 15:46:34 <bnemec> Yeah, that might be easiest for everyone. 15:46:55 <bnemec> Obviously that code isn't changing much. 15:47:06 <dhellmann> and if they end up not wanting it, they know best what that code is doing and we can work with them to figure out how to do it using the classes we do support 15:47:23 <dhellmann> was this marked for removal because we didn't want anyone to use it? 15:47:30 <dhellmann> or because we were simplifying the config library api? 15:47:54 <bnemec> I have no idea. It's been deprecated for years. 15:48:28 <dhellmann> too bad we didn't leave a note about the reason :-/ 15:50:00 <dhellmann> well, I think the simplest thing to do is going to be to propose a patch adding that class to the networking-cisco repo 15:50:12 <bnemec> Sounds like the functionality was moved into the _Namespace class, which made the separate parser redundant. 15:50:13 <bnemec> https://github.com/openstack/oslo.config/commit/c663acebc697e92f086684b2ee87546fba57cb7d 15:50:26 <bnemec> Yeah, that sounds good 15:50:32 <dhellmann> aha 15:50:41 <dhellmann> this stuff is likely to be refactored again with the driver work 15:50:48 <bnemec> #action move MultiConfigParser to networking-cisco 15:51:14 <bnemec> Yeah, with all the config work scheduled I figured it would be good to get rid of it now so we don't end up duplicating work. 15:51:53 <dhellmann> ++ 15:52:16 <dhellmann> are you going to do that? or are you looking for a volunteer? 15:52:42 <bnemec> I can do it, although if anyone else has a burning desire to I won't stop them. :-) 15:53:04 <bnemec> Hopefully moving the class won't be too much work though. 15:53:30 <dhellmann> yeah, it should be pretty straightforward to make a new module to hold it 15:55:06 <bnemec> Okay, we can come back to this next week if it turns out to be harder than we think. 15:55:23 <bnemec> #topic Open Discussion 15:55:33 <bnemec> That was it for the agenda. Anything else in the last 5 minutes? 15:56:10 <dhellmann> I have that requirements sync work coming up soon 15:56:34 <dhellmann> let me find that email link 15:56:46 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html 15:56:51 <bnemec> Yeah, I did read that whole thing. I think there were a couple more replies since then though that I haven't had a chance to look at. 15:57:08 <dhellmann> I just want to make sure that folks are aware, since it will have an effect on oslo 15:57:33 <dhellmann> I'm going to give the requirements team another day or two to respond before I start writing any patches 15:57:53 <bnemec> It should be mostly good for Oslo though, right? 15:57:58 <dhellmann> oh, yes, in a good way 15:58:06 <dhellmann> fewer releases just for requirements updates 15:58:10 <bnemec> Projects that want to consume a new Oslo feature don't have to wait for a g-r minimum bump. 15:58:16 <dhellmann> and that, too 15:58:27 <dhellmann> they may still have to wait for the constraint update 15:58:42 <dhellmann> but in general I expect it to make things go more smoothly 15:58:46 <bnemec> Yeah, that's true. 15:59:32 <bnemec> It sounds good to me, but my experience with requirements stuff has been "here be dragons" :-) 16:00:04 <dhellmann> that's pretty true, although the constraints feature in pip is a dragon slayer 16:00:28 <bnemec> Yeah, it has been a lot better since we started using that. 16:01:20 <bnemec> Okay, sounds good and we're at time so I'll let everyone go. 16:01:31 <bnemec> Always available for further discussions in this channel though. 16:01:37 <bnemec> Thanks! 16:01:40 <bnemec> #endmeeting