20:59:04 #startmeeting containers 20:59:06 Meeting started Tue Aug 14 20:59:04 2018 UTC and is due to finish in 60 minutes. The chair is strigazi. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:59:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:59:09 The meeting name has been set to 'containers' 20:59:15 #topic Roll Call 20:59:16 o/ 20:59:20 o/ 20:59:33 \o 21:00:47 I guess flwang prefers working at midnight not midday :) 21:00:51 #topic Announcements 21:00:52 haha 21:01:32 we have stable/rocky and magnum 7.0.0 21:01:49 \o/ 21:01:55 we have still patches to add so 7.0.1 would be the release 21:02:17 \o/ indeed :) 21:02:33 #topic Blueprints/Bugs/Ideas 21:02:49 I promised canori01 to tests coreos and I did 21:03:05 and apparently it is me that kind of broke it 21:03:14 I mean the coreos driver 21:03:32 details here: 21:03:37 #link https://review.openstack.org/#/c/579026 21:03:57 didnt you go to the fedora convention? 21:04:08 what are the atomic/coreos plans that you migth know of 21:04:15 The issue is passing certs with heat and using string replacement 21:04:44 #link https://review.openstack.org/#/c/590443/ 21:04:50 #link https://review.openstack.org/#/c/590346/ 21:04:56 #link https://review.openstack.org/#/c/589214/ 21:05:00 cloud-config in coreos != cloud-init 21:05:02 #link https://review.openstack.org/#/c/577570/ 21:05:17 are all ready for review 21:05:59 thanks 21:05:59 this reminds me, i was wondering strigazi or others if anyone has used hashicorp's Vault as a sidecar certificate authority in the cluster? 21:06:25 to ease some of these certificate management/distribution tasks? 21:06:43 colin-: no, at least at CERN we have barbican 21:07:03 there is work to integrate barbican and k8s 21:07:26 ok 21:07:27 eg barbican sdk was added to gophercloud 21:07:52 that's great, the interest is less in Vault in more in a more graceful way to manage all the TLS files 21:07:59 were working on org approval to work on kubernetes org repo to contribute several PRs for the standalone openstack controller 21:08:13 which will also translate to some magnum PRs 21:08:23 cool :) 21:08:26 o/ 21:09:05 canori02: o/ 21:09:48 imdigitaljim: have you pushed a patch to add kube-proxy already? 21:10:05 id need the two files merged to apply the rest 21:10:12 make-cert and configure-master 21:10:28 because it uses elements of those to complete it 21:10:42 imdigitaljim: ok 21:11:03 however the work has been already done 21:11:07 just a matter of sequence 21:11:41 you can push with depencies in gerrit, I guess you know this 21:11:56 *dependencies 21:12:14 i did not actually know, im not super knowledgeable with gerrit 21:12:16 ill check it out 21:12:23 and push it 21:12:53 https://docs.openstack.org/infra/manual/developers.html#adding-a-dependency 21:12:58 oh awesome 21:12:58 thanks 21:13:03 that will make it easy 21:13:18 three more items from me: 21:13:56 1. i'm working on the unit tests for the upgrade API, of course I love writing unit tests 21:14:16 2. with flwang we made some progress in : 21:14:43 #link https://review.openstack.org/#/c/572897/ 21:14:57 pulling the k8s cluster for health status 21:15:25 and return something like {api_health: {}, nodes: []} 21:16:18 3. k8s 1.11.x works without any issue, all patches for the certificates are merged and the contianer images are updated 21:16:41 yep! 21:16:57 we're also on 1.11.2 21:17:17 really easy now :) 21:17:56 the patch is 6 character, it would be 1 if I used a variable :) 21:18:08 we recently updated calico to 3.1.3 21:18:18 we're like 17 releases behind in magnum 21:18:34 args in dockerfiles require a newer docker version 21:18:36 probably more relevant to flwang: 21:18:42 imdigitaljim: what we have in magnum atm 21:18:48 ? 21:18:48 2.6.7 21:19:14 I wonder why flwang pushed for 2.6.x 21:19:25 there were some 3.x issues at the time 21:19:28 I think 3.x.y was out at that time 21:19:29 but to us they appear to be resolved 21:19:34 oh, ok 21:19:37 makes sense 21:19:41 yeah he was probably doing what was necessary 21:19:58 Finally, a comment for Fedora CoreOS 21:20:20 we need at least 6 months fedora having something solid to use 21:20:40 All the builds they have now are experimental and none of them are public 21:20:59 Fedora Atomic 30 will be the last one 21:21:17 Fedora CoreOS will be based on rpms 21:21:24 and will rpm-ostree 21:21:28 and will use rpm-ostree 21:21:29 will we still be able to use the same files that you know of? "atomic install etc" 21:21:50 atomic cli no, but something similar 21:22:03 ok so we'll need to make some changes 21:22:28 maybe we can get a good way to prebuild the new images as well quickly 21:22:29 they said since there are users like us they will take it into account 21:22:41 so we can inject extra stuff on the base fedora coreos image 21:23:00 regaring that, we will need to work with ignition 21:23:28 we can start investigating this with coreos and be ready 21:23:41 we need a way to compile the ignition json 21:24:11 we can join the fedora coreos meeting on the 21st 21:24:19 https://coreos.com/ignition/docs/latest/ 21:24:22 got it 21:24:24 imdigitaljim: are you interested? 21:24:35 that would be good actually 21:25:19 #link https://apps.fedoraproject.org/calendar/workstation/2018/8/20/#m9315 21:25:51 7:30 for me, great... 21:25:56 imdigitaljim: for you? 21:26:50 I can ask for the other one, if it is better, I think they will alternate 21:26:54 1030PM 21:27:00 i should be able to make it if i remember :p 21:27:12 imdigitaljim: I can ping you :) 21:27:58 speaking of atomic, I tested F28AH, works fine with magnum 7.0.0 21:28:18 and queens actually, I'll push a patch 21:29:28 I think that was all from me, imdigitaljim colin- canori02 do you want to add anything? 21:30:12 How far away is fedora coreos? 21:30:43 at least 6 months 21:31:09 I ask since the work I've been doing makes the coreos driver work through cloud-init and not ignition 21:31:25 Should we just deprecate that? 21:31:57 I would help 21:32:00 It would help 21:32:31 I think we can add your patch in rocky and then work on ignition 21:32:40 canori02: makes sense? 21:33:00 Yeah, makes sense 21:33:27 nothing else here 21:33:33 Also, had another question. Sorry if you covered this already since I was late 21:34:09 What were your guy's thougts on the discovery.etcd.io issues they were having? 21:34:50 discovery.etcd.io is back, but they plan to deprecate it, but without a clear timeline 21:35:23 canori02: if you want to put the effort with it, this can be run internally/locally 21:35:32 magnum has the option to use a local discovery so we can use that 21:35:57 strigazi: re calico 21:36:09 I posted a link in the channel last week on how to do it 21:36:14 when I worked on calico, GKE is also using 2.6.7 21:36:18 Yeah, I did deploy one internally. Wasn't too bad 21:36:35 so I trust google so I assume 2.6.7 is stable at least 21:36:53 sounds good ^^ 21:37:13 and given we have calico node tag, so user can easily upgrade if they want 21:37:34 flwang: we could change the default? 21:37:37 new version is cool, but i'm always a old man style, so.... 21:37:42 strigazi: we can 21:37:56 i can test with 3.x 21:38:12 and propose the version upgrade if it can pass the sonobuoy testing 21:39:01 do you remember what they were version locking on 2.6.x to support flwang? i seem to recall it being related to IPVS use for kube-proxy but could be wrong 21:39:08 canori02: we can start an issue in etcd repo to ask what they recommend 21:39:39 I imagine they will say, run your own discovery 21:40:20 bootstraping etcd without knowing the ips beforehand is tedious 21:42:54 I saw they were asking for feedback on how we use the service. So we can give them that 21:44:05 colin-: i can't remember, sorry 21:44:18 yeap, you can reply, I can follow it up too 21:44:38 for etcd discovery issue, at least, we can add a retry for the function 21:45:21 also the calico_tag wont work entirely 21:45:24 the yaml format changed 21:45:30 specifically plugins 21:45:48 minor changes though 21:45:57 flwang:^ 21:46:22 flwang: we've also gotten sonobuoy set up as well 21:48:01 imdigitaljim: flwang it always takes one hour to run? 21:48:39 yeah 21:48:47 its like 67 minutes for us 21:49:03 although sonobuoy make some more assumptions on a fwe things but overall its pretty good 21:49:51 what assumptions? example? 21:51:21 1 sec 21:55:01 sorry, i was in a meeting and going into another one 21:55:17 strigazi: yes, 1 hour 21:55:22 flwang: enjoy :) 21:55:30 but i'm going to dig to see if we can have a smoke test set 21:56:43 i was gonna try to link the codeline but i cant find it right this second 21:56:44 imdigitaljim: are you still there? 21:56:44 imdigitaljim: yep, that's a good point, i will check if we should upgrade to 3.x 21:57:00 but basically its assuming a master node is labeled in a specific way 21:57:03 and its not even a good way 21:57:22 i think sonobuoy pulls from the kk e2e anyways so it might actually just be a bad kk test 21:57:44 so it skips like 100s of tests 21:57:49 based solely on that 21:58:29 imdigitaljim: do you have the name of the test? I didn't see anything in the logs about the label 21:58:41 yeah ill dig it up again 21:58:47 maybe I missed ti 21:58:51 imdigitaljim: i'm interested in too 21:59:04 thanks, when I run again I'll look closer 21:59:07 i could have totally missed something too so it would be good to find out 22:00:01 let's end the meeting then 22:00:18 see you next week everyone 22:00:47 #endmeeting