*** tojuvone has joined #openstack-fenix | 05:12 | |
*** hyunsikyang__ has joined #openstack-fenix | 05:54 | |
*** hyunsikyang__ has quit IRC | 05:58 | |
*** hyunsikyang__ has joined #openstack-fenix | 05:58 | |
*** hyunsikyang__ has quit IRC | 05:58 | |
openstackgerrit | Tomi Juvonen proposed x/fenix master: Add more configuration parameters to DevStack https://review.opendev.org/662386 | 06:09 |
---|---|---|
hyunsikyang | hi | 07:12 |
hyunsikyang | anyone is here? | 07:12 |
hyunsikyang | tomi? | 07:13 |
hyunsikyang | or dangtrinhnt? | 07:13 |
hyunsikyang | tojuvone? | 07:13 |
hyunsikyang | kk | 07:13 |
tojuvone | Hi, yes | 07:29 |
hyunsikyang | hi | 07:38 |
hyunsikyang | I have a question for fenix integration.. | 07:38 |
tojuvone | yes | 07:39 |
hyunsikyang | In my understanding, Fenix knows all of the VNf which is deplyed now... and all of the procedure is lead by fenix. | 07:40 |
tojuvone | yes, all the projects in nova space currently known | 07:40 |
tojuvone | and all VNFs that have subscribed to AODH | 07:41 |
hyunsikyang | it means that all of the VNf should be registered to AODH. | 07:41 |
tojuvone | If they want to support interaction | 07:41 |
hyunsikyang | yes | 07:42 |
hyunsikyang | Of course. | 07:42 |
tojuvone | otherwise FEnix should have some default behavior | 07:42 |
hyunsikyang | now I am considering all of VNF which is made by tacker register maintanance or only maintanance option have. | 07:43 |
tojuvone | or the workflow used should have | 07:43 |
hyunsikyang | yes. So I will keep current spec for this first integration. | 07:45 |
hyunsikyang | And second one is AODH. | 07:45 |
hyunsikyang | In the tacker, | 07:45 |
tojuvone | I think it should be VNF specific if there can be VNF specific behavior in Tacker side | 07:46 |
tojuvone | otherwise for all the VNFs | 07:47 |
hyunsikyang | When we defined AODH alarm and Policy in the VNFD, these thing managed by tacker. | 07:47 |
hyunsikyang | When we defined AODH alarm and Policy in the VNFD, these thing managed by Heat* | 07:47 |
hyunsikyang | not tacker. | 07:47 |
hyunsikyang | So 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.py | 07:48 |
hyunsikyang | But in the fenix case, all of the action is managed by fenix. | 07:48 |
hyunsikyang | So I think we don't have any policy for Fenix in this time. | 07:49 |
hyunsikyang | What do you think?:) | 07:50 |
tojuvone | Fenix have admin rights always to perform migrations if VNF so chooses to do | 07:50 |
tojuvone | otherwise VNF always have right do re-instantiate | 07:50 |
tojuvone | so the policy is already in Fenix | 07:50 |
hyunsikyang | I think so.. | 07:51 |
tojuvone | If one have agreed that Fenix can be used, one have also agreed that it may make migration in interaction with VNF | 07:52 |
tojuvone | that is normally not granted fro VNF | 07:52 |
tojuvone | but now granted in maintenance then | 07:52 |
hyunsikyang | So now I am thinking of interaction between Fenix and tacker... | 07:54 |
hyunsikyang | My 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 |
tojuvone | So having the maintenance interaction enabled in tacker, will have the policy granted for all VNFs to migrate during maintenance | 07:58 |
tojuvone | yes | 07:59 |
tojuvone | separate message for each | 07:59 |
tojuvone | each of those is different project in Nova sapce | 08:00 |
tojuvone | and has it own control | 08:00 |
tojuvone | own VNF specific API endpoint in both ends for the interaction | 08:00 |
hyunsikyang | bt, can fenix have any option for grouping of VNF? | 08:01 |
tojuvone | currently no | 08:01 |
tojuvone | and it doesn't make sense | 08:01 |
hyunsikyang | In my thinking , when Host 1 needs upgrade, admin should send maintenance message to all vnf which are located at HOST1. | 08:02 |
hyunsikyang | so I am thinking about grouping. | 08:03 |
tojuvone | API to subscribe is VNF specific, so no groupping makes sense | 08:03 |
tojuvone | they can be under different VNFM | 08:04 |
hyunsikyang | Ah got it. | 08:04 |
tojuvone | And at the end its their EM making decisions | 08:04 |
hyunsikyang | About spac, we agreed that we use maintenance option optionally in the last tacker meeting. So we keep the maintanance option . | 08:07 |
tojuvone | ok | 08:09 |
*** openstack has joined #openstack-fenix | 12:30 | |
*** ChanServ sets mode: +o openstack | 12:30 | |
*** openstackstatus has joined #openstack-fenix | 14:30 | |
*** ChanServ sets mode: +v openstackstatus | 14: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.html | 14: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 IRC | 19:01 | |
*** tojuvone has quit IRC | 23:22 | |
*** tojuvone has joined #openstack-fenix | 23:22 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!