05:15:41 #startmeeting neutron/servicevm 05:15:42 Meeting started Tue Apr 1 05:15:41 2014 UTC and is due to finish in 60 minutes. The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:15:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:15:45 The meeting name has been set to 'neutron_servicevm' 05:16:01 #topic current-status 05:16:56 The code is under debugging. 05:17:08 I haven't published the image yet 05:18:08 The WIP code is available at github. It's still under debug 05:18:53 #link https://github.com/yamahata/neutron/tree/adv-svc-vm 05:20:23 Hopefully I can finish it soon. 05:20:37 any questions? 05:20:56 I took a look at the DB/API code - briefly 05:21:08 s3wong: great. 05:21:22 I generally want to ask two questions: 05:21:34 s3wong: Yes? 05:21:46 (a) there seems to be a lot of elements added to the database 05:22:03 (b) why is service type used when we are moving to a flavor framework? 05:22:08 https://review.openstack.org/#/c/83055/ 05:23:16 Regarding to (a), do you mean that newly introduced tables/coloumns are too many? 05:23:25 and that those can be reduced? 05:24:10 yamahata: yes - seems like there are a lot of table/columns introduced 05:24:18 and I wonder if some of those could be consolidated? 05:25:29 s3wong: Maybe yes. At least service-context table can/should be removed when the service insertion patch is merged. 05:26:10 s3wong: do you have ideas? 05:26:53 yamahata: I do realize the service context patch hasn't been approved yet (in fact, I just talked to SumitNaiksatam this morning) 05:26:55 I think some columns are duplicated and can be removed. 05:27:42 s3wong: I see. 05:28:26 Ok, the tables should be revised. 05:29:09 yamahata: what you have now is perhaps what is needed to make it work, but probably better to coordinate with the advanced service subgroup to see where we can work better together 05:30:20 s3wong: agree. Unfortunately the timeslot for advanced service meeting doesn't work for me. 05:30:36 anyway we can contact them by other ways. 05:31:09 yamahata: understand. Once I understand the service VM framework better, I may be able to act as a liaison (I am part of that subgroup) 05:32:57 s3wong: Regarding to (b), it's intended to represent what kind of service like lbaas, fwaas. 05:33:20 s3wong: Agreed, with flavour framework, it should be revised somehow. 05:33:57 yamahata: certainly flavor framework isn't ready neither; that said, another area that may cause you to change your code 05:36:07 s3wong: thank you for feed back 05:36:45 do you have any other issues/questions? 05:37:15 yamahata: just these - after doing a first pass through of your posted review 05:37:33 s3wong: thanks, then next topic 05:37:51 #topic dividing tasks into smaller ones 05:38:07 so far there are similar blueprints including servicevm 05:38:49 I think they (including mine) has mostly same goal. They just describe the same problem from different angle with different terminology 05:39:21 At the same time, it would be difficult to reach consensus on whole proposal. 05:40:12 So I'd like to divide the proposals into smaller ones which can be treated more easily. 05:41:12 Now I identified, vm(or device or network resource) management 05:41:32 communication with guest agent(or management layer of the device) 05:41:51 configuration(enabling/disabling) of services 05:42:13 tracking VM(or device)/service 05:42:54 They can be attacked independently and the resulted code can be shared 05:43:29 Thus each blueprints can make progress 05:44:30 the communication with guest agents could be used by other projects, I think. 05:45:03 That's what I'm thinking about. 05:45:40 any thought? 05:46:03 yamahata: it seems like your code covers quite a lot of the above already? 05:46:39 s3wong: Yes. The existing code can be a good starting point. 05:47:08 I'd like to hear from those who can share the code 05:47:51 yamahata: from the projects you listed, I don't know if any of them had posted code for review yet 05:48:00 I'll split the patches into smaller patches 05:48:18 I heard dynamic resource management has code, but I don't know if I saw the patch posted? 05:48:18 s3wong: I don't know neither. 05:49:23 yamahata: +1 for breaking up the CR into pieces 05:49:48 I think for a feature this big, community generally doesn't expect all the code to go in in a big chunk 05:49:57 breaking it down makes it easier for review also 05:52:15 let's split up the features and will see the results 05:52:43 Are those features worth each blueprints? 05:53:01 yamahata: do you need someone to help out with some pieces? 05:53:11 Maybe the documentation can be single documentation. 05:53:24 s3wong: off course. The help is welcome 05:53:47 yamahata: I think one document is fine - even one bp is fine, since the intent is clear 05:54:27 s3wong: So I won't waste my time to creating many BPs. It's easy. 05:54:42 but having pieces worked on by different community members, and submitting patches in sequence (instead of one big chunk) will help 05:55:02 for example, for the group-policy project, we also only have one bp and one design doc 05:55:25 but many people working on code, and we will integrate to get a PoC done 05:55:26 s3wong: I see. It encourages me. 05:55:53 then the idea is we will submit the CR by components instead of a one shot deal 05:56:47 sounds reasonable 05:57:22 Hmm so the first thing I do is write down the draft of the division in the doc. 05:57:27 so that people can cooperate 05:57:46 #action yamahata write down the draft of the division in the doc 05:57:56 yamahata: that would be great. I also believe the email you sent, at least Balaji has shown interest 05:58:04 he just got onto the wrong channel :-) 05:58:44 s3wong: really? I'd like to reach him, but I wasn't able to. 05:58:50 yamahata: so if you have the doc with breakdown, and send it again to the list, perhaps we can encourage others to join in to help as well 05:59:08 sound great idea. Will do 05:59:18 # action yamahata the doc with breakdown, and send it again to the list 05:59:20 yamahata: I just saw his email (though it was already 25 minutes ago), he got onto #openstack-meeting-3 05:59:49 Ah. I should have been on IRC on time. 06:00:06 I haven't seen the mails yet. 06:00:13 yamahata: Nah - he was on the wrong channel anyway :-) 06:00:33 I replied to his email, we should ask him to join again, this time on the right channel :-) 06:00:49 s3wong: anyway we can try next week. On right time on right channel. 06:01:02 right 06:01:21 anyother topics? 06:01:45 Not now - and we reached the end of the meeting time anyway :-) 06:02:03 thanks 06:02:08 thanks! 06:02:11 next week 06:02:22 sure, I will also take a look at the LB patch 06:02:23 endmeeting 06:02:27 #endmeeting