05:01:38 <yamahata> #startmeeting servicevm-device-manager
05:01:39 <openstack> Meeting started Tue Jul  8 05:01:38 2014 UTC and is due to finish in 60 minutes.  The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:01:43 <openstack> The meeting name has been set to 'servicevm_device_manager'
05:01:55 <yamahata> wow so many people
05:02:01 <yamahata> #topic Announcement
05:02:20 <yamahata> today bob skips meeting unfortunately
05:02:40 <yamahata> I pushed first code to gerrit system
05:02:53 <dougwig> link?
05:02:53 <yamahata> #link https://review.openstack.org/#/q/status:open+project:stackforge/tacker+branch:master+topic:bp/tacker-api,n,z
05:03:01 <yamahata> #link https://review.openstack.org/#/q/status:open+project:stackforge/python-tackerclient+branch:master+topic:bp/tacker-api,n,z
05:03:44 <yamahata> Although it needs api review and code review,  obvious patch(removing neutron file, rename neutron -> tacker) can be merged at first.
05:03:56 <yamahata> I marked it as obvious by adding my +1.
05:04:27 <yamahata> If you have any issues on those obvious patches,  please add -1 and push it back to me.
05:04:55 <yamahata> The server can run as standalone server and provides its api.
05:05:24 <yamahata> The next things to do is to refine API and implement l3-plugin with servicevm server.
05:05:47 <yamahata> I've uploaded a blueprint for l3-plugin with servicevm
05:06:12 <s3wong> yamahata: link?
05:06:13 <yamahata> #link https://review.openstack.org/#/c/105078/
05:07:29 <yamahata> So we show the roadmap for servicevm and Bob and Karthik can push their own specs/patches as in future it can be consolidated based on roadmap
05:08:07 <natarajk> yamahata: thanks for links. I'll review this week.
05:08:27 <yamahata> For api review I've upload it to gerrit
05:08:33 <yamahata> #link https://review.openstack.org/#/c/103724/
05:09:12 <yamahata> that's all from me to announce.
05:09:18 <yamahata> anyone else to announce?
05:10:06 <yamahata> seems nothing. let's move on
05:10:48 <yamahata> #topic Open Discussion
05:11:06 <yamahata> #undo
05:11:07 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2c8c510>
05:11:15 <yamahata> #topic servicevm spec review
05:11:32 <yamahata> Do we have anything to discuss with API now?
05:11:44 <yamahata> The detailed discussion can be done with gerrit.
05:12:03 <s3wong> yamahata: sure
05:12:20 <yamahata> At least Bob gave his feedback on google-doc. So I'll address them.
05:12:34 <yamahata> Okay seems nothing.
05:12:46 <yamahata> #topic Open Discussion
05:13:25 <yamahata> Does anyone have anything?
05:14:07 <yamahata> If no, I'd like to discuss on dnrm.
05:14:39 <yamahata> natarajk: So far I've thought on how to consolidate/integrate dnrm code.
05:14:51 <yamahata> natarajk: let me check my understanding.
05:15:07 <natarajk> yamahata: sure, go ahead
05:15:33 <yamahata> At first, the terminology is quite different.
05:16:08 <yamahata> With dnrm terminology, resource is ~= VM. it might be physical appliance or virtual appliance.
05:16:20 <natarajk> Yes
05:16:20 <yamahata> with servicevm terminology, it's hosting device. or simply device
05:17:34 <natarajk> Do you mention the hosting device as "resource" in your spec ?
05:17:34 <yamahata> Do you stick to "resource"? or is "hosting device" acceptable?
05:18:07 <yamahata> natarajk: yes.
05:18:22 <yamahata> I think mostly same meaning.
05:18:57 <yamahata> Or any better terminology?
05:18:58 <natarajk> for physical appliance, "hosting device" terminology might be confusing
05:20:08 <yamahata> To be honest, I don't care which terminology personally.
05:20:31 <yamahata> Bob introduced "hosting device".
05:20:57 <yamahata> Unfortunately we don't have Bob today, let's continue at gerrit or next meeting
05:21:17 <yamahata> continue the discussion
05:21:32 <natarajk> Ok. we need to find something common on for both virtual and physical appliance, i guess
05:21:43 <yamahata> Yes.
05:21:47 <natarajk> if it's only virtual appliance, "hosting device" might be ok.
05:22:45 <yamahata> Okay, then next termnology is "driver".
05:22:46 <natarajk> we can continue the discussion.
05:23:16 <yamahata> I think "driver" in dnrm is the code to spin up/donw VM and so on.
05:23:21 <yamahata> Correct?
05:24:04 <natarajk> Yes. But we are open to common terms there
05:24:14 <natarajk> let me read your specs in detail this week.
05:24:38 <yamahata> I just confirmed to make sure. "driver" is common.
05:25:10 <yamahata> The dnrm code doesn't allow "template" in servicevm terminology.
05:25:41 <yamahata> basically "template" is "driver" name + parameters to nova client.
05:26:11 <yamahata> So i think "template" is superset of dnrm "driver"
05:26:15 <natarajk> Yes. Those were made as configurable in plugin configuration file
05:27:05 <yamahata> Is it acceptalbe to use "template" instead of dnrm "driver"?
05:27:29 <yamahata> For dnrm driver, no parameter will be specified.
05:28:07 <natarajk> thinking ...
05:28:25 <yamahata> Ah, this is not a final call. We can discuss with actual code later.
05:28:38 <yamahata> I'd like to check my direction with others.
05:29:02 <yamahata> before starting actual coding.
05:29:42 <s3wong> yamahata: if the parameters are for provider (service drivers) to initialize, it is more commonly driver entry point, or in flavor framework it is metadata
05:29:54 <yamahata> Maybe I should write details it in spec.
05:30:36 <sweston> yamahata: we will need some time to review this.  May we sync up with you later in the week?
05:30:42 <yamahata> s3wong: Agree. Later we can utilize flavor framework
05:30:49 <yamahata> sweston: Sure.
05:31:06 <s3wong> yamahata: reminder: last week we agreed that this meeting will be 30 minutes :-)
05:31:13 <yamahata> We don't have to have conclusion now.
05:31:14 <sweston> yamahata: thanks
05:31:25 <yamahata> s3wong: thanks.
05:31:33 <yamahata> anything else to discuss?
05:32:22 <yamahata> okay thanks everyone. see you next week.
05:32:27 <s3wong> thanks!
05:32:31 <natarajk> thanks
05:32:32 <yamahata> #endmeeting