09:00:20 <flwang1> #startmeeting magnum 09:00:21 <openstack> Meeting started Wed Jul 1 09:00:20 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:24 <openstack> The meeting name has been set to 'magnum' 09:00:43 <flwang1> brtknr: seems just you and me 09:00:51 <flwang1> so i assume this could be a short meeting 09:01:43 <flwang1> i saw you added a topic 'build hca in ci', would you like to talk more about it? 09:01:46 <brtknr> flwang1: just saw an email from spyros 09:03:06 <flwang1> yep, just replied 09:05:01 <flwang1> brtknr: let's continue? 09:05:51 <brtknr> sure 09:06:18 <brtknr> flwang1: so hca stable tags are currently manually tagged 09:06:27 <flwang1> yes 09:06:28 <brtknr> it would be good to do this via CI 09:06:38 <brtknr> we discussed this a few weeks earlier 09:06:41 <flwang1> brtknr: do you have any idea to do that? 09:06:56 <flwang1> brtknr: ah, i remember now 09:07:01 <brtknr> https://review.opendev.org/#/c/735100/ 09:07:40 <openstackgerrit> Bharat Kunwar proposed openstack/magnum master: [hca] Only build/push stable images if unpublished https://review.opendev.org/735100 09:10:36 <flwang1> but this one can't resolve the issue that we have to manually tag hca version for stable branch, is it? 09:13:27 <flwang1> brtknr: ^ 09:14:13 <brtknr> flwang1: thats right 09:15:00 <brtknr> but a stable tag doesnt get built if it already exists upstream 09:15:11 <brtknr> thats the key difference 09:15:12 <flwang1> i understand 09:15:25 <flwang1> i'm ok with this change 09:18:28 <brtknr> Cool 09:18:39 <brtknr> Lets talk about your issue 09:18:55 <brtknr> what is allow_cross_minor_version_upgrade? 09:19:03 <brtknr> flwang1: 09:19:33 <flwang1> recently, i'm working on a doc about versions 09:19:35 <flwang1> for k8s 09:19:58 <flwang1> see https://github.com/openstacker/catalystcloud-docs/blob/c246d02362d343b3ae024730b40f59177e17fb4c/source/kubernetes/versions.rst 09:20:31 <flwang1> though i know Magnum does support upgrade and skip minor versions 09:21:26 <flwang1> but we (Catalyst Cloud) would like to ask user do not skip minor version to avoid surprise (may break api compatibility ) 09:21:51 <flwang1> and one of our reviewer was asking if we can enforce it by the service 09:22:28 <flwang1> hence why i'm thinking if we can support it and leave the option to the cloud admin if they would like to enable this enforcement 09:22:35 <flwang1> brtknr: does that make sense? 09:24:27 <jakeyip> very informative flwang1 :) 09:24:57 <flwang1> jakeyip: are you talking about the doc? ;) 09:25:08 <jakeyip> yeap 09:26:02 <flwang1> jakeyip: thank you 09:26:25 <flwang1> our public cloud users are seriously care the version support policies 09:26:29 <flwang1> hence why we need it 09:27:52 <jakeyip> how are you testing upgrades? 09:28:05 <flwang1> we have a pipeline running on gitlab 09:28:36 <flwang1> when we publishing a new template, the pipeline will make sure the new version is upgradeable 09:28:44 <flwang1> from the n-1 version 09:28:52 <flwang1> jakeyip: ^ 09:29:24 <jakeyip> flwang1: I see. does the pipeline spins up a new cluster with n-1 and upgrade it? 09:29:41 <flwang1> jakeyip: yes 09:29:51 <flwang1> with our public template 09:30:00 <flwang1> brtknr: any thought? 09:31:20 <brtknr> flwang1: sorry home distractions 09:31:26 <brtknr> just catching up 1 sec 09:33:16 <brtknr> flwang1: sounds good to me, shouldnt be too controvertial if its opt-in 09:33:42 <brtknr> although I slightly prefer the upgradable template proposal 09:33:56 <brtknr> which would also cover this use case 09:34:14 <flwang1> you mean add a new field to cluster template? 09:34:31 <brtknr> e.g. when you create a new template, you can specify a list of templates that you users can upgrade from 09:34:35 <brtknr> flwang1: thats right 09:34:56 <brtknr> this is more similar to other public clouds 09:35:28 <flwang1> brtknr: yep, the only thing is, that one will only work for public templates managed by the cluster admins 09:35:30 <brtknr> it seems inconvenient to force users to upgrade every minor version if there is no reprecussion 09:36:19 <brtknr> flwang1: surely you can only guarentee SLA for public templates managed by cluster admins 09:36:19 <flwang1> brtknr: AKS (and IBM?) doesn't allow skip minor version 09:36:46 <brtknr> flwang1: maybe I am misunderstanding 09:37:01 <flwang1> brtknr: no, you're right 09:37:33 <brtknr> you mean prevent users from going from 1.14.1->1.14.3? or going from 1.14.1->1.16.1 09:37:36 <flwang1> i know the 'allowed_upgrade_from' field can cover this 09:37:47 <flwang1> brtknr: the later 09:38:03 <flwang1> 1.14.1 -> v1.14.3 is just patch version 09:38:06 <brtknr> flwang1: i agree that 1.14.1->1.16.1 should not be allowed 09:38:09 <flwang1> we're talking about minor version 09:38:22 <flwang1> major.minor.patch 09:38:29 <brtknr> yep sorry i got confused 09:39:00 <flwang1> i just think a basic check is much easier than a db schema change 09:39:28 <flwang1> i will think about this again and propose a patch later 09:40:10 <brtknr> flwang1: you are right 09:40:29 <brtknr> i dont think we even need a config option 09:40:46 <brtknr> i am happy to make it the magnum default behaviour 09:41:06 <flwang1> brtknr: it's good know you support this idea 09:41:25 <flwang1> TBH, i believe it will make our support life much easier 09:41:27 <brtknr> and lets backport to ussuri 09:41:56 <brtknr> flwang1: btw do you use terraform with magnum? 09:42:16 <flwang1> brtknr: one of our large customer use terraform 09:42:42 <flwang1> and recently i'm going to contribute terraform to support the --merge-labels 09:42:52 <brtknr> flwang1: btw how many clusters do you host? 09:42:57 <flwang1> i just get it done in gophercloud 09:43:05 <brtknr> flwang1: nice! 09:43:23 <flwang1> not sure if i can share the info, sorry 09:43:46 <brtknr> flwang1: ah no worries 09:45:12 <flwang1> brtknr: we do have some serious customers are using our k8s service 09:45:48 <flwang1> that's why we're seriously caring some features like vesions support, upgrade, ca rotate 09:46:04 <flwang1> some of them, private clouds may not really care 09:46:25 <brtknr> flwang1: https://github.com/gophercloud/gophercloud/commit/f4f6cc9e28463ff34984d79089c5985b5b8df85c#diff-6134db4c32ede6a964dced2d7195db8fR36 09:46:45 <brtknr> does that mean merge-labels is true by default 09:47:13 <brtknr> Ah oops that is just a test case 09:48:02 <flwang1> by default it's empty, which means it will be skipped i think 09:48:35 <flwang1> i haven't got time to finish the work in terraform 09:48:47 <flwang1> anything else you guys want to discuss? 09:50:43 <flwang1> brtknr: jakeyip: shall we call this one done? 09:51:00 <flwang1> i'm going to close this meeting, thanks for joining 09:51:02 <jakeyip> nothing from me :) 09:51:18 <flwang1> #endmeeting