09:00:16 <flwang1> #startmeeting magnum 09:00:17 <openstack> Meeting started Wed Jul 15 09:00:16 2020 UTC and is due to finish in 60 minutes. The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:20 <openstack> The meeting name has been set to 'magnum' 09:01:05 <flwang1> #topic roll call 09:01:10 <flwang1> o/ 09:01:26 <openstackgerrit> Bharat Kunwar proposed openstack/magnum master: [docs] Bring user docs up to date with recent changes https://review.opendev.org/714721 09:01:37 <brtknr> o/ 09:02:03 <flwang1> i think just us 09:02:18 <flwang1> let's go through the topics for today 09:02:33 <flwang1> #topic master_lb_enabled 09:03:01 <flwang1> you guys merged the client side patch before merging the server side :) 09:03:20 <flwang1> so i have to push you again on this one 09:04:01 <brtknr> flwang1: hehe its opt in on client side 09:04:02 <flwang1> brtknr: can you revisit that one? https://review.opendev.org/#/c/726017/ 09:04:21 <brtknr> so no great harm, i see the server side merging imminently 09:05:10 <flwang1> and it can make our life easier 09:05:26 <flwang1> at this moment, we're maintaining 6 templates 09:05:41 <flwang1> with this one, we can reduce it to 3 09:06:05 <brtknr> flwang1: nice are you guys already using the server side patch? 09:06:40 <flwang1> no, we only maintain private patch when we have to 09:07:24 <flwang1> as long as this one merged, i will propose a patch on magnum ui to add a checkbox for this 09:07:40 <brtknr> flwang1: sounds good 09:08:04 <flwang1> brtknr: i will bug you again if i didn't see your comments by this Friday :D 09:09:00 <brtknr> flwang1: yes things have been quite busy recently so not had a chance to work on much upstream stuff 09:09:37 <flwang1> i understand and I appreciate any contribution when people are busy on internal work 09:10:02 <flwang1> let's move on? 09:10:06 <brtknr> flwang1: actually the reason I proposed the cluster template clone patch was to test your cluster upgrade patch 09:10:20 <brtknr> as i was too lazy to create a new template from scratch everytime 09:11:11 <flwang1> brtknr: that's a clever command, i like it TBH 09:11:17 <flwang1> i will test it before +2 09:11:53 <brtknr> flwang1: one thing i noticed was that after the upgrade fails, i cannot upgrade the cluster 09:11:57 <brtknr> is that expected? 09:12:14 <flwang1> you mean the cluster will be in update_failed? 09:12:19 <brtknr> yeah 09:12:27 <flwang1> and can't be upgrade again? 09:12:38 <brtknr> e.g. if i try to upgrade to 2.19 and the update_failed 09:12:55 <brtknr> looks like we are already talking about the next topic btw 09:13:02 <flwang1> #topic upgrade disallow minor version skipped 09:13:39 <flwang1> yep, so noticed that as well. so i'm thinking if we should move this logic to api layer 09:14:03 <flwang1> or when there is an error, just reset the status back 09:14:26 <flwang1> or when there is a upgrade failed error, just reset the status 09:15:17 <brtknr> flwang1: yes that would make sense 09:15:31 <flwang1> i will dig it 09:15:51 <brtknr> or allow upgrade even when state is update_failed? 09:16:08 <brtknr> otherwise how will the user know? 09:16:12 <flwang1> brtknr: or allow upgrade even when state is update_failed? --- yes, that one should be fixed as well 09:16:26 <flwang1> brtknr: good point 09:17:17 <flwang1> i think we just need to allow upgrade a cluster which in 'update_failed' status 09:17:33 <flwang1> very efficient discussion 09:17:35 <flwang1> next one? 09:17:41 <brtknr> flwang1: may I make a request btw 09:17:50 <flwang1> sure 09:18:28 <brtknr> when i test your changes, your topics are often story/xxxxxx-xxxx 09:19:10 <brtknr> while this is good for the commit messsage, it is difficult to see what this change is about when i do `git branch` 09:19:22 <flwang1> haha 09:19:25 <brtknr> especially when there are lots of branches already 09:19:41 <brtknr> may i suggest that you use a semantic topic :) 09:19:51 <flwang1> i will replace the 'story' withe a meaningful name 09:20:02 <brtknr> flwang1: thanks 09:21:24 <flwang1> btw, as your comment about major version, i don't mind to add it, but i prefer to see spyros's opinion on the existing code before i putting much effort on that 09:22:39 <brtknr> flwang1: understood 09:23:43 <flwang1> brtknr: your docs patch looks good for me, i will +2, easy one 09:25:15 <flwang1> brtknr: btw, it would be nice if you can revisit the ca rotate patch. Spyros gave some good comments and I think i have already addressed that. so please revisit it when you have time 09:29:28 <brtknr> flwang1: no problem i will test it by the end of this week 09:29:42 <flwang1> thank you very much 09:29:47 <brtknr> flwang1: probably just a basic test to make sure it works as expected 09:30:05 <brtknr> flwang1: btw have you tried the k8s cluster API? 09:30:20 <flwang1> no, why? 09:31:37 <brtknr> flwang1: i had a quick look at it recently: https://github.com/kubernetes-sigs/cluster-api-provider-openstack 09:32:01 <flwang1> brtknr: how do you think? 09:32:04 <brtknr> I was surprised it required a kubernetes cluster for bootstrapping 09:32:33 <brtknr> well the image that i uploaded to glance did not boot so i havent had a chance to try it fully 09:32:38 <brtknr> the documentation is lacking too 09:33:23 <flwang1> yep, it needs a "root" k8s cluster 09:34:24 <flwang1> one day, if EKS or GKE start to use cluster API, then i think Magnum can think about it, otherwise. it doesn't fit our scope 09:35:24 <brtknr> flwang1: it is a long way from being stable actually 09:35:33 <brtknr> e.g. i cannot delete the clusters ive created 09:36:21 <flwang1> without many people's hard work, hard to get it stable 09:36:45 <brtknr> it complains about a security group that is in use but the controller manager should delete things in the correct order 09:37:37 <flwang1> btw, did you guys using designate in your cloud? 09:37:54 <flwang1> s/did/are 09:38:16 <brtknr> we do on one of the sites but i didnt deploy it 09:40:02 <flwang1> right 09:40:14 <flwang1> i'm doing some research work now 09:40:23 <flwang1> anything else you would like to discuss? 09:41:44 <brtknr> flwang1: what are you hoping to do with designate? 09:42:23 <flwang1> basic integration with VM layer and integrate with k8s with external-dns 09:43:23 <brtknr> flwang1: i see 09:45:21 <flwang1> cool, let's call this one done 09:45:28 <flwang1> brtknr: thanks for joining 09:46:13 <brtknr> flwang1: can i quickly clarify something 09:46:21 <flwang1> sure 09:46:26 <brtknr> https://docs.openstack.org/magnum/latest/user/#keystone-authentication-and-authorization-for-kubernetes 09:47:21 <brtknr> https://docs.openstack.org/magnum/latest/user/#keystone-authn-and-authz 09:47:35 <brtknr> flwang1: these two sections seems to serve a similar purpose 09:47:53 <brtknr> flwang1: shall we keep the first and remove the second? 09:48:10 <brtknr> or merge the two together? 09:48:50 <flwang1> i will take a look and see if they can be merged 09:50:28 <flwang1> seems the 2nd part can be merged into the 1st part 09:50:49 <flwang1> brtknr: anything else? 09:51:10 <brtknr> shall I update the docs PS with this change in that case? 09:51:34 <brtknr> I was also thinking about moving #keystone-authentication-and-authorization-for-kubernetes to #kubernetes as a subsection 09:51:54 <brtknr> also Kubernetes Health Monitoring which is currecntly H1 09:52:03 <brtknr> but I think it should be H2 under kubernetes section 09:52:39 <flwang1> i would suggest put it into a separate patch 09:53:39 <brtknr> https://docs.openstack.org/magnum/latest/user/#kubernetes-external-load-balancer also seems out of date since neutron lbaas is now completely removed 09:54:46 <brtknr> Ok separate patch sounds good 09:55:00 <brtknr> As it will involve some reorganisation 09:55:17 <flwang1> yep 09:55:37 <flwang1> thanks for putting time on the docs work 09:55:41 <flwang1> appreciate that 09:56:43 <brtknr> flwang1: np, it needs some love 09:56:48 <flwang1> true 09:56:54 <flwang1> ok, i'm going to close this meeting 09:57:11 <flwang1> #endmeeting