15:01:00 <bnemec> #startmeeting oslo
15:01:01 <openstack> Meeting started Mon Jan  7 15:01:00 2019 UTC and is due to finish in 60 minutes.  The chair is bnemec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:04 <openstack> The meeting name has been set to 'oslo'
15:01:33 <bnemec> courtesy ping for amotoki, amrith, ansmith, bnemec, dansmith, dhellmann, dims
15:01:33 <bnemec> courtesy ping for dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb, haypo
15:01:33 <bnemec> courtesy ping for hberaud, jd__, johnsom, jungleboyj, kgiusti, kragniz, lhx_
15:01:33 <bnemec> courtesy ping for moguimar, njohnston, raildo, redrobot, sileht, sreshetnyak, stephenfin
15:01:33 <bnemec> courtesy ping for stevemar, therve, thinrichs, toabctl, zhiyan, zxy, zzzeek
15:01:39 <bnemec> #link https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
15:01:46 <redrobot> \o-ish
15:01:47 * dhellmann is in another meeting but will lurk
15:01:58 <moguimar> o/
15:02:06 <ansmith> o/
15:02:12 <moguimar> we will need jaosorior
15:02:22 <kgiusti> o/
15:02:29 <moguimar> for the oslo.policy
15:03:02 <bnemec> Welcome back everyone. Hope you had a happy new year!
15:03:51 <bnemec> #topic Red flags for/from liaisons
15:04:05 <bnemec> The big one from the Oslo side is the oslo.privsep release.
15:04:12 <bnemec> It broke the Neutron functional tests.
15:04:38 <bnemec> I started looking into it on Friday, but as with all things concurrency, it's tricky.
15:05:17 <bnemec> #link https://bugs.launchpad.net/bugs/1810518
15:05:17 <openstack> Launchpad bug 1810518 in oslo.privsep "neutron-functional tests failing with oslo.privsep 1.31" [Critical,Confirmed] - Assigned to Ben Nemec (bnemec)
15:06:07 <bnemec> Looks like Slawek narrowed it down to one test, so hopefully that will help.
15:06:36 <bnemec> Any other red flags before we move on?
15:06:55 <njohnston> no, I think that covers it from the neutron side
15:07:31 <bnemec> Okay, thanks
15:07:34 <bnemec> #topic Releases
15:07:57 <bnemec> There were quite a few last week, including the aforementioned oslo.privsep one.
15:08:29 <bnemec> I'll take a look today and see if we need another set.
15:08:36 * jungleboyj steps in late
15:08:53 <bnemec> If there's not much I'll probably skip this week since last week's was actually mid-week due to the holidays.
15:09:21 <bnemec> #topic Action items from last meeting
15:09:52 <bnemec> "hberaud to send email to openstack-discuss about oslo.config migrator"
15:10:03 <bnemec> Done, thanks hberaud.
15:10:20 <bnemec> Probably need to talk some more about that one, but for this topic it's done.
15:10:26 <bnemec> "bnemec to look at oslo policy checker reviews"
15:10:35 <bnemec> I think I did that.
15:10:57 <bnemec> Three weeks is a long time to remember back. :-)
15:11:02 <hberaud> o/
15:11:06 <bnemec> "moguimar to ping keystone folks for the oslo.policy change"
15:11:32 <bnemec> I'm not sure of the status on that one. moguimar?
15:11:51 <moguimar> we got some reviews on that one, but basically jaosorior was on PTO
15:12:19 <moguimar> he is the original author of the patch, I took it over during christmas/nye
15:12:29 <bnemec> Okay, fair enough.
15:12:56 <bnemec> I saw he had responded to one of my comments. I need to take another look and figure out if it makes more sense now.
15:13:05 <bnemec> "bnemec to send mail to openstack-discuss about EOY plans."
15:13:06 <bnemec> Done
15:13:19 <moguimar> I was able to break some changes down on the patch
15:13:25 <moguimar> and we got some stuff in already
15:13:42 <bnemec> Okay, let's just go to that topic then.
15:13:46 <bnemec> #topic      Reviews: oslo.policy: Add ability for policy-checker to read configuration
15:14:15 <bnemec> moguimar: Thanks for splitting the change.
15:14:20 <moguimar> sure
15:14:39 <bnemec> Was there anything else to discuss on this or do you just need reviews?
15:15:22 <moguimar> I think we need to know how to use the config passed to the enforcer
15:15:35 <moguimar> have a use case as an example or something like that
15:16:08 <moguimar> at first the script was using argparser and jaosorior was adding configparse to pass config file to the enforcer
15:16:30 <moguimar> using oslo.config we can also pass config to the enforcer through environment values now
15:16:37 <bnemec> Yeah, I think that was my point of confusion as well.
15:16:41 <moguimar> env variables*
15:17:18 <bnemec> Side benefit of the env driver. :-)
15:17:47 <moguimar> I think we can provide the conf object there at the enforcer and who ever wants to read conf from it can register what they would like to access
15:18:17 <bnemec> Yeah, I'm just confused  by the fact that it's only added in the test instance of the enforcer.
15:18:23 <bnemec> At least IIRC.
15:18:37 <moguimar> ok, I can check that with jaosorior
15:18:58 <moguimar> that's all on my end
15:19:35 <bnemec> #action moguimar to sync with jaosorior on policy config change
15:19:37 <bnemec> Thanks
15:20:02 <bnemec> #topic [RFE] Configuration mapping tool for upgrade
15:20:09 <bnemec> #link https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator
15:20:17 <bnemec> I want to circle back on this one.
15:20:46 <bnemec> It sounds like the team that originally proposed it has lost momentum, which leaves this work without a stakeholder.
15:21:34 <bnemec> Given that the usefulness of the tool in the first place is up for debate, I'm inclined to say that we either WIP or abandon the series for now.
15:21:58 <bnemec> If someone comes along and wants to resurrect it and has a definite use case then I'm open to that.
15:22:19 <bnemec> But I don't want to merge a bunch of code that doesn't have a maintainer.
15:23:18 <hberaud> I can maintain this code
15:23:30 <hberaud> but I've no personal usage
15:24:00 <bnemec> hberaud: Yes, but there are other things I'd much rather have you work on. :-)
15:24:03 <moguimar> I'll take a look on it as well
15:24:07 <hberaud> it's more for helping than using
15:24:09 <jaosorior> I'm on a meeting but will be free soon
15:24:59 <moguimar> what is the purpose of the migrator tool in a few lines?
15:25:15 <bnemec> We have 40 projects that _are_ being used, I'd rather not spend a bunch of time on code that _isn't_.
15:25:44 <bnemec> moguimar: Taking a config file from release N and migrating it to N + 1.
15:25:54 <bnemec> N as in "generic release" not specifically "Newton".
15:26:15 <moguimar> got it
15:26:17 <bnemec> It will move values for deprecated options and such so they are using the new names in the new config.
15:26:39 <bnemec> My question all along with this has been whether there is anyone who is writing configs by hand and would benefit from this.
15:26:57 <bnemec> Generally speaking I feel like configs are generated by Puppet or Ansible and thus those tools handle writing the new configs.
15:27:45 <moguimar> ok, we can move on
15:28:04 <jungleboyj> bnemec:  Outside of testing I think most of the configs are generated in an automated manner.
15:28:18 <bnemec> Maybe this needs to go back to the list. I'll send an update to that thread with my proposal.
15:28:30 <bnemec> jungleboyj: Yeah, my thoughts as well.
15:28:50 <bnemec> #action bnemec to respond again to config migrator thread
15:29:13 <bnemec> #topic      Denver PTG
15:29:23 <bnemec> Getting extra spaces in my copy-pastes today.
15:29:44 <bnemec> I need to respond to the foundation in the next couple of weeks about whether we want space at the PTG.
15:30:06 <moguimar> for project update and onboarding stuff?
15:30:22 <bnemec> Since I'm guessing nobody has made travel plans yet, my intent is to go ahead and request space on the assumption that we'll have _something_ to discuss.
15:30:31 <bnemec> moguimar: No, this is for the PTG part of the week.
15:30:36 <bnemec> I think
15:30:38 * bnemec checks
15:31:10 <bnemec> Yeah, it was specifically for the PTG.
15:31:10 <jungleboyj> bnemec:  Yeah, it was for the PTG part of the week.
15:31:21 <bnemec> I assume the project update request will come later.
15:31:25 <jungleboyj> I already responded that Cinder will be there.
15:31:25 <moguimar> ok, I've never been to one then
15:32:21 <bnemec> This one's colocated with the summit, so hopefully more people will be able to attend.
15:32:37 <jungleboyj> Will be interesting to see how it goes.
15:33:03 <bnemec> So I guess this is just a heads up that I am planning to request a room.
15:33:09 <bnemec> Make travel plans accordingly. :-)
15:33:21 <moguimar> are they happening in the same days or one after the other?
15:33:40 <bnemec> moguimar: Summit Monday-Wednesday, PTG Thursday-Saturday.
15:35:23 <openstackgerrit> weizj proposed openstack/oslo.log master: Update hacking version  https://review.openstack.org/627657
15:35:45 <bnemec> #action bnemec to request space at Denver PTG III
15:35:53 <bnemec> That was it for topics.
15:35:59 <bnemec> #topic Weekly Wayward Review
15:37:45 <bnemec> #link https://review.openstack.org/#/c/620686/
15:37:51 <bnemec> Gonna be a bit self-serving here. :-)
15:38:13 <bnemec> There are a couple of older reviews than that, but they're fairly large RFE-type changes that we probably can't resolve here.
15:38:34 <bnemec> This is a relatively simple change that has been open for a while and has a +2.
15:38:55 <bnemec> Just need another Oslo core to take a look at it (hopefully).
15:40:36 <moguimar> I can review it now
15:40:51 <moguimar> I was just reviewing something else at oslo.utils
15:40:51 <bnemec> moguimar: Thanks
15:41:26 <bnemec> #action moguimar to review https://review.openstack.org/#/c/620686/
15:41:28 <hberaud> moguimar: thanks for the review
15:41:43 <bnemec> It's a pretty minor change and has good test coverage, in my admittedly biased opinion. :-)
15:42:31 <bnemec> Okay, we'll call that one good then.
15:42:32 <bnemec> #topic Open discussion
15:42:38 <bnemec> Anything else before we close?
15:43:07 <hberaud> just some question about yaml
15:43:37 <bnemec> Okay, go ahead
15:44:25 <hberaud> some week ago I've work on a bug where MAC address have problems with PYYAML due to sexagesimal format managed by YAML specifications 1.1 and so PYYAML
15:45:01 <bnemec> Is there an lp bug for this?
15:45:17 <hberaud> a simply work around can be to use quotes MAC address
15:45:20 <hberaud> nope
15:45:28 <hberaud> https://bugzilla.redhat.com/show_bug.cgi?id=1661245
15:45:28 <openstack> bugzilla.redhat.com bug 1661245 in libyaml "bad detection of a string aka mac address" [High,Closed: notabug] - Assigned to jeckersb
15:45:48 <bnemec> Okay, bz works too.
15:46:27 <hberaud> but in openstack we handle a lot of MAC address especially in projects who use ansible and yaml config files
15:47:01 <hberaud> and I don't found any warning or something that inside openstack
15:47:52 <bnemec> Yeah, that's kind of icky behavior.
15:47:54 <hberaud> while we use PYyaml the problem can occur due to the compatibility with YAML 1.1
15:48:04 <bnemec> I would not expect a mac address to be parsed as an int.
15:48:14 <bnemec> ints don't have :'s. :-)
15:48:28 <hberaud> sexagesimal have
15:49:04 <bnemec> Yeah, apparently.
15:49:43 <bnemec> The principal of least astonishment tells me they should have prioritized the very common MAC address format over the very uncommon sexagesimal one though.
15:49:58 <jungleboyj> :-)
15:49:59 <bnemec> In any case, what are you proposing that we do?
15:50:00 <hberaud> when the yaml parser parse the document and when an MAC address with the same values possible with in sexagesimal appear we get an int
15:50:28 <bnemec> I think by the time any OpenStack code gets these values they're already mangled, right?
15:51:01 <hberaud> 1 add warning where we need
15:51:05 <hberaud> I'm not sure
15:51:33 <hberaud> 2 eventually try to adopt smoothy a yaml parser compatible with yaml 1.2
15:51:57 <bnemec> Yeah, that's kind of the problem. This bug is in a Heat template, but as you note it could easily happen in Ansible or anywhere else YAML is used.
15:52:13 <hberaud> yeah
15:52:15 <bnemec> I don't think there's a single place we can document the issue.
15:52:35 <bnemec> Is there a YAML 1.2-compatible library we could move to?
15:52:47 <bnemec> Or does PyYAML have plans to support 1.2 in the future?
15:53:00 <hberaud> ok, my main goal is to obtain temparture about this
15:53:14 <hberaud> I don't not about PYAML and 1.2
15:54:02 <hberaud> but another parser already exist like this one => https://bitbucket.org/ruamel/yaml/src/default/
15:54:23 <hberaud> and he already deal with yaml 1.2
15:54:45 <bnemec> Yeah, I've come across that a number of times over the years.
15:54:59 <bnemec> Has some other nice features like maintaining comments too.
15:55:27 <hberaud> and an other interesting subject can be to formalize the sexagesimal notation but is it an other topics
15:56:07 <bnemec> hberaud: So I don't think anyone would be opposed to fixing this if you come up with a proposal.
15:56:27 <bnemec> Although if it ends up being s/pyyaml/ruamel/ we would need to get the requirements team involved too.
15:56:33 <openstackgerrit> Will Szumski proposed openstack-dev/pbr master: Do not globally replace path prefix  https://review.openstack.org/629006
15:57:03 <hberaud> bnemec: cool, I need more thoughts but I already have a personal big picture that I need to formalize more properly
15:57:17 <bnemec> hberaud: Okay, sounds good.
15:57:21 <bnemec> Anything else?
15:57:26 <hberaud> no
15:58:22 <bnemec> Ending the meeting in 3...
15:58:25 <bnemec> 2...
15:58:27 <bnemec> 1...
15:58:31 <moguimar> o/
15:58:35 <moguimar> cya guys
15:58:35 <jungleboyj> o/
15:58:38 <bnemec> Oops, first, thanks for joining everyone!
15:58:42 <jungleboyj> Thanks.
15:58:46 <bnemec> #endmeeting