Friday, 2019-05-31

*** tojuvone has joined #openstack-fenix05:12
*** hyunsikyang__ has joined #openstack-fenix05:54
*** hyunsikyang__ has quit IRC05:58
*** hyunsikyang__ has joined #openstack-fenix05:58
*** hyunsikyang__ has quit IRC05:58
openstackgerritTomi Juvonen proposed x/fenix master: Add more configuration parameters to DevStack  https://review.opendev.org/66238606:09
hyunsikyanghi07:12
hyunsikyanganyone is here?07:12
hyunsikyangtomi?07:13
hyunsikyangor dangtrinhnt?07:13
hyunsikyangtojuvone?07:13
hyunsikyangkk07:13
tojuvoneHi, yes07:29
hyunsikyanghi07:38
hyunsikyangI have a question for fenix integration..07:38
tojuvoneyes07:39
hyunsikyangIn my understanding, Fenix knows all of the VNf which is deplyed now... and all of the procedure is lead by fenix.07:40
tojuvoneyes, all the projects in nova space currently known07:40
tojuvoneand all VNFs that have subscribed to AODH07:41
hyunsikyangit means that all of the VNf should be registered to AODH.07:41
tojuvoneIf they want to support interaction07:41
hyunsikyangyes07:42
hyunsikyangOf course.07:42
tojuvoneotherwise FEnix should have some default behavior07:42
hyunsikyangnow I am considering all of VNF which is made by tacker register maintanance or only maintanance option have.07:43
tojuvoneor the workflow used should have07:43
hyunsikyangyes. So I will keep current spec for this first integration.07:45
hyunsikyangAnd second one is AODH.07:45
hyunsikyangIn the tacker,07:45
tojuvoneI think it should be VNF specific if there can be VNF specific behavior in Tacker side07:46
tojuvoneotherwise for all the VNFs07:47
hyunsikyangWhen we defined AODH alarm and Policy in the VNFD, these thing managed by tacker.07:47
hyunsikyangWhen we defined AODH alarm and Policy in the VNFD, these thing managed by Heat*07:47
hyunsikyangnot tacker.07:47
hyunsikyangSo to register AODH.. we need a definition of policy like this https://github.com/openstack/heat-translator/blob/30f4d2ff8371bb7a33d2790ca5df77de951965ee/translator/hot/tosca/tosca_policies_reservation.py07:48
hyunsikyangBut in the fenix case, all of the action is managed by fenix.07:48
hyunsikyangSo I think we don't have any policy for Fenix in this time.07:49
hyunsikyangWhat do you think?:)07:50
tojuvoneFenix have admin rights always to perform migrations if VNF so chooses to do07:50
tojuvoneotherwise VNF always have right do re-instantiate07:50
tojuvoneso the policy is already in Fenix07:50
hyunsikyangI think so..07:51
tojuvoneIf one have agreed that Fenix can be used, one have also agreed that it may make migration in interaction with VNF07:52
tojuvonethat is normally not granted fro VNF07:52
tojuvonebut now granted in maintenance then07:52
hyunsikyangSo now I am thinking of interaction between Fenix and tacker...07:54
hyunsikyangMy last question is ... if admin knows every VNF info, can Fenix send maintenance message to particular several VNFs which is located at HOST1 at a one time?07:58
tojuvoneSo having the maintenance interaction enabled in tacker, will have the policy granted for all VNFs to migrate during maintenance07:58
tojuvoneyes07:59
tojuvoneseparate message for each07:59
tojuvoneeach of those is different project in Nova sapce08:00
tojuvoneand has it own control08:00
tojuvoneown VNF specific API endpoint in both ends for the interaction08:00
hyunsikyangbt, can fenix have any option for grouping of VNF?08:01
tojuvonecurrently no08:01
tojuvoneand it doesn't make sense08:01
hyunsikyangIn my thinking , when Host 1 needs upgrade, admin should send maintenance message to all vnf which are located at HOST1.08:02
hyunsikyangso I am thinking about grouping.08:03
tojuvoneAPI to subscribe is VNF specific, so no groupping makes sense08:03
tojuvonethey can be under different VNFM08:04
hyunsikyangAh got it.08:04
tojuvoneAnd at the end its their EM making decisions08:04
hyunsikyangAbout spac, we agreed that we use maintenance option optionally in the last tacker meeting. So we keep the maintanance option .08:07
tojuvoneok08:09
*** openstack has joined #openstack-fenix12:30
*** ChanServ sets mode: +o openstack12:30
*** openstackstatus has joined #openstack-fenix14:30
*** ChanServ sets mode: +v openstackstatus14:30
-openstackstatus- NOTICE: The Gerrit service at https://review.opendev.org/ will be offline briefly for maintenance starting at 15:00 UTC (roughly 30 minutes from now); for details see http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006684.html14:31
-openstackstatus- NOTICE: Gerrit is now entering its maintenance window. Expect Gerrit outages in the near future. We will notify when it is back up and running.15:06
*** ChanServ changes topic to "Gerrit is now entering its maintenance window. Expect Gerrit outages in the near future. We will notify when it is back up and running."15:06
*** ChanServ changes topic to "Welcome to Fenix. Next meeting: 3rd June 5 AM UTC. Add topics to: https://wiki.openstack.org/wiki/Fenix#Meetings"15:59
-openstackstatus- NOTICE: Gerrit is back up and running again. Thank you for your patience and sorry for the delay in this notification (we thought the statusbot was still busy updating channel topics).16:46
*** openstackgerrit has quit IRC19:01
*** tojuvone has quit IRC23:22
*** tojuvone has joined #openstack-fenix23:22

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!