16:00:54 #startmeeting interopwg 16:00:55 Meeting started Wed Mar 7 16:00:54 2018 UTC and is due to finish in 60 minutes. The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:58 The meeting name has been set to 'interopwg' 16:01:13 #chair eglute hogepodge 16:01:14 Current chairs: eglute hogepodge markvoelker 16:01:25 o/ 16:01:36 hi 16:02:01 #link https://etherpad.openstack.org/p/InteropWhistler.8 Today's Agenda 16:02:29 We may have a bit of a small crew today as I understand some folks are still traveling or recovering from travel. =) 16:02:47 o/ 16:03:02 Hopefully everyone got home before the next blizzard strikes 16:03:27 Please take a look at the agenda and add anything else we need to talk about today. 16:04:10 #topic Board Meeting Update 16:04:35 I think everyone in the meeting today was also in Dublin, so quick recap: 16:04:59 hi 16:05:07 The Board approved three new Guidelines at their meeting in Dublin, including the 2018.02 guideline and two new add-on programs for Designate and Heat 16:05:56 There were a couple of minor corrections that needed to be made to the 2018.02 doc (missing aliases, a test or two that need admin creds, a missing name, etc). 16:06:13 I think we've landed those all except one typo that needs correcting (which was totally my fault): 16:06:15 thanks markvoelker for fixing those 16:06:25 #link https://review.openstack.org/550514 One more typo to fix 16:06:55 * markvoelker reckons everybody can now figure out which editor I used to write that 16:07:00 thanks! 16:07:21 :-) 16:08:03 We also gave the Board an update on where we're at with the NFV program and what we're targeting 16:08:18 There are some notes here if folks haven't perused yet: 16:08:23 #link https://docs.google.com/document/d/1kgmdHTb0ve340sdwO8-8-vKTaCqFSNtGxSBvSwofeJE/edit#heading=h.yjel5gfxgg3h BoD Report 16:09:21 I think that more or less wraps up BoD notes...anything else folks want to mention that I may be forgetting before we move on to other PTG stuff? 16:09:43 i dont think so 16:10:06 #topic PTG Recap Notes 16:10:40 Here's a link to our etherpad for Dublin. Discussion was cut a little short on account of the venue closing due to the snowstorm, but I think we managed to cover most of it: 16:10:48 #link https://etherpad.openstack.org/p/InteropDublin2018PTG Dublin PTG Interop Etherpad 16:12:10 One still-lingering item that was discussed a lot both in multiple meetings (ours, QA, TC) was where to put interop tests.... 16:12:37 There's been a bit of back-and-forth on this (again). The most recent discussion was at the TC meeting on Friday. 16:13:24 Here's the current proposal being debated: https://review.openstack.org/521602 16:13:41 i think the most important part is that we have good tests. the location shouldnt matter so much. So, I am down with whatever 16:13:48 Clarify testing for interop programs 16:14:01 oops 16:14:02 #link https://review.openstack.org/521602 Clarify testing for interop programs 16:14:30 If you read this a couple of months ago, please read it again--it's markedly different now. 16:14:36 (following the TC discussion) 16:14:52 thanks markvoelker 16:14:55 will def read it again 16:16:05 You may also want to peruse the TC meeting etherpad: 16:16:16 #link https://etherpad.openstack.org/p/PTG-Dublin-TC-topics TC Dublin Etherpad 16:16:47 thanks markvoelker 16:18:07 Personally I don't have a strong opinion on the test location at this point since RefStack can handle multiple locations anyway. Seems like we're trying to find a happy medium where we don't put too much burden on QA and the project teams while maintaining some review consistency here. 16:18:25 sounds reasonable 16:18:41 If folks do have strong opinions, I'd encourage you to chime in on the discussion 16:19:02 One AI that did come out of all those discussions for us: 16:19:32 There's a bit of a chicken-and-egg problem that we've discussed before where we might want to add some tests to a guideline (Powered, Add-on, or vertical) 16:20:09 IF there's TC direction that all tests should go in some particular place (currently Tempest), do we need to get those tests into that place before we add them, or is adding them to a guideline the signal that they should be moved? 16:20:31 I think the last option is fine 16:20:47 initially new capabilities are advisory anyway, right? 16:21:02 so, moving then later could work 16:21:23 QA and the TC representative in the room asked that we get them moved first, then add them to a Guideline, as this helps them understand what they're getting into and make sure they have the resources to maintain things. They can also then register objections (like the current objection with the Heat tests being gabbi tests vs "classical" tempest tests). 16:21:42 :-) 16:22:05 well, I do see their point 16:22:21 my opinion has always been we should evaluate tests where they are, move them if necessary 16:22:25 Here again, I personally don't have a strong opinion either way so if it makes life easier QA then I'm happy to write something up in our procedure docs indicating that that's the order we'll do things in. 16:22:43 It seems that some folks on the TC want them to be in Tempest before we evaluate them, which is my mind is nonsense. 16:22:59 Especially with a directive for projects to be responsible for their own tests. 16:23:26 hogepodge: Well, I think that bit depends heavily on the outcome of https://review.openstack.org/#/c/521602/ =) 16:23:51 So I guess my opinions about that are strong. We're not bound by the TC, and IMO we should continue to evaluate non-tempest tests. 16:24:54 I absolutely think it's fine to evaluate them. I think they're just asking that if we decide there's a test we want, we get it moved into [whatever place is decided] before we actually include it in a Guideline. 16:25:12 but doesn´t the evaluation take place before anything else anyway? 16:25:28 If it can move to Tempest in a reasonable way, I prefer that. 16:25:50 To me Heat is a special case. That's the issue. 16:26:42 georgk: Yes. But in the past we've kind of said "ok, we want this test, let's add it to the Guideline and the project can get it moved into Tempest and us adding it to the guideline will serve as a signal to tempest that they should accept the test" 16:26:50 But that landed us in the current situation with Heat 16:27:27 So now they're basically saying "let's just tell QA we want the test, and we can figure out what needs to happen to make it sustainable *before* it becomes required" 16:27:53 I'm a bit annoyed at Heat too, though. This is an ongoing problem, and I thought they had worked out solutions to it. Going with a special test framework has been problematic from the beginning. 16:28:22 So that is to say, I'm impatient with all sides of this argument. 16:29:27 * eglute wonders which side hogepodge will take :D 16:30:01 Ideally, I'd like for us to evaluate API tests that are compatible with Tempest and move them to Tempest once they qualify for the trademark program. 16:30:43 ... until a NFV vertical comes along ;-) 16:30:48 :D 16:31:10 YEah, I think there's debate about "compatible" too...e.g. does that indicate no new dependencies (like gabbi)? 16:31:20 haha yeah, I'm not considering the side verticals in that. 16:32:21 Ultimately one root problem here is that QA is strapped for resources...bear in mind three people did over 50% of their reviews last cycle. So they're understandable hesitant to take on new stuff. 16:33:22 At any rate: if you've got opinions please chime in on the review and let's see if we can get this settled. I'd love for something to be decided that everyone can adhere to rather than it drag on for another several months. 16:34:30 Anything else people want to mention about this now before we move on? 16:35:31 nope 16:35:33 I guess one thing we should mention is that we were waiting on https://review.openstack.org/#/c/529836 to land to add ID's to the heat tests, but that may stall out until https://review.openstack.org/#/c/521602/ is decided 16:36:37 #topic Add-on/Vertical Programs 16:37:29 As mentioned above, we provided some updates to the BoD on the NFV program but did not request approval for anything yet as it's still a bit fledgling. See the board doc for notes on what we're targeting. 16:37:33 markvoelker i thought that the heat patch is ready to merge? 16:37:48 eglute: see Zane's note on that review =) 16:38:18 markvoelker i am tempted to merge the patch 16:38:33 since we need to update the guideline with the new tests anyways 16:38:42 and then update again when they move 16:38:47 thoughts? 16:40:03 My inclination is to wait a little bit longer and see if we can get the location issue resolved. Seems like we have some activity there thanks to the face-to-face discussions in Dublin so I'm (perhaps overly) optimistic that some progress might get made there. 16:40:27 markvoelker how long do you think we should wait? 16:40:42 It seems rather likely at the moment that those tests aren't going into tempest at this point as QA has said no. 16:41:40 ok... 16:41:59 I think it probably makes sense to at least let one more TC meeting go by so we can see if htey resolve the matter or not. 16:42:33 that sounds reasonable 16:43:13 Shall we plan to land it next week if this doesn't get worked out? 16:43:23 works for me 16:44:10 in the meantime, we can nevertheless include it in the NFV vertical, I assume? 16:44:37 georgk yes i think so, since the tests in question are for advisory 16:44:47 georgk: Yes, I think it's fine to add it to the NFV program. That won't be finalized for some time anyway so if anything truly weird happens we can always back it out again. 16:44:47 and the orchestration guideline was approved 16:44:52 (but I don't think it will) 16:45:06 yes, ok 16:45:23 Ok, anything further on this topic? 16:45:52 no, sorry to derail 16:46:05 eglute: they were directly related anyway =) 16:46:11 #topic meeting cadence 16:46:49 One matter we discussed in Dublin was whether we still needed to meet every week, or if an every-other-week cadence was better suited given the current pace of things 16:47:23 Most present felt that once every other week would be fine, but I thought we should mention it here too for those not present in Dublin in case there are other opinions 16:48:10 Mechanically, I'd be inclined to leave our reservation for every week on #openstack-meeting-3 so we can call meetings during off-weeks if something comes up, but I think every other week is generally fine. 16:48:22 markvoelker agreed 16:48:51 Anyone have opinions to the contrary? 16:49:00 sgtm 16:49:09 sounds good 16:49:10 nope 16:49:22 Ok, in that case... 16:49:47 #agreed Move to every-other-week meeting cadence with option to meet on off weeks if something important comes up 16:50:16 That means no meeting next week (which works great for me since I'll be in a tent in a swamp in Florida anyway) 16:50:26 thanks markvoelker 16:50:38 #info No meeting next week 16:50:47 * eglute thinks beach would be nicer than swamp 16:51:49 * markvoelker has been called a pythonista since working on OpenStack and heard there were lots of pythons in the Everglades, so.... 16:52:03 #topic Guideline cadence 16:52:04 and an alligator or two as well, i bet 16:52:28 Last topic for the day: there's been some discussion about potentially changing the cadence of Guidelines too 16:53:13 There are a lot of things to think about here, such as the span of releases covered in a Guideline, how plans for "long term maintenance" branches shape up, and the rate at which we add things to Guidelines 16:53:35 not sure if we need to officially change the cadence since we will have to move advisory to required 16:54:36 I'm not sure we have time to think through it all in the remaining 5 minutes, but it'd be good to start hashing through mentally if nothing else. 16:54:57 markvoelker +1 16:55:15 Consensus in Dublin was that we do at least want to do a Guideline this fall since we have some things we'd like to get promoted 16:56:21 Folks may also want to be aware of the release cycle discussions that are happening too.... 16:56:30 #link https://etherpad.openstack.org/p/release-cycles-ptg-rocky Release cycles, stable branch maintenance, LTS vs. downstream consumption models 16:56:59 See also: 16:57:14 #link https://review.openstack.org/#/c/548916/ Add a resolution about stable branch EOL and "extended maintenance" 16:57:35 Three minutes remaining, so... 16:57:38 #topic Open Floor 16:57:48 Anything else folks want to talk about today (very quickly)? 16:58:15 i am good :) 16:58:31 good luck with pythons markvoelker, be sure they are pep8 compliant 16:58:52 :-) 16:59:04 #info It was great to see most of you again in Dublin. Thanks for all your continued efforts! 16:59:14 yes, thanks everyone!!! 16:59:27 #endmeeting