05:30:05 <gongysh> #startmeeting tacker
05:30:06 <openstack> Meeting started Wed May 24 05:30:05 2017 UTC and is due to finish in 60 minutes.  The chair is gongysh. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:30:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:09 <openstack> The meeting name has been set to 'tacker'
05:30:28 <gongysh> hi everyone
05:30:35 <gongysh> welcome to tacker meeting
05:31:09 <gongysh> #topic roll call
05:31:15 <YanXing_an> hello
05:32:09 <gongysh> sridhar_ram hi
05:32:28 <gongysh> YanXing_an, hi
05:33:42 <YanXing_an> two man's date?
05:33:47 <gongysh> YanXing_an, it seems there are two of us in the meeting.
05:34:12 <gongysh> YanXing_an, lets start
05:34:27 <YanXing_an> hahaha, ok
05:34:27 <dkushwaha> o/
05:34:40 <dkushwaha> sorry I am late
05:34:41 <gongysh> dkushwaha, it is just on time.
05:34:56 <gongysh> ok, we have one more.
05:35:01 <gongysh> dkushwaha, welcome
05:35:08 <YanXing_an> dkushwaha, nice to see you here
05:35:41 <gongysh> #topic annoucement
05:35:58 <gongysh> 1. meeting time change is requested at https://review.openstack.org/#/c/467443/
05:36:21 <gongysh> once merged, we will update the meeting time.
05:36:46 <gongysh> 2. we have merged 6+ patches last week. a big progress
05:37:38 <dkushwaha> gongysh, can we give +1 on https://review.openstack.org/#/c/467443/ ?
05:37:54 <YanXing_an> Will send a email to declare the meeting time changes?
05:38:01 * sridhar_ram rolls in ..
05:38:01 <gongysh> dkushwaha, anyone can review.
05:38:12 <gongysh> sridhar_ram,  come on.
05:38:31 <gongysh> #topic project activity
05:38:33 <gongysh> http://stackalytics.com/?metric=commits&module=tacker-group
05:38:34 <sridhar_ram> apologies for the delay
05:38:40 <gongysh> sridhar_ram, welcome
05:39:09 <gongysh> YanXing_an and me were thinking this would be a two-men date meeting.
05:39:38 <sridhar_ram> :)
05:40:31 <gongysh> our commit activities is still behind on the http://stackalytics.com/ ranking board.
05:41:09 <gongysh> core members should be more active.
05:41:21 <gongysh> #topic bp
05:41:47 <gongysh> dkushwaha, do you have anything to say about your bp?
05:42:20 <dkushwaha> gongysh, I could not work much  on this in this week
05:42:41 <gongysh> dkushwaha, ok, I have some more comments on it.
05:42:58 <gongysh> we should merge it before p2 deadline.
05:43:32 <dkushwaha> gongysh, yes will update it.
05:43:33 <gongysh> dkushwaha, this feature is of the first priority on feature completeness of this tacker cycle.
05:44:04 <gongysh> #link https://review.openstack.org/#/c/448109/
05:44:06 <dkushwaha> gongysh, I have a question , how can i get network_src_port_id
05:44:36 <gongysh> dkushwaha, maybe your standalone CP01, or by input
05:45:07 <sridhar_ram> dkushwaha: it is the neutron port uuid of the first VNFs ingress CP
05:45:33 <sridhar_ram> dkushwaha: this is where neutron-sfc applies the classifier to steer traffic
05:45:40 <sridhar_ram> .. in the chain
05:45:45 <sridhar_ram> *into
05:45:46 <gongysh> dkushwaha, I think we can treat  the first part on path as the network_src_port_id.
05:46:13 <dkushwaha> gongysh, so it should be their before VNF instance creation?
05:46:39 <dkushwaha> sridhar_ram, ^
05:46:50 <gongysh> dkushwaha, creates path (CP01->CP11->CP13->CP21->CP31)
05:46:54 <YanXing_an> sridhar_ram, yes, it's the first point of flow classifier applied
05:47:05 <gongysh> you can put CP01 as the network_src_port_id.
05:47:07 <sridhar_ram> dkushwaha: no, it can't be known before VNF-1 instantiates
05:47:38 <sridhar_ram> gongysh: the string "CP01" is just a string label
05:47:58 <gongysh> sridhar_ram,         requirements:
05:47:58 <gongysh> - forwarder: CP01
05:47:59 <gongysh> - forwarder: VNF1
05:47:59 <gongysh> capability: forwarder1  #CP11
05:48:00 <gongysh> - forwarder: VNF1
05:48:01 <gongysh> capability: forwarder3  #CP13
05:48:02 <gongysh> - forwarder: VNF2
05:48:03 <gongysh> capability: forwarder1  #CP21
05:48:04 <gongysh> - forwarder: VNF3
05:48:05 <gongysh> capability: forwarder1  #CP31
05:48:06 <gongysh> symmetrical: true
05:48:13 <gongysh> the string label is the same in forwarder path.
05:48:31 <gongysh> should be  the same.
05:49:21 <sridhar_ram> that's fine .. as along as we don't hardcode or interpret the suffix number (01) in the CP
05:50:14 <YanXing_an> gongysh, i think network_src_port_id can not be CP01. In my testbed, it's the gateway port uuid
05:51:05 <dkushwaha> sridhar_ram, gongysh i am referring https://github.com/openstack/tacker/blob/master/samples/tosca-templates/vnffgd/tosca-vnffgd-sample.yaml   and http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd03/tosca-nfv-v1.0-csd03.html#_Toc447714731
05:51:46 <gongysh> dkushwaha, https://github.com/openstack/tacker/blob/master/samples/tosca-templates/vnffgd/tosca-vnffgd-sample.yaml#L18
05:51:59 <gongysh> it specifies the network_src_port_id.
05:52:15 <gongysh> we still need a way to do the same thing in your spec.
05:53:11 <YanXing_an> traffic sent to network_src_port_id will be transfered the first forwarder VNF.
05:53:25 <sridhar_ram> YanXing_an: I'm afraid you might be correct
05:53:33 * sridhar_ram checking networking-sfc docs
05:54:11 <gongysh> so if we do not take the first part of the path as network_src_port_id, we need another way to do it.
05:54:47 <dkushwaha> gongysh, sridhar_ram I am not clear, but I think I am agree with YanXing_an
05:54:51 <gongysh> maybe it is the input of the NS, just like the way we do in vnffg spec.
05:54:54 <YanXing_an> network_src_port_id -> vnf1 -> cp1 -> vnf2 -> cp2 -> ...
05:56:25 <gongysh> YanXing_an, at https://review.openstack.org/#/c/448109/5/specs/pike/vnffg-ns.rst, it should be network_src_port_id -> cp01 -> vnf1:forward1 -> vnf1:forwarder3 ...
05:56:32 <gongysh> right?
05:58:37 <sridhar_ram> this behavior will be dictated by neutron-sfc .. we can try automating finding the "upstream" router port where the CP01 network is connected to
05:59:10 <gongysh> ok, dkushwaha so we need to elaborate the spec  on the network_src_port_id
05:59:39 <dkushwaha> gongysh, I need to look more into this
05:59:56 <gongysh> in vnffg, we are using input parameter to deal with it.
06:00:27 <gongysh> also for symmetric chain, we also need a network_dst_port_id.
06:00:50 <gongysh> 30 mins past
06:00:56 <gongysh> next bps
06:01:27 <YanXing_an> gongysh, i will spend some time on this bp
06:01:38 <gongysh> YanXing_an, thanks
06:01:46 <gongysh> #link https://review.openstack.org/#/c/459520/
06:01:59 <gongysh> Use mistral to do vim reachability monitor
06:02:05 <gongysh> we have got two +2
06:02:17 <gongysh> can anyone of you approve it?
06:02:25 <sridhar_ram> gongysh: i'll do it
06:02:38 <gongysh> #link https://review.openstack.org/#/c/467479/
06:02:44 <gongysh> Implement VNF monitor policies with Mistral workflow
06:02:56 <gongysh> I have write one more
06:03:38 <gongysh> after barbican, and these two specs,  we will remove the obstacle to scale our tacker server.
06:04:52 <sridhar_ram> gongysh: i need to review vnf-monitor spec, but a quick question .. does this also use polling from mistral_action back to tacker conductor
06:05:02 <gongysh> yes
06:05:27 <sridhar_ram> hmm...
06:06:01 <gongysh> to remove it, we need to enhance mistral itself
06:06:22 <sridhar_ram> perhaps a dumb question, can mistral action listen on an "unique" rpc channel ..
06:06:53 <sridhar_ram> .. can this channel.. arg.. topic saved in the tacker-db and used to "stop" mistral action ?
06:08:39 <sridhar_ram> tacker-conductor will be bombarded with polls from all the moinitored VNFs and VIMs
06:10:13 <gongysh> sridhar_ram,  allow tacker conductor to notifyy the actions is one way to do it.
06:10:30 <sridhar_ram> gongysh: exactly ...
06:10:55 <gongysh> sridhar_ram, lets do this way before mistral fixes its problem.
06:11:28 <sridhar_ram> great .. this will go a long way towards scalability
06:12:00 <gongysh> sridhar_ram, thanks the idea.
06:12:07 <sridhar_ram> sure
06:12:22 <gongysh> block volumes support bp
06:12:45 <gongysh> #link https://review.openstack.org/#/c/453442/
06:13:05 <gongysh> it seems the author slept for a long time.
06:13:41 <gongysh> #link https://review.openstack.org/#/c/434974/
06:13:52 <gongysh> Add service assurance engine for E2E services
06:14:25 <gongysh> this should be dealing with some kind of design bugs in VNFFG
06:15:08 <gongysh> #topic bugs
06:15:33 <trinaths> o/
06:15:45 <gongysh> trinaths, hi
06:15:49 <gongysh> https://review.openstack.org/#/c/465080/
06:15:58 <YanXing_an> need more reviews on barbican
06:16:00 <gongysh> this is YanXing_an's brbican integration
06:16:38 <gongysh> YanXing_an, you need to consider the db migration
06:16:54 <YanXing_an> gongysh, ok, i will add it
06:17:01 <sridhar_ram> The reporter of https://bugs.launchpad.net/tacker/+bug/1691792 is looking for some help
06:17:02 <openstack> Launchpad bug 1691792 in tacker "Can't create forwarding graph on tacker" [Undecided,Incomplete]
06:17:11 <gongysh> and to consider the existed VIM which has no your defined key_type.
06:17:21 <sridhar_ram> YanXing_an: i'll review ur barbican
06:17:30 <sridhar_ram> .. patchset
06:18:06 <gongysh> sridhar_ram, yes, but I think the reporter pasted the log on tacker client side, not tacker server side.
06:18:26 <YanXing_an> sridhar_ram, nice to have your review opinions. thanks
06:18:27 <gongysh> so we are not able to tell what is happened on server side.
06:18:35 <sridhar_ram> YanXing_an: sure
06:18:50 <sridhar_ram> gongysh: agree, we need server logs ...
06:19:43 <gongysh> I have no other bugs to talk about.
06:20:02 <gongysh> sridhar_ram, I remember you have a patch to unified the openstack drivers.
06:20:19 <YanXing_an> if existed vim has key_type, it will use fernet_key in local file system
06:20:43 <sridhar_ram> gongysh: yes, i need to revive it and re-spin ... will get to it next week
06:20:49 <YanXing_an> -> has no key_type
06:21:45 <gongysh> #topic open discussion
06:22:01 <gongysh> so what other stuff do you guys want to talk?
06:22:55 <YanXing_an> I think we need validate tosca template, what do you think?
06:23:07 <YanXing_an> for example, https://bugs.launchpad.net/tacker/+bug/1693070
06:23:09 <openstack> Launchpad bug 1693070 in tacker "Should only support one mgmt-ports" [Undecided,New] - Assigned to Yan Xing'an (yanxingan)
06:24:05 <sridhar_ram> also, there was this weird issue reported here .. https://answers.launchpad.net/tacker/+question/633708
06:24:16 <sridhar_ram> i was scratching my head
06:25:51 <gongysh> sridhar_ram, 2017-05-23 12:46:42.704 8178 DEBUG tacker.vnfm.plugin [req-14c6d1e2-ec5d-4da8-b582-0d55236fea13 2db962522806470c98bc1c4c1be4c002 b078332877a243c3be1644d4ae77f439 - - -] unknown vim driver openstack in ['noop', 'openstack']
06:26:23 <gongysh> unknown vim driver openstack in ['noop', 'openstack']?
06:26:25 <gongysh> haha
06:26:46 <sridhar_ram> yeah, but the type is 'openstack' from the vim-list output
06:27:21 <sridhar_ram> YanXing_an: need to think a bit, if multiple mgmt CPs are valid for any particular use-case ..
06:27:53 <sridhar_ram> ... i *think* it shd be okay to restrict it to one per VNF
06:28:46 <sridhar_ram> need to update this doc if we change this behavior .. https://docs.openstack.org/developer/tacker/devref/vnfd_template_description.html
06:29:09 <YanXing_an> maybe openstack is not added into infra driver
06:29:33 <YanXing_an> sridhar_ram, yes, i will think it
06:30:08 <gongysh> ok time is up.
06:30:09 <sridhar_ram> mgmt-driver can be configured to accept a list of mgmt_ips and process it
06:30:11 <gongysh> thanks everyone.
06:30:14 <YanXing_an> if infra_driver not in self._vnf_manager:  maybe self._vnf_manager is empty?
06:30:20 <gongysh> #endmeeting