17:01:10 <thinrichs1> #startmeeting CongressTeamMeeting
17:01:11 <LouisF> hi
17:01:11 <openstack> Meeting started Tue Sep  9 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 <pballand> hi
17:01:31 <sarob_> Hey
17:01:36 <arosen> Hi!
17:02:19 <thinrichs1> Let's start with status updates from the previous week.
17:02:29 <thinrichs1> arosen: want to go first?  How's the python client coming?
17:02:50 <arosen> The pythonclient is coming along well. I believe i have all the API calls implemented that congress-api exposes now.
17:02:55 <arosen> https://review.openstack.org/#/c/104375/
17:03:14 <arosen> I'm going through the tutorial and adding the bindings for the client commands where curl is using to confirm.
17:03:40 <arosen> I've gotten Jamie Lennox and Dean Troyer to help review it who wrote the openstackclient so hopefully we should be good to merge it soon.
17:03:51 <arosen> That's all I have to report for now.
17:04:00 <thinrichs1> Great!  I'm excited to leave curl on the curb.
17:04:54 <thinrichs1> sarob: You ready to go next?  How's the policy summit?
17:05:03 <sarob_> 60 plus
17:05:32 <sarob_> Nailing sow
17:05:38 <sarob_> Down
17:05:53 <sarob_> First day talks
17:06:25 <thinrichs1> Which projects do we have confirmed for giving talks?
17:06:41 <sarob_> Neutron
17:06:43 <sarob_> Nova
17:06:49 <sarob_> Congress ;)
17:06:53 <sarob_> Heat
17:07:02 <sarob_> Working on swift
17:07:22 <sarob_> Abstracts should be showing up soon
17:07:41 <sarob_> Second day agenda looks set
17:08:01 <sarob_> Etherpad is up to date
17:08:09 <thinrichs1> That sounds like a pretty good representative sample.
17:08:17 <thinrichs1> There's a waitlist, I understand.
17:08:37 <sarob_> I'm seeing if we can get a bigger room
17:08:55 <sarob_> And table mics for our remote friends
17:09:09 <thinrichs1> And if we can't get a bigger room, let's make sure we all decline the invite if we decide we're not going.
17:09:58 <thinrichs1> Table mics are a good idea.
17:10:02 <sarob_> I'll ping the attendees if the bigger space doesn't come available
17:10:26 <sarob_> That all on that
17:10:39 <thinrichs1> Thanks.
17:10:47 <thinrichs1> rajdeep: want to go next?
17:10:52 <rajdeep> hi
17:11:19 <rajdeep> i have been working on fixing the bug https://bugs.launchpad.net/congress/+bug/1364515
17:11:42 <rajdeep> replaced dependency on FakeClient in python-novaclient with Mock
17:12:04 <rajdeep> need to respond to thinrichs1 comment and close it
17:12:22 <thinrichs1> Yeah—I think it's ready to go in.
17:12:44 <rajdeep> here is the CL's link for everybody's reference https://review.openstack.org/#/c/119734/2
17:13:14 <rajdeep> thinrichs1 using fakes might be a better idea than embedding mocks directly
17:13:30 <rajdeep> this way we can change mocking framework later
17:13:38 <rajdeep> without changing the test case
17:14:03 <rajdeep> i guess we should change neutron driver as well
17:14:17 <rajdeep> and also change mox to Mock
17:14:33 <thinrichs1> Anyone know the diff between fakes and mocks?
17:15:01 <thinrichs1> I thought mocks allowed you to test an entire *sequence* of calls, whereas fakes allow you to test the results of a single call.
17:15:30 <thinrichs1> So you could test list_networks(), list_networks(), list_networks() with a mock and make the result different on each call.
17:15:51 <thinrichs1> Whereas I thought a fake would require the the result of list_networks() to be the same in all 3 cases.
17:16:36 <rajdeep> thinrichs you are right..
17:16:56 <rajdeep> is our requirement to change output dynamically
17:16:57 <thinrichs1> So it sounds like mock is functionally a superset of fake.
17:17:11 <thinrichs1> I don't think we want to replace mock with fake; rather, I think we want to replace fake with mock.
17:18:10 <rajdeep> i will give you example from neutron they used mox as a mocking framework
17:18:23 <rajdeep> and then decided to go with mock.Mock
17:18:32 <thinrichs1> rajdeep: yes we want to be able to test a *sequence* of different responses by list_networks
17:18:34 <rajdeep> since mox is spread all over the code base
17:19:06 <rajdeep> so shall i go ahead and follow the neutron driver model
17:19:38 <thinrichs1> I'm not too worried about mock being spread throughout our tests.  It would be nice if that weren't the case, but we definitely want the functionality of a mock.
17:20:03 <thinrichs1> So yes I'd lean toward using mocks as we do in Neutron.
17:20:14 <thinrichs1> But if you have a better way of using mocks, go for it.
17:20:29 <rajdeep> i guess will submit this CL
17:20:43 <rajdeep> and replace with neutron driver based implementation
17:20:47 <rajdeep> in next CL
17:20:55 <thinrichs1> Yes—a separate change for moving from fake to mock is good.  The one you already have is ready to merge.
17:21:07 <rajdeep> ok thanks :)
17:21:21 <rajdeep> even in neutron driver test need to get rid of mox
17:21:28 <rajdeep> with MagicMock
17:22:10 <thinrichs1> I don't know the difference, really.  So use your best judgment.
17:22:33 <thinrichs1> arosen: you've said something about mocking drivers in OS.  Any opinions here?
17:23:02 <arosen> There is definitely a trade off between mocks and fakes
17:23:12 <arosen> usually we can reuse fakes if we are going to be faking something a lot
17:23:23 <arosen> but mocks are usually preferred if we only need to mock it out once.
17:23:32 <rajdeep> fYI on moving away from mox in nova http://lists.openstack.org/pipermail/openstack-dev/2013-July/012484.html
17:23:34 <arosen> In my opinion i think we should probably use mocks
17:23:44 <thinrichs1> arosen: earlier we decided mocks were functionally superior.
17:24:09 <thinrichs1> arosen: I was interested in how OS does mocking.  I *think*  I remember seeing decorators being used.  Which mock package is that?
17:24:21 <arosen> Right I perfer mocks over mox but one downside of mock is there is no way to call order with mock. One needs to use mox :(
17:24:23 <thinrichs1> mox versus MagicMock, perhaps.
17:24:26 * arosen I believe
17:25:01 <rajdeep> yes i know
17:25:14 <thinrichs1> We do want to use ordering of calls so that for example the networks that get returned are in sync with the ports that get returned.
17:25:26 <rajdeep> but using mox is very complex for cases you mention specially with reset
17:25:54 <arosen> rajdeep:  mox should only be needed if you want to test that you call one method before the next one.
17:25:57 <thinrichs1> e.g. we test  list_networks() and list_ports() and then we test list_networks() and list_ports() again.
17:26:19 <rajdeep> ok, got it
17:27:13 <thinrichs1> Time to move on.
17:27:27 <thinrichs1> Radu_: anything to report?
17:28:57 <thinrichs1> Maybe he had to step away.
17:29:20 <thinrichs1> harrisonkelly, who couldn't attend, has been working on making DSE use eventlets instead of threads.
17:29:27 <thinrichs1> That seems to be progressing nicely.
17:29:50 <thinrichs1> There were more changes since our discussion last week, which is why it's not merged.
17:30:06 <thinrichs1> kudva, who also couldn't attend, is still working on the builtins for the policy engine.
17:30:26 <thinrichs1> It was more work than he expected because of the test reorg that we did.
17:31:07 <thinrichs1> A quick reminder: everyone who hasn't should look for a datasource driver they'd like to implement.
17:31:32 <thinrichs1> It's a great way of really starting to understand how the datasources are pulled into Congress and then how to write policy over those datasources.
17:32:51 <thinrichs1> Let's do this.  I'm going to task everyone with choosing a datasource driver that they would like to implement.
17:33:25 <thinrichs1> It could be an OS project, a proprietary service, or really anything.
17:33:48 <madhumohan> hi all, just reintroducing myself. I have just started ramping up on the core part of congress after working through devstack and client..I just started working on a basic ceilometer datasource driver to help me ramp up. looking forward to actively working with this team...
17:34:06 <thinrichs1> Great!
17:34:27 <thinrichs1> madhumohan: Let us know what we can do to help.
17:34:29 <arosen> awesome welcome madhumohan!
17:34:56 <thinrichs1> Did you know there are several of us on the #congress irc pretty much all day?
17:35:19 <thinrichs1> That's a good place to go with questions/comments/etc.
17:36:43 <thinrichs1> I'll put this in a formal action so no one forgets.
17:36:59 <thinrichs1> #action Everyone will choose a datasource they'd like to write a driver for by next week.
17:36:59 <rajdeep> please add my name to keystone driver
17:37:23 <thinrichs1> rajdeep: thanks for volunteering!
17:37:48 <thinrichs1> For everyone else, rajdeep has done the most driver development, having written both the Nova and Neutron drivers that we have.
17:38:34 <thinrichs1> Forgot my own update.
17:39:09 <thinrichs1> My changes cleaning up the datasource drivers are just about ready to be merged.
17:39:19 <thinrichs1> I'm hoping they'll go in later today.
17:39:47 <thinrichs1> I've also been thinking about the next big features we might want to tackle (i.e. before the beta).
17:40:29 <thinrichs1> I'm leaning toward adding (i) basic enforcement capabilities and (ii) a UI for making policy-writing easier.
17:40:48 <thinrichs1> For enforcement, I'm thinking we support one or both of…
17:41:05 <thinrichs1> (i) writing policy that describes which *actions* to take under certain conditions.
17:41:31 <thinrichs1> For example…. if there's a network connected to a black-listed VM, execute the disconnect_network action.
17:41:50 <thinrichs1> (ii) writing policy that describes which actions are *permitted* under certain conditions.
17:42:06 <thinrichs1> For example, a user is permitted to connect a network to a VM if that VM is not blacklisted.
17:42:25 <thinrichs1> (i) gives us a version of reactive enforcement, while (ii) gives us a version of proactive enforcement.
17:42:47 <thinrichs1> (ii) is roughly a generalization of the current policy.json functionality.
17:42:51 <thinrichs1> Thoughts?
17:43:51 <madhumohan> Regarding enforcement, I was thinking one way could be to just produce notifications.... (form of assistive)
17:44:28 <rajdeep> i guess having a UI to writing policies is super important
17:44:42 <rajdeep> and also some form of horizon integration
17:44:59 <thinrichs1> madhumohan: I was thinking we could implement that with the reactive enforcement version (ii).
17:45:09 <rajdeep> this will help adoption of congress
17:45:11 <thinrichs1> The action in this case would be  'send_email'
17:45:25 <thinrichs1> rajdeep: agreed.  arosen is working on a horizon integration.
17:45:40 <arosen> I had a WIP thing for the horizon integration I didn't really get to far there.
17:45:57 <thinrichs1> rajdeep: But we want more than just horizon integration.  We want a GUI for making policy-writing easy.
17:46:00 <arosen> So if anyone wants to own that component it's definitely up for grabs :)
17:46:11 <thinrichs1> rajdeep: embedded within Horizon.
17:46:35 <arosen> have you guys seen how heat templates integrate with horizon?
17:46:51 <thinrichs1> arosen: a brief overview would be helpful for me.
17:47:32 <rajdeep> would love to help in horizon integration, though my knowledge of django is very  little
17:47:58 <arosen> They have inputs in their template like {{IMAGE}} , {{NETWORK_ID}} and when you upload a template with those values they auto propulate a select box for you to fill in data.
17:48:35 <arosen> so we might be able to leverage something simlar kinda today. Sorry it's probably best to take a look at it. My explanintion isn't very good lol
17:48:42 <arosen> rajdeep:  neither do I :P
17:48:54 <thinrichs1> rajdeep: that would be great.  If you'd rather spend your time on horizon than on the keystone driver, I'd be in favor.
17:49:39 <rajdeep> sure, let me do some homework first before committing
17:49:48 <thinrichs1> rajdeep: sounds good.
17:50:55 <arosen> rajdeep:  there are a few tutorials on creating horizon pannels if you google around. That's what I was trying to use as a starter.
17:51:04 * arosen fyi
17:51:18 <thinrichs1> arosen: good to know.
17:51:19 <thinrichs1> Let's transition to open discussion.  Anyone have anything pressing?
17:51:23 <thinrichs1> #topic Open discussion
17:51:31 <rajdeep> arosen : thanks will look around
17:52:01 <madhumohan> arosen: could you share some links.. I would be interested too
17:52:25 <arosen> http://docs.openstack.org/developer/horizon/topics/tutorial.html
17:52:36 <arosen> http://docs.openstack.org/developer/horizon/quickstart.html
17:55:47 <thinrichs1> Seems like that does it for this week.
17:55:55 <thinrichs1> Thanks all!
17:56:00 <sarob> thanks
17:56:05 <rajdeep> thanks
17:56:20 <madhumohan> I would need all the help and will hook into the #congress channel from this moment....thanks all...
17:57:06 <thinrichs1> #endmeeting