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