08:02:08 <yasufum> #startmeeting tacker
08:02:09 <openstack> Meeting started Tue May 18 08:02:08 2021 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:12 <openstack> The meeting name has been set to 'tacker'
08:03:19 <yasufum> We have one topic suggested by ueha today.
08:03:25 <yasufum> link: https://etherpad.opendev.org/p/tacker-meeting
08:03:48 <yasufum> ueha: can you share the topic?
08:04:02 <ueha> Sure, I wrote to etherpad
08:04:25 <ueha> just information sharing and question.
08:04:42 <ueha> devstack will change default network backend driver from ML2/OVS to ML2/OVN.
08:04:58 <ueha> Once the patch [1] was merged, and that seemed to cause the Zuul FT error during May 13-14.
08:05:04 <ueha> [1] "Change Neutron's default ML2 driver to OVN": https://review.opendev.org/c/openstack/devstack/+/735097
08:05:32 <ueha> But the patch was reverted at May 14 PM, so the Zuul FT error is not occurring now.
08:06:19 <ueha> However, the similar patch [3] is posted to devstack.
08:06:27 <ueha> [3] "Change default network backend driver to ML2/OVN": https://review.opendev.org/c/openstack/devstack/+/791436
08:06:46 <ueha> If the patch is merged, I think same Zuul FT error will occur.
08:07:51 <ueha> That's information sharing. Do you have any comments so far?
08:11:00 <yasufum> I’m not sure the detail of the discussion and temporary(?) errors in zuul, but the change is going to be merged?
08:12:28 <ueha> Probably I think patch [3] will be merged.
08:14:11 <yasufum> I am also not sure [3] causes similar error on our zuul test, and your DNM patch is for fixing it?
08:15:08 <ueha> Yes, I posted patch for tying to fix it.
08:18:12 <yasufum> thanks
08:18:19 <ueha> I have confirmed that there is no problem that the controller or compute is not built, but some FT function is failed..
08:18:50 <ueha> So, after patch [3] is merged, I need to check a little more.
08:20:35 <ueha> (If there is a problem after merging...)
08:21:07 <yasufum> btw, your fix is just for zuul. Is there any problem happened other than zuul test, I mean using tacker by your self or so?
08:21:36 <yasufum> Do we need to change the config in devstack possibly?
08:22:17 <ueha> Yes,, I think change or add some parameter in local.conf.
08:23:19 <yasufum> I would like to confirm just a bit more about your change.
08:23:44 <yasufum> Your change is just move back to use ovs instead of ovn, right?
08:24:05 <ueha> yes, just move back to ovs.
08:25:15 <yasufum> If so, I think we should catch up to move to use ovn later maybe.
08:25:44 <ueha> Yes, I think so.
08:25:57 <yasufum> because shift to ovn itself is a huge advance for users and openstack itself.
08:26:14 <yasufum> OK
08:26:17 <ueha> That is my question point wrote to etherpad.
08:26:23 <takahashi-tsc> +1, using ovn is better.
08:26:27 <ueha> Is there any probrems if Tacker change network backend driver to ML2/OVN?
08:27:04 <ueha> I find the following comment on configure of neutron service in ".zuul.yaml"
08:27:14 <ueha> # We need to keep using the neutron-legacy based services for now until all issues with the new lib/neutron code are solved
08:27:21 <ueha> https://opendev.org/openstack/tacker/src/branch/master/.zuul.yaml#L154-L156
08:27:41 <ueha> According to the above comment, Tacker can't change to ML2/OVN?
08:27:43 <yasufum> For now, we have to keep zuul test run well first. So, patch from ueha is very welcom for us. Thanks.
08:28:09 <takahashi-tsc> Thanks!
08:29:35 <ueha> sure!
08:30:07 <ueha> Does anyone know about neutron service's comment?
08:31:14 <takahashi-tsc> No... I don't know about it.
08:31:54 <ueha> Okay.. If no one knows, I will try to change network backend driver to ML2/OVN first after the devstack patch [3] is merged.
08:32:53 <yasufum> thanks
08:33:23 <takahashi-tsc> thanks!
08:33:31 <ueha> If there is no other comment, that's it from me. Thanks!
08:34:28 <yasufum> Another topic is added on etherpad
08:34:38 <yasufum> Can we go to the next topic?
08:35:17 <yasufum> masaki-ueno: can you start it?
08:36:08 <masaki-ueno> I'm ready, may I share the next topic?
08:36:25 <yasufum> sure, pls go ahead.
08:36:58 <masaki-ueno> OK, I wrote the topic on the etherpad.
08:37:52 <masaki-ueno> This topic is related on the Xena spec "Support Helm chart for Kubernetes VIM" [1].
08:38:02 <masaki-ueno> [1] https://review.opendev.org/c/openstack/tacker-specs/+/786581
08:38:41 <masaki-ueno> In this spec, we show the procedure of CNF instantiation with Helm chart.
08:39:38 <masaki-ueno> In the procedure, mgmtdriver executes `helm repo index` and `helm repo add` commands to register helm packages to master nodes.
08:40:11 <masaki-ueno> `helm repo index` -> https://review.opendev.org/c/openstack/tacker-specs/+/786581/1/specs/xena/helmchart-k8s-vim.rst#566
08:40:27 <masaki-ueno> `helm repo add` -> https://review.opendev.org/c/openstack/tacker-specs/+/786581/1/specs/xena/helmchart-k8s-vim.rst#579
08:41:42 <masaki-ueno> However, those commands are generally required when operators expose helm packages to public helm repositories, or pull helm packages from certain Helm repositories.
08:42:19 <masaki-ueno> So those commands may be redundant in CNF instantiation with locally managed helm charts.
08:43:41 <masaki-ueno> Helm charts are .yaml files, so `scp` (or other similar transmission command) satisfies the requirement in the procedure.
08:44:01 <masaki-ueno> So, I'd like to discuss use cases, which requires registration of helm packages in CNF instantiation procedure.
08:44:54 <masaki-ueno> Is there any situation such as `scp` is not applicable in certain environments? I have no idea....
08:46:41 <masaki-ueno> Opps, Kubernetes InfraDriver executes helm commands, not mgmtdriver. Sorry for my mistake.
08:47:02 <yasufum> OK, but I am not sure at the moment actually.
08:47:53 <yasufum> Basically, it seems you are right and agree with your suggestion.
08:48:13 <yasufum> What do you think?
08:49:48 <yasufum> “agree with your suggestion” <- agree to omit, correctly
08:50:15 <masaki-ueno> Thanks. I think those steps are redundant, so we should omit those steps for now.
08:51:43 <masaki-ueno> Is there any questions or comments?
08:52:29 <yasufum> seems nothing
08:52:33 <yasufum> OK. Please give a comment on gerrit if you have later, everyone.
08:53:05 <yasufum> masaki-ueno: thanks for sharing.
08:53:07 <masaki-ueno> Thank you. That's all from my side.
08:54:06 <yasufum> thanks
08:54:08 <takahashi-tsc> Thanks, need some consideration... Anyway, if I have comment, I'll write it in erhetpad
08:54:51 <yasufum> Is there any other topics?
08:55:55 <yasufum> good
08:56:22 <yasufum> I would like to close this meeting, thank you for joining.
08:56:24 <yasufum> bye
08:56:32 <masaki-ueno> ty bye
08:56:37 <ueha> Thank you, bye
08:56:41 <takahashi-tsc> thank you, bye
08:56:51 <yasufum> #endmeeting