| *** JangwonLee__ has joined #openstack-fenix | 06:30 | |
| *** JangwonLee_ has quit IRC | 06:34 | |
| hyunsikyang | Hi tojuvon, | 08:51 |
|---|---|---|
| hyunsikyang | I have a question for tacker integration. | 08:51 |
| hyunsikyang | In the spec of tacker-fenix, we created url for each vnf. so, we can do procedure of maintenance for specific VNF. But, in the case of Host Maintenance, does fenix send request with each url for each VNF? | 08:58 |
| tojuvone | Yes, URL is VNF (OpenStack terms project/tenant ID) specific | 09:53 |
| tojuvone | Well in VNFM one could surely have one end point only. But in Fenix side there is this VNF specific endpoint according to project/tenant ID | 09:54 |
| tojuvone | So VNF needs project/tenant specific subscription to AODH, but basically that subscription could always have the same endpoint in VNFM. Then handling events coming to that endpoint just needs to look which "project" is mentioned in event and can map it to right VNF. | 09:56 |
| *** JangwonLee_ has joined #openstack-fenix | 10:20 | |
| *** JangwonLee__ has quit IRC | 10:23 | |
| hyunsikyang | is it kinds of group URL? | 11:09 |
| hyunsikyang | Then handling events coming to that endpoint just needs to look which "project" is mentioned in event and can map it to right VNF. --> Does VNFM handle it? | 11:09 |
| hyunsikyang | the reason why we think like that is when we want to move several vnf which deployed at server1, we thought that we should send request URL to each VNF. And we think that it is not appropriate. | 11:13 |
| tojuvone | In real NFV use case the VNF itself should play a role. Only VNF own "manager" could know how ETSI FEAT03 constraints at the moment of request (what is the VNF load). VNF could have part of the constraints defined statically, like in VNFD, but optimally the values are dynamic. In case of some static definitions, VNFM could be made to handle VNF specific requests, but in more sophisticated case and if without some hard coded "lead_time" and | 11:30 |
| tojuvone | similar, it should be the VNFs own manager telling when it is ready for "VM to be moved" and how many similar type of VMs (groupped VMs ) can be affected at this moment... Only this is the way to optimize and really take the advantage of Fenix interaction. | 11:30 |
| hyunsikyang | ok thanks:) | 12:13 |
| *** hyunsikyang__ has joined #openstack-fenix | 12:44 | |
| *** hyunsikyang has quit IRC | 12:47 | |
| *** hyunsikyang has joined #openstack-fenix | 12:53 | |
| *** hyunsikyang__ has quit IRC | 12:56 | |
| *** hyunsikyang__ has joined #openstack-fenix | 12:57 | |
| *** hyunsikyang has quit IRC | 12:58 | |
| *** JangwonLee_ has quit IRC | 19:24 | |
| *** JangwonLee_ has joined #openstack-fenix | 19:24 | |
| -openstackstatus- NOTICE: The Zuul project gating service is reporting new patches in merge conflict erroneously due to a configuration error, fix in progress | 20:20 | |
| -openstackstatus- NOTICE: the This Zuul outage was taken as an opportunity to perform an impromptu maintenance for changing our service deployment model; any merge failures received from Zuul between 19:40 and 20:20 UTC were likely in error and those changes should be rechecked; any patches uploaded between 20:55 and 22:45 UTC were missed entirely by Zuul and should also be rechecked to get fresh test results | 22:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!