04:29:50 <gongysh_> #startmeeting tacker
04:29:51 <openstack> Meeting started Wed Jun 28 04:29:50 2017 UTC and is due to finish in 60 minutes.  The chair is gongysh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:29:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:29:54 <openstack> The meeting name has been set to 'tacker'
04:29:58 <Liuqing> \o
04:30:12 <gongysh_> #topic roll call
04:30:18 <YanXing_an> hello
04:30:21 <gongysh_> hi, everyone
04:30:36 <YanXing_an> Liuqing, hello
04:30:39 <tbh_> Hi all
04:30:47 <gongysh_> YanXing_an, you have a busy last week, right?
04:30:53 <Liuqing> YanXing_an ,hi
04:31:32 <YanXing_an> gongysh, yes, finally fix the CI case, it's a looong work
04:31:34 <tung_doan> o/
04:32:09 <sridhar_ram> o/
04:32:56 <gongysh_> YanXing_an, yes,  it works at last. thanks the CI gate which help us to improve the codes.
04:33:19 <gongysh_> sridhar_ram, hi, how's the week?
04:33:32 <sridhar_ram> gongysh_: going on ..
04:33:47 <gongysh_> sridhar_ram, it never stops the beat!
04:34:10 <tung_doan> sridhar_ram: long time no see :)
04:34:12 <sridhar_ram> gongysh_: help as much possible w/ the reviews under the circumstances
04:34:19 <sridhar_ram> *helping
04:34:48 <sridhar_ram> unfortunately that the current state of affairs in my end :(
04:35:16 <gongysh_> #topic bp
04:35:30 <gongysh_> tung_doan, hi
04:35:44 <gongysh_> Add auto-healing function for VNFFG
04:35:56 <gongysh_> https://review.openstack.org/#/c/434974/
04:36:09 <gongysh_> I think we should have time for this.
04:36:17 <tung_doan> gongysh_: hi.. I am trying to wrap my bp
04:36:32 <gongysh_> my concern is the API way for vnfm to nfvo
04:36:55 <tung_doan> gongysh_: I think it just needs some minor changes now
04:36:58 <gongysh_> sridhar_ram, do you have any comments for the callback method.
04:37:19 <tung_doan> gongysh_: I prefer using API for this
04:37:32 <sridhar_ram> tung_doan: gongysh_: yes, that will break the modularity and the layering
04:37:34 <gongysh_> tung_doan is using http API, my commented way is to use MESSAGE rpc.
04:38:36 <sridhar_ram> in fact, we should avoid any VNFM -> NFVO call .. both http and rpc
04:38:44 <sridhar_ram> can
04:39:10 <sridhar_ram> can't NFVO listen for events from VNFM and readjust FFG if needed ?
04:39:21 <tung_doan> gongysh_: sridhar_ram: We also need a generic method for Network Services (NSs). Therefore, I think API is a suitable choice
04:40:18 <sridhar_ram> we need to clearly understand the ownership of resources first .. VNF resources are "owned" by VNFM. FFG is "owned" by NFVO
04:40:27 <trinaths> o/
04:40:38 <gongysh_> sridhar_ram,  even with events: (in fact, RPC or HTTP API is a kind of event) we can not isoloate VNFM and NFVO.
04:40:44 <gongysh_> sridhar_ram, right
04:41:15 <sridhar_ram> VNFM shouldn't know a VNF is participating in a FFG ..
04:41:39 <sridhar_ram> all it needs to give are .. low level neutron ports IDs for NFVO to stitch a FFG
04:41:39 <tung_doan> sridhar_ram: alsolutely.
04:42:05 <trinaths> sridhar_ram: +1
04:42:13 <sridhar_ram> .. if that low level ports change .. NFVO needs to be notified so that it can reapply a FFG using newer low level ports
04:42:16 <tung_doan> sridhar_ram: you got the point. That's why we inform vnffgs (NSs), which VNFs belong to
04:42:32 <sridhar_ram> VNFM shd just emit events out and NFVO shd react
04:43:07 <sridhar_ram> tung_doan: then, can we make this generic .. can VNFM emit "VNF" respawned or altered or scaled event out ..
04:43:09 <tung_doan> sridhar_ram: +2
04:43:20 <sridhar_ram> tung_doan: NFVO can subscribe to these events and react appropriately
04:43:32 <tung_doan> sridhar_ram: that's totally something I want to do :)
04:43:42 <sridhar_ram> tung_doan: but there shd be no REST API or RPC calls from VNFM towards NFVO API
04:44:06 <gongysh_> what is the event method?
04:44:33 <tung_doan> sridhar_ram: gongysh_: how can we emit events?
04:45:57 <sridhar_ram> we don't have the async event publish method implemented yet
04:45:57 <gongysh_> sridhar_ram,  enssentially, the RPC call, or HTTP API is a kind of event  emit and acceptance. RPC call can be RPC cast, which is asynchronous.
04:46:08 <tung_doan> gongysh_: sridhar_ram: My code locally implemented with API. It looks reasonable
04:46:34 <sridhar_ram> we had planned a follow on to https://blueprints.launchpad.net/tacker/+spec/audit-support which will send the events out ...
04:46:56 <sridhar_ram> gongysh_: what direction is the HTTP API happens ?
04:48:02 <sridhar_ram> here is a proposal .. that the most efficient but architecturally the right thing (IMO):
04:48:20 <gongysh_> one way I think is to differentiate the policy into two level. one level is VNFM,  another is nfvo level.
04:48:48 <sridhar_ram> have NFVO poll VNF event list periodically .. if any of the VNFs in the FFG respawned or scaled .. delete and re-apply FFG
04:48:54 <tung_doan> sridhar_ram: my concern is whether it is generic enough to use event/audit functions in place
04:49:19 <sridhar_ram> tung_doan: why do you think it WON'T be generic?
04:49:31 <gongysh_> nfvo policy is done on nfvo level, if a vnf is managed by NFVO policy, its own policy is disabled.
04:50:00 <YanXing_an> the HTTP API is exposed to user, i think it is not a good way, user does not use it
04:50:45 <sridhar_ram> just to be clear are we talking about https://review.openstack.org/#/c/434974/12/specs/pike/vnffg-autohealing.rst@L55 here ?
04:50:55 <tung_doan> sridhar_ram: when we refer to API, we can control request. with event/audit, I cannot imagine how to do
04:50:59 <sridhar_ram> call back action from VFNM policy back to NFVO ?
04:51:38 <sridhar_ram> tung_doan: it is HUGE layer violation for VNFM to call a NFVO API in first place ..
04:52:06 <sridhar_ram> tung_doan: architecturally that does not make sense ..
04:53:10 <YanXing_an> In ETSI NFV MANO, Or-vnfm reference point is used between nfvo and vnfm, supports:
04:54:01 <YanXing_an> Forwarding of events, other state information about the VNF that may impact also the NS instance
04:54:26 <sridhar_ram> Exactly ...
04:54:44 <sridhar_ram> .. we shd restrict it to events out of VNFM -> NFVO
04:54:47 <trinaths> YanXing_an: agree
04:55:09 <tung_doan> YanXing_an: that's right. ETSI said that NSs can get failure events from other functional blocks. It could be from VNFM level
04:55:35 <sridhar_ram> in fact, the current tacker architecture event envisions a SINGLE NFVO using multiple site-local VNFMs .. we need to preserve that model
04:55:42 <sridhar_ram> s/event/even/
04:55:46 <gongysh_> YanXing_an, sridhar_ram , I think there should allow vnfm to emit event to upper layers.
04:56:32 <sridhar_ram> gongysh_: we planned a follow for https://blueprints.launchpad.net/tacker/+spec/audit-support .. to use a pub-sub bus for external entities to receive events from Tacker
04:57:19 <sridhar_ram> for now, we can use an internal event queue from VNFM -> NFVO to implement this FFG-HA feature
04:57:39 <sridhar_ram> .. suggesting this as a way to unblock us for near term
04:58:07 <tung_doan> sridhar_ram: what problem if users they want to do HA functions for VNFFG or even NSs?
04:58:25 <gongysh_> sridhar_ram,  how about to use rabbit mq for vnfm to emit cast message to a certain queues?
04:58:43 <sridhar_ram> gongysh_: that would work too ..
04:59:07 <sridhar_ram> as long as the changes to VNFM are "generic" and not specific
04:59:49 <sridhar_ram> tung_doan: the user facing functionality is fine .. it is a valid feature and we need to implement it.. "how" is the question here
05:00:40 <gongysh_> tung_doan, lets use tacker conductor to implement the queue.
05:00:41 <tung_doan> sridhar_ram: that's why I am stil thinking about API support :)
05:01:16 <gongysh_> vnfm rpc cast, conductor receives it.
05:01:33 <sridhar_ram> tung_doan: API from VNFM -> NFVO does (reverse) coupling of layers that does not make sense
05:02:38 <tung_doan> sridhar_ram: I mean API support can use for both users and VNFM level. Is it acceptable?
05:03:44 <sridhar_ram> tung_doan: sorry, what you mean by users here?
05:04:01 <gongysh_> tung_doan, I don't think https://review.openstack.org/#/c/434974/12/specs/pike/vnffg-autohealing.rst@L55 is for user
05:04:33 <sridhar_ram> gongysh_: +1
05:04:53 <YanXing_an> gongysh, +1
05:05:16 <YanXing_an> Sridhar_ram: Tacker support events on VNF resource, how about nfv subscibe the events? If so, we need define the event carefully
05:05:16 <gongysh_> so, about for tacker conductor way?
05:05:43 <sridhar_ram> YanXing_an: that is exactly what I
05:05:56 <sridhar_ram> YanXing_an: that is exactly what I'm proposing
05:06:27 <sridhar_ram> gongysh_: for near-term, yes that would work ..
05:07:03 <sridhar_ram> i'm trying to search with success a ppt from a previous tacker midcycle meetup that describes events emitted using a pub-sub bus
05:07:14 <gongysh_> tung_doan, then do tacker conductor way.
05:07:47 <tung_doan> gongysh_: i will look into conductor. thanks
05:07:49 <sridhar_ram> this for any application on top of Tacker to receive events .. that is the ideal way .. an internal rpc might work as a near term alternative
05:08:08 <gongysh_> sridhar_ram, we have to think pub-sub bus beyond tacker api server process.
05:08:27 <gongysh_> the rabbitmq is the way to do it.
05:08:27 <sridhar_ram> yes.. it is generic and can be used internally as well..
05:08:44 <sridhar_ram> Tacker NFVO becomes an "app" for Tacker VNFM
05:09:03 <sridhar_ram> for -> "on top of"
05:09:06 <gongysh_> sridhar_ram, also to remember, we will remove all policy action into tacker conductor.
05:09:21 <gongysh_> remove -> move.
05:09:53 <sridhar_ram> gongysh_: i see tacker-conductor as a worker process shared by both NFVO and VNFM ..
05:10:03 <sridhar_ram> it is more a utility worker process IMO
05:10:15 <sridhar_ram> what do you think?
05:10:52 <sridhar_ram> both NFVO and VNFM can send their long running "work" to tacker-conductor to get it done
05:10:58 <sridhar_ram> .. and have the results back
05:11:21 <gongysh_> sridhar_ram, if I understand you, I say yes. we can use tacker conductor as a pub-sub system too.
05:11:44 <sridhar_ram> ack ...
05:11:59 <gongysh_> lets wrap the healing bp.
05:12:25 <sridhar_ram> again, please keep the architecture clean in a way one day Tacker NFVO can be installed in a central site and local Tacker VNFM can be installed in local OpenStack sites
05:12:35 <gongysh_> tung_doan, to investigate the conductor way, thanks.
05:12:38 <gongysh_> sridhar_ram, right.
05:12:45 <tung_doan> gongysh_ : sure
05:12:50 <trinaths> sridhar_ram: that must be the design
05:13:00 <gongysh_> #topic code patches
05:13:09 <sridhar_ram> trinaths: yep
05:13:33 <gongysh_> vim monitoring mistral way is merged.
05:13:42 <gongysh_> do you anyone try it?
05:14:24 <gongysh_> not yet?
05:14:29 <YanXing_an> i will upgrade my testbed to use it
05:14:39 <trinaths> gongysh_: not yet. will try that
05:14:47 <gongysh_> YanXing_an, great.
05:14:49 <YanXing_an> not yet +1.
05:14:49 <gongysh_> trinaths, thanks
05:15:29 <gongysh_> next patch I want you to merge is https://review.openstack.org/#/c/465080/
05:16:17 <gongysh_> It passed the CI gate and a long patchset chain.
05:16:26 <gongysh_> I think it is the time to get it merged.
05:17:24 <gongysh_> and then we will have time to test it during developers daily work, when they are developing other features.
05:17:37 <YanXing_an> wow, it's good news. I will fix any bugs if appeared.
05:17:45 <trinaths> YanXing_an: nice work
05:17:52 <sridhar_ram> YanXing_an: great job!!
05:18:02 <gongysh_> https://review.openstack.org/#/c/476449/
05:18:16 <YanXing_an> trinaths, sridhar_ram, thanks.
05:18:19 <gongysh_> this is from
05:18:20 <gongysh_> vagrant <dharmendra.kushwaha@nectechnologies.in>
05:18:35 <gongysh_> will conflict with https://review.openstack.org/#/c/465080/
05:18:44 <gongysh_> on db migration script
05:19:08 <gongysh_> so we will merge  https://review.openstack.org/#/c/465080/ and then https://review.openstack.org/#/c/476449/
05:19:49 <gongysh_> other patch is https://review.openstack.org/#/c/472045/
05:19:58 <gongysh_> also from dharmendra.kushwaha@nectechnologies.in
05:20:23 <gongysh_> recently, our core dharmendra is doing great to improve the tacker inner logical
05:20:29 <gongysh_> that is great.
05:20:57 <sridhar_ram> +1
05:21:43 <gongysh_> before next meeting, we will have these patch to be merged.
05:21:55 <gongysh_> #topic open discussion
05:22:16 <gongysh_> anything to talk?
05:22:48 <gongysh_> tung_doan, hi
05:23:10 <tung_doan> gongysh_: pong
05:23:19 <gongysh_> could we enable the policy related CI tests?
05:23:50 <tung_doan> gongysh_: could you pls elaborate? Why we need this? thanks
05:24:16 <YanXing_an> gongysh, how to generate a asic chart using blockdiag, i can only generate a picture
05:24:55 <gongysh_> tung_doan, http://logs.openstack.org/80/465080/22/check/gate-tacker-dsvm-functional-ubuntu-xenial-nv/47dd728/testr_results.html.gz
05:25:14 <sridhar_ram> YanXing_an: team: https://answers.launchpad.net/tacker/+question/633708 keeps lingering ... seems multiple folks are hitting this issue.
05:25:17 <gongysh_> tung_doan, tacker.tests.functional.vnfm.test_tosca_vnf_alarm.VnfTestAlarmMonitor
05:26:21 <tung_doan> gongysh_: I am trying to fix this patch: https://review.openstack.org/#/c/462690/ . It will be finished soon for sure
05:26:23 <trinaths> YanXing_an: you can use ascii to text generators
05:26:55 * gongysh_ is seaching for YanXing_an
05:27:28 <tbh_> sridhar_ram:  can I work on that
05:27:56 <gongysh_> YanXing_an, why do you need asscii?
05:28:05 <YanXing_an> sridhar_ram, yes, it linger there for long time
05:28:06 <tbh_> Or someone working on that
05:28:27 <gongysh_> you can just put the blockdiag in rst.
05:28:36 <sridhar_ram> tbh_: YanXing_an: i just asked some info .. but tbh_ if yoyu'
05:28:42 <gongysh_> you don't need to upload the png.
05:28:55 <sridhar_ram> tbh_: if you've some time please take a look. thanks!
05:28:55 <trinaths> gongysh_: we dont upload any png.
05:29:06 <YanXing_an> gongysh, if so, we can only see the chart in CI result
05:29:11 <trinaths> gongysh_: we just do ascii based diagrams
05:29:23 <gongysh_> trinaths,  no, that is not absolutely.
05:29:46 <trinaths> gongysh_: can we have png/jpeg stuff included ?
05:29:59 <gongysh_> YanXing_an, yes sometime.
05:30:05 <gongysh_> time is up.
05:30:11 <gongysh_> thanks for everyone.
05:30:16 <gongysh_> good day or night.
05:30:19 <gongysh_> #endmeeting