13:00:52 #startmeeting senlin 13:00:53 Meeting started Tue Jul 18 13:00:52 2017 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:57 The meeting name has been set to 'senlin' 13:02:13 hello? 13:02:21 hi Qiming 13:03:23 hi, Ruijie_ 13:04:18 let's see if others are joining 13:05:16 Ruijie_, next week would be p-3 milestone, are you aware of any high priority bugs to fix? 13:05:49 no Qiming, the support for recovery action in lb policy had been done 13:06:03 great 13:07:08 Oh, another thing is about the deletion process of cluster recover action 13:07:14 that still need to be improved 13:07:36 okay 13:07:49 can we get that landed in this week? 13:08:09 I am afraid not Qiming ..:( 13:08:16 I don't have high priority work items before p-3 release 13:08:59 okay 13:09:16 have you submitted a talk proposal for the sydney summit? 13:09:26 I am with you Qiming :) 13:09:43 about managing clearwater clusters 13:10:14 I know xinhui and xuefeng have each submitted topics 13:10:30 elynn submitted one also 13:10:58 my top priority in the near term is about federated kubernetes clusters 13:11:09 I am not sure, xinhui, me and you are in the NFV: clearwater .. proposal 13:11:20 okay 13:11:44 I can do the poc job for that since elynn already submitted the VDU profile 13:12:01 I see 13:12:21 I'll be doing k8s + senlin integration 13:12:37 I know many of you have expressed interests in this as well 13:12:42 that's great 13:12:52 just not sure how to frame this work 13:13:33 I think elynn might have started looking into standing up vms with scripts for k8s install 13:14:13 hope you can sync that with us, that topic is interesting 13:14:16 I'm looking from the other side, getting it up and summarize what we can do to make things easy to reproduce 13:14:34 it is not a talk for the summit 13:14:49 I'm doing that for real-life workload 13:15:18 seems elynn has 15 minutes jet-lag from us, :) 13:15:20 Hi, sorry about late, just trapped in another meeting. 13:15:36 hello sir 13:15:47 we were talking about k8s on senlin 13:16:12 ooo, anything important I missed? 13:16:26 I think elynn might have started looking into standing up vms with scripts for k8s install 13:16:35 I'm looking from the other side, getting it up and summarize what we can do to make things easy to reproduce 13:17:20 I think XueFeng and friends are interested in this as well 13:17:57 Yes, XueFeng discuss this with me last week, and He said he could find some colleagues to help if available. 13:18:22 I'm still thinking about how to setup a k8s 13:18:50 Basically we will have two clusters, one for k8s masters and one for k8s nodes, right? 13:19:25 Am I lost connection again? 13:19:27 master node doesn't have to be a separate cluster, a cluster is needed only for HA setup 13:19:54 all the nodes belong to one cluster? 13:20:04 on master nodes, you install apiserver, controller-manager, scheduler, and dns 13:20:20 on all worker nodes, you install kubelet and kube-proxy 13:20:33 these are the basics 13:20:55 how do we distinguish the master and worker node if all in one cluster? 13:20:57 Ruijie_, I'm afraid not 13:21:10 Like scale up and down operations.. 13:21:12 if you do, we distinguish them by 'role' 13:21:43 Policies doesn't respect 'role' for now, I guess? 13:22:10 u r rt, elynn 13:22:47 and ... I don't see clear benefits having master node and workers live in the same senlin cluster 13:23:22 So your proposal is ... one master node and a cluster of worker nodes? 13:23:52 however, if we have a master 'cluster' and a node 'cluster', we will need to synchronize quite some things between the two 13:24:08 that is a dilemma 13:25:16 I'm still confused here... 13:27:05 basically, some network settings, authentication data should be shared from the apiserver to all kubelets 13:27:15 kubelets don't have to know each other 13:28:24 Okay, I got your point, from your perspective , make this as simple as possible 13:28:32 yes 13:28:58 Deploy a cluster, then user will get a k8s cluster later. 13:29:07 we can postpone advanced features later, such as tls bootstrap ... 13:29:21 But many details need to figure out. 13:29:26 yes 13:29:29 I think kubeadm is a good start? 13:29:40 kubeadm is very limited 13:29:58 it encapsulates too many things 13:30:09 but ... you are right, it can be a starting point 13:30:46 maybe just run 'kubeadm init' on master with a predefined token 13:30:50 That's only for tools part, we still need to solve how to share configuration info between nodes in a cluster 13:31:04 at the same time, run 'kubeadm join' on all other nodes with the same token 13:31:22 And how to pass it to user-data, etc... 13:31:50 em, right 13:31:57 Since only vdu profile in contrib folder support passing parameters to user-data... 13:32:12 I don't want to use any vendor specific tools 13:32:21 And also how to avoid deleting master node in cluster.. 13:32:49 cluster should be operatable if masters are gone .. 13:33:02 although no new resources can be created, :) 13:33:24 so ... ideally, master nodes should be a separate cluster 13:33:49 in the future we can even move etcd out to a third cluster 13:34:26 I know your concern, eventually we will have some scripts to setup k8s if that is ... I have enough time to implement such a script.. 13:34:30 then ... we will need the inter-cluster dependencies properly 13:34:46 oh really 13:35:22 Do you suggest we start from HA mode or just a single master node? 13:35:33 just a single could be fine 13:35:49 I was thinking about a kube-master profile type and a kube-worker profile 13:36:34 O? New profile? 13:36:44 Sounds good actually. 13:37:02 these kinds of nodes have a lot of things to do upon bare VM 13:37:17 implementation wise we can subclass Server 13:37:29 Yes, agree 13:37:52 this way we can quickly stand up something 13:38:17 and that "something" won't become garbage soon 13:38:30 And we can put them in contrib folder firstly? 13:38:46 we can gradually expose properties when there is a need 13:38:49 sure 13:39:28 ideally, here would be what you can deploy a k8s with senlin 13:39:29 Do you think what kind of properties we can expose for now? 13:40:33 openstack cluster create --profile master.k8s --count 3 my_master 13:40:36 Hi XueFeng 13:40:45 hi 13:40:50 elynn 13:40:54 hi, all 13:41:10 We are talking about k8s now. 13:41:16 openstack cluster create --profile worker.k8s --count 5 --metadata "master=my_master" my_workers 13:41:24 ok 13:41:41 Sounds doable. 13:41:47 clusters need to talk to each other? 13:42:16 workers need to know master's api 13:42:46 if you do TLS, you will need their key-pairs etc, you will need to know their cidr configurations etc 13:42:57 it is a one way depenency 13:44:11 em.. okay Qiming, that makes sense. How about the monitor for the workers? 13:44:20 I would suggest we expose those kind of configurations to properties, what do you think? 13:44:35 Just come back, sorry for late. Let me see the log http://eavesdrop.openstack.org/meetings/senlin/2017/senlin.2017-07-18-13.00.log.txt 13:45:13 monitors, loggings, kernel optimization ... etc can be added to the worker.k8s profile later 13:46:51 elynn, we can add properties one by one 13:47:32 if we expose a hundred properties at the very beginning, ... the framework will fall apart pretty soon 13:48:03 yes, yes 13:48:28 the challenge, though, is about the details 13:48:45 Speaking about monitors, that reminds me that we might need to control the sequence of scripts between workers and masters... 13:48:54 things work differently when you are using ubuntu or fedora ... 13:49:06 elynn, there is no such need 13:49:25 they will be able to "find" each other 13:49:25 Deploy master -> deploy workers -> deploy monitor yaml on master ? 13:49:55 oh, no 13:50:21 don't introduce circular dependency 13:50:32 we have to do this in one pass 13:51:05 if you want monitoring, deploy it with your master components on master nodes 13:51:25 or you can add them later by upgrading the master node cluster 13:52:20 The devil is in the detail.. 13:52:25 yes 13:52:43 I can record it in my notes and think about it later. 13:53:01 So we will add kube-master profile type and a kube-worker profile? 13:53:11 For image, I would suggest we start from ubuntu? 13:53:55 Details again, how can we limit the image they used...like os version, 14.04 or 16.04... 13:53:56 agree 13:54:10 don't want to reinstall my local machines, :) 13:54:50 the most annoying thing is about os distros 13:55:16 I believe we can start from one of them say ubuntu16.04 13:55:29 then extend to other distros later 13:55:39 I think the docker deamon version is limited 13:56:02 most version above 1.12 should work 13:57:28 For vm 1404 is not suggest to support 13:57:37 ub14.04 13:57:49 yes, it is ... history now 13:57:59 So first support in 16.04 is ok 13:58:41 .....just change to 16.04 these days .. 13:58:52 there are more to design/implement regarding network and storage 13:58:57 Silently shutdown the VM in script if we don't support it ;) 13:59:10 hahha 13:59:36 I can do some work if needed 13:59:53 alright 13:59:56 About network and storage, what do you suggest? Qiming 13:59:58 time's up guys 14:00:00 thanks for joining 14:00:05 Okay... 14:00:06 pls switch to #senlin 14:00:10 #endmeeting