00:01:08 <ekcs> #startmeeting congressteammeeting
00:01:09 <openstack> Meeting started Thu Jun 15 00:01:08 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:13 <openstack> The meeting name has been set to 'congressteammeeting'
00:01:24 <ramineni_> ekcs_: hi
00:01:36 <ekcs> Hi all. Welcome back to another week. As usual, topics are here: https://etherpad.openstack.org/p/congress-meeting-topics
00:01:47 <ekcs> pls feel free to add/comment/edit
00:01:49 <ekcs> hi ramineni_ !
00:06:16 <ekcs> ok let’s get started then.
00:06:20 <ekcs> #topic announcements
00:06:31 <ekcs> Pike-2 released for congress and congress-dashboard
00:06:43 <ekcs> client 1.7 also released
00:06:57 <ramineni_> Great :)
00:07:36 <ekcs> the release for congress and congress-dashboard ended up being late because we forgot to set create the pypi project and set the project-config release job for congress-dashboard.
00:08:01 <ekcs> thankfully the release went out despite the hiccup.
00:08:28 <ekcs> lesson learned for me is to do the release early especially for initial release like congress-dashboard.
00:08:36 <ekcs> any other announcements?
00:09:50 <ramineni_> Oh ok
00:11:13 <ekcs> ok moving on then =)
00:11:27 <ekcs> #topic Rule ID logging for action execution
00:11:56 <ekcs> ramineni_: is there anything to talk about on that front? any follow-up questions or discussions?
00:13:22 <ramineni_> ekcs : actually I couldn't find a proper way to get the rule id in execute action part
00:14:17 <ramineni_> Because , I think there we need to update trigger registry to store rule id somewhere
00:15:13 <ekcs> yea so there are at least two ways to do it. one is to store rule id when the execute table is evaluated. that’s probably the more proper way.
00:15:38 <ekcs> but another is to after the fact query the execute table again using the explain feature to look at the rule that triggered it.
00:16:20 <ekcs> did you get my email about the explain feature?
00:16:34 <ramineni_> Trace right?
00:17:07 <ramineni_> Explain feature =trace ?
00:17:14 <ekcs> yea. does that seem promising?
00:17:54 <ekcs> theoretically you can query the execute table, find the rule that caused the particular entry that caused the recent execution, then query the policy engine again to retrieve the rule ID of that rule.
00:18:26 <ekcs> not sure if it’ll end up being more or less complicated than storing rule ID during first evaluation.
00:18:56 <ramineni_> Ya .. It's helpful .. Thanks.
00:19:33 <ramineni_> But I'm able to get the rule id if it's the single table
00:20:22 <ekcs> sorry what do you mean “single table”?
00:20:32 <ramineni_> Like execute [ nova.servers.pause], if there are 2 rules defined with same head
00:20:50 <ramineni_> Then which rule caused that is not available
00:21:16 <ramineni_> May be I have to dig more
00:21:22 <ekcs> got it do you have a sample output from trace?
00:22:01 <ekcs> I think the information is there (in the SUCCESS and FAIL), but it’s not obvious how to read it.
00:22:18 <ekcs> you can also email me later.
00:22:45 <ramineni_> Ya .. I'll email you on where I'm stuck
00:23:05 <ramineni_> Thanks for the pointers
00:23:10 <ramineni_> :)
00:23:26 <ekcs> ok great.
00:25:12 <ekcs> #topic policy monitoring UI discussions
00:25:45 <ekcs> Last time I think we have more or less a consensus on the mockup except for remedial actions.
00:27:18 <ekcs> I’m thinking we could focus on parts that don’t involve remedial actions. and it can always be added later.
00:27:32 <ramineni_> Yes, sounds good
00:27:58 <ekcs> but I did also added some mock-up having to do with remedial actions.
00:28:09 <ramineni_> UI part are we trageting for pike or q release
00:29:24 <ramineni_> Ok .. great , can you share the link
00:29:30 <ekcs> I’m hoping we can get the basic version into Pike. Just displaying the number of errors and warnings per policy in the main page, and displaying the warning and error table.
00:29:37 <ekcs> does that seem reasonable?
00:30:04 <ekcs> link is on the topics etherpad. here again: https://wireframepro.mockflow.com/view/congress-policy-monitor
00:30:27 <ekcs> remedial action stuff we can discuss and target queen maybe?
00:30:28 <thinrichs> Hi all.  Sorry I'm late.
00:30:57 <ekcs> hi thinrichs !
00:31:19 <ekcs> we’re discussing policy monitoring UI.
00:32:03 <thinrichs> Ok
00:32:34 <ramineni_> Hi thinrichs
00:32:41 <thinrichs> ramineni_: hi
00:33:44 <ramineni_> ekcs_: ok
00:33:53 <ekcs> we’re talking about whether we can reasonbly finish the basic version in Pike, without addressing remedial actions.
00:34:09 <ekcs> Here’s the latest mockup btw, https://wireframepro.mockflow.com/view/congress-policy-monitor
00:36:15 <ekcs> we could also talk about the latest additions in the mock-up for remedial action, if there’s something to discuss now. or leave for another time. not urgent.
00:37:24 <thinrichs> The remedial action is the V2 comment, right?  That records how many action executions there were.
00:37:42 <thinrichs> I would think we should separate (i) adding functionality to backend and (ii) creating the UI
00:37:45 <ekcs> thinrichs: right. also some things in the per policy page
00:37:55 <thinrichs> So that we don't create a UI until the backend supports the info the front-end needs.
00:38:10 <thinrichs> I don't think we have counters on the backend for how many times an execution fired
00:38:20 <thinrichs> or even if all of the action-execution firings correspond to policy violations
00:38:37 <thinrichs> They could be sending out logs or shuttling data to another service
00:39:34 <ekcs> thinrichs: right, we don’t. but knowing what front-end we’d like helps us know what back-end functionality is needed right?
00:41:45 <ekcs> anyway the discussions around remedial action in the UI is early stage. we can move on if there isn’t much to talk about right now.
00:42:17 <thinrichs> +1 to using the UI to generate requirements for backend
00:43:06 <ekcs> ok let’s move on for now then. feel free to comment on the mockup. (no signed needed I believe to comment)
00:43:18 <ekcs> #topic policy library discussions
00:43:54 <ekcs> Thanks for the reviews on the policy lib data model patch. I’m working on a second patchset addressing the comments and including the API methods.
00:44:13 <ekcs> One point to address:
00:44:35 <ekcs> is it important to have the UUID for the library policies?
00:45:12 <ekcs> I remember hearing about how UUID was added to the policy enigne policies API because people wanted that.
00:45:19 <ekcs> would the same reasons apply here?
00:45:34 <thinrichs> Trying to remember...
00:45:48 <thinrichs> People definitely expected a UUID on all the resources
00:46:05 <thinrichs> We tried just having the name for a long time (and even called it the ID), but that didn't help
00:46:38 <thinrichs> Do we expect the names to be unique for the library?
00:46:53 <ekcs> Hmm ok. So that means we should have UUID here too then?
00:46:56 <thinrichs> The names had to be unique for the policies so that we could reference policy A from policy B as A:foo
00:47:13 <thinrichs> But for the library, it's not as clear that all the names need to be unique
00:47:44 <thinrichs> You could have 3 policies named A, with a policy B that references A:foo, and it's the user's job to pick which version of A to instantiate.
00:48:22 <thinrichs> (Maybe the 3 policies differ in whether they reference glance or glare; ceilometer or monasca; etc.)
00:48:38 <thinrichs> In both cases I'd lean toward having a UUID for each policy in the library.
00:49:06 <ekcs> hmmm. that’s a good point. I had designed for the names to be unique even in the library. but then you lose this use case.
00:50:35 <ekcs> but regardless of whether names are unique, people want to see UUID.
00:50:50 <thinrichs> right
00:50:50 <ekcs> correct?
00:50:53 <thinrichs> yep
00:51:01 <ekcs> ok.
00:51:21 <ekcs> and hmm any more arguments for or against unique names in library?
00:52:51 <ekcs> I can’t think of any reason to insist on uniqueness.
00:53:30 <ekcs> except maybe it’s easier to activate a policy by name in CLI. weak argument though.
00:54:00 <thinrichs> Could always do a lookup: given name, find the UUID
00:54:17 <thinrichs> (meaning the CLI could do the lookup, and the API could require having a UUID)
00:54:25 <thinrichs> Or the API could accept both
00:54:55 <thinrichs> I've got to run home.  Just found out the nanny bailed (again)
00:55:08 <ekcs> ok later thinrichs
00:55:13 <thinrichs> Thanks all!
00:55:24 <ekcs> ramineni_: any more thoughts on uniqueness of names or anything else policy library?
00:56:17 <ramineni_> Nothing from my side
00:56:27 <ekcs> ok then!
00:56:31 <ekcs> #topic open discussion
00:56:39 <ekcs> anything else to talk about?
00:56:50 <ekcs> if not we can call it =)
00:56:55 <ramineni_> Are we having ptg
00:57:04 <ramineni_> ?
00:57:22 <ekcs> oh right. I responded probably to the questionaire.
00:57:28 <ekcs> meant to talk about it at some point when people are around.
00:58:02 <ramineni_> Oohk ..np ..we can discuss next time then
00:58:46 <ekcs> basically I think it’s really helpful to have the time set aside to talk. but it may also be an option to do it remotely to avoid a trip. but the time difference makes it complicated too. and it’s hard to get the same kind of dedicated time.
00:59:17 <ekcs> yea please think about what you think is best and email me or ML and we can also talk about it at future meeting.
00:59:17 <ramineni_> Ya , right
00:59:28 <ramineni_> Sure
00:59:55 <ekcs> alright then. more next time!
01:00:01 <ekcs> #endmeeting