17:01:14 #startmeeting CongressTeamMeeting 17:01:15 Meeting started Tue Sep 2 17:01:14 2014 UTC and is due to finish in 60 minutes. The chair is pballand. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:17 Hi all 17:01:18 The meeting name has been set to 'congressteammeeting' 17:01:19 hello all 17:01:22 hey 17:02:21 Lots of stuff happening last week 17:02:44 we hit our alpha milestone 17:02:51 thinrichs1: you mind giving an update of that? 17:02:58 pballand: sure. 17:03:15 hi! 17:03:20 The alpha is ready for everyone to test. 17:03:34 The README has install instructions for both devstack and standalone. 17:03:45 You can write policy over Nova and Neutron. 17:03:50 And then monitor that policy. 17:04:01 The docs are pretty good. 17:04:08 There's a tutorial and a troubleshooting guide as well. 17:04:31 README contains info about how to view the docs (we're using RST, which you can compile to HTML). 17:04:51 File bugs as you find them, if you would. 17:05:13 We'll be sending an announcement to the ML later today. 17:05:42 I think the upshot of this is that everyone can now do an end-to-end trace through the (working) code. 17:05:52 morning 17:06:08 I think that's about it for the alpha. 17:06:09 thanks to all who helped on the alpha 17:06:21 thanks thinrichs1 17:06:48 to echo thinrichs1, if anyone has not yet tried the alpha, please do so 17:07:52 harrisonkelly: any updates on what you’ve been working on? 17:08:15 yes 17:08:30 Derick suggested that I do the eventlet switch a different way, so I made minor changes 17:08:47 but that introduced that weird error from run_tests.sh that I told you about before, the missing inbox 17:09:24 the fix for that was to add a start() method to the deepsix class, but I cannot do that because of how Derick and me rewrote the deepsix class 17:09:51 I’ve been off from work for a few days, so I haven’t had a lot of time to look into why thats happening yet 17:10:25 would it make sense to push the change you have as an incremental change in the right diretion (away from threads)? 17:10:55 the one that I have waiting for review now works, so I was waiting to see if I should push it or wait until it works because I changed a lot of files 17:11:35 what patch are you referring to? 17:11:41 one sec 17:11:50 https://review.openstack.org/#/c/116308/ 17:12:12 that patch works (it ran run_tests.sh and tox -epy27 without errors) 17:12:12 if you don’t want that pushed, you had better mark it as such 17:12:29 (place a -1 on the workflow) 17:12:56 that patch seems like a reasonable step in the right direction to me 17:13:04 Should I do that? Or let it be merged (if it gets a check for the review) and then merge the new one in after so we can get rid of threading quicker 17:14:13 it’s your code, what do you think? 17:15:04 I think the patch I linked is step 1 to a two step process. Step 1 removes threading and uses eventlets, step 2 adds more power to the eventlets and according to Derick, adds more power to the eventlets 17:15:40 in that case, letting the patch go in makes sense to me 17:16:09 (the faster you push incremental code, the lower the chance it will conflict with work others are doing) 17:16:28 Yeah, I’m going to try to figure out whats causing it 17:16:43 I think its because I’m automatically starting the eventlet when you create the object 17:17:13 which is because you spawn the eventlet to create it, but if I had a start() method, it doesn’t start it until you explicitly say so 17:18:16 harrisonkelly: ok - so the exiting code in review works, and you’ve got a couple kinks to work out in your next patch, right? 17:18:26 correct 17:18:59 harrisonkelly: sounds good 17:19:53 anyone else have code updates to discuss before we move on? 17:20:59 sarob: would you mind giving an update on the policy summit? 17:21:23 I've been working on the congressclient hopefully I can get that out by the end of the week. 17:21:42 That's all from me though. (I know i've been moving slow on the client) :/ 17:22:24 arosen: that will be great, thanks for the update 17:22:49 also I have this patch here which changes the default port number: https://review.openstack.org/#/c/118207/ We might want to merge this before we announce the alpha 17:23:09 but not super important either way probably. 17:24:14 arosen: I like the port # change :) 17:24:39 we already tagged the alpha, but it may be nice to get it in before most people pull (assuming they pull from master) 17:25:27 hi rajdeep 17:25:58 hi pballand 17:26:14 rajdeep: we were just going through updates - do you have any updates to report? 17:27:14 ok -- this week i worked on fixing the test cases 17:27:55 for CollectionHandler webservice 17:29:49 thats it from side 17:29:57 arosen: pushed a workaround this morning for a bug that broke the gate 17:30:06 https://bugs.launchpad.net/congress/+bug/1364515 17:30:26 rajdeep: this looks like something you would be familiar with - would you be able to take a look? 17:31:26 i remember that - perhaps replace the FakeClient with local Mocks 17:32:06 rajdeep: I have a few changes in review that do some cleanup of the Nova/Neutron clients. 17:32:16 It would be good if you could make your changes on top of those. 17:32:38 rajdeep: replacing with local Mocks makes sense to me 17:32:46 rajdeep: yea I think local mocks is what you want to use. Or copy the fakes used in novaclient to congress. 17:32:47 Here's the last one: 17:32:48 https://review.openstack.org/#/c/118400/ 17:36:03 ok - I want to remind people that the policy summit is coming up 17:36:11 #link https://etherpad.openstack.org/p/juno-midcycle-policy-summit 17:36:51 we’ll be working on the schedule this week 17:37:48 if you have a particular topic to discuss, please update the etherpad 17:37:58 im back online when ready for me 17:38:15 sarob: was hoping you could comment on the policy summit 17:38:20 (or any other updates) 17:38:23 yup 17:39:00 so mikal will be asking a local to step in representing nova 17:39:31 and writing up what nova policy looks like for him 17:40:02 im going to get the gbp and heat guys to dump a bit into the etherpad as well this week 17:40:19 we have about 60 people signed up right now 17:40:34 almost 20 remotes 17:41:12 should be good 17:41:19 id ask anyone that has some interest in the use case discussion to add some thoughts to the etherpad as well 17:42:08 thats it 17:42:46 #topic Open Discussion 17:42:50 thanks sarob 17:43:04 that’s all I had for this week 17:43:12 pballand: I’m not going to be able to make it to the meetings anymore because I have a class that falls right over this time block 17:43:46 I can email you a status update every week, or let you know what I’ve been doing on the Congress channel if you’re on when I am 17:44:01 harrisonkelly: that’s too bad - we hope you can still be involved 17:44:20 harrisonkelly: you can absolutely keep in touch through the #congress channel and openstack-dev mailing lists 17:44:22 I can still help, just not make the meetings 17:44:47 harrisonkelly: good to hear - hope it’s a good class ;-) 17:45:01 it’s GUI programming I, its a senior project class so I’m hoping its a good one 17:45:31 harrisonkelly: sounds like fun :-) 17:45:53 so about working on new data sources 17:46:56 sarob: thanks for the reminder 17:47:31 we are hoping to get people to start working on more data source plugins 17:47:51 as part of that, thinrichs1 posted patches cleaning up the existing implementations 17:48:33 we would like to recommend that everyone involved with the project writes a datasource driver 17:49:11 doing so will help the project greatly, and also give each developer a good feel for how congress works 17:49:15 I agree, i look forward to writing a datasource driver that integrates with something outside of openstack 17:49:43 * pballand needs to write a datasource driver as well :) 17:49:52 perhaps we could list the drivers we would like to write 17:50:05 then people could volunteer 17:50:41 rajdeep: we could do that, but field is really wide open at this point 17:50:56 any core OpenStack project is up for grabs 17:51:12 ok i could write 1-2 17:51:32 starting with keystone 17:51:33 and there are numerous outside projects that would also make sense 17:51:41 rajdeep: that would be great 17:51:58 kudva wanted to write one for ceilometer 17:52:27 if anyone is having trouble coming up with a component that needs a datasource driver, we can help them find something 17:52:52 kudva and skn were both working on drivers, but they aren’t here this week 17:52:52 there are other components we could write for - nsx, vsphere , open daylight outside openstack 17:53:28 also cinder driver is up for grabs 17:53:46 rajdeep: yes, the list goes on and on (Active Directory, antivirus, storage arrays, HVAC systems, ...) 17:54:02 aws, gce, euca will be good ones once we knock out the major openstack projects 17:54:55 i remember companies like tibco having a driver factory team at infosys - 100+ people 17:55:04 with 200+ dirvers 17:55:31 The goal here is partly to build drivers but it's mainly to get people comfortable with Congress. 17:55:53 There may be a better way to integrate with many data sources. 17:56:08 For example, lots of the translation code is boilerplate 17:56:32 and if we had a description of the return value for an API call, we could in principle generate that code automatically. 17:56:38 Or have a generic translation algorithm. 17:56:54 But even if we had that, it's still valuable to roll one by hand. 17:57:04 From an educational perspective. 17:57:05 ok, driver part is easier i would like to learn more about plexxi part 17:57:25 so we want to have some mentoring around this 17:58:05 teamwork on what good data source driver behavior looks like 17:58:38 sarob: I just made an editing pass through the drivers we have so others have good examples to work from. 17:58:42 Seems like a good first step. 17:58:43 time check: one minute left 17:59:02 thinrichs1: agreed 17:59:43 that’s it for this week, thanks everyone for coming 17:59:53 Thanks all! 17:59:55 #endmeeting