| *** hyunsikyang__ has quit IRC | 01:46 | |
| *** hyunsikyang has joined #openstack-fenix | 01:46 | |
| hyunsikyang | Hi all | 06:24 |
|---|---|---|
| hyunsikyang | anyone is here? | 06:24 |
| hyunsikyang | I have a question:) | 06:26 |
| *** tojuvone has quit IRC | 06:41 | |
| *** tojuvone has joined #openstack-fenix | 06:41 | |
| hyunsikyang | Hi tojuvone | 06:46 |
| tojuvone | hi hyunsikyang | 07:27 |
| hyunsikyang | Hi I have a question:) | 07:27 |
| hyunsikyang | Are you busy? | 07:27 |
| tojuvone | Not really, just trying demo and retry, retry.... | 07:28 |
| hyunsikyang | Ah.. | 07:29 |
| hyunsikyang | Cheer up...\0/ BTW, I am thinking about event type.. | 07:30 |
| hyunsikyang | I read this. | 07:31 |
| hyunsikyang | https://fenix.readthedocs.io/en/latest/user/baseworkflow.html# | 07:31 |
| tojuvone | yes | 07:31 |
| hyunsikyang | And here all of message use a 'maintenance.planned' for AODH. | 07:32 |
| tojuvone | yes and thus need single subscription | 07:32 |
| hyunsikyang | How AODH distingush the message? | 07:32 |
| hyunsikyang | I mean that MAINTENANCE also use maintenance.planned | 07:33 |
| tojuvone | in aodh you subscribe to event type 'maintenance.planned' with your project id | 07:33 |
| hyunsikyang | and PLANNED_MAINTENANCE also use 'maintenance.planned' | 07:33 |
| tojuvone | frmo here you can see notif structure: https://fenix.readthedocs.io/en/latest/notification/notifications.html#project | 07:33 |
| tojuvone | so the 'state' is the one telling what notif is about, is it: MAINTENANCE, SCALE_IN, PREPARE_MAINTENANCE,... | 07:34 |
| hyunsikyang | ah right:) | 07:34 |
| tojuvone | the idea of single event type is to only need single subscription | 07:35 |
| tojuvone | and you could then come up different states to handle | 07:35 |
| tojuvone | so the event payload differs according to state | 07:36 |
| hyunsikyang | Great:) and can we make a two workflow? | 07:37 |
| tojuvone | we shouldn't make too many to maintain, but yes | 07:38 |
| tojuvone | and perhaps when really building up testing | 07:38 |
| tojuvone | some test directory might have a workflow or action plugins suitable for that case | 07:39 |
| hyunsikyang | First case is only for VNF. When VNf need a maintenance procedure, I think all of the procedure is not necessary. So, in this case, we just delivery simple acito such as stop the VNF or change the path. | 07:39 |
| tojuvone | currently for OpenStack I do not see a need for different workflow | 07:40 |
| hyunsikyang | But, If VNFM should work with fenix due to host maintenance, | 07:40 |
| tojuvone | some changes to existing and using different action plugins to do different mainteannce/upgrade action | 07:40 |
| hyunsikyang | It should follow default procedure. | 07:40 |
| hyunsikyang | So, IMO, we don't need all of the procedure for VNF maintenance itself. What do you think? | 07:41 |
| tojuvone | Well, when ETSI definitions comes to Fenix... | 07:41 |
| tojuvone | there should be a standard way to subscribe with details of VNF specific hhandling | 07:42 |
| tojuvone | yes, you are right. there can be different use cases how to handle VNF side and infra | 07:43 |
| tojuvone | you can add capacity to infra or not | 07:43 |
| tojuvone | If we look to skip handling of SCALE_IN and PREPARE_MAINTENANCE | 07:44 |
| hyunsikyang | yes | 07:44 |
| tojuvone | we just need to add empty compute to system and those steps are skipped | 07:44 |
| hyunsikyang | after ack-maintenance, we just go to maintenance planned | 07:45 |
| tojuvone | yes | 07:45 |
| tojuvone | and that should wok as I said if there is no bug in the default workflow | 07:45 |
| tojuvone | both of those steps are run only because default workflow tries to have at least one empty compute | 07:47 |
| hyunsikyang | You mean that we just exchange the message without any real action? | 07:48 |
| tojuvone | SCALE_IN and PREPARE_MAINTENANCE are only send to VNFM if needed | 07:48 |
| tojuvone | as of any other 'state' | 07:49 |
| tojuvone | if one has empty compute in system under test, these will never occur | 07:49 |
| tojuvone | current test system have just always been so that all compute capacity have been in use | 07:50 |
| tojuvone | so VNFs first have to SCALE_IN | 07:50 |
| tojuvone | and as VMs are then removed from "random" compute nodes | 07:50 |
| tojuvone | there will still not be any empty compute (unless get lucky) | 07:51 |
| tojuvone | and still have to call PREPARE_MAINTENANCE to arrange one | 07:51 |
| tojuvone | So if so wanted when testing with Tacker, we could always have the empty compute in system, so SCALE_IN and PREPARE_MAINTENANCE are not needed | 07:52 |
| hyunsikyang | Yes, if we need to move the VNF, it should check the host too. but, now tacker doesn't know about VNF which made by NOVA without tacker/ | 07:52 |
| tojuvone | yes | 07:53 |
| tojuvone | and it shouldn't | 07:53 |
| tojuvone | tacker should only subscribe to things under its own control | 07:53 |
| hyunsikyang | If the maintenance action is simple like VNF stop, we can skip the PREPARE_MAINTENANCE... scale . things. | 07:54 |
| hyunsikyang | but, like I said , if we need to move the VNF, these things is needed | 07:54 |
| tojuvone | it is Fenix problem to find any VNFM responsible for other VNFs are have some own dfault way of handling VMs not controlled by any VNFM | 07:54 |
| hyunsikyang | I just recheck it. Anyway, I will think about the procedure which can cover the all of case. | 07:56 |
| tojuvone | We do not currently implement implement moving a VNF or stop? VNF (does that mean removing a VNF) | 07:56 |
| hyunsikyang | What you mean? | 07:57 |
| tojuvone | That is what I am asking you. What is "VNF stop" or "move VNF" | 07:58 |
| tojuvone | We are currently only implementing rolling maintenance/upgrade | 07:58 |
| hyunsikyang | ah | 07:59 |
| tojuvone | and more use cases would be later | 07:59 |
| hyunsikyang | Yes. that is the just example of action for maintenace. | 07:59 |
| tojuvone | and like I said, once get the ETSI specifications finalized, can have real VNFM subscirption with all contraints it needs | 07:59 |
| tojuvone | and implement different scenarios | 08:00 |
| tojuvone | I would expect more people in project later and more capacity to work on full blown implementation and scenarios | 08:01 |
| hyunsikyang | I mean that when we think about the case of VNF maintenance or upgrade, VNFM should stop the VNF first and upgrade it. So i just mention VNF stop as a action like blueprint. | 08:01 |
| hyunsikyang | yes:) I agree with you. | 08:02 |
| tojuvone | I wouldn't see stopping a whole VNF as a very Telco thing to do to keep zero downtime for the service over VNF upgrade | 08:03 |
| tojuvone | but surely simple way to upgrade VNF if allowed by operator | 08:04 |
| hyunsikyang | yes. you are right. even the case is for VNF maintenance, stopping the VNF is not good way. | 08:04 |
| hyunsikyang | switching the pass from act to stb is more suitable. | 08:05 |
| hyunsikyang | path* | 08:05 |
| hyunsikyang | sorry..kk | 08:05 |
| tojuvone | yes | 08:05 |
| tojuvone | and you do online upgrades... | 08:06 |
| tojuvone | or re-instantiate some instances and so | 08:06 |
| tojuvone | surely also overkill of duplicating the VNF (old and new version) and switch over | 08:07 |
| hyunsikyang | OK in the case of VNF maintenance (not by the host), we can mention the other action, not VNF stop. | 08:07 |
| hyunsikyang | and we can skip the some procedure which is related to HOST maintenance. | 08:08 |
| tojuvone | or can mention what is supported now and other scenarios can come later | 08:09 |
| hyunsikyang | Ok:) Thanks for your advice. | 08:14 |
| hyunsikyang | I will modify the blueprint and announce it soon. | 08:15 |
| tojuvone | hyunsikyang, great :) | 08:15 |
| tojuvone | wow, almost had demo working with neutron part, but one compute just happened to fail upgrade (quite a devstack thing to do) | 09:23 |
| *** tojuvone has quit IRC | 09:46 | |
| *** tojuvone has joined #openstack-fenix | 09:47 | |
| *** tojuvone has quit IRC | 11:25 | |
| *** tojuvone has joined #openstack-fenix | 11:25 | |
| *** tojuvone has quit IRC | 12:39 | |
| *** tojuvone has joined #openstack-fenix | 12:40 | |
| *** tojuvone has quit IRC | 13:37 | |
| *** tojuvone has joined #openstack-fenix | 13:37 | |
| *** tojuvone has quit IRC | 16:46 | |
| *** tojuvone has joined #openstack-fenix | 16:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!