15:02:16 #startmeeting marconi 15:02:17 Meeting started Tue Jul 15 15:02:16 2014 UTC and is due to finish in 60 minutes. The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:21 The meeting name has been set to 'marconi' 15:02:35 #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda 15:03:03 #topic new meeting time 15:04:34 so, if we want to keep the meeting time on the same day yet accommodate people on opposite sides of the planet, 1900 is our best bet 15:04:38 1900 UTC 15:05:00 a little later would be better, but that conflicts with TC and project release meetings 15:05:11 that is 7am NZT 15:05:20 yay 15:05:23 flwang says that is a little early, but he could try to make it work 15:05:49 other thing we could try is move to a different day and do it at 2000 or 2100 UTC 15:06:27 let's assign something to someone who isn't here 15:06:30 :D 15:06:58 #action flaper87 or kgriffs to send out email to finalize new team meeting time/day 15:07:18 so yeah, we'll have to get some feedback from everyone on that. I'd like to start meeting at the new time starting next week 15:07:34 any suggestions/questions/comments/rude remarks before we move on? 15:08:08 #topic Juno-2 ends July 24! 15:08:26 any questions? :D 15:08:47 #link https://launchpad.net/marconi/+milestone/juno-2 15:08:55 want to go thru the list of pending stuff? 15:09:11 yeah, we will do that in a minute once we get through "Extra things" on the agenda 15:09:58 oh, also, FWIW, I updated the roadmap - moved some stuff out of j-2. 15:10:00 #link https://wiki.openstack.org/wiki/Roadmap_(Marconi) 15:10:10 anyway, we need REVIEWS 15:10:54 I'm personally going to be spending a lot of time on reviews this week. I'd love to see everyone else pitching in as well so we can get patches merged quickly 15:10:55 also 15:10:59 if you have a patch pending 15:11:04 last I checked, many of the pending reviews had some kinda -1 15:11:09 please update it quickly once you get teh reviewz 15:11:14 then kgriffs went ahead & submitted a few more patches 15:11:21 heh 15:11:43 kgriffs: Sure. I have done it just today. 15:12:08 I will say... I tend to skip patches that have a -1 from Jenkins 15:12:34 so please, get those fixed ASAP! 15:13:12 and please, ping me or another core reviewer if you are waiting on a review. we have lots of distractions and so it can be helpful to get some pokes. :D 15:13:44 cool? 15:13:48 kgriffs: Sure :) 15:14:17 #topic API test organization 15:14:21 will do. 15:15:00 #link https://github.com/openstack/marconi/tree/master/tests/unit/queues/transport/wsgi 15:15:08 :) 15:15:12 so.... 15:15:47 if you look at, e.g., test_v1_1.py 15:16:09 we have all kinds of two-liner classes like this 15:16:34 class TestClaimsMongoDB(v1_1.TestClaimsMongoDB): 15:16:34 url_prefix = URL_PREFIX 15:17:44 It seems silly to write our real tests in a base class that is already specific to a certain version of the API, and then simply inherit from it under "tests" so that testunit will find it 15:18:27 the original reason for the model as it now stands was to share the same base classes between 1.0 and 1.1, and then set a few class variables for minor variations in the test (e.g., url prefix) 15:19:31 however, now that we have copy-pasted all the base class tests between v1.0 and v1.1, this model seems like a waste of time 15:19:43 thoughts? 15:19:50 we need to revisit the whole copy paste approach 15:19:54 it works for now 15:19:59 but is a lot of duplication 15:20:22 good point 15:20:35 hmm, we would probably need to do some analysis on which test belonging where. 15:20:39 as a new dev, it confused me. 15:20:49 I think we should revisit our entire test structure 15:21:17 we have some tests in base.py - define what tests qualify to live there (if at all) 15:21:21 couldn't we just move the test classes and mixin the url? 15:21:42 couple things 15:21:43 peoplemerge_: as in specify the version in the actual tests? 15:22:15 first of all, I don't see what the url_prefix class variable is buying us at this point, since we already have duplicated the tests for 1.1 15:22:33 malini: --^ 15:22:57 second of all, I think if we are sticking with the duplicated tests for now, we should just move them directly under the tests folder 15:23:05 longer term 15:23:12 I agree with malini 15:23:20 we need to rethink tests 15:23:28 lots of things about that 15:23:38 unit vs. functional 15:23:41 where they live 15:23:45 how to DRY 15:23:47 etc. 15:24:09 is it an accident tht kgriffs thoughts look like a triangle? 15:24:34 * peoplemerge_ lol 15:24:39 :D 15:24:51 lol 15:24:58 haha 15:25:07 TBH, I don't think we have time in Juno to do it, but I would like to see it as a major theme in K 15:25:21 I mean, the major test redux 15:25:25 kgriffs: +1 15:25:26 :D 15:25:37 we could do some smaller moves 15:25:46 in j-3 15:25:52 +1 15:26:04 kgriffs: +1 15:26:12 ok. mind if I schedule a bug? 15:26:31 and malini: can you create a bp or something to help us remember the major refactoring work to do in K 15:26:37 sure 15:26:45 #action kgriffs to schedule a bug 15:26:57 There is also some chatter in the ML abt creating a common functional test structure for individual projects. We can be the guinea pigs, if we are anyways doing the revamp 15:27:08 #action malini to create a blueprint and start a wiki page or etherpad to keep track of ideas for testing redux 15:27:55 ok 15:28:04 next topic is "Move or copy _TRANSPORT_LIMITS_OPTIONS to pool catalog?" but I need flaper87|afk to be around for that. 15:28:33 #topic Review actions from last time 15:28:51 heh. looks like there weren't any 15:29:01 malini: btw, I moved rename the project to j-3 15:29:13 saw that ..thx :) 15:29:26 #topic Updates on blueprints 15:29:36 #link https://launchpad.net/marconi/+milestone/juno-2 15:29:45 malini: Tempest integration 15:29:58 We have the graduation req complete (AFAIK) 15:30:08 We now have coverage for all v1 APIs positive tests 15:30:20 But Tempest will be an ongoing effort 15:30:37 Next steps are v1.1 APIs & CLI tests 15:30:44 But tht'll be for j-3 15:31:27 But we really need the TC blessing to confirm tht we have met the grad reqs for Tempest - which I hope we'll do at the mid review 15:32:59 tht's all I had 15:33:04 concerns/questions? 15:33:06 is this blueprint complete then? 15:33:12 are there other blueprints for those other items? 15:33:23 yes - I'll create a new bp for other items 15:33:37 ok. can you mark this bp as complete as well? 15:33:54 sure..doing it now 15:34:10 I think it is important to celebrate our progress, and completing blueprints is one way to do that. :D 15:34:26 sriram: API V1.1 - Treat a Missing Queue the Same as an Empty Queue 15:34:39 Yeah, I checked that. 15:34:39 applause plzzz….The tempest bp is now 'Implemented' 15:34:45 its working as expected. 15:34:46 \o/ 15:34:51 * kgriffs claps loudly 15:34:55 :D 15:35:00 I'll go ahead and mark that as done. :) 15:35:01 * prashanthr_ Appalause :) 15:35:09 sriram: w00t 15:35:20 malini: API v1.1 - Remove the endpoint to check if a queue exists 15:35:38 I haven't started on tht yet.. 15:35:58 But since it is removing existing functionality - I hope tht will be easy to get done 15:36:42 I will submit a patch for it by tomorrow - or is it too ambitious? 15:38:15 sounds good 15:38:21 cool 15:38:41 kgriffs: API v1.1 Homedoc changes 15:39:01 this is a catch-all to sanity-check the homedoc once all the other changes are done 15:39:07 I think this may slip to j-3 15:39:13 Alex has an outstanding patch for tht 15:39:14 since it depends on everything else being stable 15:39:19 exception handling :P 15:39:36 malini: oh darn, that never got merged? 15:39:39 * kgriffs hides 15:39:49 ok, something else that needs teh reviewz! 15:41:10 It needs some updates from Alex - to address reviews 15:41:34 next 15:41:34 API v1.1 header changes. 15:41:45 tht one also has a patch from Alex :D 15:41:49 yep 15:42:05 #link https://review.openstack.org/#/c/102007/ 15:42:09 let's get that reviewed ASAP 15:42:30 kgriffs: API v1.1 Response Document Changes 15:42:33 not started 15:42:43 hope to get a patch for that in a day or two 15:42:51 kgriffs: API v1.1 Request Document Changes 15:42:58 halfway done 15:43:01 got a pending patch 15:43:07 please review! 15:43:08 :D 15:43:43 flaper87|afk: Support different types - flavors - of queues 15:44:06 iirc, Flavio asked for some eyes on this: https://review.openstack.org/#/c/98793 15:44:27 I'm pretty sure flavors is going to slip to j-3 15:45:02 esp. since it is going to require moving queue management to the control plane 15:45:40 flwang: API v1.1 - Provide more detailed info with /health 15:45:55 I saw some code from flwang submitted yesterday 15:46:02 again, please review! 15:46:17 the plan is to provide two things 15:46:25 overall message stats for an entire pool 15:46:35 and a "deep health check" 15:46:48 the deep check will basically do a message lifecycle test 15:46:58 peoplemerge_: API v1.1 - Support application/x-msgpack 15:47:04 thx for prioritizing the reviews, I wanted to take some on but didn't know which were (not) important. 15:47:08 kgriffs: yes 15:47:28 submitted test code for review only 15:47:51 got the hang of the review process 15:48:24 will start implementation Thu/Fri 15:49:22 kgriffs: the last patchset can be reviewd (#..) 15:49:58 https://review.openstack.org/#/c/106687/ 15:50:10 no sorry 15:51:15 https://review.openstack.org/#/c/105830/4 15:51:28 ok, thanks! 15:52:13 you 15:52:24 have probably seen these links, but we have some tips and tricks on the wiki 15:52:24 https://wiki.openstack.org/wiki/Your_First_Patch_(Marconi) 15:52:38 https://wiki.openstack.org/wiki/Your_First_Review_(Marconi) 15:53:02 prashanthr_: Redis Storage Driver (Basic) 15:53:19 kgriffs: All the controllers for redis storage driver 15:53:22 kgriffs: have some other issues around implementation but can take them offline 15:53:24 are up for review now 15:53:31 kgriffs: thx reading... 15:53:45 I guess we must have them for j-2. Just waiting for reviews 15:53:53 Test cases are also setup. 15:54:11 when should I try to get impl done to have time for reviews by j2? 15:54:33 https://review.openstack.org/#/c/97178/ - Queue and Message Controllers. 15:54:33 https://review.openstack.org/#/c/97701/ - Adding global dependencies. 15:54:33 https://review.openstack.org/104055 - Adding claims controllers 15:54:33 https://review.openstack.org/#/c/104058/ - Implements Pools and Catalogue controllers for Redis 15:54:42 The following are the code patches 15:54:47 for the individual controllers 15:54:53 hmm.. usually takes a couple days to get a patch merged, even when we have lots of people doing reviews 15:55:05 peoplemerge_: ^^^ 15:55:32 prashanthr_: great, nice work! Let's get those reviews 15:55:35 k 15:55:52 kgriffs: Sure. Thank you :) 15:55:55 we really should get everything merged by next wed 15:56:09 so we have a day for smoke testing or whatever 15:56:22 kgriffs: That would really be awesome. Yes a smoke test will really help. 15:56:23 sriram: Basic Benchmarking 15:56:27 kgriffs: yes 15:56:35 https://review.openstack.org/#/c/98875/ -> the patch is here 15:56:51 The enivronment is setup here : 166.78.236.4 15:57:17 I have done some performance tweaking : https://gist.github.com/kgriffs/4027835 15:57:17 prashanthr_: I think even the basic driver could be useful for single-app/private cloud deployments. Just a thought. 15:57:39 cool 15:57:44 kgriffs: Totally agreed. 15:57:56 FWIW, I am researching those and more kernel tweaks for a future blog post. stay tuned. :D 15:58:07 so need we need to get it merged, for the next process to continue.. reporting patch 15:58:13 kgriffs: woohoo! :) 15:58:14 awesome 15:58:35 cool, thanks sriram. reviews please! 15:58:45 * kgriffs wonders whether anyone else is noticing a trend 15:59:10 ok, I will move "Reporting of Generated Benchmarks" to j-3 15:59:42 sriram: with this, let's for the first patch do the "simplest thing that could possibly work" 15:59:43 https://blueprints.launchpad.net/marconi/+spec/gen-bench-reports 16:00:28 ok folks, we are outa time 16:00:33 cool 16:00:34 any final thoughts? 16:00:37 #topic open discussion 16:00:57 10 seconds. :) 16:01:20 #endmeeting