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