08:01:43 <yasufum> #startmeeting tacker
08:01:44 <opendevmeet> Meeting started Tue Jun  8 08:01:43 2021 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:45 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:47 <opendevmeet> The meeting name has been set to 'tacker'
08:02:17 <tsukasasa_> hi
08:03:04 <yasufum> ueha: thx for your fix for zuul tests
08:03:27 <yasufum> it works fine now :)
08:03:35 <ueha> You're welcome!
08:04:31 <yasufum> Another fix for using OVN also looks good
08:05:03 <yasufum> Do you have any update discussing here today?
08:06:04 <ueha> No, nothing in particular. If I had to say, this is the third point I wrote on etherpad.
08:07:17 <ueha> I have been looking at kuryr-Kubernetes and it seems that there is no patch development for formal fix yet.
08:08:10 <yasufum> yes
08:08:19 <ueha> I will continue to watch and try it if there is any update. thanks.
08:11:07 <ueha> That's all from my side today.
08:11:23 <yasufum> I think we don’t need to hurry up to merge your patch soon actually, but don’t wait for the fix kuryr-kubernetes.
08:13:57 <ueha> Sorry, what does "don’t wait for the fix kuryr-kubernetes." mean?
08:14:21 <yasufum> If no update from kuryr-kubernetes, go forward to your patch also it includes some dependency on old-kuryr.
08:15:34 <ueha> I see. thanks.
08:17:14 <yasufum> yes, I think it’s good to us if we discard the old dependency before merging the patch.
08:17:34 <yasufum> thanks
08:18:49 <yasufum> I have also updated my patch for local.conf to enable to setup tacker with ovn
08:18:55 <yasufum> #link https://review.opendev.org/c/openstack/tacker/+/794014
08:19:45 <yasufum> I’d appreciate if you test it on your server to confirm it works.
08:20:47 <yasufum> I’m not sure it works on redhat distros actually
08:21:16 <yasufum> only tested on ubuntu 20.04 currently.
08:22:41 <ueha> I'm testing it now on ubuntu20 using local.conf.kubernetes.
08:22:58 <yasufum> thanks
08:23:09 <manpreetk> i have tested in 20.04 it worked
08:23:17 <manpreetk> *ubuntu
08:23:23 <yasufum> ok, great
08:24:24 <ueha> I see the following error, but I wonder if my environment is not good.
08:24:39 <ueha> ++ /opt/stack/kuryr-kubernetes/devstack/lib/kubernetes:kubeadm_init:119 :   sudo kubeadm init --config /opt/stack/data/kuryr-kubernetes/kubeadm-init.yaml --skip-phases=addon/kube-proxy --ignore-preflight-errors Swap --skip-phases=addon/coredns
08:24:46 <ueha> unable to select an IP from lo network interface
08:26:02 <ueha> You didn't get the above error, did you?
08:26:50 <yasufum> Umm… I don’t see such a situation in my log.
08:28:09 <ueha> Is it because it is a VM environment via nat..?
08:28:48 <yasufum> I’m not sure, but possibly
08:30:34 <ueha> Changing the parameters for HOST_IP and PUBLIC_NETWORK_GATEWAY or either seems to work well. I will try!
08:30:59 <yasufum> Anyway, I’d like to check the code around kubeadm_init
08:31:58 <ueha> Thanks, I will also check!
08:32:11 <yasufum> OK
08:32:25 <yasufum> Is there any comment, or other topics?
08:32:50 <manpreetk> Just a humble request to review XS patches,
08:32:51 <manpreetk> https://review.opendev.org/q/owner:kaurmanpreet2620%2540gmail.com+status:open+projects:openstack/tacker+size:%253C10+
08:32:51 <manpreetk> https://review.opendev.org/c/openstack/python-tackerclient/+/790584
08:32:51 <manpreetk> Most of the patches are been reviewed by Yasufumi Ogawa san.
08:32:51 <manpreetk> Thanks in advance. That's all from my side.
08:34:56 <yasufum> For patches for tacker-horizon, it already got two +2 and ready to be merged.
08:35:24 <yasufum> I will proceed to it. Thanks
08:35:36 <manpreetk> Thanks :)
08:39:29 <yasufum> Any other asking to be reviewed?
08:39:34 <yasufum> in hurry
08:41:16 <yasufum> seems nothing
08:41:47 <ueha> Sorry, could you review the patch? https://review.opendev.org/c/openstack/tacker/+/795016
08:42:17 <ueha> He want you to review it as soon as possible. thanks.
08:42:31 <yasufum> sure!
08:43:20 <ueha> Thank you! I will review it too.
08:44:49 <yasufum> I’d like to close this meeting if you have no more topics today.
08:45:14 <tsukasasa_> I want to make sure my proposals are OK, about fixing a bug. https://etherpad.opendev.org/p/tacker-meeting L.73
08:46:00 <tsukasasa_> This is a bug that the state of vnf_lcm_op_occs does not change from PROCESSING due to an unexpected stop of the process.
08:46:13 <tsukasasa_> takahashi-tsc spoke at PTG.
08:46:36 <tsukasasa_> My proposals are:
08:46:58 <tsukasasa_> Create an API that changes the state to FAILED_TEMP from PROCESSING. API is  /vnflcm/v1/vnf_lcm_op_oocs/{id}/force_fail. the API is not included in SOL003. Tacker server receives the request via the API. Tacker server changes the record and returns the changed record as a result.
08:48:07 <tsukasasa_> My point is
08:48:49 <tsukasasa_> Can I add new API.
08:53:07 <tsukasasa_> I don't care about adding new API.
08:53:44 <tsukasasa_> easy to implement.
08:56:06 <ueha> Could you tell me one thing. What is the difference from "Cancel operation" as defined in SOL 003?
08:57:14 <ueha> I see "Figure 5.6.2.1-1: States of a VNF lifecycle management operation occurrence", and the transition from PROCESSING to FAILED_TEMP appears to use cancel.
08:59:03 <tsukasasa_> there is no big difference.
08:59:08 <tsukasasa_> But
09:01:16 <tsukasasa_> I want to fix the bug immediately, Implementation according to SOL003 is difficult.
09:06:28 <tsukasasa_> Complete cancel API is difficult. So I want to add a different API name, We might misunderstand that the same API name is SOL compliant.
09:08:59 <ueha> I see.. I can't judge, but the ideal is to have a SOL003 compliant interface. Is it possible to implement it step by step?
09:10:52 <ueha> yasufum and tsc-takahashi: What do you think?
09:11:44 <yasufum> I don’t agree to add such a API basically.
09:12:51 <takahashi-tsc> Does it mean adding API is not good? Adding new option of existing API or make tools is better?
09:15:51 <yasufum> I think it’s better to provide such a feature for changing status forcibly other than API.
09:16:46 <tsukasasa_> I consider providing a tool to change the DB without via API.
09:17:05 <yasufum> although I don’t understand how it difficult without using API
09:18:05 <tsukasasa_> Probably not difficult.
09:19:07 <tsukasasa_> Conclusion: provide tool without using API.
09:19:45 <tsukasasa_> Thank you.
09:20:56 <yasufum> ueha: what do you think?
09:22:36 <ueha> If the tool is available and implement is not difficult, I think that's more fine than adding non-compliant API.
09:22:46 <takahashi-tsc> In my understanding, the disussion point is just about how to expose. And adding API is just current implementation. So we just choose a better way.
09:24:44 <yasufum> Yes.
09:24:59 <takahashi-tsc> Tacker dicision seems not adding new non-compliant API, so tsukasasa should proceed with consideration of such implementtion. @tsukasasa Is it OK for you?
09:25:39 <tsukasasa_> OK.
09:26:03 <yasufum> My opinion is it’s a normal operation and required to do that only when an unexpected error is happen, right?
09:26:49 <yasufum> so, it is not so good way to provide the feature as other features of APIs.
09:28:23 <takahashi-tsc> I see... yes, your understanding seems correct.
09:30:29 <yasufum> Anyway, thank you for tha proposal for fixing the critical issue.
09:31:05 <tsukasasa_> Thanks.
09:33:15 <yasufum> I’d appreciate if you write down our conclusion and some information how to implement on etherpad simply.
09:34:59 <yasufum> sorry everyone for taking for a long time. I’d like to close the meeting if you OK.
09:35:11 <takahashi-tsc> OK
09:35:23 <ueha> Okay, thank you!
09:35:38 <takahashi-tsc> thanks!
09:35:46 <yasufum> thnak, bye
09:35:53 <tsukasasa_> thanks.
09:36:00 <yasufum> #endmeeting