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