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