17:01:10 <thinrichs1> #startmeeting CongressTeamMeeting
17:01:11 <openstack> Meeting started Tue Dec  2 17:01:10 2014 UTC and is due to finish in 60 minutes.  The chair is thinrichs1. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:15 <openstack> The meeting name has been set to 'congressteammeeting'
17:01:16 <zhipeng> yo yo
17:02:29 <thinrichs1> We have 2 things on the agenda today (feel free to add): assigning milestones to blueprints and doing status updates.
17:03:04 <thinrichs1> Seems like we've got enough people to start with the milestones.
17:03:17 <thinrichs1> For those who aren't aware…
17:03:30 <thinrichs1> there are 3 milestones each code release (kilo is the next one).
17:03:44 <thinrichs1> Each milestone is basically a deadline for getting code committed.
17:03:52 <thinrichs1> All code must be committed by the 3rd milestone.
17:03:56 <thinrichs1> Here are the dates.
17:03:56 <thinrichs1> kilo1 Dec 18
17:03:57 <thinrichs1> kilo2 Feb 5
17:03:57 <thinrichs1> kilo3 Mar 19
17:03:58 <glebo> (fyi: AdvServ mtg runs concurrently to this mtg. My attention will primarily be there, but I'll try to keep an eye on this one)
17:04:08 <llu-laptop> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
17:04:08 <thinrichs1> glebo: understood.  Thanks.
17:04:38 <thinrichs1> So for those of you who have signed up to work on a blueprint, we want to get an idea as to when you think you'll be finished.
17:04:53 <thinrichs1> Then we'll assign the blueprint to the appropriate milestone.
17:05:26 <zhipeng> since we are targeting for opnfv releases, kilo 3 should wok for us
17:05:36 <zhipeng> for the reactive policy enforcement
17:05:56 <thinrichs1> zhipeng: there are 3-4 blueprints needed to implement reactive enforcement.
17:06:10 <thinrichs1> Ideally we'd space those out so that we see incremental progress throughout the release cycle.
17:06:55 <thinrichs1> One sec while I pull up a link.
17:07:27 <thinrichs1> For example, policy-engine-trigger
17:07:28 <thinrichs1> #link https://blueprints.launchpad.net/congress/+spec/policy-engine-trigger
17:07:49 <thinrichs1> is used by a couple of blueprints.  Ideally we'd have that land in kilo1 or kilo2.
17:08:02 <madhumohan> thinrichs: I started working on implementing modal operators last week (https://review.openstack.org/#/c/134376/2/specs/kilo/modal-operators-for-policy.rst)
17:08:35 <thinrichs1> madhumohan: great!  Think you'll have it done by Dec 18?
17:08:51 <thinrichs1> Or should we push that to Feb 5?
17:08:58 <zhipeng> okey so what do you think is best for those bps? I don't think we could pull a Dec 18
17:09:10 <thinrichs1> Agreed that Dec 18 is coming up fast.
17:09:20 <madhumohan> I should have the first version only by next meeting...
17:09:44 <zhipeng> and another problem is that we could do 2 BPs for the reasons of resources
17:09:55 <thinrichs1> The goal is to assign realistic dates for these blueprints.
17:10:08 <zhipeng> do you have other volunteers for reactive enforce?
17:10:13 <thinrichs1> So you tell me when you think they can get done.  Madhu: I'm guessing that means you think Feb 5 is reasonable?
17:10:37 <llu-laptop> for the bunch of bps for reactive enforcement, I think many of them are still being reviewed in the spec repository. How about put the proposed milestone into the specs being reviewed?
17:10:38 <thinrichs1> zhipeng: we can definitely spread the blueprints out.
17:10:44 <madhumohan> thinrichs: yes i think feb 5th would be reasonable..
17:11:00 <zhipeng> I think Kilo 2 should be reasonable for us as well
17:11:14 <thinrichs1> madhumohan: great!
17:11:22 <zhipeng> llu-laptop agree
17:11:24 <thinrichs1> zhipeng: which BPs are you talking about, specifically?
17:11:38 <zhipeng> have u got my email last week?
17:12:07 <sarob> zhipeng: llu, kirshan volunteered for also for reactive enforcement
17:12:20 <zhipeng> I think the trigger one and the reactive one
17:12:22 <thinrichs1> llu-laptop, zhipeng: I'm hesitant to put milestones into the specs.
17:13:04 <arosen> here's all the open reviews for congress-specs: https://review.openstack.org/#/q/status:open+project:stackforge/congress-specs,n,z
17:13:19 <thinrichs1> zhipeng: the reactive one can't be built until we also have the action-interface implemented.
17:13:34 <thinrichs1> Sounds like madhumohan is handling the modals.
17:13:42 <zhipeng> ah okey
17:13:44 <thinrichs1> So we just need to find someone for the action-interface.
17:13:46 <kitho_> we could help on reactive enforcement as part of the murano integration work
17:13:54 <thinrichs1> Sarob: can we volunteer kishan?
17:14:18 <sarob> thinrichs1 he signed on for it
17:14:45 <kitho_> for murano integration we will focus on the datasource/driver bp's first
17:15:00 <sarob> thinrichs1: as per #link https://etherpad.openstack.org/p/par-kilo-congress-design-session
17:15:13 <thinrichs1> sarob: so then let's assume the actin-interface is done by M2.  That gives us til M3 to put it all together with reactive-enforcement.
17:15:29 <thinrichs1> kitho_: makes sense to start with the murano datasource driver.
17:15:29 <sarob> thinrichs1: roger that
17:15:42 <kitho_> for murano integration we are still ramping up,  design by kilo1 and early version by kilo2
17:16:11 <thinrichs1> kitho_: by murano integration, are we talking about code changes to Congress or code changes to Murano?
17:16:29 <thinrichs1> Or … what code changes to Congress are we talking about?
17:16:41 <thinrichs1> I had (i) a murano datasource driver and (ii) multiple policies.
17:16:52 <thinrichs1> Is there anything else you think we need?
17:17:36 <arosen> the integration on the murano side to consume congress for the proactive enforcement
17:17:51 <kitho_> we will need some integration work for policy binding on murano side - maybe more murano side change
17:18:13 <thinrichs1> kitho_: understood.  Just wanted to double-check I wasn't missing a (known) pot of work somewhere.
17:18:38 <madhumohan> thinrichs: Anything on triggers ? Is someone working on it ? This is one of the 3 included for reactive enforcement BPs.
17:18:43 <thinrichs1> That was a fast and furious few minutes.  Did I miss anything?
17:18:59 <thinrichs1> madhumohan: zhipeng volunteered for triggers.
17:19:03 <zhipeng> yep
17:19:32 <thinrichs1> madhumohan: are you also working on aggregates?
17:22:22 <thinrichs1> llu_laptop: have you signed up for any blueprints?
17:22:39 <thinrichs1> Or would you like to?
17:22:57 <madhumohan> samta is working on aggregates and is almost done.. should have first patch in this week to support "count".
17:23:05 <llu-laptop> maybe https://review.openstack.org/#/c/134417/ ? But i'm still learning the code now
17:23:56 <thinrichs1> llu-laptop: we can find some starter projects if you'd rather begin there.
17:24:17 <sarob> cloudtoad: you online?
17:24:39 <thinrichs1> zhipeng: we should definitely go through a couple of rounds of design via the specs for the trigger blueprints.
17:25:03 <thinrichs1> We mainly just stubbed something in for the spec, expecting people to add comments to refine the design.
17:25:17 <llu-laptop> thinrichs1: what's the starter projects?
17:25:20 <thinrichs1> I'd like to see some details about how that will work.
17:25:24 <sarob> llu-laptop: perhaps work with straz on datalog-ng
17:25:40 <thinrichs1> sarob: I wouldn't call that a starter project.
17:25:57 <zhipeng> ok, I will be working on it this week, hopefully have more details on the triggers
17:26:15 <sarob> thinrichs1: its out of the main stream of priorities
17:26:15 <zhipeng> since we'll have to sync with opnfv proposals
17:26:19 <thinrichs1> llu-laptop: I don't have a list off the top of my head.  But something like fixing up some of our logging.
17:26:44 <thinrichs1> Something that doesn't take tons of programming but let's you see a good chunk of the code and get into the process of committing.
17:27:10 <arosen> llu-laptop:  i have a few ideas on starter bugs. I'll create some launchpad bugs and tag them with low hanging fruit.
17:27:13 <thinrichs1> Same goes for everyone, actually.  If you want a simple task or two to get your feet wet, drop me an email.
17:27:28 <thinrichs1> thinrichs@vmware.com
17:27:39 <llu-laptop> arosen: great, i'll search for the low hanging fruit tags
17:27:43 <thinrichs1> arosen: great!  Maybe email out to the ML once we've got a half dozen.
17:27:51 <arosen> sounds good will do
17:27:55 <kitho_> is there a backlog list of simple tasks
17:28:16 <arosen> kitho_:  not currently written down but i'll work on that this afternoon.
17:28:27 <llu-laptop> thinrichs1: yeah, I think we should use the publich ML as much as possbile
17:28:42 <sarob> i can help get you going for your first patch as well or other startup issues
17:29:07 <thinrichs1> llu-laptop: good reminder to use the ML.
17:29:13 <jwy> what is the ML?
17:29:25 <thinrichs1> openstack-dev Mailing List.
17:29:26 <arosen> we all generally idle in #congress as well so if you get stuck there that's a great place to live chat.
17:29:43 <sarob> openstack-dev@lists.openstack.org with subject starting with [congress]
17:30:07 <jwy> ah ok
17:30:33 <thinrichs1> jwy: I think you've signed up for the horizon-create-policies blueprint.
17:30:40 <jwy> i did
17:30:44 <thinrichs1> Which milestone should we assign that to?
17:30:59 <thinrichs1> Dec 18, Feb 5, Mar 19
17:31:10 <jwy> thinrichs1: feb is probably doable
17:31:59 <thinrichs1> Okay—I'll sign you up for kilo2.
17:33:04 <thinrichs1> kitho_: are you signed up for the murano datasource driver?
17:33:17 <thinrichs1> (Trying to match up IRC handles with names/emails.)
17:33:49 <kitho_> yes kitho == kishan thomas
17:34:20 <thinrichs1> Got it!
17:34:43 <thinrichs1> Which milestone should we assign that?
17:34:52 <thinrichs1> I realize you're probably going to do a starter project or 2 first.
17:35:02 <thinrichs1> Dec 18, Feb 5, Mar 19
17:36:13 <kitho_> murano data source  will be kilo2
17:36:23 <thinrichs1> Thanks.
17:36:55 <thinrichs1> madhumohan: Trying again.  Are you still planning to work on the datalog aggregates?
17:38:29 <thinrichs1> Maybe he's stepped out for a few minutes.
17:38:52 <thinrichs1> Okay—I think that's all the milestones we need.
17:39:19 <thinrichs1> Did anyone here sign up for a blueprint but not choose a milestone?
17:39:21 <madhumohan> thinrichs: Samta from my team has been working on aggregates. We should have the patch up for review this week
17:39:39 <zhipeng> thinrichs1 just to double check, trigger is kilo 2 right?
17:39:43 <thinrichs1> madhumohan: so do we think Dec 18 is doable?
17:39:45 <thinrichs1> zhipeng: yep
17:39:49 <zhipeng> great
17:40:19 <thinrichs1> And of course if things change, let me know.  It's better to know we're going to miss a deadline than not know and miss it anyway.
17:41:04 <madhumohan> thinrichs: first cut version with support for end of statement aggregate is doable...
17:41:30 <thinrichs1> Let's put it down for Dec 18, and if we miss it, we miss it.
17:41:45 <thinrichs1> Anyone else with a blueprint/milestone to discuss?
17:42:04 <thinrichs1> (Hopefully next cycle we'll be doing this at the summit.)
17:42:18 <llu-laptop> I saw on https://etherpad.openstack.org/p/par-kilo-congress-design-session, there is an item Granular/trigger-based datasource driver for ceilometer,
17:42:28 <llu-laptop> just wonder what's the details requirements of that?
17:43:11 <thinrichs1> And just another reminder: please refine the design of your blueprints by leaving comments in Gerrit and/or submitting changes to the spec via Gerrit.
17:43:25 <thinrichs1> llu-laptop: I'm dubious we have the bandwidth for that this cycle.
17:43:52 <thinrichs1> But the idea was to have the ceilometer driver only pull the data it needs based on the current policy in place.
17:44:02 <llu-laptop> ok
17:44:10 <thinrichs1> So if the policy required 'cpu-util' then the driver would only pull data for that metric, instead of data for all metrics.
17:44:21 <sarob> llu-laptop: it was spun out from the policy mid-cycle summit if member right #link https://etherpad.openstack.org/p/juno-midcycle-policy-summit
17:44:48 <thinrichs1> If we don't have a blueprint for that we should.
17:45:03 <thinrichs1> It's actually pretty important for properly integrating something with lots of data like Ceilometer.
17:45:27 <thinrichs1> Okay.  15 minutes left.  Let's try to get through some status updates.
17:45:30 <thinrichs1> #topic status
17:45:53 <thinrichs1> Who has made some substantial changes that we all need to know about?
17:46:32 <thinrichs1> I've been debugging Congress running in our cloud (sort of at scale).
17:46:51 <thinrichs1> There are a couple of bug fixes that are important.
17:47:26 <arosen> thinrichs1: nice
17:47:37 <arosen> i wouldn't say substantial but we not how a ci job up that is leveraging nodepool with disk-image-building. This seems to have reduced the CI time by ~8min or so.
17:47:41 <thinrichs1> There's an old bug with datasource race conditions that was fixed, then reappeared, and is fixed again.
17:48:05 <thinrichs1> There was a bug with column-references that is fixed now.
17:48:28 <thinrichs1> And there was a pretty serious bug with the recent logging changes that basically stopped the server from running with loglevel DEBUG.
17:48:36 <sarob> arosen: 8min is a pretty big deal
17:48:47 <thinrichs1> Looking to see if all those have been merged yet.
17:49:21 <arosen> thinrichs1: i had a question on your race condition bug that was a regression but we can follow up on the review if you prefer
17:49:47 <thinrichs1> Looks like just the race condition bug hasn't been merged.
17:50:22 <thinrichs1> This happens just about every time in our cloud, so if you see errors about the client not existing, you need to cherry-pick this change (or wait til it gets merged).
17:50:26 <thinrichs1> https://review.openstack.org/#/c/137529/
17:50:49 <thinrichs1> arosen: is our cloud CI working?  Seemed like I saw a lot of failures the other day.
17:50:56 <thinrichs1> Or were those legit failures?
17:51:13 <thinrichs1> arosen: let's follow up on gerrit
17:51:21 <jasonsb> i actually don't understand that race
17:51:24 <arosen> thinrichs1: this occurs in the ci runs too though it doesn't seem to cause the driver to stop working
17:51:28 <jasonsb> someday :)
17:51:46 <arosen> thinrichs1:  i think the exception is just caught and passed in poll() so it doesn't really break anything but does show an error
17:52:15 <thinrichs1> jasonsb: have a status update?
17:52:40 <jasonsb> not really
17:52:49 <thinrichs1> arosen: right—except when you're only polling once an hour that first failure means that datasource is empty for an hour.  Not good for debugging.
17:52:49 <jasonsb> i'll send you an email on silisec
17:53:01 <arosen> thinrichs1: ah good point ;)
17:53:20 <thinrichs1> jasonsb: that'd be great.  We're getting more customer interest, so understanding the security benefits/drawbacks of Congress would be good.
17:53:33 <jasonsb> things are going slow :(
17:53:50 <thinrichs1> :(
17:53:51 <jasonsb> still trying thoguh
17:54:00 <thinrichs1> Let us know if we can help!
17:54:22 <thinrichs1> Any other status updates?
17:55:40 <alexsyip> Just debugging congress-server
17:56:28 <thinrichs1> alexsyip: great!  Operations-level testing/debugging is crucial.
17:56:43 <thinrichs1> We want those customer first-experiences to be good ones.
17:57:02 <thinrichs1> Okay—let's call it a few minutes early today.   Next week we can all go through and do proper status updates.
17:57:05 <thinrichs1> Thanks all!
17:57:11 <sarob> cheers!
17:57:13 <arosen> later!
17:57:25 <thinrichs1> #endmeeting