00:01:18 #startmeeting congressteammeeting 00:01:19 Meeting started Thu Oct 12 00:01:18 2017 UTC and is due to finish in 60 minutes. The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:22 The meeting name has been set to 'congressteammeeting' 00:01:27 Hi all 00:01:30 hello all. 00:01:32 hi thinrichs 00:01:46 topics here as usual: https://etherpad.openstack.org/p/congress-meeting-topics 00:03:00 ekcs: hi. 00:03:09 hi masahito ! 00:03:22 topics here as usual: https://etherpad.openstack.org/p/congress-meeting-topics 00:03:40 sorry, I need to go in 30 mins. 00:03:55 got it! 00:04:16 well let’s get started then. 00:04:19 #topic priorities 00:04:52 since the PTG I’ve been maintaining a list of congress priorities in strict order. 00:04:52 https://etherpad.openstack.org/p/congress-task-priority 00:05:15 Idea is to avoid having a bunch of things all at the same priority level. 00:05:41 in reality it may not be exact, but it’s better than having 10 “high priority” items we can’t distinguish between. 00:06:18 Please take a look from time to time and make any comments, suggestions, changes as needed. 00:06:19 Total priority is good 00:06:52 yups. 00:07:31 we’re making decent progress so far. 1, 2.2, 2.3, 4 are all in review. 00:07:56 1 is ready to merge just need the unblock the gate still. 00:08:46 any comments, additions, thoughts, or discussions on the list? 00:10:32 Look good to me. I'd focus on solving community pain points, which it looks like is where the priorities are lining up. 00:11:04 thinrichs: agreed on focusing on concrete pain points. 00:11:40 please feel free to insert anything you guys see missing from the list. 00:11:48 or bring them up in IRC. 00:14:27 ok moving on then 00:15:08 #topic gate blockage 00:15:30 unfortunately our gate is still blocked since the jenkin to zuul migration. 00:16:19 we have patch ready to fix things in our repo, but that patch is still blocked by stuff in other repos. 00:16:43 also seeing a fair amount of infra instability with POST_FAILURE. 00:17:01 hoping for things to be settled down by next week. 00:17:22 quite a few patches stuck at the gate. 00:17:33 any thoughts/comments/questions? 00:18:05 main external issue we’re still waiting on: https://bugs.launchpad.net/designate/+bug/1721432 00:18:06 Launchpad bug 1721432 in oslo.context "TypeError: __init__() got an unexpected keyword argument 'project' in Designate" [Critical,In progress] - Assigned to Juan Antonio Osorio Robles (juan-osorio-robles) 00:19:00 ok moving along then. 00:19:16 #topic continue drivers conf discussion 00:20:14 actually ramineni seems to be in and out. 00:20:23 maybe we’ll wait a bit more. 00:20:31 any other topics on our minds? 00:20:56 Not me 00:21:04 except… did you figure out the grammar problem? 00:21:53 thinrichs: no I haven’t. the triple quote appears to be broken. but not sure we want to actually try and fix it. 00:22:36 I’m thinking we’ll work around it for feeding YAML to mistral in rule. 00:23:16 like explicitly de-escape the \n in a string argument before passing on the mistral. 00:24:03 one issue is what the intended result is when we write something like p(“a\nb”) in a congress rule. 00:24:35 is it supposed to be length 3 with a newline character or is it supposed to be length 4? right now it reads as length 4. 00:25:12 I’m thinking we don’t really want to muck with that behavior so we can just add another layer of de-escape on top of that. 00:25:21 open to thoughts and suggestions. 00:27:14 btw here is what I organized from our previous discussion around changing driver conf behavior: https://etherpad.openstack.org/p/congress-driver-conf 00:28:07 Not clear to me why embedding the carriage-return in the triple quote is the wrong thing. It gives the user the power to choose that. 00:28:16 Especially if the triple-quotes are broken. 00:28:43 I also don't know where the code that would change \n to a CRLF would live. The datasource? 00:29:21 thinrichs: I’m thinking the datasource, for specific use like YAML string arg. 00:29:43 thinrichs: I agree it’s cleaner to make p(“a\nb”) read as length 4 string. 00:29:49 sorry length 3 00:30:39 To be clear, I was thinking "a\nb" would be a 4-length string, but """a\nb""" would be a 3-length string. 00:30:57 oh I see what you mean. 00:31:33 I was thinking “a\nb” would be length 3, and “a\\nb” would be length 4. consistent with python. 00:31:50 so you’re saying since triple quote is broken, we can just fix it. 00:32:01 since clearly we’re not going to break people. 00:32:32 in python triple quote, “””a\nb””” would be length 4. 00:32:37 “””a 00:32:40 b””” 00:32:45 would be length 3. 00:33:06 Oh I see. I was assuming we wanted to write with the actual line-breaks in there. 00:33:32 But you're saying we want to use \n instead of the actual line-break. 00:34:15 sorry to interrupt. I need to go. 00:34:17 If I were embedding YAML into the file I'd probably want to cut-and-paste as is (and use YAML linters). That would require using the actual line breaks, instead of the \n./ 00:34:35 thanks masahito see you later! 00:34:42 ekcs: thanks, bye. 00:35:09 bye masahito 00:35:16 thinrichs: bye 00:35:36 thinrichs: right. if we want to be able to copy past YAML into an arg, we’d need to fix triple quote and allow actual line breaks in the input. 00:35:55 that would be ideal. 00:36:29 but I have no idea where to start in fixing triple quote. 00:37:00 and a compromise would be for user to replace newline by \n before pasting. 00:37:28 may be the preferable style anyway in many cases. 00:37:45 rather than 00:38:22 So then something consistent with Python makes sense. Maybe a backwards incompatible change, but that seems fine. 00:40:01 what is the backward incompatible change? 00:40:14 reading “a\nb” is length three? 00:40:54 Yes 00:41:00 That's not how it works today, right? 00:41:38 no not how it works today. my favored option right now is to keep it working the way it is today. 00:41:44 (It'd obviously be a pretty tiny change in behavior) 00:41:59 Oh—then no backwards incompatible change. 00:42:11 Put the translation in the datasource driver. 00:42:14 Right? 00:42:18 but simply built it into specific action executions to de-escape. so it’s part of that action semantic rather than general parsing semantic 00:42:36 right. it’s a bit hacky (ie. specific to something) 00:42:51 but it keeps backward compatibility. 00:45:28 but it’s also an option to just change the way “a\nb” parses completely to be consistent with python. 00:46:17 i’m not sure how to do that either, but it may be easier to figure out than the triple quote. 00:47:42 The datasource answer sounds like the simplest for now 00:48:26 yea that’s what I’m thinking. 00:48:35 i’ll give it a try. 00:48:49 so do you have any more thoughts on the drivers conf? 00:49:42 I added a new suggestion which is to treat the existing drivers option as specifying drivers in addition to the default ones. 00:49:50 https://etherpad.openstack.org/p/congress-driver-conf 00:50:30 that way people who have additional drivers configured don’t get broken by upgrade. people who have old config don’t miss out on new drivers. 00:50:57 only people who get “messed up” are people who specifically want certain drivers to be unavailable. 00:51:19 they’d need to specify a new whitelist_driver option to limit to those. 00:51:54 that’s 2.2 in the etherpad. 00:53:03 sorry it’s 2.3 in the etherpad. 00:53:13 2.2 is what I think both you and ramineni favored in last meeting. 00:53:47 2.1 is what I favored last meeting before I considered 2.3. 01:00:03 ok well time’s up. thanks for the discussion! feel free to add comments to the etherpad and/or respond to my ML message later. have a great week. #endmeeting 01:00:09 #endmeeting