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