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