00:00:42 <ekcs> #startmeeting congressteammeeting
00:00:42 <openstack> Meeting started Thu Sep  7 00:00:42 2017 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:46 <openstack> The meeting name has been set to 'congressteammeeting'
00:00:49 <thinrichs> Hi all
00:01:04 <ekcs> Hi all. Welcome back to congress meeting.
00:01:17 <ekcs> as usual topics are kept here: #link https://etherpad.openstack.org/p/congress-meeting-topics
00:01:25 <ekcs> pls feel free to read/comment/add
00:05:20 <ekcs> ok let’s dive in then.
00:06:11 <ekcs> quick announcement: I’m joining a webinar today/tomorrow on openstack pike updates to talk a little bit about Congress. Here’s a link: https://content.mirantis.com/Webinar-OpenStack-Pike_Landing-Page.html
00:07:17 <ekcs> Not many items of business today.
00:07:20 <ekcs> #topic PTG
00:09:26 <ekcs> We’re still firming up the agenda. but we have topics around Congress use cases and direction, in particular the fault management / self-healing use cases.
00:10:02 <ekcs> Expecting a special session with other projects on how the difference services fit together for fault management.
00:10:12 <ekcs> Anything to talk about here for PTG?
00:10:47 <thinrichs> Sounds good to me
00:11:56 <ekcs> Ok moving on then =)
00:12:50 <ekcs> #topic meeting time
00:13:12 <ekcs> At the end of a cycle it’s a good time to think about whether our current meeting time is working for us and whether we want to change it.
00:13:29 <ekcs> But since most of us aren’t here today, maybe we’ll table the topic
00:13:44 <ekcs> I can initiate it over email.
00:13:59 <thinrichs> Sounds good to me
00:14:00 <ekcs> thinrichs: do you have any thoughts about meeting time?
00:14:20 <thinrichs> Historically it's been hard getting something that works for ramineni, masahito, and anyone in the US.
00:14:26 <thinrichs> Timezone skew is large
00:14:37 <thinrichs> There's never been a good time to do it
00:15:04 <thinrichs> But certainly it makes sense to revisit on the ML and see if anyone's schedule has changed
00:16:23 <ekcs> thinrichs: got it. great we’ll do that then.
00:16:40 <ekcs> #topic open discussion
00:16:52 <ekcs> thinrichs: anything else we want to talk about today?
00:17:30 <thinrichs> Not from me.  Any reviews that need my attention?
00:18:46 <ekcs> Nothing specifically requiring your attention. The most substantive thing around is songming’s qos patch ready for review #link https://review.openstack.org/#/c/488992/
00:19:07 <thinrichs> That breaks the problem around QoS into 2 drivers, right?
00:19:32 <ekcs> along with tempest testing all done. so it’d be good to get that in.
00:19:33 <ekcs> riht.
00:19:37 <ekcs> right
00:21:00 <ekcs> The process of that driver along with the experience working with the magnum and designate drivers (incomplete because of tempest tests)
00:21:31 <ekcs> showed me just how difficult it is to do tempest tests
00:22:46 <ekcs> mostly around figuring out how to interact with each new service. the bulk of the total work end up in dealing with tempest tests. and a huge hurdle for newcomers.
00:23:02 <ekcs> I wish I knew a good solution but I don’t.
00:23:43 <thinrichs> Cross-system tests are always hard b/c you need to understand both ends.  At least it's easy to get the non-Congress service running with Tempest.
00:25:35 <ekcs> thinrichs: right. It makes me wonder whether insisting that we get the tempets tests done along with new drivers is the right way to go. it seems necessary because otherwise we end up with broken drivers all the time. but also a huge hurdle. anyway….
00:26:47 <thinrichs> I don't see a good solution either.
00:26:52 <thinrichs> Looking through the reviews...
00:27:04 <thinrichs> Do we know why these DSENode tests are flaky?
00:27:05 <thinrichs> https://review.openstack.org/#/c/498996/1
00:27:28 <thinrichs> Those look to be pretty core.  Is it just timeouts?
00:28:11 <ekcs> I don’t know yet. ramineni filed a bug on it and is looking into it.
00:28:19 <ekcs> yes it looks pretty core.
00:28:37 <ekcs> if it’s something fundamentally unstable about the in-mem transport, then we have a serious problem.
00:29:18 <ekcs> on the other hand, I don’t remember ever noticing it affecting something else other than these tests.
00:29:28 <thinrichs> If all the other tests are working though it'd be weird if there was something really wrong.
00:29:56 <ekcs> right that’s why I’m not quite worried. but we need to understand what’s going on.
00:30:56 <masahito> hi, sorry late
00:31:03 <ekcs> hi masahito !
00:31:36 <ekcs> we’re just in open discussion now.
00:32:23 <ekcs> Another topic is around the place of congress in a larger fault-management/self-healing infra.
00:33:04 <ekcs> so far all the examples I have found have fairly simple conditions for triggering action.
00:34:21 <ekcs> which may not justify a place for the flexible policy language of congress because they can be done directly in monitoring services like monasca or vitrage.
00:35:06 <ekcs> So I’m looking for examples of the need for more complex conditions that span data sources and services. to better understand the place for congress.
00:35:34 <ekcs> definitely love to hear/see any thoughts or references you may have.
00:36:42 <masahito> one of the moderators in the discussion is my colleague.
00:37:07 <ekcs> masahito: right. Sampath?
00:37:40 <masahito> so if there is any question that you want to have an answer, I can ask it of him.
00:37:42 <masahito> right
00:38:49 <ekcs> got it.
00:43:33 <ekcs> I’m looking to understand whether/where there is a need for complex multi-source/service conditions for fault management actions. alarming services can set certain conditions. workflow services can take proper actions based on conditions too. so one can connect the alarming services directly to the workflow services. I think there is a benefit to having a policy layer in between that consumes the alarms and other data before triggering the workflows.
00:43:43 <ekcs> but we need to understand and make the case.
00:46:42 <ekcs> anyway do hit me up if you have any more thoughts or suggestions later.
00:46:51 <ekcs> anything else we want to talk about?
00:46:51 <masahito> got it.
00:49:11 <ekcs> ok unless there is something else let’s call it a day.
00:49:32 <ekcs> next week is PTG so let’s cancel the IRC meeting.
00:49:38 <thinrichs> Sounds good
00:50:05 <ekcs> I’ll announce on ML.
00:50:29 <ekcs> Ok see you all next time then! have a great week
00:50:41 <masahito> see you
00:51:15 <ekcs> bye!
00:51:19 <ekcs> #endmeeting