21:00:42 #startmeeting containers 21:00:43 Meeting started Tue Aug 28 21:00:42 2018 UTC and is due to finish in 60 minutes. The chair is strigazi. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:47 The meeting name has been set to 'containers' 21:00:53 #topic Roll Call 21:01:03 o/ 21:01:05 hello 21:01:15 hello o/ 21:02:02 o/ 21:02:40 Thanks for joining the meeting colin- tobias-urdin imdigitaljim 21:02:56 #agenda https://wiki.openstack.org/wiki/Meetings/Containers 21:03:11 #topic Announcements 21:03:41 Magnum 7.0.0 provides certified kubernetes 21:04:00 thanks to flwang that pushed the results to cncf 21:04:14 * strigazi is fetching the path 21:04:14 awesome 21:04:18 :] 21:04:21 Congrats all 21:04:24 cool, nice work 21:04:45 #link https://github.com/cncf/k8s-conformance/commit/263ea91efef9f1decd3c5f5437ee704f0a1af261 21:05:16 FYI, magnum queens was passing the conformance tests as well, we just didn't posted the results to cncf 21:05:29 o/ 21:05:38 Now it is more official 21:05:42 hi canori02 21:05:46 are these just sonobuoy runs? 21:06:01 yes, nothing more nothing less 21:06:14 SUCCESS! -- 143 Passed | 0 Failed | 0 Pending | 853 Skipped PASS 21:06:26 i feel it a goal to improve the tests skipped 21:06:32 (if applicable) 21:06:58 it skips some tests when features arent present 21:07:08 some it skips with alternative configurations 21:07:10 so it depends 21:07:26 let's see if we can run more 21:08:29 anyways nice job o/\o 21:08:35 2nd announcement: magnum 7.0.1 is released, we will to more point releases in rocky 21:08:45 2nd announcement: magnum 7.0.1 is released, we will two more point releases in rocky 21:09:15 Of course we can do more later if we find bugs 21:09:39 #topic Blueprints/Bugs/Ideas 21:10:00 I have pushed the patch to put kubelet on the master node 21:10:08 looks good 21:10:29 And since I was trying to make it work with flannel on the master node 21:10:40 when flwang finishes his part ill be pushing any of my remaining changes 21:10:47 I proposed a patch for making flannel self hosted 21:10:54 similar to calico 21:10:54 :) 21:11:15 What is flwang's part? 21:11:19 on kubelet? 21:11:33 not on kubelet, he was working on some remaining changes i believe 21:11:41 ok 21:12:29 If the flannel patch passes the conformance tests, I don't see a reason not to take, it cleans a lot of files. 21:13:06 thoughts? ^^ 21:13:26 *take it in rocky 21:13:55 i can't think of anything about flannel that would prevent it from working in that way; sounds good to me 21:14:48 I like the fact that it doesn't mess with docker config a lot like before. let's take this discussion in the review: 21:15:02 #link https://review.openstack.org/#/c/597150/ 21:15:20 i'll take a look there 21:15:28 and two more items: 21:16:03 You can give input in flwang's patches for cluster health monitoting here: 21:16:20 #link https://review.openstack.org/#/q/status:open+project:openstack/magnum+branch:master+topic:story/2002742-24593 21:16:38 I posted sample output of some possible cases here: 21:16:57 #link https://review.openstack.org/#/c/572897/ 21:17:36 I think we can take it this week. We will just need a client patch as well. 21:18:52 And last item, is regarding upgrades, I haven't pushed the UTs yet but the API will not change: 21:18:59 #link https://review.openstack.org/#/c/514959/ 21:20:17 Next, I think tobias-urdin wants to bring up some items 21:20:29 sure 21:20:54 i've pretty much went through what i through is missing to make it easier to run magnum in production 21:21:19 magnum-ui is missing functionality, we cannot discover COE, volume drivers, network drivers etc 21:21:49 We adddress this issue by using public cluster templates ^^ 21:22:07 two other things I think is, two config options, one to select allowed coe engines and allowed volume drivers 21:22:13 same like was done for the network drivers 21:23:13 We have an option in magnum conf to enable only some drivers 21:23:27 for volumes, let me check 21:24:01 having something like glance implements, a discovery endpoint that then magnum-ui can use to populate causing it to not be hardcoded 21:24:12 i think would benefit a lot 21:26:02 For disabling COE's we have http://git.openstack.org/cgit/openstack/magnum/tree/magnum/conf/drivers.py#n40 21:26:08 another example would be swarm-mode completely missing in magnum-ui :) 21:26:31 and for ops we have magnum list-drivers 21:27:06 So, you proposal is to discover the configuration options with an API? 21:27:10 ok, how would the disabled_drivers look if specified? 21:28:01 magnum has these drivers enabled by default: http://git.openstack.org/cgit/openstack/magnum/tree/setup.cfg#n60 21:28:27 thanks 21:28:29 in the magnum controller node the admin can do: 21:28:35 magnum list-drivers 21:28:46 and see which are enabled 21:29:13 using disabled_drivers the operator can opt-out from using some of them 21:29:42 then that is exactly what i'm looking for, i then think that is something we should expose using API so that the UI can consume it 21:30:59 we decided not give the end users this option, one it adds complecity and second the clients don't need access to such low level info about magnum. 21:31:22 What we actually tried in the past was 21:31:38 to allow operators intriduce more drivers more easily 21:32:13 but continue to provide the users with public cluster templates 21:33:03 what we could invesigate is, having magnum-ui consume some of the configuration options in the magnum.conf? 21:33:23 magnum-ui may not always be on the same location as magnum.conf 21:33:37 yeah :( 21:33:38 imdigitaljim: 99% is not in the same place 21:33:41 so i'd say magnum-api should still provide it and ui consume it 21:34:02 by same please i mean even same machine* 21:34:31 I think end users should only consumes the cluster API 21:34:36 I think end users should only consume the cluster API 21:34:52 not the clustertemplate api 21:35:08 we also agree with that sentiment 21:35:25 we have modified our ui to only allow cluster creation and not template creation 21:35:34 the massive hole we have on the cluster template API is labels 21:35:37 not just by policy but we've simplified the ux 21:35:57 yeah labels are a feature-gate but eventually need to be turned into actual features :P 21:36:05 labels can not be consumed by the API atm 21:36:15 i think we should convert to consuming config files 21:36:29 have a config file map to a template 21:36:35 my users is mostly ui based, so we'll be doing the same, which is what i'm wanting to prevent 21:36:42 instead of openstack coe cluster template create --amillionthings 21:36:55 dont want to modify downstream, instead have it supported upstream the ways operators want to use it 21:37:16 we're looking for ways to make the new content upstreamable 21:37:24 but still just consuming it as downstream for now 21:37:41 tobias-urdin: if you provide users with public cluster templates? Doesn't this help? 21:38:57 yes but it doesn't address all pain points that the ui currently has, you never know which coe, volume/network drivers is supported (and recommended) by the operators 21:39:18 this is how simple our create panel is 21:39:19 https://imgur.com/a/Y7acH9X 21:39:39 but these parameters are not exposed in the cluster api 21:40:14 id like to add some kind of configurable traits to simplify the user experience on the ui 21:40:31 as an option at least 21:41:16 ours look like this: https://imgur.com/a/Sqk56Zw 21:41:20 i think we've come to the conclusion that we have something to look at atleast :) i'm very satisfied disabling drivers was possible, which i probably should have checked better myself 21:42:06 user need only to select the cluster template and the size of the cluster, flavor, num_nodes, docker-volume-size 21:42:23 s/user/users/ 21:42:59 when we are on the magnum-ui subject, i would like to propose a change to add swarm-mode to the hardcoded COE list in magnum-ui, backport it 21:43:23 https://imgur.com/a/xx5DnnO 21:43:23 and request a new magnum-ui release for queens to release that change and bug fix https://review.openstack.org/#/c/595245/ 21:43:38 we will do both 21:44:28 tobias-urdin: imdigitaljim what we discussed in the community before was: 21:45:05 have cluster template or another api object that operators use for configuration parameters and to set the allowed values 21:45:58 the end users would consume the cluster templates, fork them and edit them but being restricted by the operator 21:47:13 it required a lot of effort on the API and we lacked man power to do it. 21:47:31 which is fine and working good, i'm simply talking about the population of the fields for cluster templates 21:47:52 So, at least at CERN, we decided to have a set of supported Cluster Templates and tell users consume those 21:48:00 it's no big deal really, but a simple thing like the swarm-mode COE is not even present in the list there 21:48:25 advanced users that want more features should open tickets or experiment with the api. 21:48:49 tobias-urdin: swarm-mode should be there, we missed that. 21:49:16 which takes me back to :) 21:49:16 23:33 < tobias-urdin> when we are on the magnum-ui subject, i would like to propose a change to add swarm-mode to the hardcoded COE list in magnum-ui, backport it | 21:49:21 23:34 < tobias-urdin> and request a new magnum-ui release for queens to release that change and bug fix https://review.openstack.org/#/c/595245/ 21:49:50 please cherry-pick it 21:49:58 to rocky and queens 21:50:14 I'll approve and release 21:50:47 for swarm-mode propose a patch and will take it, backport it and release it 21:50:52 sounds good? 21:51:09 yeah, thanks 21:51:41 Anything else for today? 21:52:00 i have one more, unless somebody else have anything 21:52:12 tobias-urdin: where are you based? Europe? Sure, go ahead 21:52:33 yes gmt+1 21:52:58 Just my coreos patch for me. I believe I have the cert issue sorted out. Just need reviews again 21:53:03 i've been testing around to see what works, are there any support matrix COE vs OS version etc 21:53:16 kubernetes pretty much worked on first attempt, seems the most maintained 21:53:35 Fedora Atomic 27 works with kubernetes and swarm-mode 21:53:52 docker swarm is broken on fedora 27, etcd is not in fedora atomic but is run as container, which i saw a commit 21:54:05 os_distro=fedora-atomic coe=swarm-mode|kubernetes 21:54:27 docker swarm-mode on fedora 27 almost works, it's missing tcp port 2377 so minion node cannot join swarm cluster 21:54:47 is fedora 28 working at all? 21:55:04 it does 21:55:08 Works with k8s for me 21:55:19 to fix swarm-mode we need to push port 2377 for security group 21:55:22 here i think https://github.com/openstack/magnum/blob/master/magnum/drivers/swarm_fedora_atomic_v2/templates/swarmcluster.yaml#L244 21:55:27 got it 21:56:16 * strigazi is thinking how swarm-mode works in devstack 21:56:23 same there, would appreciate a backport for such a fix 21:56:30 +1\ 21:57:01 without even googling my guess is 2377 is TLS swarm endpoint and 2375 is non-tls which perhaps, unfoutunately, the testing uses? 21:57:22 2375 is behind tls 21:57:30 i added 2377 to sec group after I saw that was executed in the magnum-swarm-manager script 21:57:34 AFAIK 2377 is not 21:58:08 2377 is the default port for the swarm-mode inter-node communication 21:58:58 tobias-urdin: in your cloud, magnum creates a private network per cluster? 22:00:35 unsure 22:00:51 tobias-urdin: just push a patch for the security group and we take it. Just add a story in storybaord 22:00:54 think that example used an existing private network 22:01:18 we can take the discussion there 22:01:25 sure 22:01:28 anything else? it's time 22:01:48 sorry for the lengthy meeting, would like to be more involved in magnum but don't have the time currently :( 22:01:51 i have nothing 22:01:59 thanks for hosting strigazi 22:02:21 canori02: I haven't forgotten you, I'll leave comments in your coreos patch 22:02:23 yea, real thanks for clearing a lot of stuff up! 22:02:31 thanks colin- 22:02:46 Thnaks for joining colin- tobias-urdin canori02 imdigitaljim 22:03:04 See you 22:03:14 #endmeeting