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