17:03:51 <thinrichs> #startmeeting CongressTeamMeeting
17:03:52 <openstack> Meeting started Tue Jun  3 17:03:51 2014 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:55 <openstack> The meeting name has been set to 'congressteammeeting'
17:04:26 <thinrichs> let’s start with last week’s action items.
17:04:40 <thinrichs> I saw some use cases published to the gdoc.
17:04:50 <skn__> Yeah, I added a few
17:04:52 <thinrichs> But I didn’t get a chance to look at them.
17:05:02 <skn__> but I have not put them in the main page though
17:05:05 <thinrichs> #link https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#
17:06:15 <sarob> Here
17:06:31 <sarob> Added use cases as well
17:06:36 <pballand> I’m hoping we can prioritize these somehow
17:06:39 <sarob> Need more meat
17:06:55 <pballand> at least mark some first-priority targets
17:07:13 <thinrichs> It might help if for each use case we added some more info.
17:07:15 <sarob> My ideas are priority
17:07:29 <sarob> Solved your problem ;)
17:07:31 <thinrichs> sarob: :)
17:07:51 <skn__> How many do we have to cover for the initial demo?
17:07:51 <thinrichs> Such as (i) what the policy is in Datalog, (ii) what datasources it depends on.
17:08:10 <sjcazzol> folks we have define our use case, it is called "Automatic Evacuation on Host Failure"
17:08:18 <pballand> thinrichs: +1
17:08:19 <skn__> Or, rather want to cover
17:08:21 <thinrichs> Then we can see if it fits into the policy language and if we have datasource wrappers to cover it.
17:09:06 <thinrichs> sjcazzol: I see the title but not the desc.
17:09:14 <sjcazzol> I am working on this
17:09:20 <sjcazzol> today I'll complete this
17:09:30 <thinrichs> sjcazzol: good—just wanted to make sure I wasn’t missing it somewhere.
17:09:47 <sjcazzol> thinrichs: :)
17:09:51 <thinrichs> We should work with sjcazzol to fill in the policy and datasource details I mentioned.
17:10:00 <thinrichs> Any volunteers?
17:10:04 <kudva> So are you monitoring host condition with Ceilometer
17:10:13 * sarob hand up
17:10:15 <thinrichs> For that matter, skn and sarob, would you like help writing Datalog policies too?
17:10:18 <sjcazzol> kudva: yes
17:10:29 <kudva> I can work with you on that
17:10:42 <skn__> thinrichs: you mean the real policy statements?
17:10:42 <thinrichs> sarob: thanks.
17:10:43 <sjcazzol> kudva: great
17:10:53 <thinrichs> skn: yep or at least something close
17:11:06 <sarob> Hmm, what would a datalog policy be?
17:11:07 <skn__> Got it, yeah I can do some of that
17:11:28 <thinrichs> Let me find a policy example to point you all at.  Hang on.
17:11:58 <sarob> I'll keep editing the use case gdoc
17:12:02 <kudva> the network example in the congress directory is a good one. but it doesn't connect to monitoring data yet I think
17:12:15 <sarob> For prioritization
17:12:18 <skn__> But I am missing the biger picture, what’s the plan?
17:12:26 <sarob> We have two audiences
17:12:39 <sarob> The other projects like neutron
17:12:45 <skn__> sarob: I could work with for priotizing stuffs
17:12:55 <sarob> And the operators
17:13:08 <sjcazzol> kudva: good, I'll take a look
17:13:18 <thinrichs> kudva is right: congress/examples/private_public_network.classify
17:13:21 <sarob> What's important is going to be diff
17:13:26 <thinrichs> is a good example of policy
17:14:29 <sarob> If incubation is the release cycle goal
17:14:56 <sarob> Then we need to meet other project needs before operators
17:15:06 <skn__> thinrichs: the issue is we have to integrate with neutron/nova/etc, and we need some of that capability demo'ed
17:15:43 <thinrichs> skn: yes.  sarob is articulating what the principles are for prioritizing use cases.
17:15:50 <sarob> Project policy Interop as the priority
17:15:59 <thinrichs> I’d imagine the top-priority use cases will make it into the demo.
17:16:00 <skn__> sarob: agreed
17:16:06 <sarob> Better way of saying it
17:16:22 <thinrichs> Of course, limited by our ability to build those use cases without boiling the ocean
17:16:44 <sarob> The gdoc is a good place to boil
17:16:51 <thinrichs> Do we know which of the use cases in the doc are important for other projects?
17:17:02 <sarob> Not sure yet
17:17:09 <kudva> I think the host evacuation from sjcazzol is simple yet important I think
17:17:14 <sarob> We need more water to boil
17:17:19 <pballand> adding the list of data necessary for each use case will help
17:17:22 <kudva> But needs ceilometer integration
17:17:25 <thinrichs> I know adrian_otto, who I have yet to track down, added a use case for Solum
17:18:11 <sarob> I will get Michael still to review the gdoc
17:18:26 <skn__> I think we should show one of the security use cases combined with neutron
17:18:29 <sarob> Important from the source
17:18:30 <thinrichs> One way to convince other projects that Congress is useful is to demonstrate use cases where their projects are central to the use case.
17:18:52 <sarob> And Mestery
17:19:10 * mestery is lurking.
17:19:16 <sarob> Sweet
17:19:29 <mestery> I'm a fan of Congress. What do you guys need from me?
17:19:48 <thinrichs> We need to understand if there are use cases you’d like to see us deliver.
17:20:05 <mestery> thinrichs: OK, that makes sense.
17:20:21 <thinrichs> We’ve been focused on policies that span different OS components, e.g. nova and neutron.
17:20:26 <sarob> Mestery: #link https://goo.gl/RM3W6W
17:20:28 <skn__> mestery: We have a use case gdoc, if you could take a look at it
17:20:52 <mestery> sarob thinrichs skn__: Will have a look.
17:21:04 <thinrichs> mestery: Thanks—any feedback would be great!
17:21:10 <banix> s3wong: still here?
17:21:29 <mestery> thinrichs: Sure!
17:21:34 <s3wong> banix: yes, just lurking though :-)
17:22:22 <banix> s3wong: mestery I think for Neutron the group policy work may be coming a bit later; we may want to focus on non gp stuff to begin with?
17:22:49 <mestery> banix: It's possible, yes, with the goal of having Congress use GBP eventually.
17:23:11 <s3wong> banix: oh? is congress moving ahead this quickly? they are ahead of Neutron GP now?
17:23:14 <thinrichs> banix: we definitely don’t want to confuse GBP with Congress (that happens a lot).
17:23:22 <banix> mestery: yes of course that would be the goal but if congress wants to showcase something this cycle that may be a bit difficult
17:23:41 <thinrichs> I’d say that initially we should focus on non-GBP use cases so people can understand the diff.
17:24:01 <banix> thinrichs: agree; that should be a good start
17:24:28 <skn__> mestery, banix: by non group stuffs in Neutron, do you mean generic networking capabilities?
17:24:33 <s3wong> thinrichs: agreed. a quick glance into your use cases, seems to encompass Nova and Neutron, thus no yet in scope of GBP
17:24:43 <banix> skn__: yes
17:24:58 <skn__> banix: ok, thanks
17:25:08 <thinrichs> s3wong: that was part of the goal—to highlight the things Congress does that are diff from gbp and the nova policy work
17:25:27 <s3wong> thinrichs: great!
17:25:39 <thinrichs> If no one has anything else on this, we should move on.  I’ll leave an action item to continue soliciting feedback about how to prioritize use cases wrt OS projects for incubation.
17:25:56 <pballand> we also want the use cases to start out using simple, well-understood primitives, and grow over time
17:26:03 <skn__> thinrichs: agreed
17:26:06 <thinrichs> #action Everyone will contribute use cases and we will solicit other OS projects’ interest so as to prioritize.
17:26:07 <sarob> Agreed
17:26:25 * sarob exceelent
17:26:33 <skn__> so, sarob, thinrichs, and me can work on priotizing?
17:26:42 <skn__> prioritizing?
17:27:07 <sarob> Gdoc boiling ocean of ideas
17:27:12 <skn__> oh ok
17:27:28 <thinrichs> Yep
17:27:45 <thinrichs> Moving on…
17:28:10 <thinrichs> kudva: you’ve been working on builtins for the alpha release.  How’s it going?
17:28:21 <thinrichs> #link https://review.openstack.org/#/c/95340/
17:28:28 <kudva> You I completed some unit tests which passed, and jenkins as well passed
17:28:39 <kudva> https://review.openstack.org/97081
17:28:40 <kudva> latest
17:28:52 <kudva> the unit test is called test_builtin.py
17:29:03 <kudva> have some tests there, will add more with time (and features added)
17:29:06 <kudva> Made all the changes
17:29:20 <kudva> that Tim recommended to the congressbuiltin code
17:29:38 <thinrichs> Sounds good.  I’ll follow up via gerrit comments.  I’ve been slammed the last few days.
17:29:46 <kudva> okay
17:30:11 <kudva> https://review.openstack.org/97065
17:30:15 <kudva> actually that's the last commit
17:30:44 <thinrichs> kudva: thanks for the update
17:30:44 <rajdeep> kudva it might be easier to update the CL
17:31:05 <kudva> rajdeep: ok will do
17:31:08 <rajdeep> with the changes using --amend
17:31:39 <thinrichs> rajdeep: I saw you added some more tests.  Everything working out there?
17:31:58 <skn__> thinrichs: do we want to put together some working version withwhatever we have today for alpha? is that the plan?
17:32:01 <rajdeep> yes ..added test cases for neutron
17:32:25 <thinrichs> I’ve started looking into mock instead of fakes (as banix mentioned in a review).
17:32:30 <rajdeep> some minor pep8 issues but otherwise we have good coverage on both nova and neutron drivers
17:32:38 <thinrichs> What’s the concensus on mock vs. fakes in OS?
17:32:54 <rajdeep> i used mocks for neutron
17:33:04 <sjcazzol> mock I think
17:33:11 <sjcazzol> at least in nova
17:33:15 <rajdeep> but stuck to fakes for nova
17:33:19 <rajdeep> driver
17:33:40 <rajdeep> will eventually move to mocks  i guess
17:33:56 <thinrichs> rajdeep: sounds like a plan.  I think mocks are better, and it should be easy to port.
17:34:20 <thinrichs> sjcazzol and rajdeep: did you sync up about our Nova coverage?
17:34:22 <rajdeep> yes, it was easy enough to use them
17:34:28 <thinrichs> Do we have enough coverage for sjcazzol’s use cases?
17:34:32 <rajdeep> not yet
17:34:56 <thinrichs> Maybe once we get the use case on the gdoc, you two can chat about the details.
17:34:57 <rajdeep> sjcazzol : it will be great if you can look at the nova driver
17:35:04 <rajdeep> and give feedback
17:35:15 <sjcazzol> rajdeep: of course
17:35:34 <thinrichs> rajdeep: to make that easier, maybe we can describe what data we are currently pulling out of Nova.
17:35:52 <thinrichs> Reading the code for how to convert JSON into tables might be too difficult.
17:36:09 <sjcazzol> rajdeep: I am delayed because we just define the full scope for the use case
17:36:16 <thinrichs> Not on IRC—but maybe in a doc
17:36:47 <thinrichs> sjcazzol: a use case hot off the pressess—I like it!
17:36:50 <rajdeep> ok, i will document and send across the doc
17:37:19 <thinrichs> Sounds good.
17:37:32 <kudva> sjcazzol: would like to see the plan for host evacuation on google doc with dependencies on both nova and monitoring/notifications
17:37:51 <thinrichs> #action rajdeep will document info exported from nova and touch base with sjcazzol
17:37:55 <sjcazzol> kudva: yes!
17:38:20 <rajdeep> sjcazzol what is the best way to contact you offline
17:38:42 <sjcazzol> sergio.j.cazzolato@intel.com
17:38:47 <skn__> What about neutron? Do we already have the data exported from neutron somewhere?
17:39:44 <thinrichs> The code that exports data from neutron is there.  No docs, though.
17:40:04 <skn__> thinrichs: oh okay.
17:40:31 <thinrichs> rajdeep: want to add Neutron to the doc if you have spare cycles?
17:40:45 <skn__> yeah that would be helpful
17:42:04 <thinrichs> (While waiting to hear from rajdeep…) Just a reminder there’s a nova-spec like blueprint avail for everyone to critique.
17:42:06 <thinrichs> https://review.openstack.org/#/c/94692/
17:42:22 <thinrichs> The plan is to get in the habit of writing these.
17:42:23 <rajdeep_> sorry got disconnected
17:42:51 <thinrichs> rajdeep: I just asked if you could add Neutron to the doc if you have spare cycles.
17:43:16 <rajdeep_> which doc?
17:43:31 <thinrichs> The one about the datasources we’re exporting that you’re sending to sjcazzol
17:44:01 <rajdeep_> neutron is already documented https://docs.google.com/document/d/1K9RkQuBSPN7Z2TmKfok7mw3E24otEGo8Pnsemxd5544/edit
17:44:11 <rajdeep_> i will update this with nova
17:44:29 <rajdeep_> do you want this in rst format?
17:45:35 <thinrichs> Not sure I ever saw that before—great!
17:47:27 <thinrichs> I guess we’ll eventually want it in RST, so we can publish it to users.  Maybe it makes sense to start that now so we don’t dig ourselves into a hole of RST debt?
17:47:33 <skn__> Yeah, I wanted to see this one, thanks.
17:47:49 <thinrichs> But priority 1 is getting it documented so you and sjcazzol can talk
17:48:05 <rajdeep_> ok sounds good
17:48:14 <thinrichs> Time check: about 12 min left.
17:48:30 <thinrichs> pballand: you’ve been working on the API, right?  How’s it going?
17:48:56 <pballand> I’ve got the eventlet wsgi server and DSE (deep6) code running together
17:49:16 <pballand> there are some architectural issues there to iron out
17:49:24 <pballand> no code for review yet
17:49:35 <pballand> still working against the spect at https://docs.google.com/document/d/14hM7-GSm3CcyohPT2Q7GalyrQRohVcx77hxEx4AO4Bk/edit#
17:49:58 <pballand> only one comment was to add arbitrary table metadata - if anyone has thoughts on that, it would be helpful to hear
17:51:00 <pballand> thats about all I have to report
17:52:31 <thinrichs> Metadata about cols/tables is sensible.  It’s lower priority than the rest though.
17:53:15 <thinrichs> rajdeep might have some idea what metadata we would want since the metadata would be useful to people trying to understand what the tables contain.
17:54:20 <thinrichs> pballand: great that we’re making progress here!
17:54:21 <pballand> I think the proposal was to allow the user to input _anything_
17:54:24 <thinrichs> Short on time…
17:54:30 <pballand> so it would be more like an extension
17:54:48 <pballand> this can be addressed later
17:54:58 <thinrichs> pballand: not sure if it should be a formal extension or just a change we make after we get the basics in.
17:55:00 <thinrichs> I’ve been working on integrating DSE, data sources, and the policy engine.
17:55:11 <thinrichs> Here are some interesting changesets, if anyone is interested...
17:55:27 <thinrichs> Still works in progress.
17:55:29 <thinrichs> https://review.openstack.org/#/c/93143/  (basic integration)
17:55:29 <thinrichs> https://review.openstack.org/#/c/96978/  (make datasources poll -- unfinished)
17:55:30 <thinrichs> https://review.openstack.org/#/c/95966/  (toplevel integration -- unfinished)
17:55:43 <skn__> thinrichs: thanks.
17:56:02 <skn__> when do we target to tentatively have an alpha?
17:56:06 <thinrichs> I’ve got a few other changes in review.  The changes above are all dependent on those.
17:56:17 <thinrichs> skn: as soon as we can manage to get the pieces all put together.
17:56:56 <thinrichs> Speaking of which, we don’t have plans for a python-client.  Anyone think that’s important for the alpha?
17:57:00 <skn__> thinrichs: oh ok, its ASAP then :)
17:57:11 <thinrichs> Or I should say important enough to delay the alpha?
17:57:33 <thinrichs> And since we’re rapidly running out of time, chime in with other issues we haven’t covered yet.
17:57:58 <banix> if no cient, then rest api is the interface only?
17:58:01 <skn__> may be dicuss about this python client in the next meeting
17:58:16 <thinrichs> skn__: good suggestion
17:58:43 <thinrichs> banix: the “alpha” is just something that people can use to kick the tires.
17:58:55 <thinrichs> We want early feedback on this to see what real users actually want.
17:59:12 <banix> thinrichs: ok but how will they use it?
17:59:32 <thinrichs> banix: the REST interface — wget or whatever
17:59:46 <banix> thinrichs: ok thx
18:00:10 <thinrichs> Times up for this week.
18:00:29 <banix> bye
18:00:35 <thinrichs> This was a good meeting!  See you all next week (or on gerritt/email)!
18:01:02 <thinrichs> #endmeeting