00:01:06 <ekcs> #startmeeting congressteammeeting
00:01:07 <openstack> Meeting started Thu Oct 26 00:01:06 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:10 <openstack> The meeting name has been set to 'congressteammeeting'
00:02:33 <ekcs> Hi all! welcome back. topics here as usual. add/comment/edit as you see fit. #link https://etherpad.openstack.org/p/congress-meeting-topics
00:02:52 <thinrichs> Hi all
00:04:19 <ekcs> hi thinrichs !
00:04:31 <ekcs> topics are here as usual: https://etherpad.openstack.org/p/congress-meeting-topics
00:04:33 <thinrichs> Wondered for a minute if the meeting time had changed
00:04:52 <ramineni_> ekcs: thinrichs :hi
00:04:59 <ekcs> hi ramineni_
00:05:22 <thinrichs> hi ramineni_, ekcs
00:05:56 <ekcs> ok let’s dive in then.
00:06:05 <ekcs> #topic meeting time
00:06:15 <ekcs> Proposed move to Fridays 02:30 UTC to make time more bearable for India.
00:06:24 <ekcs> Got feedback privately and also sought feedback on ML. If there are no objections, let's go ahead and make the switch starting next week.
00:06:50 <ekcs> Any more thoughts about the time change?
00:08:45 <ekcs> Ok then I’ll send out an ML announcement for the change effective next week (Nov 3).
00:08:58 <ekcs> #topic Gate status
00:09:10 <ekcs> Our gate is not in great shape right now.
00:09:30 <ekcs> Master blocked as of 10/25 because An object we mock in testing has been removed in oslo policy 1.29
00:09:54 <ekcs> Here is the commit: https://github.com/openstack/oslo.policy/commit/7e185ad96b043c0cb450a6dfc6245db7aa4a0fd6#diff-38dac991635941a0cc209c729f58298eL280
00:11:10 <ekcs> Stable branches are also blocked, hopefully will be resolved by backporting this Murano devstack patch (don’t attempt to contact now defunct app catalog): https://review.openstack.org/#/c/507740/
00:12:59 <ekcs> Replicated Congress integration tests all failing well before getting to Congress. Hopefully to be worked out here with some help from infra folks: https://review.openstack.org/#/c/509697/
00:14:05 <thinrichs> That one looks interesting.
00:14:26 <ekcs> Which one?
00:14:47 <ekcs> last one?
00:14:48 <thinrichs> The 2nd one.  Seems zuul was updated
00:15:29 <ekcs> right. since the change to zuul v3 that’s been failing.
00:16:07 <ekcs> anyway.
00:16:42 <ekcs> moving on then?
00:17:07 <thinrichs> Yep—seems like a lot of work's gone into the gate tracking all that down
00:17:50 <ekcs> yea hopefully things get back to normal soonish. not great to be going without the replicated tests.
00:18:22 <ekcs> #topic sydney summit
00:19:01 <ekcs> So I wanted to mention some Congress-relevant events at the sydney summit.
00:19:48 <ekcs> I’m doing a project update. here are the slides I’ve been working on: https://docs.google.com/presentation/d/1vxp_kb-d-HDalu5G-zPa1tqHTYIl3Cwp6G_gjrDEfdU/edit#slide=id.p8
00:19:57 <ekcs> Thanks thinrichs for the helpful feedback.
00:20:56 <ekcs> comments and suggestions still appreciated. particularly around whether there are helpful significant things to mention that I’m leaving out.
00:21:33 <ekcs> masahito and I will be doing our first ever congress onboarding event.
00:21:41 <ekcs> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20429/congress-project-onboarding?BackURL=https%3A%2F%2Fwww.openstack.org%2Fsummit%2Fsydney-2017%2Fsummit-schedule%2Fglobal-search%3Ft%3Dcongress%23eventid%3D20429
00:22:20 <ekcs> Not really sure what to expect, but the idea is people interested in contributing can show up and get an overview of the project & code, and get a jump start.
00:22:48 <thinrichs> Sounds fun!
00:23:04 <thinrichs> Will they get to try using Congress, or is it focused more on developing Congress?
00:23:54 <ekcs> it’s focused on developing. my thinking was so do a quick version of the project update presentation and follow with overview of code and answering more questions at length.
00:24:00 <ekcs> but now that you mention it,
00:24:13 <ekcs> trying it out could be really good too.
00:25:11 <ekcs> do please share any other suggestions with me or masahito.
00:26:17 <ekcs> Then I’m also going to be part of the self-healing infra forum session.
00:26:25 <ekcs> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20508/self-healing-and-optimization-sig?BackURL=https%3A%2F%2Fwww.openstack.org%2Fsummit%2Fsydney-2017%2Fsummit-schedule%2Fglobal-search%3Ft%3Dself-healing%23eventid%3D20508
00:27:02 <ekcs> It’ll be a lot of people and not a long meeting, so I’m not sure whether we’ll get down into much detail or mostly just logistics of the new SIG.
00:27:57 <ekcs> I’ve been working on some Congress examples to be ready to share there if appropriate. I’ll ask for more feedback when ready.
00:28:37 <ekcs> any other thoughts about what we want to bring to the forum, please share here or later with me =)
00:29:37 <ekcs> this forum etherpad has some discussion topics already: https://etherpad.openstack.org/p/self-healing-rocky-forum
00:30:22 <ekcs> any more comments about the events I mentioned or anything else about the sydney summit?
00:31:03 <thinrichs> No from me.  The self-healing forum looks like it's got the right folks attending
00:32:03 <ekcs> great.
00:32:05 <ramineni_> And monitoring demo ..is it just a session
00:32:20 <ramineni_> Already implemented one ..I mean
00:32:26 <ramineni_> Using all projects
00:34:06 <ekcs> ramineni_: right there is also a presentation that mentions using Congress.
00:34:11 <ekcs> DMA(Distributed Monitoring and Analysis): Monitoring Practice and Lifecycle Management for Telecom
00:34:24 <ekcs> I’m not clear on all the details myself, but plan to find out more there.
00:34:44 <ramineni_> Ok ..nice ..looks interesting
00:34:58 <ekcs> In this presentation, we will show the service lifecycle management, enlarging the scope of our framework to utilize monitoring data for failure recovery. The advantages of the framework are (1) fast fault detection by shorter interval monitoring (2) silent failure detection by machine learning with various types of metrics. The presentation also includes a demo, showing a workflow of quick service recovery, interworking among OpenStack, including Congre
00:34:58 <ekcs> Ceilometer and Aodh, collectd, scikit-learn and related OPNFV projects.
00:35:26 <ekcs> Right I’m curious to see how Congress fits in.
00:36:05 <ekcs> a broader thought on “machine learning” in infra management.
00:37:20 <ekcs> I’ve been wondering whether Congress makes sense as a human-specified layer that sits between “machine learning” signals and remedial actions.
00:38:51 <ekcs> basically we’d add additional data sources / alarms based on machine learned signals. and write policy over those. Not sure whether there is a good case to be made for doing things that way.
00:40:10 <ekcs> does it provide something valuable over directly connecting machine learing signals to remedial actions?
00:40:51 <ekcs> does it negate any value?
00:41:00 <ekcs> all fairly open questions I think.
00:41:35 <thinrichs> Yep—guess it depends on whether you want ML to figure out the actions, or whether you want people to codify the logic that translates ML signals into action.
00:42:30 <ekcs> thinrichs: right. and also if we want ML to figure out some actions, but override it in some circumstances, would congress make sense as a layer for that control.
00:43:39 <ekcs> anyway. for the rest of the time, we can continue the driver loading discussion, or discuss any open patches, or discuss the config verification spec, or anything else we want to talk about.
00:44:49 <ekcs> any thoughts?
00:48:01 <ramineni_> Driver loading ..I think we have discussed  a lot ,but not everyone on agreement:)
00:48:31 <ekcs> I think ramineni_ and thinrichs are more or less in agreement.
00:48:42 <ekcs> #topic driver conf
00:48:53 <ramineni_> I'm inclined towards stevedore ..if everyone else thinks not good option .. we can ignore this
00:49:02 <ekcs> but I added a new suggestion.
00:49:36 <ekcs> Something I sent out over ML a while back #link https://etherpad.openstack.org/p/congress-driver-conf
00:50:37 <ramineni_> Which point number
00:50:50 <ekcs> the way I understood it from our discussions, there are three main questions to answer.
00:51:04 <ekcs> we all agree that on a clean slate installation of Congress, all packaged drivers should be available for use without specific config.
00:51:08 <ekcs> but questions:
00:51:12 <ekcs> 1. what to do with exsting drivers config in existing installation upgraded to new Congress?
00:51:25 <ekcs> 2. specify the options by class path or by driver name
00:51:31 <ekcs> 3. lazy loading or eager loading
00:51:56 <ekcs> my new suggestion is
00:52:06 <ekcs> 2.3
00:52:48 <ekcs> on the question of what to do with existing driver config.
00:53:47 <ekcs> during the previous discussion, I think ramineni_ and thinrichs liked 2.2. ekcs liked 2.1, but when I was summarizing the pros and cons, I realized 2.3 is an interesting option worth considering.
00:55:55 <ramineni_> I didn't understand 2.3
00:56:08 <ramineni_> Is it new option
00:56:18 <ramineni_> Supplement drivers
00:57:31 <ekcs> it means congress behaves by loading all default drivers PLUS all drivers specified on the conf option `driver`
00:58:36 <ramineni_> Ok
00:59:06 <ekcs> that way anyone with custom drivers don’t get broken with the upgrade.
00:59:34 <ramineni_> If anyone have written custom driver  .. it should be still ok to load new driver via setup.cfg ..will not be big change for them IMO
00:59:56 <ramineni_> We should eventually deprecate right anyway
01:00:54 <ekcs> ramineni_: can you add your thoughts to the pros and cons list in the etherpad?
01:01:05 <ramineni_> Hehe
01:01:07 <ekcs> since time is up.
01:01:09 <ekcs> =)
01:01:24 <ekcs> we can also continue next time but it’s helpful to lay it out in pros and cons.
01:01:29 <ramineni_> Ok ..no issue ..I don't think we will be in agreement :p
01:01:46 <thinrichs> See you all later!
01:01:57 <ekcs> ok later all!
01:02:04 <ekcs> #endmeeting