21:01:09 #startmeeting containers 21:01:10 Meeting started Tue Feb 5 21:01:09 2019 UTC and is due to finish in 60 minutes. The chair is strigazi. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:14 The meeting name has been set to 'containers' 21:01:17 #topic Roll Call 21:01:18 o/ 21:01:25 o/ 21:01:29 o/ 21:03:17 Hey eandersson and jakeyip, let's get into it. I needs some reviewers :) 21:03:28 #topic Stories/Tasks 21:03:41 That's what we are here for! :D 21:04:08 5 items, here it goes: 21:04:19 k8s_fedora: Deploy tiller https://review.openstack.org/#/c/612336/ 21:04:19 [k8s_fedora] Add heat-agent to worker nodes https://review.openstack.org/#/c/561858/ 21:04:22 [k8s] helm install metrics service https://review.openstack.org/#/c/632392/ 21:04:25 Allow cluster template being renamed https://review.openstack.org/#/c/609174/ 21:04:28 Add hidden flag to cluster template https://review.openstack.org/#/c/634948/ 21:04:51 First two are mine, ready for review. I have mentioned them before. 21:05:12 Tiller in master nodes, and heat-agent in all nodes 21:05:43 Next, colleague Diogo works on deploying the metrics server with helm in 632392 21:06:08 And last two are useful for operators to advertise public CTs 21:06:45 Feilong proposed to allow CTs being renamed, like docker.io/ubuntu:latest 21:07:15 And ricardo has a complementary patch to add a hidden field in CTs. 21:07:46 You advertise a CT to users and when you want to put it away you hide like images. 21:07:47 would love to help, actually looking at last two right now because that's something I was interested in :) 21:08:27 clusters can use a hidden public CT, but users shopping for a CT can not list it. 21:09:29 If the know the uuid they can use it. (bad for them, kind of). We can add a check to not allow creation with hidden CTs. Not sure we want this or if it is that important. 21:09:37 nice jakeyip 21:09:48 jakeyip: eandersson any questions? 21:10:09 there's actually a similar thing in glance but it's called community (?) 21:10:17 Spyros Trigazis proposed openstack/magnum master: k8s_fedora: Deploy tiller https://review.openstack.org/612336 21:10:18 Spyros Trigazis proposed openstack/magnum master: [k8s] helm install metrics service https://review.openstack.org/632392 21:10:29 jakeyip yes, we thought about it 21:10:34 sounds straightforward enough 21:10:42 anything in particular that is of higher priority? 21:10:54 but we would have to deprecate public and make a new enum field. microversions etc 21:11:31 honestly, I think this is easier to understand and less awkward, but just would like to know if making things similar across services was considered 21:11:42 all good then 21:12:20 1st 634948 and 609174 the other three are important too but can be cherry-picked :) 21:12:36 I mean downstream 21:13:14 Adding helm, will simplify things a lot. We want all the CERN specific things to become a single chart that we just enable 21:13:52 The heat agent can wait a bit but it is the simplest :) 21:14:06 re: tiller, I wonder if anybody has done tiller in gitlab before? does this implementation break that? 21:14:33 jakeyip I had tried it. You can have many tillers 21:14:49 that is why I add tiller in magnum-tiller 21:15:15 the releases of helm live there 21:15:38 The only thing that would break if gitlab's tiller wants to deploy the same thing. 21:15:53 However I added the option to select the namespace 21:16:04 I see. nice! 21:16:07 So you can install tiller in kube-system 21:16:28 only things is you would have to distribute tiller certs 21:17:23 jakeyip: how you deploy with gitlab? 21:17:26 so you can install in kube-system and let gitlab detect it? 21:18:03 jakeyip: yes, it is the default but gitlab will need the certs to talk to tiller over tls. I haven't tried that 21:18:18 jakeyip: I'll give it a go. 21:18:19 strigazi: a gitlab user can spin up their own cluster and attach the cluster to it their gitlab account 21:19:23 strigazi: then they'll have the option to install tiller and it'll be able to pick up the jobs in CI/CD pipelines on a commit. 21:20:12 jakeyip: I'll give a go again, it is been some time. The option to insall tiller in magnum-tiller ns is totally compatible 21:20:16 I think it's fine if it's different NS 21:20:45 the annoying thing is that gitlab doesn't let you choose NS :P 21:21:00 your implementation is superior 21:21:54 jakeyip: I implemtented all the best practices mentioned in the docs 21:22:15 jakeyip: only thing I couldn't avoid is make tiller sa very powerfull 21:22:45 jakeyip: the metrics server chart needs to create cluster level roles and bindings 21:23:02 jakeyip: it was unavoidable 21:23:22 jakeyip: eandersson have a look into this: https://github.com/stefanprodan/gitops-helm 21:23:47 better than pushing to the cluster. The cluster pulls instead when you push code. 21:24:12 cbrumm_, ^ 21:25:01 thanks @eandersson: I'll review later 21:25:26 Ricardo had implemented a similar method but this one is more mature 21:26:07 eandersson: this one https://gitlab.cern.ch/helm/plugins/crd-release/tree/crd 21:26:30 interesting 21:27:07 we didn't know about the gitops thing before 21:28:21 eandersson: the only depressing thing is that it is the same pattern as our puppet deployment, soooo it might bite later? who knows :) 21:30:12 strigazi: how's your puppet deployment like? 21:31:56 jakeyip: in short: you push to repo, puppet-master picks up the changes, puppet agent runs every 60mins (unless you tell it to run) and applies the config 21:32:58 jakeyip: so similarly, with gitops, you push the chart to repo, cluster listens to webhook (or cronjob) and it applies the chart 21:33:01 jakeyip: makes sense? 21:33:42 are you using puppet to update helm charts? 21:34:13 jakeyip: no 21:34:38 sorry, I mean to run the updated charts; update containers in your cluster 21:36:51 jakeyip: at the moment each team has each own method. Some do it with helm by hand 21:37:33 others with gitlab, but without the integration, just in gitlab ci the ci knows how to talk to the cluster 21:39:34 strigazi: which integration is this referring to? 21:40:07 (I think we can take this topic offline if necessary, I don't want to hold up meeting time) 21:41:48 eandersson: do you have anything to add? Do you need any further clarifications for the patches I mentioned before? 21:41:53 jakeyip: same ^^ 21:42:24 I'll take some time towards the end of the week to go through them 21:42:35 and I'll let you know if I need anything else 21:43:28 Thanks 21:44:05 same. I'm new so not that familiar with magnum code base, but I'll try to help. 21:45:50 thanks jakeyip 21:46:42 Merged openstack/magnum master: Allow cluster template being renamed https://review.openstack.org/609174 21:47:15 eandersson: jakeyip so Feilong was did it :) 21:47:44 flwang1: you can also review Ricardo's patch, Allow cluster template being renamed https://review.openstack.org/#/c/609174/ 21:48:12 I think you will need that to not have a huge list of CTs 21:48:44 strigazi: which one? 21:48:55 two line above 21:49:14 wrong link 21:49:21 correct: 21:49:22 Add hidden flag to cluster template https://review.openstack.org/#/c/634948/ 21:50:04 strigazi: oh, yep, we had similar idea for glance public images 21:50:20 it's quite annoying when the number is big 21:50:41 flwang1: the idea comes from there. We use community images in our cloud to not have a massive list of images 21:50:59 i will review that 21:51:22 I explained above that we didn't use the same thing to not have to deprecate the public field. 21:51:42 Also IMO hidden makes more sense than community 21:52:20 strigazi: yep, generally, user/admin just don't want to see them in the list 21:52:20 When the cloud admin marks an image community, it is strange 21:54:21 i agree 21:54:37 personally, i like the 'hidden' idea 21:54:53 sweet \o/ 21:55:02 let's do this :) 21:55:11 I need to review it actually first xD 21:55:54 Let's end the meeting? Anything else to discuss? 21:57:05 said once 21:57:22 said twice 21:57:34 See you around! 21:57:38 #endmeeting