17:00:39 #startmeeting ironic 17:00:40 Meeting started Mon Aug 24 17:00:39 2015 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:43 The meeting name has been set to 'ironic' 17:00:44 o/ 17:00:45 o/ 17:00:47 o/ 17:00:54 o/ 17:00:58 g'morning / afternoon / evening, everyone! 17:01:07 o/ 17:01:08 As usual, the agenda can be found here: 17:01:09 good UGT morning 17:01:10 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:11 o/ 17:01:25 \o 17:01:27 morning y'all 17:01:48 o/ 17:02:01 o/ 17:02:03 oh devananda will out burning things for a couple of weekes :) 17:02:03 o/ 17:02:07 #topic announcements 17:02:13 o/ 17:02:24 as NobodyCam has pointed out ... I will be off in the dessert for a few weeks 17:02:27 NobodyCam: excellent annoucemnt :) 17:02:40 enjoy! 17:02:42 o/ 17:02:48 o/ hi all 17:02:54 #info devananda offline for vacation soon -- rough dates are Aug 27 - Sept 8 17:02:55 have fun devananda 17:03:10 devananda: while you're away, do others have authority to do stuff you can do? 17:03:10 o/ 17:03:18 also, jroll and I are going to try *really* hard to get a release cut this week 17:03:24 devananda: eg, did we do a release of ironic 17:03:30 devananda: yeah that ^^ 17:03:35 :) 17:03:41 devananda: Uh, jroll is on vacation 17:03:47 devananda, ++ for the release 17:03:48 eh? 17:03:48 oops 17:03:59 Jim will be back next week :) 17:04:00 JayF: when does jroll get back? 17:04:01 At least I think he is 17:04:04 ahahaha 17:04:05 well then 17:04:17 #info jroll on vacation this week, back next week 17:04:20 devananda: also, there's a feature freeze for liberty coming up. how does that affect ironic. it isn't clear to me wrt our new release process. 17:04:28 devananda, what is needed for the release? 17:04:46 let's talk about the release in more detail in another section of the meeting 17:04:54 anyone else have announcements? 17:05:02 I've refactored our whiteboard a bit 17:05:09 * dtantsur hides 17:05:24 rloo: if you don't mind, I'll inject the release discussion right after the subteam status report, and before your topic 17:05:32 devananda: ok with me 17:05:32 o/ 17:05:43 dtantsur: whiteboard looks fine to me :) 17:05:45 thanks! 17:05:50 :) 17:06:03 ok, moving on 17:06:07 #topic subteam status reports 17:06:27 dtantsur: want to update on bug status? 17:06:35 Sukhdev: want to update on the neutron work, since jroll is out? 17:06:48 o/ 17:06:53 devananda: sure 17:07:03 devananda, nothing except for what is on the whiteboard.. 17:07:18 dtantsur: great :) 17:07:21 dtantsur, jlvillal: where's the link to get more info on the nova bugs? 17:07:24 We are in the middle of integration testing 17:07:45 devananda, would be cool if you manage to review ironic-lib gate testing patches 17:07:48 devananda: opps - Looks like I am out of order 17:07:48 rloo: This? https://wiki.openstack.org/wiki/Nova-Ironic-Bugs 17:07:50 they're on the whiteboard as well 17:07:55 dtantsur: 50 "in progress" seems a little high to me. how many of those do you think are stale? 17:08:00 rloo: Or this? https://bugs.launchpad.net/nova/+bugs?field.tag=ironic 17:08:13 jlvillal: the first one. thx. 17:08:32 devananda, I'm afraid not less that a half... yeah, we should start pinging people, I'll add to my todo list 17:08:52 jlvillal: that's a great summary wiki page. looks like it's not autogenerated though? 17:09:11 devananda: Yeah, mrda and I update it each week. 17:09:15 devananda, jlvillal, some nova bugs information is on the bug dashboard 17:09:20 We have a bug scrub each Tuesday. 17:09:57 which is ironic-divius.rhcloud.com 17:10:25 Ah :) 17:10:57 OneView team is working on integration tests and would like to put the 3rd party CI to work ASAP. Are we clear to add it to the stack as soon as the tests are ready? 17:10:59 pshige_: docs patch merge \o/ 17:11:31 thiagop, you can add the 3rd party CI at anything I think 17:11:33 api version testing still hasn't landed in tempest .. that makes me sad too 17:11:34 it's all good 17:11:34 any objections (since the driver isn't yet merged, might be some...) 17:11:38 ? 17:11:40 https://review.openstack.org/#/c/166386/ 17:12:04 woops, meant to paste that elsewhere 17:12:53 thiagop: I see that the spec is approved. has the code been reviewed yet by anyone? 17:12:59 devananda, the comments there seems just syntax nitpicks and typo 17:12:59 :-( 17:13:16 * lucasagomes can push a new patch-set fixing those if it makes the tempest guys happier 17:13:20 just preliminarily devananda 17:13:35 thiagop: ok, so there is no guarantee when it will land 17:14:24 thx lucasagomes 17:14:45 thiagop: it's up to reviewers what they review when, and there are several high priority items to review that were approved a long time ago, so... 17:15:08 if somebody have time to take a look, OneView driver code: https://review.openstack.org/#/c/191822/ 17:15:20 TheJulia: how goes the bifrost gate testing stuff? 17:15:25 also qas were asking for help reviewing this tempest patch, if you have time - https://review.openstack.org/#/c/178607/ 17:15:28 np devananda, but your idea is to wait until merge the driver to put up the CI? 17:15:43 thiagop: could you add a link to the gerrit review(s) for your code to the whiteboard? 17:15:46 devananda: Just need the changes to land in infra to rename the test, and I can propose for ironic/shade 17:15:53 thiagop: under the "Drivers" section 17:15:53 devananda: sure 17:16:26 thiagop: you can put up the CI any time. Start with the "experimental" pipeline, so that you[r team] can trigger the jobs on your patches 17:16:39 and that way it doesn't report on any other patches yet 17:16:49 TheJulia: awesome 17:17:08 devananda: roger roger 17:17:18 good stuff, everyone! 17:17:21 anything else before we move on? 17:17:24 nicodemos: ^ 17:17:56 i htink Sukhdev didn't finish 17:18:12 rloo: ooh, thanks 17:18:36 Sukhdev: we try to go through the status updates quickly, so it's not exactly "ordered" 17:18:46 devananda: you want me to provide status now? 17:19:00 Sukhdev: jroll is on vacation AIUI, so, yes please 17:19:20 this is the part of our meeting where subteams report their status. we'll move into discussions of specific topics shortly 17:19:27 We are in the middle of integration testing and have discovered some issues, which we are addressing 17:19:48 Sukhdev: are there bug or a list of the issues? 17:20:09 One of the blocker is the authentication issue when ironic driver makes create_port() request to neutron - the context is not set correctly, hence it is rejected 17:20:17 #link: https://etherpad.openstack.org/p/ironic-neutron-mid-cycle 17:20:39 NobodyCam: this etherpad lists all the patches, TODO's etc. 17:20:56 We are using this etherpad to track the patches and issues 17:21:06 Sukhdev: ah - that is an ironic admin context, not the nova user context, yes? 17:21:26 o/ 17:21:45 devananda: correct - that is what we were discussing in our meeting earlier lazy_prince is looking at it 17:21:56 Sukhdev: great 17:21:58 thank you Sukhdev 17:22:02 as soon as an updated patch comes in, this will unblock us 17:22:20 Sukhdev: sounds good. thx for the update! 17:22:28 krotscheck: hi there! did you want to update on webclient? 17:22:34 devananda, https://blueprints.launchpad.net/openstack/?searchtext=remove-swift-dependency-for-ilo-drivers is not listed under priorities list of ironic while the specis merged for it long back 17:22:37 essentially, I am taking all the patches and running end-to-end integration testing and providing feedback to the members so that they can be fixed 17:23:04 devananda: CORS is still broken because pxe tests. 17:23:31 devananda: Also, people don't like the patch. 17:23:32 Sukhdev: thanks for the testing! 17:23:33 krotscheck: I have added a section to our whiteboard for you! (and for betherly) 17:23:34 That's all I got. 17:23:40 krotscheck: link to patch? 17:23:47 https://review.openstack.org/#/c/199769/ 17:23:50 rloo: no problem 17:24:03 Note, that's the second patch. The first one started in may 17:24:05 #link https://review.openstack.org/#/c/199769/ 17:24:12 (before summit, because summit) 17:24:20 krotscheck: ok - noted on the status pad. thanks! 17:24:29 we're way over time -- moving on now. tanks all! 17:24:37 #topic release status 17:24:43 this is an unintended topic 17:24:53 mostly, jroll and I had wanted to do a 4.0.0 release back at the midcycle 17:25:09 and ran into actual issues in the gate, with how the release mgmt team has changed the release process during Liberty 17:25:21 dhellmann is going to work with me to fix those today, I hope 17:25:43 however I am now sad that jroll is on vacation this week, since it means he's not going to be around to help or iron out issues after the fact 17:25:49 since I am going on vacation on Thursday morning 17:25:56 devananda: is there a bug or is this just a learning curve issue? 17:26:01 learning curve issues 17:26:05 :) ack 17:26:07 devananda, can you defer it to someone then? 17:26:12 they changed things to enable the stuff we want. we didn't track it 17:26:17 we == mostly me, and some jroll 17:26:36 what exactly to the release to happen ? (if it's not too long) 17:26:40 lucasagomes: sort of. except the person I was deferring it to is on vacation (jroll) 17:26:43 exactly is needed* 17:26:54 lucasagomes: I'm still figuring that out :( 17:26:57 jroll has some patch to tag at 4.0.0. sorry it is vague 17:27:09 #link https://review.openstack.org/#/c/214301/2 17:27:10 i remember seeing it last week. can find it later. 17:27:21 that's it! ^^ 17:27:22 that, however, isn't the whole picture 17:27:28 devananda, right, if you progress with that I think we have enough people around that may help with it 17:28:06 right 17:28:09 so that's the update 17:28:39 I wish I had a clearer update for ya'll :-/ 17:28:53 also the next topic is, well, fun :) 17:28:56 it's cool, still on going 17:28:58 :-) 17:29:01 devananda: even if "we" manage to clear things up, will something have to wait for you to do? 17:29:19 devananda: aren't you the only one that can do a release? 17:29:46 rloo: of the client? yes, for now 17:30:05 devananda: wasn't thinking of the client, but i'll touch base with you later about my question 17:30:07 I think rloo means for Ironic 17:30:09 because jroll's gpg key isn't signed by the relmgr team :-/ 17:30:19 on the server? no. actually, I can't do that. 17:30:22 lucasagomes: ++ 17:30:22 only the relmgr team can 17:30:35 devananda: ok, good to know. 17:30:47 and I have designated jroll as the liaison there -- https://wiki.openstack.org/wiki/CrossProjectLiaisons 17:31:09 hence the awkwardness of him being on vacation right now :p 17:31:20 anway, it is what it is. we all need vacations some times :) 17:31:27 moving on ... 17:31:42 #topic API version defaults in the python client 17:31:54 rloo: that's you! want to give the back story? 17:32:06 i put that cuz there's email on the devlist and i think we just need to decide. 17:32:16 the issue is that the client now defaults to the 'latest' microversion 17:32:28 it defaults to 1.6 17:32:31 but folks feel that is wrong, so i think we have agreed that it should default to the lowest version 17:32:57 yeah. so currently, it is set to default to 1.6, the client that has been released i mean. 17:33:06 and the client in master is at 1.9 or something like that 17:33:13 and devananda submitted a patch to set it back to 1.6 17:33:26 dropping it to 1.1 is an immediate change that will break nearly every user out there, including many of our CI jobs 17:33:35 1.6 and 1.9 are both "safe-ish" 17:33:39 and i think we should just decide. i don't think 1.1 is realistic any more cuz of kilo. 17:33:43 yeah, I think we should default to either 1.6 or 1.9 17:33:53 agreed, 1.6 or 1.9 17:33:59 and I proposed 1.6 because most users consume the client from releases 17:34:04 IMHO since 1.9 is already merged on master (and we usually assume that people use master) I think we should go with 1.9 17:34:08 wrt not breaking anyone else, lucasagomes suggested 1.9 17:34:08 whether those are distro packages or pip packages -- those are all at 1.6 right now 17:34:12 so pinning there is the "safest" 17:34:15 rather than "safeish" 17:34:17 also from 1.6 to 1.9 there are no backward incompatible changes 17:34:27 meaning that we won't break users using the default from last release 17:34:29 lucasagomes: I do not assume anyone uses master, except for rackspace 17:34:41 and delorean... 17:34:43 devananda, well, they are one but we don't have any data 17:34:53 so better we assume people use (you just gave 2 examples) 17:35:05 sure - I know they do. I assume others _might_ use master. but I _know_ many, many users who consume packages 17:35:10 * devananda points to the user survey 17:35:22 there is also packaging from master though 17:35:23 devananda, but that's cool, that's why I think 1.9 would be better 17:35:27 cause it doesn't break any of those 17:35:29 sure 17:35:41 while putting it back to 1.6 may break rackspace and/or delorean 17:35:42 so between 1.6 and 1.9 I dont have a terribly strong view 17:36:07 I'll give a few minutes for any other viewpoints to be expressed before we vote :) 17:36:13 ++ 17:36:19 1.9 is the least breakage in my view since it does not break 1.6 17:36:47 I would be okay with 1.9 here... just a side question that is not ment to side track the converastion.. when do we forsee a value > 1.11 being the default? 17:36:51 if it doesn't breaks with 1.6, we should go with the more up to date version 17:36:53 1.6 sounds cleaner, but 1.9 is probably the right thing to do... 17:36:57 NobodyCam, never? :) 17:37:24 NobodyCam: i'm hoping we can decide that we'll do that for N 17:37:27 * jlvillal assumes they are not talking about the DeLorean motor company. 17:37:44 * TheJulia requests time machine 17:37:53 jlvillal, heh no :-) not back to the future 17:38:01 * betherly agrees with TheJulia 17:38:02 fwiw, I feel that 1.6 is the cleanest because it pins the default to Kilo's default 17:38:02 nor* 17:38:08 NobodyCam: never? 17:38:17 jlvillal: https://github.com/openstack-packages/delorean 17:38:26 ack :/ 17:38:36 trown: Thanks. I was confused :/ 17:38:53 re: delorean, rather than just 'they package master' -- I would like to know if they use any features from v1.7 ... v1.9 17:38:58 if not, then it shouldn't affect them 17:39:24 ah - but that's not something we are likely to answer right now 17:39:26 devananda: that would be more about the users of the delorean packages though 17:39:32 I agree with devananda that 1.6 is the "cleanest", but to avoid breaking anyone even delorean or some unknown out there, it probably doesn't hurt to use 1.9 17:39:35 yea. I just realized that 17:39:35 agreed about cleaneast, but I still prefer to not break users using packaging OR master when possible 17:39:46 which is anyone consuming RDO 17:39:48 s/OR/AND* 17:40:11 rloo: "probably doesn't hurt" <<< sounds like my motto: "what could possibly go wrong" 17:40:16 also, both are famous last words :) 17:40:29 devananda: i believe you're the one that tells us to try not to break anyone? 17:40:36 indeed 17:40:39 lucasagomes: I may regret this, but don't worry about breaking our tools 17:40:47 lucasagomes: if we need to change our API versions we can and are willing to 17:40:58 JayF: thank you. ya'll are great at keeping up with changes to upstream 17:40:59 JayF, right, well I do 17:41:06 it's the rest of the world that consumes from packages which I worry about 17:41:10 JayF, cause I know it may not be only you 17:41:35 ok, we could discuss this all day, so let's vote 17:41:36 19 minutes left 17:41:57 devananda: if i understand you, you mean that folks that are using packages are using 1.6, so if we change to 1.9 it might possibly break them but we don't think it will? 17:42:49 #vote Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad? 1.6, 1.9, latest, abstain 17:42:55 #startvote Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad? 1.6, 1.9, latest, abstain 17:42:56 Begin voting on: Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad? Valid vote options are 1, 6, 1, 9, latest, abstain. 17:42:58 Vote using '#vote OPTION'. Only your last vote counts. 17:43:03 #vote abstain 17:43:03 #endvote 17:43:03 Voted on "Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad?" Results are 17:43:04 abstain (1): JayF 17:43:08 #undo 17:43:09 Removing item from minutes: 17:43:10 there's a typo 17:43:19 #startvote Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad? 16, 19, latest, abstain 17:43:20 Begin voting on: Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad? Valid vote options are 16, 19, latest, abstain. 17:43:21 Vote using '#vote OPTION'. Only your last vote counts. 17:43:31 apparently periods are separators 17:43:34 #vote 19 17:43:35 #vote 19 17:43:36 #vote 19 17:43:39 #vote latest 17:43:42 ##vote latest 17:43:42 #vote 19 17:43:44 #vote abstain 17:43:46 #vote 16 17:43:47 #vote latest 17:43:48 #vote 16 17:43:52 #vote abstain 17:43:54 #vote abstain 17:43:59 #vote 19 17:44:00 #vote 19 17:44:02 #vote 19 17:44:07 #vote abstain 17:44:08 #vote 19 17:44:14 #vote abstain 17:44:29 #vote abstain 17:44:41 giving in 30 seconds more 17:44:52 #vote latest 17:45:09 #endvote 17:45:10 Voted on "Pin and release a client with which versions ... 1.6 may affect users-of-trunk but is cleanest, 1.9 is newer than kilo but probably safe, latest is probably bad?" Results are 17:45:11 19 (8): NobodyCam, rloo, vdrok_, mariojv, trown, lucasagomes, JoshNang, thiagop 17:45:12 16 (2): TheJulia, devananda 17:45:13 abstain (6): cinerama, jlvillal, BadCub, JayF, Nisha_away, dtantsur 17:45:14 latest (3): betherly, krotscheck, gabriel-bezerra 17:45:37 1.9 is the clear leader. also it has the most votes from core reviewers present 17:45:44 latest breaks almost the whole world... 17:45:49 #agreed we'll pin the client to 1.9 17:46:07 #topic tokyo session layout 17:46:19 last time we had 2 fishbowl + 6 boardroom + 2 meetup 17:46:20 tokyo has smaller rooms and fewer fishbowls... and more projects! 17:46:37 devananda: are the fish bowls smaller too? 17:46:42 I think we need fishbowls because of these big topics: ironic+neutron, ironic+nova, deployment/packaging/release, drivers 17:46:48 NobodyCam: yes. everything is smaller. because tokyo 17:46:52 :) 17:46:55 devananda: please remind me. fishbowl smaller than boardroom, meetup the smallest? 17:46:58 I'm also suggesting that we share the meetup room with Infra b/c they are using Bifrost 17:47:04 devananda, one thing about the ironic+nova 17:47:11 fishbowl > boardroom > meetup 17:47:16 in vancouver we had 0 (zero) nova developers in the meeting 17:47:31 oh good point lucasagomes 17:47:32 lucasagomes: heh, good point. however, we had several ironic developers in the nova room 17:47:38 it would be good if some of them could join the ironic+nova meeeting thins time 17:47:45 devananda, right yeah 17:47:55 lucasagomes: or we dont put one on our schedule, and they bring us into theirs 17:47:57 the interests just doesn't seem to be mutual 17:47:58 that seems more their style 17:48:00 lucasagomes: i thought the ironic+nova discussions were in nova rooms? 17:48:25 rloo, we had one about how to scale up the nova compute (since now we can only have 1 n-cpu with the ironic driver loaded) 17:48:25 I imagine that Tokyo may have fewer attendees compared to Vancouver. Due to costs. Not sure. 17:48:28 otherwise it's racy 17:48:36 devananda, fair 17:48:42 lucasagomes: I agree. and honestly I wish more of us had attended that meeting. it was ... very interesting 17:48:53 jlvillal: I suspect you are right there 17:48:54 jlvillal: do not count on that 17:48:56 heh 17:49:00 for ironic+nova, seems better for us to go to them. interesting to watch the nova cores in action... 17:49:07 ++ indeed. But it's always good to have someone from that project to correct our assumptions 17:49:19 lucasagomes, ++ 17:49:33 lucasagomes: the "how to do nova.virt.ironic with HA" discussoin happened in the nova track. it was the basis for all the work jroll has been doing this cycle on it, fwiw 17:49:37 anyhow 17:49:54 do we know who would have the first meeting time.. Ie could we do both (in our track and the nova track) 17:49:55 any objections to 4 + 4 + 1 , and to sharing our friday meetup with the Infra team? 17:50:00 so if ironic+nova -> nova, we only need 3 fishbowls? 17:50:04 NobodyCam: no. we know nothing yet 17:50:18 rloo, yeah that's what I'm thinking too 17:50:24 then I have no objections at this time :p 17:50:28 the process is that all the PTLs propose a room count to ttx, he drafts a layout, then we all discuss and shuffle based on things like ^^^ 17:50:34 *10 minutes* 17:50:36 the problem with sharing friday meetup with infra team, is that in the last summit, even though we had a meetup room, it was too noisy and we had to look for other space. 17:50:45 rloo: good point 17:50:56 we need 2 meetups! 17:50:57 rloo: it was also super crowded, IIRC 17:51:06 so perhaps a larger meetup room? 17:51:14 devananda: yeah. more crowded than the boardrooms i think. 17:51:39 yeah, we shared with tripleo in Paris, it was a bit troublesome... 17:51:41 and previous to the last summit, there were more folks in the boardrooms. 17:51:48 devananda: please make sure I am not nominated to take on anything at Tokyo as I am not sure I will be attending yet 17:51:57 BadCub: duly noted 17:52:03 BadCub, :-( 17:52:09 especially since we seem to have a lot of stuff under the ironic umbrella these days. 17:52:14 :( 17:52:19 sad times BadCub 17:52:22 rloo, ++ 17:52:29 rloo: yea. we have our own umbrella now ... 17:52:38 * jlvillal is also not sure if he is going :( 17:52:52 also fridays tend to be slow, cause we're all tired and some folks are pack[ed/ing] and leaving 17:53:03 * betherly is still waiting to get my pass and also to hear if getting transport authorised 17:53:05 indeed 17:53:06 well, we've digressed to reminiscing :) 17:53:12 yup, fri after lunch is almost not worth it. 17:53:19 thanks for the feedback, all! I'll draft a reply to ttx after the meeting 17:53:22 rloo: agreed 17:53:28 #topic open discussion 17:53:50 i wanted to ask if anyone knew how ironic was going to align with the end of liberty timelines 17:54:00 ++ for question 17:54:06 cuz we're going to do an ironic release that coincides with that. 17:54:20 rloo: I know what we discussed in YVR, and what we wrote in the spec 17:54:22 but what about things like i18n changes, blah blah. oslo libraries.... can we continue to change? 17:54:57 and regardless of ironic release -- we should try to get nova/ironic driver bug/etc changes in before whatever deadline. 17:55:04 but we haven't ironed out all those issues yet, so pushing a new release when we want to, branching a stable branch, etc, isn't a well oiled machine right now 17:55:24 yeah, I don't have a very clear picture in my head as well 17:55:29 re: oslo libs, we probably need to adhere to the global requirements freeze 17:55:33 because of the nature of the gate jobs right now 17:55:38 I wanted to ask about viability of using utils.execute w/o checking output on binaries that could return unknown exit codes 17:55:54 natorious: erm, that sounds not good. 17:55:57 apparently we do that alot 17:55:57 natorious: also rootwrap 17:56:33 rloo: i18n things were awkward last cycle. it turned out we didn't get nearly enough translation work done to matter 17:56:42 so there was no benefit to our string freeze 17:57:02 I was wondering about Ironic having an event bus for state transistions, node enrolment, error events... How doable do you think it is? 17:57:19 devananda: yeah, which is why i've always wondered about string freeze for us. i guess for now, we can just worry about the global requirements freeze. 17:57:22 gabriel-bezerra, ++ 17:57:23 gabriel-bezerra: we've discussed it before. it's a serious rewrite of the core architecture of the project 17:57:30 devananda: not talking so much security as unknowns 17:57:36 gabriel-bezerra, it may require some changes, but I like the idea 17:57:41 I mean big changes 17:57:49 gabriel-bezerra: but one we all generally agreed wsa worth investigating 17:58:00 natorious: fwiw utils.execute defaults to check_exit_code[0] if not specified, unless I'm misremembering 17:58:08 JayF, ++ 17:58:12 *2 minutes* 17:58:16 natorious: What do you mean by not checking output? Not checking result code? 17:58:25 natorious: And what JayF says 17:58:35 devananda: like w/o seeing the binary source, and not being able to check every possible outcome, there could be failures returning exit code 0 etc 17:58:41 #link https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py#L117-L119 17:58:45