09:00:26 <flwang1> #startmeeting magnum
09:00:27 <openstack> Meeting started Wed Dec 11 09:00:26 2019 UTC and is due to finish in 60 minutes.  The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:30 <openstack> The meeting name has been set to 'magnum'
09:00:36 <flwang1> #topic roll call
09:00:40 <strigazi> o/
09:00:43 <flwang1> o/
09:00:44 <brtknr> o/
09:01:34 <flwang1> anyone else?
09:01:51 <flwang1> ok, let's go through our agenda?
09:02:08 <strigazi> +1
09:02:11 <brtknr> dioguerra:
09:03:10 <flwang1> strigazi: your turn, irc or gerrt?
09:03:13 <brtknr> +1
09:03:22 <strigazi> VS not or :)
09:03:29 <brtknr> change topic :)
09:03:58 <flwang1> #topic gerrit vs irc
09:04:30 <strigazi> I was trying to review https://review.opendev.org/637939 - metrics server chart tag AND https://review.opendev.org/696832 - heapster enabled label
09:04:44 <brtknr> I like both, agree is better for keeping a record
09:05:02 <brtknr> Gerrit*
09:05:05 <strigazi> and it seems that a lot of context was only in IRC. This requires a lot of effor.
09:05:22 <strigazi> and it seems that a lot of context was only in IRC. This requires a lot of effort just ti get to the context.
09:05:30 <strigazi> s/ti/to/
09:05:54 <strigazi> I just wanted to bring up that all discussion should be in gerrit.
09:06:09 <flwang1> strigazi: i get your point, i would suggest for patch review, let's take the comments to gerrit
09:06:13 <strigazi> Or a summary of the discussion should be added in gerrit.
09:06:20 <flwang1> strigazi: +1
09:06:37 <strigazi> Sometimes things need to be discussed in a chat, I get it
09:07:08 <strigazi> That's it for gerrit vs IRC.
09:07:14 <strigazi> follow up:
09:07:15 <brtknr> +1
09:07:41 <strigazi> I proposed that before and I didnt do it. Let's do it now:
09:07:48 <strigazi> abandon close all gerrit changes and stories in storyboard that are more than two weeks old with the following message
09:08:03 <strigazi> #topic backlog clean up
09:08:09 <flwang1> strigazi: actually, i have abandoned quite a lot
09:08:10 <brtknr> ok
09:08:13 <flwang1> strigazi: did you see that?
09:08:18 <strigazi> no
09:08:22 <flwang1> :(
09:08:42 <strigazi> https://review.opendev.org/#/q/project:openstack/magnum+status:abandoned
09:08:56 <strigazi> The ones in November?
09:09:32 <strigazi> flwang1: ^^
09:10:05 <flwang1> i abandoned at least 20+ or 30+
09:10:12 <flwang1> anyway, that doesn't matter
09:10:43 <strigazi> we have five pages of open changes
09:11:17 <flwang1> i agree with abandon old changes
09:11:23 <flwang1> but 2 weeks is too short
09:11:43 <strigazi> let's keep only the ones from december?
09:11:53 <strigazi> contributors can open again anyway
09:11:56 <flwang1> i'd suggest let's do it for 2 stages
09:12:13 <flwang1> stage 1, abandon patches older than 3 months
09:12:36 <flwang1> stage 2, abandon patches older than 1 month
09:13:07 <flwang1> as long as we finish the stage 1, we can revisit this topic, thoughts?
09:13:43 <strigazi> I think 3months is a bit much, we are only three
09:13:49 <brtknr> lets take an average and abandon everything more than 2 months
09:13:55 <strigazi> xD
09:13:55 <brtknr> lets not complicate things
09:14:33 <strigazi> Only November and December stays open
09:14:35 <brtknr> I have started abandoning things in the reverse order
09:14:43 <brtknr> oldest first
09:14:48 <flwang1> fair enough
09:15:07 <strigazi> brtknr: you want to go over them manually?
09:15:24 <strigazi> brtknr: we won't be able to follow this.
09:15:56 <brtknr> is there an automatic way of doing it?
09:16:11 <strigazi> API + python client
09:16:38 <brtknr> ive not used the python client but happy for this to be in place
09:16:39 <strigazi> I can do this and share the code.
09:16:49 <brtknr> +1
09:16:57 <strigazi> same for storyboard
09:17:01 <flwang1> strigazi: if you can do it with code, then i don't care 1 month or 2 or 3
09:17:03 <brtknr> where is the daemon going to run?
09:17:30 <brtknr> CERN HQ?
09:17:39 <flwang1> we're making things complicated i think
09:17:42 <brtknr> or your laptop?
09:17:42 <strigazi> it won't be daemon, I will do it once.
09:17:46 <flwang1> strigazi: just share the script on github
09:18:02 <flwang1> we can ran it on demand or casucally
09:18:05 <brtknr> should  we start a new openstack project?
09:18:09 <strigazi> I'll push a patch in our repo.
09:18:17 <brtknr> :P
09:18:50 <flwang1> let's move to next topic?
09:18:53 <strigazi> every month a core can do it and report in the meeting. we don't need a bot
09:19:02 <flwang1> strigazi: +1
09:19:04 <brtknr> sounds good time
09:19:14 <strigazi> before moving, same for storyboard, ok?
09:19:25 <brtknr> sounds good to me for both storyboard and gerrit
09:19:29 <flwang1> strigazi: i'm ok with that
09:19:36 <strigazi> move on then
09:20:04 <strigazi> I'm working on containerd
09:20:29 <strigazi> we have done some tests and we presented some optimizations yesterday here:
09:20:53 <strigazi> https://indico.cern.ch/event/739899/contributions/3662104/attachments/1959729/3256569/CERN-containerd-remote-snapshotter.pdf
09:21:19 <strigazi> I will add CI to build containerd and add the config.
09:21:36 <brtknr> #topic containerd
09:21:37 <strigazi> that's it for containerd. It will be opt-in ofcourse.
09:21:55 <strigazi> only flwang1 can use topic is seems.
09:22:07 <flwang1> #topic containerd
09:22:25 <flwang1> strigazi: thanks for sharing the slides
09:22:32 <strigazi> I don't have anything to add actually for containerd :)
09:22:45 <strigazi> I mentioned everything :)
09:23:05 <flwang1> strigazi: thanks
09:23:25 <flwang1> #topic the hash/digest verification
09:23:40 <flwang1> strigazi: what do you mean " sha is not security xD"?
09:24:09 <openstackgerrit> Xinliang Liu proposed openstack/magnum-ui master: Add fedora-coreos distro  https://review.opendev.org/698130
09:24:34 <strigazi> flwang1: the sha verifies the download of integtity. a mitm attack is still possible.
09:25:27 <flwang1> strigazi: can you explain more?
09:25:36 <brtknr> strigazi: even if you know the sha of the expected image?
09:26:30 <strigazi> flwang1: I can serve you something else for that sha
09:27:24 <flwang1> strigazi: you mean generate a fake image with the same sha256?
09:27:27 <brtknr> strigazi: you'd need to waste a lot of compute to perfectly produce an image with the exact same sha
09:27:52 <brtknr> isnt the point to make attach difficult than to prevent it?
09:28:02 <flwang1> brtknr: +1
09:28:15 <strigazi> yes, but it is not security.
09:28:38 <strigazi> debian for example is using GPG for the packages. not checksums
09:28:52 <strigazi> I'm not saying it is not an improvement.
09:28:53 <flwang1> do you have a better solution for this issue?
09:29:22 <dioguerra> o/ uhh forgot about it
09:30:11 <brtknr> dioguerra: o/
09:30:29 <brtknr> cant find any gpg public key for hyperkube
09:30:32 <strigazi> My point is, we should not advertise this as a security measure.
09:30:38 <brtknr> this only applies to hyperkube right flwang1 ?
09:30:50 <flwang1> brtknr: yes
09:31:25 <strigazi> I  will comment in  gerrit.
09:31:33 <flwang1> strigazi: i'm not saying that and i don't think we should take too much time to discuss if it's absolute secure or not
09:31:39 <strigazi> I will review the change.
09:32:30 <flwang1> strigazi: i think this is a simple method we can do at this moment to improve the image security
09:32:44 <zainub_wahid> Hello, I am trying to create a cluster using CoreOS not "Fedora CoreOS". I am using kolla-ansible stein 8.0.1. It is giving error: ERROR: The Parameter (octavia_ingress_controller_tag) was not defined in template.any help?
09:33:10 <flwang1> zainub_wahid: we're in a meeting, can we talk this later?
09:33:26 <flwang1> i'm open for any better solution
09:33:29 <zainub_wahid> ohh okay sorry
09:33:56 <flwang1> zainub_wahid: no worries
09:34:04 <flwang1> move to next topic?
09:34:08 <strigazi> flwang1 I will comment in gerrit, having the option to use sha is good.
09:34:10 <brtknr> +1
09:34:21 <brtknr> i am happy to take the patch
09:34:31 <strigazi> not happy with current format.
09:34:43 <brtknr> perhaps we should call it hyperkube_digest since it only applies to the hyperkube image
09:35:12 <strigazi> let's move on
09:35:16 <flwang1> brtknr: strigazi: please leave your comments on gerrit, we can discuss there
09:35:30 <flwang1> #topic proxy regression issue for fedora drivers
09:35:44 <flwang1> https://review.opendev.org/#/c/698353/ we have a regression issue about proxy
09:36:06 <flwang1> it's introduced because recently we changed the code quite a lot
09:36:18 <flwang1> and we don't have a good way to test the proxy scenarios
09:36:56 <strigazi> ack
09:37:02 <flwang1> in above patch, i have tested the fedora atomic cases on production. i need test the fedora coreos case
09:37:31 <flwang1> strigazi: brtknr: please keep an eye on this one, because it's breaking cluster creation
09:37:44 <brtknr> we dont use proxy and not sure how to test it so will take your word for it
09:38:33 <strigazi> ok
09:38:54 <brtknr> will do!
09:39:27 <flwang1> #topic train 9.2.0
09:39:41 <flwang1> brtknr: i think we have merged all the patches proposed for train 9.2.0
09:39:55 <flwang1> brtknr: are you going to propose a patch in releases?
09:40:07 <brtknr> flwang1: we are still waiting for a bunch of things on master to be merged
09:40:11 <brtknr> and backported
09:40:52 <flwang1> brtknr: hmm... are they bugs or new features?
09:41:09 <brtknr> some are required because they do not work in 1.16.x
09:41:23 <brtknr> because of deprecated APIs
09:41:38 <dioguerra> shouldn this one be added too? https://review.opendev.org/#/c/694230/
09:41:48 <flwang1> brtknr: i see. if they're bugs(breaking functions), then we're OK to backport
09:42:25 <brtknr> dioguerra: +1
09:42:45 <flwang1> dioguerra: btw, can i set labels for node group to let them being bypassed to kubelet?
09:43:06 <flwang1> as kubelet labels
09:43:24 <brtknr> what do you think aobut this one btw: https://review.opendev.org/#/c/697143/
09:43:35 <flwang1> brtknr: is it a question for me?
09:43:36 <brtknr> sometimes we might just want to upgrade the OS and not the kube tag
09:43:52 <brtknr> flwang1: yeah
09:44:16 <flwang1> brtknr: that's a valid user case, i will take a look
09:45:04 <dioguerra> flwang1: i don think this is available now. labels are static
09:45:21 <brtknr> dioguerra: i could only get the prometheus adaptor working with backoffLimit of 10
09:45:22 <brtknr> https://review.opendev.org/698338 - increase backoffLimit
09:45:43 <brtknr> this is in the case of podman
09:45:56 <flwang1> dioguerra: so in the NG world,  the labels are still only for magnum, right?
09:46:50 <brtknr> flwang1: i dont understand your question
09:46:58 <brtknr> arent all labels for magnum?
09:47:04 <dioguerra> brtknr: this happens when the vms are slow... We can actually increase to 30s maybe
09:47:48 <flwang1> brtknr: i'm asking if we introduced a special "label" which can be passed in to set the kubelet labels
09:47:59 <brtknr> dioguerra: do you want to propose the necessary change and override https://review.opendev.org/698338
09:48:03 <flwang1> because with NG, that will be a common requirement
09:48:17 <flwang1> we can discuss offline
09:48:34 <flwang1> brtknr: strigazi: anything else you want to discuss?
09:48:45 <flwang1> we have about 10 mins
09:49:01 <strigazi> The backoff limit is already congurable for kubelet
09:49:28 <strigazi> useing kubelet_params or args, I don't remember the name
09:49:33 <strigazi> one sec
09:49:34 <brtknr> this is not for kubelet, only for helm install job
09:49:40 <brtknr> strigazi:
09:49:42 <dioguerra> brtknr: can you squash and push? since you have the modifications
09:50:03 <brtknr> dioguerra: squash with what?
09:50:16 <dioguerra> with my commit for prom-adapter
09:50:30 <brtknr> the change i made applies to everything installed via helm
09:50:42 <brtknr> its not a particularly slow vm either
09:52:30 <dioguerra> flwang1: it sets the nodegroup names in the kubernetes as a node label https://review.opendev.org/#/c/685748/3
09:53:22 <flwang1> dioguerra: no, that's different
09:53:28 <flwang1> let's discuss offline
09:53:36 <strigazi> is there an issue?
09:53:42 <strigazi> what are you talking about?
09:53:56 <dioguerra> flwang1: ok
09:53:56 <flwang1> strigazi: not an issue, it's mostly like a feature
09:54:06 <brtknr> i am losttoo
09:54:30 <flwang1> to allow user can set the kubelet(node) labels when creating node group
09:54:42 <flwang1> i will double check if GKE supports that
09:55:00 <strigazi> flwang1: this is possible already
09:55:16 <flwang1> strigazi: i know it's possible
09:55:33 <flwang1> my question is, is it already there
09:55:37 <strigazi> it is
09:55:44 <strigazi> that is what I'm saying
09:56:10 * strigazi is typing
09:57:10 <strigazi> --labels kubelet-options="--node-labels=foo=zoo"
09:57:22 <strigazi> --labels kubelet_options="--node-labels=foo=zoo"
09:57:31 <strigazi> flwang1: ^^
09:58:00 <strigazi> this is what you want, right?
09:58:07 <flwang1> strigazi: ah, right, that's what i want
09:58:27 <strigazi> It is already in place.
09:58:34 <flwang1> strigazi: i remember now
09:58:35 <flwang1> thanks
09:58:38 <brtknr> ok lets wrap up
09:59:09 <brtknr> one last thing i want to bring up is about the magnum-ui changes contributed by catalyst
09:59:22 <brtknr> just needs a release notes as its a major feature
09:59:33 <flwang1> brtknr: ok, i will let the owner know
09:59:43 <brtknr> flwang1: thanks
09:59:49 <flwang1> i have tested the resize patch and it works perfectly
09:59:49 <brtknr> g2g folks, nice chatting
09:59:53 <flwang1> i will test the upgrade later
09:59:55 <dioguerra> Can we merge this 2? https://review.opendev.org/#/c/691646/ https://review.opendev.org/#/c/695681/
10:00:56 <strigazi> dioguerra: I will test asap. ^^
10:01:25 <brtknr> dioguerra: i tested and works for me
10:01:46 <strigazi> let's test two times if it is ok
10:01:47 <flwang1> #endmeeting