05:00:10 <tojuvone> #startmeeting Fenix
05:00:11 <openstack> Meeting started Mon May 20 05:00:10 2019 UTC and is due to finish in 60 minutes.  The chair is tojuvone. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:00:14 <openstack> The meeting name has been set to 'fenix'
05:00:37 <dangtrinhnt> o/
05:00:46 <tojuvone> Wecome to Fenix meeting, time to start
05:01:29 <tojuvone> So, let's have the first topic
05:01:47 <tojuvone> #topic status
05:02:15 <tojuvone> Some bits from OIS + PTG...
05:02:28 <tojuvone> OIS summit and PTG went well, once more links to etherpads
05:02:34 <tojuvone> https://etherpad.openstack.org/p/DEN-fenix-forum-brainstorming
05:02:40 <tojuvone> https://etherpad.openstack.org/p/DEN2019-fenix-ETSI-NFV-PTG
05:02:45 <tojuvone> https://etherpad.openstack.org/p/DEN2019-fenix-PTG
05:02:55 <tojuvone> There was good amount of participants in forum and also good input in PTG
05:03:26 <tojuvone> 22 people in Forum was nice for a new project
05:03:34 <dangtrinhnt> wow
05:03:35 <hyunsikyang> Great
05:04:33 <tojuvone> and in PTG some 5 - 10.. wel there wass 2 sessions anyhow
05:05:16 <tojuvone> There was some discussion about the ETSI changes
05:05:33 <tojuvone> But did not have participants from ETSI side really
05:05:49 <tojuvone> Anyhow good input on the document proposal I had
05:06:26 <tojuvone> Like the interface to be used between Fenix and VNFM
05:07:08 <tojuvone> Otherwise the details are still not ready in ETSI too
05:07:39 <tojuvone> But the interface is the thing to be considered. So still with the AODH
05:08:06 <dangtrinhnt> I'm looking into it. Truth is AODH is only for OpenStack.
05:08:10 <hyunsikyang> Yes. I think the first integration of VNFM, I only think about using AODH and tacker API
05:08:32 <hyunsikyang> However, after that, we can make it independantly.
05:09:02 <hyunsikyang> with this, we also consider ETSI sol interface too:)
05:09:32 <tojuvone> There is was also this etcd v2 "watch" API that one can look at
05:10:14 <tojuvone> and still there is wither someting should be pushed to Nova
05:10:53 <tojuvone> bad thing is that it will then be Nova and not for other cloud
05:11:13 <dangtrinhnt> You meant this #link https://coreos.com/etcd/docs/latest/learning/api.html#watch-api
05:11:17 <tojuvone> Those are like "instance group" details during mainteannce
05:12:33 <tojuvone> dangtrinhnt, yes.. I looked fast there, but haven't given a thought on this
05:13:15 <tojuvone> The thing was that infra should nto call something external (VNFM) directly
05:14:13 <tojuvone> Anyhow just like if have opinions, this is what was mentioned
05:14:56 <tojuvone> Anyhow I would have reasons to have something else as priority first
05:15:05 <hyunsikyang> ok..
05:15:12 <tojuvone> as becasue summit input...
05:15:24 <tojuvone> Want to hear? :)
05:15:45 <dangtrinhnt> So is it that you worrying about Fenix too much depends on OpenStack?
05:16:15 <tojuvone> Well, Kubecon is 16000 people
05:16:32 <dangtrinhnt> holy...
05:16:36 <hyunsikyang> kkkkkkkkk
05:16:55 <tojuvone> that is some number to play against
05:17:20 <tojuvone> Yes, we need to have the OpenStack, but that is so coming next
05:18:15 <hyunsikyang> right.
05:18:29 <tojuvone> In other words, whiel I have not had time for k8s, it will come and fast
05:19:27 <tojuvone> But maybe moving on from this ETSI thing for now?
05:19:49 <dangtrinhnt> True. I had a plan to add support for K8S in Searchlight this cycle.
05:19:54 <dangtrinhnt> +1 tojuvone
05:20:05 <tojuvone> And what would lead to our priority...
05:20:28 <tojuvone> As from PTG input...
05:20:35 <tojuvone> Two big users told to be interested in Fenix. This means we need to focus on maturity
05:21:24 <tojuvone> Like if I recall 147 regions were mentioned
05:22:11 <tojuvone> I would say as of this: Serving potential users is the first priority
05:22:36 <dangtrinhnt> Okie, I looked at the pad. So I think next thing we need to do is to define what maturity means for Fenix.
05:22:58 <tojuvone> yes
05:23:34 <dangtrinhnt> How can we know if Fenix is matured. Some measurable metrics like features, test cases, use cases, number of contributors, etc.
05:23:38 <tojuvone> For me it would be security (interfaces) and ability to take Fenix into use in general
05:23:56 <hyunsikyang> IMO, usecase is important
05:24:48 <tojuvone> Maturity as being able to utilize it. Having testing...
05:24:56 <hyunsikyang> so, I think that we focus on integration of openstack and we should show the result accroding to fenix architecture.
05:25:43 <tojuvone> yes, both user were surely looking into OpenStack maintenance scenario
05:26:20 <tojuvone> This bigger cloud case was to have continuous maintenance as of size of cloud
05:26:50 <tojuvone> So what is "generic" in Fenix should be in shape
05:26:52 <hyunsikyang> we show demo and open the source code and many people can test it. After mature of each function, we make it independently
05:27:02 <hyunsikyang> for generic.
05:27:03 <tojuvone> Whiel users might end up with own plugins
05:27:51 <tojuvone> Our biggest problem is to build testing
05:28:08 <tojuvone> Effort to complete that in every level is huge
05:28:27 <dangtrinhnt> true.
05:29:33 <tojuvone> So I have tried to put priority in storybord and wiki
05:29:45 <dangtrinhnt> okie, that's great.
05:29:52 <hyunsikyang> ok:)
05:29:53 <tojuvone> that would aim to have things ready for users
05:30:02 <dangtrinhnt> Thanks tojuvone.
05:30:24 <tojuvone> storyborad had some tag on priority work
05:31:11 <tojuvone> <level>-priority
05:31:38 <tojuvone> Latest work on this is live migration and almost ready devstack plugin
05:31:53 <tojuvone> Next would be documenting how to install Fenix and how to configure AODH for VNFM interaction
05:32:28 <tojuvone> but I have some other thing going on as well..
05:32:47 <tojuvone> might slow me down, but again showing Fenix to the world
05:33:12 <dangtrinhnt> tojuvone, let put it there and let me see if can do something.
05:33:38 <tojuvone> dangtrinhnt, +1
05:33:50 <hyunsikyang> yes. please share it:)
05:34:12 <tojuvone> So in OPNFV, looking to have a closed-loop demo for something "new"
05:34:43 <tojuvone> Work has started for self-healing + maintenance demo
05:35:15 <tojuvone> Maybe: Prometheus + Vitrage + Mistral and finally Fenix
05:35:23 <tojuvone> aim might be ONS Europe
05:35:34 <dangtrinhnt> great
05:35:42 <hyunsikyang> good
05:36:10 <tojuvone> This kind of closes everything OPNFV Doctor is aiming to do
05:36:23 <tojuvone> that is "fault management and maintenance"
05:36:45 <tojuvone> First you heal instance that is affected by memory fault
05:37:01 <tojuvone> isolate that memory, do nto allow new instances to host
05:37:11 <tojuvone> other instances still stable on host
05:37:28 <tojuvone> but Fenix needs to be called so one can maintain the host then
05:37:57 <tojuvone> and finally all instances running on healthy hosts
05:38:48 <dangtrinhnt> +1
05:39:17 <hyunsikyang> what is the usage(function) of vitrage in this demo?
05:39:19 <tojuvone> I will keep you up-to-date on this
05:39:30 <hyunsikyang> just for GUI?
05:39:37 <tojuvone> Vitrage is root casue analysis
05:40:34 <tojuvone> so it analyses 5 memory faults from monitoring...
05:40:43 <tojuvone> raises alarm in its graph
05:41:08 <tojuvone> and Vitrage template will trigger further action on this
05:41:22 <hyunsikyang> using mistarl. I got it.
05:41:31 <tojuvone> Also Vitrage graph should show Fenix state for a host
05:41:50 <tojuvone> Mistral might have the workflow for self-healing
05:42:26 <tojuvone> While I might rather do the switchover for VM withing sample VNFM code
05:42:44 <tojuvone> as this should be using some Doctor test code
05:43:20 <tojuvone> This is part of Intel started OPNFV closed loop WG work
05:44:43 <tojuvone> ok, I do not think I have anything further
05:44:56 <tojuvone> Do you have something?
05:45:53 <dangtrinhnt> The telemetry is designing its new future. If you have any input, please feel free #link https://etherpad.openstack.org/p/telemetry-train-roadmap
05:47:01 <tojuvone> Great, I also saw there was some AODH demo.. need to look that
05:47:29 <tojuvone> autohealing
05:47:40 <dangtrinhnt> Some suggest auto-scaling and self-healing that may need Fenix :)
05:48:24 <dangtrinhnt> This #link https://www.youtube.com/watch?v=dXsGnbr7DfM&feature=youtu.be
05:48:53 <tojuvone> yes, you could do "self-healing" with Fenix too
05:49:13 <tojuvone> I just do not see it in Telco thing where you react fast
05:49:17 <dangtrinhnt> lxkong, one of the core made that. We're developing some use cases of Ceilometer and AODH in Train-1 milestone
05:49:24 <tojuvone> so more like maintenance
05:49:47 <tojuvone> :)
05:49:54 <dangtrinhnt> :)
05:50:12 <tojuvone> I will definitely watch that
05:50:42 <dangtrinhnt> But I think it more like application self-healing than infras.
05:51:05 <tojuvone> yes, self-healing is mostly that
05:51:26 <tojuvone> if you are not in a hurry, you can utilize Fenix
05:51:47 <tojuvone> Otherwise you need something faster
05:51:49 <dangtrinhnt> Absolutely, I will put it on the next meeting agenda of Telemetry.
05:52:29 <tojuvone> Normally you need ready policy fro infra fault to trigger self-healing
05:52:33 <tojuvone> in split second
05:53:06 <tojuvone> but if it is not that crucial, it can be done with mainteannce session, like fenix
05:53:07 <dangtrinhnt> +1
05:53:32 <dangtrinhnt> Fenix is on our meeting agenda this Thursday :) #link https://etherpad.openstack.org/p/telemetry-meeting-agenda
05:54:32 <hyunsikyang> Tacker also can use it later.
05:54:33 <tojuvone> great, let's see if I can join the meeting
05:54:46 <hyunsikyang> good
05:54:56 <tojuvone> Yes, you have the Tacker BP ongoing :)
05:55:37 <dangtrinhnt> Okie, that's all from me.
05:55:42 <tojuvone> ok, anything else? I will need to jump to doctor meeting soon
05:56:00 <hyunsikyang> nothing from me.
05:56:21 <tojuvone> ok, thanks for the meeting
05:56:34 <tojuvone> And if want to work on sometinhg, just ask
05:56:34 <dangtrinhnt> Thanks, tojuvone.
05:56:43 <hyunsikyang> thanks all
05:56:58 <tojuvone> #endmeeting