05:01:32 <yamahata> #startmeeting servicevm-device-manager
05:01:33 <openstack> Meeting started Tue Sep 30 05:01:32 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:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:01:37 <openstack> The meeting name has been set to 'servicevm_device_manager'
05:01:44 <bmelande> Hi all!
05:01:59 <yamahata> bmelande: hi. glad to see you
05:02:11 <yamahata> #topic Announcement
05:02:22 <yamahata> #chair s3wong bmelande
05:02:23 <openstack> Current chairs: bmelande s3wong yamahata
05:03:26 <yamahata> I uploaded preview patches to refactor l3_db for routervm
05:03:46 <yamahata> #link https://review.openstack.org/#/c/124695/
05:03:52 <bmelande> yamahata: Yes I saw that. I will review them.
05:03:53 <yamahata> #link https://review.openstack.org/#/c/124699/
05:04:03 <yamahata> #link https://review.openstack.org/#/c/124699/
05:04:13 <yamahata> as Kilo cycle is not opened yet, I maked them WIP
05:04:34 <yamahata> They are intended to pave the road for routervm
05:05:02 <bmelande> yamahata: What are the main changes you want to make?
05:05:10 <yamahata> I think they needs discussion to address requirements.
05:05:42 <s3wong> yamahata: will take a look
05:05:43 <yamahata> They allow hooks to override port deletion/update.
05:06:36 <yamahata> when router or interface attached to router is deleted, we'd like to avoid actual port deletion.
05:06:46 <bmelande> yamahata: But router ports still use device_owner, device_id attributres?
05:07:30 <yamahata> bmelande: Yes, basically. the patch allows routervm to do its own task instead of common code that deletes port unconditionally
05:08:21 <bmelande> yamahata: Ok, I see.
05:08:24 <yamahata> vyatta plugin duplicates many code to override it.  So I put hooks there.
05:08:39 <bmelande> yamahata: ok, makes sense.
05:09:06 <yamahata> That's all from me.
05:09:28 <yamahata> s3wong: any announce for other project of design summit?
05:09:46 <s3wong> yamahata: other projects?
05:10:04 <yamahata> s3wong:  the "Other projects" track
05:10:06 <s3wong> you mean to apply for the "other projects" design summit?
05:10:19 <s3wong> yamahata: I haven't heard back yet. I don't think they will notify us this early
05:11:09 <yamahata> s3wong: I see. I'll pray for the acceptance.
05:11:43 <s3wong> yamahata: bmelande: yes, as I mentioned in the email, it didn't ask for descriptions
05:11:58 <bmelande> yamahata: what is the status of Tacker, wrt to incubation?
05:12:08 <s3wong> so my guess is it is either first come first serve, or it is through some hidden selection process
05:12:35 <yamahata> bmelande: The plan is to make reference routervm work and apply for official incubation in kilo cycle.
05:12:41 <bmelande> s3wong: Who do we buy some beers? :-)
05:13:00 <yamahata> I suppose without working code, TC won't approve the application
05:13:10 <s3wong> bmelande: probably too many people :-)  Secret society everywhere in OpenStack :-)
05:13:44 <yamahata> To be honest, I don't know the actual criteria.
05:13:47 <bmelande> yamahata: Ok. Seems like a reasonable requirement and plan to deal with it,
05:13:55 <s3wong> yamahata: bmelande: I agree, we need to justify having a separate project - and that needs code and clear use
05:14:01 <yamahata> Do we want to apply for incubation even without working code?
05:14:13 <s3wong> yamahata: I would wait
05:14:42 <s3wong> yamahata: bmelande: for example, Congress has had their alpha release, and I haven't heard they are going to apply for incubation yet
05:14:46 <bmelande> yamahata, s3wong: Same here. Let's wait and proceeed as we do now until basic working code is in place.
05:15:04 <yamahata> #topic Open Discussion
05:15:21 <yamahata> Regarding to reference routervm code, I'm working on it.
05:15:39 <yamahata> Now I'm trying to refactor/simplify config agent code
05:15:58 <bmelande> yamahata: ok.
05:16:10 <s3wong> yamahata: cool
05:16:12 <yamahata> During that, I happened to refactor l3_db
05:16:46 <bmelande> yamahata, s3wong: Did any of you add the service VM and routervm code consolidation to the Neutron kilo summit ehterpad?
05:17:01 <s3wong> bmelande: yes, I did
05:17:19 <bmelande> s3wong: Ok good
05:17:20 <s3wong> bmelande: and I believe someone else also added a sub-item on fw-vm
05:17:31 <yamahata> s3wong: I did for fw-vm
05:17:42 <s3wong> yamahata: oh, that was you :-)
05:18:35 <yamahata> bmelande: I suppose you have already code so you have opinions
05:19:02 <bmelande> yamahata, s3wong: I also saw that someone added L3 router servicetype/flavor support as an item. We should make sure to be part of that if it is discussed.
05:19:35 <s3wong> bmelande: yamahata: IF we get a session slot, we should discuss the content we want to talk about
05:19:57 <s3wong> bmelande: yes, flavor didn't make Juno; so it is up for Kilo discussion
05:21:02 <yamahata> Once kilo spec is opened, we will submit specs and start discussion in advance.
05:21:35 <bmelande> yamahata: what specs did you have in mind?
05:21:56 <s3wong> yamahata: you mean we should submit tacker related specs at Neutron?
05:22:07 <yamahata> s3wong: a sort of
05:22:16 <yamahata> bmelande: (l3 refactoring,)
05:22:23 <yamahata> refererence routervm
05:22:23 <s3wong> yamahata: I see
05:22:53 <yamahata> router plugin servicetype(or flavor) support
05:23:28 <yamahata> For firewall case, I'd like to submit vendor specific blob, L4-7 api
05:24:06 <yamahata> Probably generic config agent and so on. This would be to generalize CSR1kv code.
05:24:26 <yamahata> Do you want to take some of them?
05:24:56 <s3wong> yamahata: do you foresee vendor service VM to have code running with Neutron server?
05:25:46 <s3wong> i.e., do you see that vendor service VM would invoke core_plugin methods directly (thus needs to run in the same context as Neutron)?
05:25:46 <bmelande> yamahata: Yes we can discuss that. There is a patch set in review to add FW support for CSR via cfg agent adn new fw plugin
05:26:07 <yamahata> s3wong: I think in Neutron there is their own driver code to talk to their VM. Not so much code in nuetron.
05:27:02 <s3wong> yamahata: yes, the trend seems to be advanced services may eventually all be spinned off of Nuetron (even Salvatore talked about that once in the ML)
05:27:10 <yamahata> bmelande: regarding to vlan trunking, I'm not sure how to make progress or united effort
05:27:22 <bmelande> s3wong, yamahata: Describing usgage models for service vm will be useful.
05:27:47 <s3wong> yamahata: bmelande: I would hate to see the tacker code to start calling Neutron core method or dependent on running with Neutron
05:28:24 <s3wong> yamahata: bmelande: there are too many VLAN trunking related bps
05:28:26 <yamahata> s3wong: Sure. just one way from neutron to tacker.
05:28:38 <bmelande> yamahata: Yes, if/how VLNA trunking will be supported is still open in Neutron
05:29:10 <yamahata> If we need two way communication, the tacker code should be in neutron, I suppose. anyway we will see.
05:29:24 <s3wong> yamahata: bmelande: though I think it is inevitable that VLAN trunking support would need to be in Neutron, probably not in serviceVM
05:29:46 <bmelande> s3wong: Yes definitely.
05:30:10 <yamahata> s3wong: Yes.
05:31:06 <yamahata> s3wong: I mean there are several blueprints.  and how to reconcile them.
05:31:13 <s3wong> yamahata: yes
05:31:18 <bmelande> yamahata, s3wong: For now I think we can leave issues like VLAN trunking for future and focus on nailing down how tacker is to be used, interactions between neturon and tacker etc
05:31:40 <yamahata> bmelande: +1
05:31:50 <s3wong> yamahata: bmelande: also, I agree with bmelande here. IF we get a design session slot, or just get an hour at the pod, we should explain the need of serviceVM / tacker
05:33:30 <yamahata> time is over.
05:33:32 <bmelande> yamahata: s3wong: so, going in that direction... how are we going to have that discusion leading up to the summit? Do we do it as a spec and comment on it?
05:34:04 <yamahata> bmelande: anyway is okay for me.
05:34:13 <s3wong> yamahata: bmelande: we should have a direction on where we want to go for Kilo
05:34:38 <s3wong> yamahata: bmelande: and subsequently file specs for that direction
05:36:03 <s3wong> yamahata: bmelande: if we are just filing specs for tacker, that's easy; but if we are filing specs for Neutron --- I think kilo spec is open now (according to markcmcclain during today's Neutron meeting)
05:36:42 <yamahata> s3wong: Oh. that's good. I missed today's neutron meeting.
05:37:16 <s3wong> yamahata: I might have misread it, it could be "will open"
05:37:17 <yamahata> For tacker-spec, it's always open. :-)
05:37:44 <s3wong> yamahata: we are in the midst of RC1 release, so I am not sure spec is open; but it should be soon, if not now...
05:38:43 <yamahata> s3wong: I see. anyway I'm going to follow irc log.
05:38:47 <ekarlso> what's the service-vm thing btw vs using heat ?
05:39:45 <yamahata> ekarlso: service-vm mainly focuses on network stuff. It's spin off from Neutron.
05:40:16 <yamahata> Probably there are some overlap with Heat, the focus is different.
05:40:18 <ekarlso> aho k
05:40:33 <bmelande> ekarlso: Sort of a "mission statement is here" :https://review.openstack.org/#/c/103724/4/specs/juno/api.rst
05:42:29 <yamahata> anything else to discuss?
05:42:54 <s3wong> all good
05:43:19 <yamahata> thank you everyone. see you next week
05:43:24 <s3wong> thanks!
05:43:24 <yamahata> #endmeeting