17:02:14 #startmeeting CongressTeamMeeting 17:02:15 Meeting started Tue May 6 17:02: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:02:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:18 The meeting name has been set to 'congressteammeeting' 17:02:52 Agenda today: recap on action items, then planning for Atlanta 17:03:16 rajdeep: do you mind going first? 17:03:34 sure 17:03:37 Hi 17:03:45 kudva: hi 17:03:55 last two weeks spent adding more get data to nova driver 17:03:55 kudva: just getting started on recap 17:04:03 ok 17:04:12 added details about hosts and floating_ips 17:04:42 now our nova driver has four tuple types 17:04:59 servers, flavours, floating_ips and hosts 17:05:07 and their associated field elements 17:05:37 That definitely gives a richer feel to the Nova integration. Good work. 17:05:43 thanks! 17:06:03 now i am planning to add some test cases as suggested by thinrichs 17:06:14 need some guidance on test case structure 17:06:47 I would suggest starting with unit tests, and everyting mocked up 17:07:14 ok, we use mock framework? 17:07:33 up to you 17:08:11 where should these test cases be added in the tree. 17:08:24 ‘tests’ subtree of the module 17:08:54 ok 17:09:03 While on the topic of subtrees, I think we ought to pull out the service_pluggins from the server directory and make it its own dir. 17:09:11 And maybe rename it to just "datasources". 17:09:36 I've been importing those things, and the paths are cumbersome. 17:09:41 thats a good idea 17:09:53 great, other questions on datasources? 17:10:06 so we will have a tests directory under service_pluggins/datasources 17:10:29 just /congress/datasources/tests 17:10:49 ok.. 17:11:11 kudva: do you mind sharing an update? 17:11:16 i will take the AI of changing the location and name of the directory service_pluggin 17:11:35 Yes. I sent some code to Tim to review, and he responded with some nice suggestions, specifically 17:11:46 #action rajdeep will change location of the service_plugin directory 17:12:09 I have a builtin.py program, which gets imported into runtime.py (which was Tim's recommendation). I added code to runtime.py 17:12:14 Now, I am writing tests using mock 17:12:41 I will put these test locally for now. Once the tests pass, I will move them to the tests directory (should be simple to move). 17:13:29 any estimate on when you may have soemthing for code reveiw? 17:13:32 We talked a bit if the the working code into git, but he wasn't sure whether some of the jenkins test need to be disabled. 17:13:57 currently, jenkins isn’t running the tests because i 17:13:58 Tim has looked through the code. For the team, I would say next tuesday. 17:14:03 ‘make’ isn’t wired in 17:14:09 that’s on my plate (and has been for too long) 17:14:24 you can still run the tests locally 17:14:24 that way, I have some tests passing 17:14:29 okay 17:15:02 #action kudva to submit first pass of builtins for review next week 17:15:28 that’s very exciting - I’m looking forward to having this fuctionality 17:15:46 other questions or comments on builtins? 17:16:26 ok, thinrichs: do you have any updates to share? 17:16:39 I've been working on integrating the Plexxi code. 17:16:57 It's been slow going, but I'm finally starting to understand that code. 17:17:18 I've got the first test case working. 17:17:52 Excellent! 17:17:59 That test case is just getting 2 data drivers to talk over the amqp bus. 17:18:08 thats great - this will be really importaint for tying everything together in a nice runnable package! 17:18:14 Next test case will be to get a data source and the policy engine to talk. 17:18:20 cloudtoad: good to see you here! 17:18:32 everyone else: cloudtoad wrote the Plexxi code. 17:18:44 Thanks, I'm glad to be a part of this. 17:18:45 hi cloudtoad 17:18:53 And we should probably start calling it DSE (Data services engine), instead of Plexxi code. 17:19:13 or integration engine 17:19:43 since cloudtoad is the author, I think he should get naming rights :) 17:19:54 (it’s currently called dse) 17:20:19 do you think you will be able to push some tests/examples soon? 17:20:30 Maybe--depends on how things go. 17:20:47 cloudtoad has also been planning on making some tweaks here and there. 17:20:56 So I don't want to step on those. 17:21:02 ok, fair enough :) 17:21:09 But I'll push for review as soon as I have something solid. 17:21:26 cloudtoad: anything add? 17:21:36 Yep.. 17:21:42 #action thinrichs to push tests for dse 17:22:03 s/anything add/anything to add/ 17:22:05 DSE needs a bit of cleanup work, I believe we will convert from Threading model to eventlets. 17:22:37 Comments, and perhaps some readme.md files in the DSE directory to walk through how it works and how to write data source modules. 17:22:53 cloudtoad: yes, I took a peek at that, but haven’t made any changes yet - I was hesitant to change code without tests :) 17:23:16 Maybe I'll push my baby unit test, so you've got a starting point. 17:23:26 the dox would be a great help too 17:23:49 !action cloudtoad to add documentation to DSE modules 17:23:50 pballand: Error: "action" is not a valid command. 17:23:57 #action cloudtoad to add documentation to DSE modules 17:24:04 * pballand is !-happy today for some reason 17:24:19 quick question 17:24:43 will the data source drivers need some rework for dse integration? 17:25:02 it shouldn’t be much - just some boilerplate if anything 17:25:17 I was playing around with that for my tests. 17:25:31 I think we'll just have DataSourceDriver inherit from dse.deepSix 17:25:45 ok that is good news 17:25:47 ! 17:25:54 Might need to tweak __init__ but otherwise I think they should be completely compatible. 17:26:04 As long as we're not stepping on the function names deepsix uses. 17:26:45 anything else on DSE? 17:27:20 I have been working on the API design, and have a proposal to send out 17:27:21 Not from me (that I can remember/think of) 17:27:38 I started as a google doc for ease of comments: http://goo.gl/1E5MeY 17:28:37 basically, I propose modeling all data as a data-source (including data output from a policy) 17:29:26 Good plan.. 17:29:29 I also left placeholders in for multi-tenancy, but will stick to just one ‘default’ policy for the first cut 17:29:57 If you can model policies and rules as tables, then policy data can be published on the DSE bus. 17:31:01 We can publish policies/data/whatever on the DSE bus, right? There's nothing about tables built into DSE. 17:31:19 Sorry, that's correct... 17:31:21 But right I think we're expecting the API calls to be sent via the bus. 17:31:33 You can structure the information however you wish 17:32:04 cloudtoad: agreed 17:32:20 thinrichs: raises a good point - I envisioned the entire API running over the bus (it is just a REST projection of the bus) 17:32:47 How will that interface with Horizon, if at all? 17:33:23 at this point, we don’t have any resources to work on horizon intergration, but that is definitely something we will need to takel 17:33:28 tackle 17:33:33 i thought REST was more for HTTP rather than messaging style interaction 17:34:30 rajdeep: yes, they are different styles - the point is that the fundamental data interchange style of the core of the system is the message bus 17:35:00 this model will facilitate scale-out in the future 17:35:12 so it is json in a message body 17:35:17 (and not lock us in to inefficient REST calls when we need better performance) 17:35:29 Rest calls really are requests for data... Perhaps the URL will translate to AMQP address and body of request will be passed to policy module (or even a data source module). 17:35:39 rajdeep: Yes. 17:36:14 cloudtoad: exactly 17:36:58 the scalability is a bit of overkill at this point, but the pattern is pretty nice to work in 17:37:29 other comments or questions about the API? 17:37:37 (we can continue the conversation in the google doc) 17:38:14 ok - I wanted to talk a bit about the conference next week 17:38:48 there is one session scheduled for Congress on Wed evening, and a developer track on Friday morning 9-12:20 17:39:39 I’ll just be giving an overview on Wed, but it would be great to have everyone in attendance 17:40:14 On Friday, it will be an interactive design session 17:40:34 #topic Open Discussion 17:41:16 any other topics to discuss? 17:41:21 What is the actual agenda for Friday or is that freeform? 17:41:56 We’re still working on that 17:42:06 Let me rephrase that... should I prepare something re: DSE for Wed or Fri? 17:42:26 that would be awesome - for Fri 17:42:45 sorry got disconnected 17:42:55 I’ll get in touch with you about specifics 17:43:02 ok 17:43:49 anything else? 17:44:25 Thanks everyone, and I’m looking forward to seeing you in Atlanta next week! 17:44:36 See you there! 17:44:43 #endmeeting