| *** dangtrinhnt has quit IRC | 01:45 | |
| *** dangtrinhnt has joined #openstack-fenix | 01:49 | |
| *** tojuvone has quit IRC | 02:28 | |
| *** tojuvone has joined #openstack-fenix | 02:28 | |
| hyunsikyang | Hello tojuvone and dangtrinnhnt, | 04:02 |
|---|---|---|
| hyunsikyang | I have some question. | 04:02 |
| tojuvone | hi hyunsikyang, yes? | 04:05 |
| hyunsikyang | Hi | 04:05 |
| hyunsikyang | I see your comment. Thanks:) | 04:06 |
| tojuvone | np :) | 04:07 |
| hyunsikyang | BTW, you mean that we don't need to separate the case? I just want to emphasize the what is the trigger point.( Host or VNF it self.) | 04:09 |
| tojuvone | Infra admin calls maintenance on infrastructure. There is interaction with VNF(M) becasue it needs to minimize downtime | 04:11 |
| tojuvone | It just happens to be that with this capability, VNF could make its own upgrade at the same | 04:11 |
| tojuvone | as VMs are to be "moved" anyhow and Fenix can tell about new infra capabilites like new HW or SW in infra, that VNF can take into use | 04:12 |
| tojuvone | So the idea is to make infra maintenance/upgrade | 04:13 |
| tojuvone | but if it happens to be so, it is affecting to all VMs in VNF, why not make the VNF upgrade at the same | 04:13 |
| tojuvone | its a win win situation in VNF point of view | 04:15 |
| tojuvone | so the difference between cases is just if you have / add empty capacity as compute nodes | 04:17 |
| tojuvone | or you need to scale down VNF | 04:17 |
| tojuvone | Thoughts? | 04:19 |
| hyunsikyang | I aggree. | 04:20 |
| hyunsikyang | But, when only VNF want to upgrade itself, we don't need scale out or moving VNF. right? | 04:21 |
| hyunsikyang | ah It needs. When resource is not enough or VNf provide sverice constantly. | 04:22 |
| hyunsikyang | Right. coud you explane about it more? 'but if it happens to be so, it is affecting to all VMs in VNF, why not make the VNF upgrade at the same' | 04:23 |
| tojuvone | ok, explaining... | 04:24 |
| hyunsikyang | You mean that one VNF consists of several VM and one of the VM needs upgrade? | 04:24 |
| tojuvone | If you would plan to upgrade VNF while it keeps on running... | 04:25 |
| tojuvone | you would do that VM by VM (VNF consist of several VMs) | 04:25 |
| tojuvone | now, if you have rolling infrastructure maintenance/upgrade, it is going compute by compute... | 04:26 |
| tojuvone | meaning in VNF point of view "VM by VM" | 04:26 |
| tojuvone | so upgrading same time as infra would make it so that you do not go through same operation "twice" in VNF side | 04:28 |
| tojuvone | "twice", would be that you would upgrade VNF later | 04:29 |
| tojuvone | not the same time the infra is upgraded | 04:29 |
| tojuvone | surely that if far more safe thing to do | 04:29 |
| tojuvone | in case infra upgrade would fail | 04:29 |
| tojuvone | Anyway... | 04:31 |
| hyunsikyang | give me a sec. | 04:31 |
| tojuvone | if infra upgrade should fail, it should be known before any compute node is upgraded | 04:31 |
| tojuvone | first one upgrades controllers and then one compute. It is anyhow tested before given back to VNF use | 04:32 |
| tojuvone | if this will fail, infra can be rolled back before it affects to VNF | 04:32 |
| tojuvone | upgrading computes should already be much safer thing to do and for crucial things there should be pre upgrade checks in place in OpenStack services | 04:33 |
| tojuvone | ok | 04:33 |
| hyunsikyang | I see. In the blue print, I wanted to emphasize that procedure will be different since who trigger Maintenance. | 04:45 |
| hyunsikyang | but you also want to say that VNF upgrade also possible at the same time. | 04:45 |
| hyunsikyang | In the blueprint, upgrading in the second case is just one of the example when VNF maintenance is needed without starting from Host. | 04:46 |
| hyunsikyang | Ok I will change it according to your comment. | 04:48 |
| tojuvone | Yes. It is another approach if VNF would just like to upgrade itself without infra being upgraded | 04:56 |
| hyunsikyang | And Do we need to write a blueprint for adding planned.maintenance type at aodh? or just commit? | 05:01 |
| tojuvone | For aodh, I think it is just about how it is configured / deployed | 05:02 |
| tojuvone | Fenix installation guide shoudl say, one need to confiugure aodh to be able to have event alarm from planned.maintenance | 05:03 |
| tojuvone | to me, it doesn't change aodh by any means otherwise | 05:03 |
| hyunsikyang | So we just mention it in the doc.. | 05:06 |
| tojuvone | yes, I think so | 05:07 |
| hyunsikyang | I thought we need to commit the code to AODH. | 05:07 |
| tojuvone | AODH is generic code to have event alarm from notifications | 05:08 |
| tojuvone | so it just needs configuration of which notifications | 05:08 |
| *** tojuvone has quit IRC | 05:13 | |
| *** tojuvone has joined #openstack-fenix | 05:14 | |
| hyunsikyang | got it :) Thanks | 05:15 |
| *** tojuvone has quit IRC | 05:24 | |
| *** tojuvone has joined #openstack-fenix | 05:31 | |
| *** tojuvone has quit IRC | 05:42 | |
| *** tojuvone has joined #openstack-fenix | 05:42 | |
| *** tojuvone has quit IRC | 06:54 | |
| *** tojuvone has joined #openstack-fenix | 06:54 | |
| *** tojuvone has quit IRC | 07:58 | |
| *** tojuvone has joined #openstack-fenix | 07:58 | |
| *** tojuvone has quit IRC | 08:11 | |
| *** tojuvone has joined #openstack-fenix | 08:11 | |
| *** tojuvone has quit IRC | 08:15 | |
| *** tojuvone has joined #openstack-fenix | 08:16 | |
| *** tojuvone has quit IRC | 08:23 | |
| *** tojuvone has joined #openstack-fenix | 08:24 | |
| *** tojuvone has quit IRC | 08:47 | |
| *** tojuvone has joined #openstack-fenix | 08:47 | |
| *** tojuvone has quit IRC | 08:56 | |
| *** tojuvone has joined #openstack-fenix | 08:56 | |
| *** tojuvone has quit IRC | 09:02 | |
| *** tojuvone has joined #openstack-fenix | 09:02 | |
| *** tojuvone has quit IRC | 09:04 | |
| *** tojuvone has joined #openstack-fenix | 09:05 | |
| *** tojuvone has quit IRC | 09:13 | |
| *** tojuvone has joined #openstack-fenix | 09:13 | |
| tojuvone | Trying to describe how to model ETSI FEAT03 requirements | 09:23 |
| tojuvone | Have to have some idea before PTG | 09:23 |
| *** tojuvone has quit IRC | 09:49 | |
| *** tojuvone has joined #openstack-fenix | 09:50 | |
| *** tojuvone has quit IRC | 09:52 | |
| *** tojuvone has joined #openstack-fenix | 09:52 | |
| *** tojuvone has quit IRC | 10:11 | |
| *** tojuvone has joined #openstack-fenix | 10:11 | |
| *** tojuvone has quit IRC | 10:13 | |
| *** tojuvone has joined #openstack-fenix | 10:13 | |
| *** tojuvone has quit IRC | 11:57 | |
| *** tojuvone has joined #openstack-fenix | 11:58 | |
| *** tojuvone has quit IRC | 11:58 | |
| *** tojuvone has joined #openstack-fenix | 11:59 | |
| *** tojuvone has quit IRC | 12:10 | |
| *** tojuvone has joined #openstack-fenix | 12:10 | |
| *** tojuvone has quit IRC | 13:09 | |
| *** tojuvone has joined #openstack-fenix | 13:10 | |
| *** tojuvone has quit IRC | 16:18 | |
| *** tojuvone has joined #openstack-fenix | 16:18 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!