15:01:12 <bnemec> #startmeeting oslo
15:01:13 <openstack> Meeting started Mon Sep 17 15:01:12 2018 UTC and is due to finish in 60 minutes.  The chair is bnemec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:16 <openstack> The meeting name has been set to 'oslo'
15:01:21 <bnemec> courtesy ping for amotoki, amrith, ansmith, bnemec, dansmith, dhellmann, dims
15:01:21 <bnemec> courtesy ping for dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb, haypo
15:01:21 <bnemec> courtesy ping for jd__, johnsom, jungleboyj, kgiusti, kragniz, lhx_, njohnston
15:01:21 <bnemec> courtesy ping for raildo, redrobot, sileht, sreshetnyak, stephenfin, stevemar, therve
15:01:21 <bnemec> courtesy ping for thinrichs, toabctl, zhiyan, zxy, zzzeek
15:01:35 <dhellmann> o/
15:01:46 <bnemec> #link https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
15:01:59 <ansmith> o/
15:01:59 <Phuongnh> o/
15:02:09 <ducnv_> o/
15:02:23 <raildo> o/
15:02:46 <kgiusti> StevenK: ping - oslo meeting...
15:02:50 <kgiusti> o/
15:03:39 <njohnston> o/
15:03:47 <bnemec> #topic Red flags for/from liaisons
15:04:19 <bnemec> Nothing much from our side. I'm planning to start the regular weekly releases again now that stein is open.
15:05:56 <bnemec> #topic Releases
15:06:55 <bnemec> See above. I expect to release all the things this week, possibly with the exception of olso.messaging if all of the removal patches haven't merged yet.
15:07:22 <bnemec> If you're aware of anything else I should hold off on please let me know asap.
15:07:58 <bnemec> #topic Action items from last meeting
15:08:09 <bnemec> "bnemec check if we can release stein libraries"
15:08:13 <bnemec> We can. :-)
15:08:21 <bnemec> "review patches listed in http://paste.openstack.org/show/728832/"
15:09:11 <bnemec> I think we finished that.
15:09:49 <bnemec> "bnemec to check with VMT about Oslo libraries"
15:10:16 <bnemec> I briefly discussed this at the PTG, but never got a chance to have the full discussion. Still on the todo list.
15:10:25 <bnemec> "dhellmann to respond to uuidsentinel thread"
15:10:33 <bnemec> That one is done.
15:10:39 <bnemec> "bnemec cancel oslo meeting for next week"
15:10:44 <bnemec> And that one too.
15:11:57 <bnemec> #topic Config migrator
15:12:25 <bnemec> Phuongnh_: ducnv_: I can't remember, was there anything new to talk about here or are you just waiting on reviews?
15:13:32 <Phuongnh_> We have added release note as your request, now waiting for your review
15:14:24 <ducnv_> hi Ben, I just push follow up patch, it ready for review
15:14:33 <ducnv_> https://review.openstack.org/#/c/603060/
15:15:19 <bnemec> Great, thanks!
15:15:47 <Phuongnh_> :)
15:15:58 * jungleboyj sneaks in late
15:16:31 <bnemec> #topic  oslo.upgradecheck
15:17:10 <bnemec> If you haven't been following this, it's a new library to support the upgrade check community goal for this cycle.
15:17:31 <bnemec> Basically it will house the common code for the checks and hopefully make it a little easier for projects to implement them.
15:18:04 <Phuongnh_> I see
15:18:16 <bnemec> I kind of did an end run around the new library proposal process in Oslo though, so if you have any concerns let me know.
15:19:02 <bnemec> https://github.com/cybertron/oslo.upgradecheck
15:19:42 <bnemec> I guess the one thought I had about it since initially proposing it is whether we should make it a more generic oslo.cli library or something like that.
15:19:44 <Phuongnh_> Thanks, there is nothing for now
15:19:46 <openstackgerrit> Lance Bragstad proposed openstack/oslo.limit master: Render API reference documentation  https://review.openstack.org/600264
15:19:47 <openstackgerrit> Lance Bragstad proposed openstack/oslo.limit master: Add a conceptual overview to docs  https://review.openstack.org/600265
15:19:48 <openstackgerrit> Lance Bragstad proposed openstack/oslo.limit master: Allow ProjectClaims to support multiple resources  https://review.openstack.org/600266
15:19:49 <openstackgerrit> Lance Bragstad proposed openstack/oslo.limit master: Ignore documentation builds  https://review.openstack.org/603167
15:20:23 <bnemec> I don't know whether there is more common cli code that we might want to pull in later.
15:21:57 <Phuongnh_> Yes, I will check it later
15:23:15 <bnemec> The change to add it to governance is here: https://review.openstack.org/#/c/602483/
15:23:54 <bnemec> I don't have anything else to say about it. This was mostly just an FYI since it was done in a bit of a hurry.
15:24:00 <Phuongnh_> I see, thanks
15:24:54 <bnemec> #topic Weekly Wayward Review
15:25:05 <bnemec> #link https://review.openstack.org/#/c/559484/
15:28:29 <bnemec> This is a review to allow pbr to bootstrap the configuration for a new project.
15:28:50 <bnemec> It probably isn't all that relevant for OpenStack since we use cookiecutter for that, but for external users I could see it being useful.
15:31:20 <bnemec> I don't see any major problem with this and it's been out there long enough for anyone else to object.
15:31:28 <bnemec> There is one typo, but we can fix that in a followup.
15:35:32 <bnemec> Okay, need to look at that one a little closer after the meeting, but I think it should be about ready to go.
15:35:37 <bnemec> #topic Open discussion
15:35:37 <stephenfin> bnemec: FWIW, I'm not overly gone on the idea, though I haven't been able to articulate "why" enough to warrant a minus vote
15:35:39 <kgiusti> bnemec: IIUC it can overwrite any existing setup.py/cfg - is that an issue
15:35:55 <stephenfin> Something about pbr already having too much stuff bolted on
15:36:06 <bnemec> kgiusti: Yeah, I was wondering about that. It should probably be documented.
15:36:09 <stephenfin> I'll go review
15:36:21 <bnemec> stephenfin: Thanks.
15:37:07 <dhellmann> kgiusti : did you see the ML thread about python 3 upgrade testing in which we discussed the idea of a functional test for oslo.messaging to show messages passing between python 2 and 3?
15:37:40 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/134592.html
15:37:51 <kgiusti> bnemec: re: oslo.messaging removals - there's only one patch outstanding (and one for releasenotes) but we've held it up because there are a couple of projects that still reference the removed code:
15:37:59 <kgiusti> https://review.openstack.org/#/q/topic:bug/1712399+status:open
15:38:01 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/134663.html
15:38:19 <kgiusti> StevenK has patched these projects and reached out, but to no avail...
15:38:51 <kgiusti> dhellmann: /me reads...
15:39:26 <kgiusti> dhellmann: that's a fairly large hole in oslo.messaging testing
15:39:49 <dhellmann> oh, I was hoping you'd say "we could modify the $x job to do that..."
15:40:17 <kgiusti> dhellmann: perhaps, I'd need to throw some grey matter at it for a bit
15:40:26 <dhellmann> yeah, for now I just wanted to make sure you'd seen it
15:40:50 <kgiusti> dhellmann: thanks.  I'll look at it further.
15:41:28 <kgiusti> dhellmann: perhaps the system functional tests are the best place to put that.
15:41:52 <dhellmann> that seems reasonable
15:41:58 <dhellmann> it doesn't have to be fancy
15:42:14 <dhellmann> stand up a client on 2 and a server on 3 and makes some cast and call calls, then do the reverse
15:42:52 <kgiusti> dhellmann: I've got to dig around there a bit - I also need to remove the blocking executor so that's going to require some work on the tests as well.
15:43:10 <njohnston> I have a quick question about oslo.config... one of the proposals discussed for Neutron in the PTG had to do with taking the Provider Networks configuration that is currently in config files (and which Neutron can't function without) and creating CRUD API methods for it, migrating the values to a database.  The question was raised if oslo.config allows config to be read from a database, possibly in combination
15:43:10 <njohnston> with a file.
15:43:54 <bnemec> njohnston: Not at the moment, but with the new driver functionality that could be added.
15:44:10 <bnemec> #link http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
15:44:21 <njohnston> bnemec: That's what I thought would be the most likely answer.  Thanks!
15:44:45 <bnemec> However, that would require everyone to configure the database driver since it can't be added by default.
15:44:49 <dhellmann> njohnston : it doesn't today. I'm not sure the config data model would be flexible enough to support that. it might with the drivers, as bnemec proposes, but you might also want those values to come naturally from the data objects
15:45:24 <dhellmann> for example, adding a new one with oslo.config would require HUPping the service at least
15:45:38 <dhellmann> whereas doing it with the data models would just require re-reading the database in the application code
15:46:13 <njohnston> dhellmann: Thanks, I will definitely note that as well
15:46:18 <njohnston> It is an idea fraught with peril on many fronts, but if I can establish what a theoretical path would be we can take the discussion to gerrit review comments.
15:47:08 <njohnston> thanks bnemec dhellmann
15:47:11 <bnemec> Yeah, adding CRUD for config opts seems sketchy, but in theory it could be done.
15:47:27 <dhellmann> if you're going to put them in the db, I think I'd just write a migration tool that does that and then rewrite any application code that uses the existing config values to use the db models
15:47:51 <dhellmann> that might be a good thing for the upgrade checker to report on, too
15:48:06 <njohnston> if we go that path, definitely
15:48:47 <bnemec> +1. Maybe for one cycle both code paths exist to allow migration, and then in the next one you remove the config version.
15:49:18 <bnemec> We had a similar discussion around oslo.limit and upgrades.
15:50:56 <bnemec> Okay, keep us in the loop on that.
15:51:02 <bnemec> Anything else before we close?
15:51:11 <kgiusti> yes
15:51:33 <kgiusti> I'd like to get steve's final code patch to remove rpc_backend: https://review.openstack.org/#/c/580910/
15:52:02 <kgiusti> but there are a couple of projects that have not accepted his patches: https://review.openstack.org/#/q/topic:bug/1712399+status:open
15:52:26 <kgiusti> We've given them enough time to adopt the changes
15:52:47 <kgiusti> So I'm in favor of moving forward - does anyone disagree?
15:52:52 <bnemec> So two of those do appear to be dead. Nothing has merged in months for either. Not even a core review.
15:53:03 <kgiusti> +1 yep
15:53:11 <bnemec> Tacker does seem to be active still though. Can we send something to the list to get the attention of their cores?
15:53:24 <bnemec> Or maybe add them to the review?
15:54:01 <bnemec> Oh, weird. One of the +1's is from a core. :-/
15:54:20 <bnemec> The incorrect -1 might be preventing them from looking at it though.
15:55:06 <kgiusti> bnemec: I can do that, but I don't want to wait too long into the cycle for this change to land
15:56:13 <bnemec> kgiusti: Understood, and I don't expect us to wait indefinitely.
15:56:51 <bnemec> It seems like we should be able to land the patch in tacker though, so unless we get completely stonewalled there I'd prefer to wait for that.
15:57:12 <bnemec> The other two we can send a message to the list, but I don't anticipate a response based on the lack of activity so I don't think we should wait.
15:57:25 <kgiusti> I'll do both - thanks
15:57:38 <bnemec> Sounds good.
15:57:52 <bnemec> #action kgiusti to contact tacker team about removing transport_url
15:58:23 <bnemec> #action kgiusti to send message to openstack-dev for meteos and daisycloud about transport_url
15:58:32 <stephenfin> Another open. Since we discussed one of his other patches, I think this needs another look at https://review.openstack.org/#/c/561731/
15:59:28 <stephenfin> dhellmann had reviewed it and there were some opens around removing pbr's automatic versioning machinery. I'm looking at it as we speak but I'd appreciate other eyes
16:01:07 <bnemec> Ah, I had looked at that review too at one point.
16:02:34 <dhellmann> kgiusti, bnemec : daisycloud and meteos are not official, so if they aren't responding on the mailing list or reviews I don't think we need to wait for them
16:02:40 <openstackgerrit> Ilya Shakhat proposed openstack/osprofiler master: Add a job to run full Tempest with enabled profiler  https://review.openstack.org/602992
16:03:20 <kgiusti> dhellmann: thanks - I'll follow up on the mailing list and we can give them a few days before we pull the trigger (next week perhaps)
16:03:26 <kgiusti> dhellmann: also just fyi: https://bugs.launchpad.net/oslo.messaging/+bug/1792977
16:03:26 <openstack> Launchpad bug 1792977 in oslo.messaging "Need a functional test to verify py2 <-> py3 interoperability" [High,Triaged]
16:03:59 <dhellmann> kgiusti : thanks * 2
16:06:25 <bnemec> Okay, we're over time.
16:06:39 <bnemec> I'll add a
16:06:39 <bnemec> #action review https://review.openstack.org/#/c/561731
16:06:45 <bnemec> so we follow up on that next week.
16:07:12 <bnemec> Thanks for joining!
16:07:15 <bnemec> #endmeeting