介绍一下就是我是尼蓬菲实际上在很早之前就开始做KBIS社区的贡献了然后像之前的话在Signo的在Network然后包括collab provider做的contribution比较多然后我在github上面的话也有一个开源的那个handbookKBIS的handbook然后大家如果要找我的话可以在github上面找到我好 接下来我们就开始今天的正式的内容然后在首先的话就是我们先来看一下What and Why就是什么是collab provider以及为什么我们在KBIS社区里面需要collab provider通常我们在听到collab provider这个词的时候我们可能大部分情况下说的跟我今天要讲的这个topic是有点不一样的在通常在各种关于云的report里面或者说讨论里面我们说到的collab provider实际上更多的是指的云提供商也就是包括像Irla, AWS, Huawei 云, Ali 云这些在内的各种各样的云平台然后这些云平台的话实际上现在也是在KBIS作为一些最主流的一个运行的平台当然也包括像BioMeta这些那个物理就是私有的这些环境在KBIS社区里面的话我们也有一个collab provider对应的话也有一个segcollab provider专门去负责collab provider这个组件在KBIS作为KBIS的一个组件的话collab provider实际上主要负责的就是把 Kubernetes 和下面的云提供商作为一个胶水层把它们连接到一起然后这样的话就变于KBIS来去更好的利用云提供商的一些功能就比如说你去创建一个 Kubernetes service 的时候可以到云提供商上面去创建对应的负载军航器然后配用对应的健康检测的探针然后collab provider的话实际上现在主要在两个组件里面这个是可配的就是一部分可以你把它配到库不control manager 里面也可以把它配到cloud control manager 里面这两个不同的话我们接下来还会继续介绍然后接下来就是我们为什么在KBIS市区里面需要这么一个collab provider这个组件这一块实际上最主要的目的就是像我刚才提到的就是为了更好的去利用云的功能然后让KBIS用户可以通过KBIS的标准的API去直接跟底下的云提供商的功能进行交互然后并且可以把云提供商各个不同的API抽象起来通过统一的KBIS的API去跟他们进行交互然后在collab provider 里面实际上最主要的就是四个控制器包括note, note, lifecycle, root和service 这几个控制器这几个控制器主要是负责管理这个节点的生命中期然后包括网络的路由的配置以及包括负载运行器的配置接下来我还会再继续展开然后刚才提到实际上在collab provider 这边我们可以把它配置在两个不同的组件里面一个是cube controller manager一个是collab controller manager然后cube controller manager的话实际上这一块就是我们通常把它叫做intree就是collab provider 的代码会编译到KCM的它的binary 里面去然后这样你在部署的时候只需要通过一个配置选项就可以把它打开了然后collab controller manager的话实际上是后来抽出来的相当于把前面提到的这四个控制器从KCM里面摘掉 摘出来形成了一个新的组件这个组件叫collab controller manager然后因为它是一个新的组件然后它的binary跟KCM完全解药了然后并且它的repo也不在KBi4的repo里面了所以我们通常把它称为AutoTree然后除了这两个组件实际上还有一个cube lid里面它也编译了一部分的collab provider的功能这部分功能实际上也是跟着KCM和CCM走的就是如果你用CCM的话实际上cube lid里面的collab provider你都不需要了你可以把它关密掉或者说你不给它配collab provider然后如果用KCM的话一般情况下还是要打开cube lid的collab provider的功能然后cube lid里面实际上最主要的功能的话也是cube lid的功能力部分就是负责节点自身的处置化然后在这边的话实际上collab provider的话他们最主要的功能就是实现collab provider的interfaceinterface实际上就是一系列的够的接口然后每个collab provider可以有选择的去实现全部或者一部分的功能然后根据自己的云提供上的状况去做相应的功能的集成然后说到这个out of trade的话实际上在整个KBIS社区实际上大家如果接触过的话我们KBIS这边很多的组件都在做out of trade的migration这个实际上最主要的就是把我们很多的功能从KBIS最核心的代码桑枯里面解偶出来这样一部分可以更好的去维护KBIS最核心的代码然后另外一部分的话可以让KBIS自身跟各个公有云的具体的实现去解偶像很早之前我们KBIS里面很多的功能跟GCP是偶合得非常紧的然后在之前可能跟Docker的功能实现比较紧的所以像现在这些像GCP 像Docker可能Round Time然后包括之前的很多的这个volume的实现了然后现在全部都迁移到了out of trade的模型里面所以现在有了各种非常丰富的生态就从存储到可能Round Time再到今天讲的collab provider实际上有非常非常多的生态就出现在了这里然后每个人每家公司都可以根据自己的情况去实现自己的想要的功能所以这个就可以其他的促进整个客人社区的繁荣OK然后接下来再来说一下就是out of trade的状态这里就是只是提一下collab provider这边的一些功能然后像Storage像刚才说的couplet可能Round Time这些的话大家可以到社区里面再去看一下collab provider这边对应的话实际上在1.221.23的时候就开始加入了几个fetch gate这几个fetch gate的话这两个fetch gate的话实际上就是为了把collab provider它的功能从couplet maintenance binary里面把它给禁止掉一个的话是dcbalcollab provider就是把intrade的collab provider禁止掉他们的代码他们的控制器就不在couplet control manager里面运行了然后第二个的话实际上是couplet的一个组件把couplet内置的credential provider给禁止掉这两个fetch的话到1.29的时候也就下一个release里面的时候他们会进入batter状态进入batter状态之后意味着这两个fetch gate默认就会打开的所以从1.29开始的话out of trade的模型就是kbis最默认的行为然后这个时候是这样如果说大家还没有做out of trade的migroson的操作的话我觉得现在可以准备开始计划起来了然后对应的就是intrade的代码的话也会在接下来release里面就是慢慢地把它们移除掉像openstack在1.26的时候已经删除了然后aws的话在1.27的时候删除了然后还有像irre、gcp然后还有wisfire这些couplet provider也会在接下来的release里面去删除掉然后这边也对应着在社区里面有对应的cap to check这些out of trade的migroson然后实际上就是这些运提供上对应的coupletcontrol manager的实现都在不同的report里面然后这些report的发布都完全进入了接应的状态就比如说在irre上面我们couplet provider irre的实现已经很早之前就接应了然后并且已经在所有的aks的机器里面默认打开了所以大家实际上可以放心地把intrade的couplet provider的功能迁移到out of trade上面来OK前面是简单介绍了一下就是什么是couplet provider为什么需要couplet provider接下来我们再来看一下couplet provider到底做了什么事情首先还是先来看一下就是couplet provider它在couplet provider的各个组织里面它是一个什么样的状态然后因为couplet control manager实际上是到1.29开始就变成默认的行为了所以接下来的介绍的话我就以CCM为例去介绍然后intrade的话后面就不再展开了couplet control manager实际上刚才提到这是从CCM里面摘出来的一些控制器所以在部署的时候实际上你可以认为它是control plan的一部分通常推荐的话就是可以把它跟KSM一样采用完全相同的这个部署方式部署在控制品面上然后同时的话也要像KSM一样给它们配置多个副本然后打开lead election保证它的高可用当然实际上这个只是一个最佳的时间的推荐就是couplet control manager实际上可以作为一个普通的pod运行在任何的地方所以这个只是一个时间的建议同样的话对于couplet这边的话就是用了CCM的话实际上它的collaborator实际上就可以不用开了然后couplet这边的credential provider实际上也有out of trade的实现out of trade的实现应该是在1.28的时候也接应了所以对于intrade的collaborator的话都可以禁止掉了然后接下来就是再来分别看一下这几个control它们到底是干什么事的首先第一个的话是note controllernote controller的话实际上一开始是运行在couplet里面的然后后来把它们抽出来的时候就跟note life cycle跟其他三个control一样把它迁移到了CCM里面来然后这个control实际上最主要的功能就是负责更新这个节点的状态包括这个节点一些metadata的触触化就比如说它的provide ID这个节点的appd值然后它的hostname它的zome它的region这些都是在节点触触化的时候把它更新到节点的状态里面去然后特别是provide ID通常是用来在云平台上唯一的标志这个节点然后这里面实际上有两个比较重要的label就是一个是region一个是zomeregion和zone的话实际上不止在节点上面使用在高可用的时候跨region的高可用的场景里面实际上是特别有用的包括你去调度这些有状态的用用包括去调度PositionVolume它们都会依赖有这些label然后在旧的版本里面实际上还有两个label它们对应的是beta的label所以在为了方便大家去做migration从旧的版本迁移到新的版本里面在ccm的collaborator里面有一个对应的cool它可以帮你去实现这个从旧的label自动的迁移到新的label上面来然后前面收到out of tradeout of trade实际上对应的就是有一个点就是刚才提到的可以让各个cloud去实现自己的想要的逻辑这里就比如说我们看一下在adder上面实际上note controller的实现跟在aws上面它就有一些不一样的地方这里对应的社区里面也有一个cap 2328然后在adder上面实际上我们在大规模集群的时候实际上经常碰到的一个问题就是假如说我同时创建5000个节点5000个节点同时去触触画触触画的时候他们会同时去调adder的API去查询这个节点的一些基本信息这个时候adder的API就会很有可能会被sortledsortled之后的话你接下来就需要重视所以如果说这个重视发生的比较多的话就可能会把你整个集群的创建的过程会被拖慢所以我们这里做了一个优化就是我们把note controller从CCM里面摘了出来然后把它放到一个单独的组件里面这个组件我们叫clad node manager它是做一个diminsight跑在每个节点上摘出来的一个好处就是它可以去直接去调用每个节点本地的incense method service去查询这个节点的基本信息这样的话它就避免了去调adder的API然后从而实际上也就没有了sortled的问题了所以这里就是一个简单的例子就是在outer trade migration的时候实际上每个control的具体的实现的话可以集合自己云的实际的情况去做对应的定制的开发和优化然后这个像clad node manager比如说你在AWS上面或者说在GCP上面它们可能就没有这个control了就是它们有其他的方式去解决类似的问题第二个控制器的话就是note lifecycle controller这个实际上主要是控制节点的一些状态跟云提供商上面的训练机它们状态之间的一致性就比如说我的节点我的VM在云平台上面删除了删除了对应了note object在KBase里面也应该被删掉所以就是这个control去把它删掉然后同时的话如果说一个节点被一个VM被关机了关机了之后这个状态对应了也要反映到KBase node上面来这边就对应了一个shutdown的tint然后note lifecycle controller就可以把tint加到这个节点上面来然后实际上如果说你看最近的这个1.28的release的话1.28release里面还接了一个非设叫non-graceful node shutdown也就是说我在shutdown的时候实际上它有一个graceful shutdown和non-graceful shutdowngraceful shutdown的话就是couplet它能检测到这个节点正在被关机couplet可以做pod eviction可以把这个节点上的容器去除掉然后调度到其他健康的这个节点上但是有很多情况下这个节点的关机状态是couplet没法控制的所以这个只能在外部来检测在外部来检测的话实际上就是叫non-graceful shutdownnon-graceful shutdown一个推荐的做法就是你可以去检测这个节点它是不是关机了如果是关机了的话这个时候你应该去触发pod的eviction同时的话对于像这种有状态的应用的话你应该把它的volume从这个节点上detach下来然后调度到其他健康的节点上面来所以这边就对应了另外一个可以在collaborator里面实现了就是可以把整个的过程把它给自动化了但是你看KBAS的文档的话实际上它并没有提到这一点就是可能更多的可以就是靠用户管理员可以到节点上面加上一个tent就是out of service的一个tent然后有了这个tent之后KCM这边它会监测这个tent的状态然后同时去开始pod的eviction的流程所以像这个过程其实你就可以在ccm里面把对应的逻辑来实现了因为这里面实际上最关键的一点就是你要去检测这个节点的状态是什么样子的在云平台上是不是关系了是不是应该触发eviction的操作然后第三个控制器的话就是root controllerroot controller实际上最主要的目的的话就是顾名思义创建在云平台上创建路由就比如说我们在这个控制器实际上跟那个CNN插件它的实现是仅有何的就是比如说你用了云平台提供商的这些跟它的虚拟网络直接集成的这些CNN插件的话这个路由通常情况是不需要的比如说你用adderCNNadderCNN它可以让pod直接从adder的vnet里面去分配IP地址这个时候你就不需要去创建这个路由但是如果说你用的不是它你用了像linkbridge像以前那个比较早期的就是在linkbridge够建的这个CNN插件的时候它就需要在每一个节点上有这些pod set的路由这个路由的话如果说你没有开启root controller你就需要在每一台note里面去手动的创建linux的路由而现在有了root controller的话你就可以在同一的云平台上去创建这样就避免了去更新每一个节点内部的路由OK然后还有最后一个这个路由最后一个control这个control实际上是整个collaborator里面然后它的功能特性作为丰富的一个control但是它的最基本的功能实际上是比较简单的就是看到kbass里面是不是创建了一个service它的类型是load balance如果是的话那么它就去找对应的云平共商在上面去创建一个负载军用器然后同时的话给它分配相关的公网IP配置安全组然后配置安全检测的探针等等然后这一块实际上它的功能丰富主要是因为负载军用器在云平台上实际上是一个功能非常复杂的一个产品这个产品它可能会有各种各样的不同的特性功能特性然后这些功能特性的话通常我们在kbass里面通过service annotation的形式把这些功能特性暴露到kbass的IP上面来所以你无论是用哪一个共云的collaborator实际上它的文档上面都会提到它们有一系列的annotation然后这些annotation就可以用来去定义你的load balance想要的一些行为所以对于service来说它的实现实际上是跟云平台的实现具体的实现的话是紧密相关的就是你在一个云平台上面的这些annotation难道另外一个云平台上面去的话有可能是完全不剩下的所以说就是在我们比如说我们在使用多云策略的时候我们在不同的云上面有不同的service去部署的时候它们对应的load balance的annotation可能是不一样的OK 收了这么多的控制器接下来我们再看一个就是把它们集成到一起的一个例子就是这些控制器它们都是异布的它们到底是怎么样去在kbass里面来工作的这边的话就还是以刚才的airer为例因为这边实际上多了一个组件叫collar node manager然后就是我们开启了这个out of trade的collar provider之后的话然后cublator这边它在创建几点的时候它会带一个tint这个叫collar provider uninitialized tint这个tint用来标志说我这个几点已经注册到kbass的controlling里面了但是我的collar provider还需要做进一步的触触化也就是刚才提到的note controller还需要做一些触触化同时的话在几点刚开始创建的时候很有可能它的很多的状态没有ready的就比如说它的CNN插件可能这个时候还没有部署然后这些的话实际上都是一个几点最一开始的not ready状态所对应的一些note condition然后这个几点一旦注册到了几点里面后然后对应的很多去握持这个note的控制器就开始工作了就包括cub controller manager那个schedule这些就会触发比如说像这种diminset的pod它就开始调度到这个几点上当然这些diminset的pod首先要能容忍这个几点是not ready状态的就比如说collar node manager它是通常的话以host network的方式来跑它不依赖于这个声音插件它就可以调度到这个几点上然后的话再去调insent metadata service拿到这个几点的基本信息进一步的话就是做几点的触触化触触化完成之后刚才collar provider initialize the tent给删掉了同时的话在control plane这边collar controller manager它实际上也会坚持到这个几点的状态然后比如说我给它配置了要分配一个podtheader有了podtheader之后root controller就开始给这个几点创建一个路由这个路由创建好了之后就会给这个几点更新它的网络的ready的状态这个condition变成ready了然后接下来的话就是还有CNN插件我们比如说用CLIM 用calicola这些CNN插件它们也是一个diminsight的形式跑在明个几点上这些diminsight pod在这个时候也会调度到这个几点上然后它们就开始取触触化CNN插件CNN插件触触化好了之后cublate监测到说我CNN的banner rapeCNN的配置都已经有了然后cublate就会更新它自己的状态变成这个network的pluginready的状态然后等到所有的这些步骤全部完成了之后这个几点才会变成ready的状态然后其他普通的pod这个时候就可以调度到这个几点上面来了然后这里其实还有一点就是假如说这个几点不是唯一的几点可能前面已经有很多的几点了在这个机型里面已经创建了很多的这种low balance type of service这个时候来了一个新的几点之后clad controller manager他还要干一件事就是他要看一下这个几点是不是加到了LB的back and pull里面如果说它不在里面的话那CCM就会把它加进去加进去之后后面再来了新的pod来了新的网络的请求就可以把对应的请求转发到这个几点上面来所以这就是一个这几个controller他们一起跟cublate跟CNN插件整个完整地控制这个几点的一个触触化的一个过程接下来一个就是service的创建service创建的话其实刚才提到就是它在不同的clad上面它的实现是差别最大的一个地方然后在不同的云上面它的功能特性实际上也是差别非常的大这里的话还是以arrow为例的话就是介绍一下我们在创建或者是更新一个low balance service的时候它的流程是什么样子的首先的话还是这里有两个所以尤其是个ELB和IELBELB的话就是代表有公网IP的这种load balance叫externalELBIELB的话就是internalELB就是它对应的分配一个内网IP它没有公网IP的然后这在arrow上面实际上对应在两个不同的load balance的results所以这里有两个虚框一个虚框就是负责配置ELB一个虚框是负责配置IELB然后用户这边去创建一个load balance的类型service之后首先我们会先看一下我们要选择哪一个ELB选中了这个ELB之后然后比如说它是ARB是external类型的接下来我们就给它创建一个公网IP然后拿着这个公网IP到ARB上面去配置配置它的负载均衡的规则健康检查的碳针然后还有这个ARB的backend pull所有这些配置好了之后这个ARB的话它的配置实际上就完成了当然在arrow上面实际上我们的backend pull还有两种不同的类型就是它可以是网卡的reference也可以是极点的IP地址这里实际上也都是用户可配的等到这个ARB配置好了之后接下来我们会配置它的安全组就是让外网可以通过公网IP访问这一个public IP接下来就是我们在service上面实际上还有很多的annotation比如说你加了一个annotation我要同时给这个ARB创建一个privalling service那这个时候我们就会继续在这个ARB的基础如此上创建一个privalling service到这里的话就是假如说是一个新的service创建的话实际上这个时候这个节点就会走到最后一步update service data把这个service.ip更新到它的状态上面来然后我们这里实际上还多了一步就是因为一个service有可能不是新创建的它有可能是一个旧的service比如说我通过annotation把这个service的状态从ARB切换成了ARB的类型然后这个时候的话或者反过来我们可以从ARB的类型切换到ARB的类型在切换完了之后我们会首先去按到刚才的流程配置ARBARB配置完了之后ARB上面的这些规则实际上还在那里的所以就有了我们最后这个虚框我们要到ARB上面把对应的这些规则给清理掉然后这个时候就会选中ARB然后把上面的负载均衡器的规则它的frontend IP configuration然后它的backend pool这些东西再给清理掉所以这里的步骤就多了一点OK 实际上刚才我提到就是我们在各个不同的云平台上面有非常多的丰富的功能然后这个在Adder上面实际上也不例外我们在Adder平台上也提供了非常多的这个功能然后就包括CCM的实现的话实际上刚才也介绍了就是我们这边有一个collared node managerdiminside运行在每个节点上然后这样在触触化的时候我们可以避免去调用很多的RAP减少这个srl认定的问题然后我们的AdderTree的实现从1.21开始就已经接应了所以就是包括在AKS在内我们很多的集群默认都已经吸换到了AdderTree的model上面来就是无论说你用AKS作为managed service还是用collared API的这个实现实际上现在默认都是使用了AdderTree的collared provider然后我们也有官方的一个文档上面列出了就是怎么样去配置collared provider怎么样去自定义loaded balance的各种行为然后因为所有的这些东西实际上都是在一个AdderTree的model上面来所以我们做到这些秤的不需要去改这个KBS是最核心的代码我们的release然后包括平时的BugFix也好都可以跟KBS的发布完全交的所以AdderTree的一个好处就是我们所有的这些collared provider的实现就可以跟KBS的release结合你不需要等着KBS这边release比如说他那边可能要四个月有一个release在CCM这边你可以根据自己的需要发布的可以更频繁一些然后在接下来的一些release里面我们这边还会有很多的新的功能特性包括IP-based SLB然后包括在同一个机型里面支持用多个loaded balance就是多个ELB然后还有HealthProb的优化然后ConnectionJoin然后还有通过delete NoteObject去delete它底下的ARRE的VM然后它的存储这些资源等等OK然后前面就介绍了就是collared provider这边他们内部到底是这些control他们干了什么事情然后还有就是这些control怎么样跟其他的像coblate这些核心的组件一起去控制整个机型里面的这些results的life cycle然后接下来的话我们再来看一下就是CCM的operating首先第一个就是实际上在前面也简单提了一点就是怎么样去运行CCMCCM的运行的话实际上要说简单实际上就挺简单的就是你可以把它等同于这个KCMKCM怎么部署的这个CCM实际上就可以怎么部署都可以把它们部署到这个控制品面上比如说作为这个static pod然后在比如说你有三个控制级点每个控制级点上跑一个然后给它们开启这个lead election然后如果说你想要实现这种跨的重的高可用的话你可以把这些副本跑在不同Zone的这个级点上然后这样的话在一个Zone出问题的时候它可以通过lead election切换到另外其他的这个健康的Zone上面这里需要注意的一点就是假如说你是通过这个Demonside或者通过deployment的方式来部署这个CCM的话那CCM的话就是因为它跟像CNX件跟其他的系统里面的一些组件它们是有相互依赖关系的就比如说那个CNX件有很多的CNX件是依赖于这个级点的状态才能去做处置化的如果说你的CCM部署依赖于CNX的处置化的话那就会出现一个死死的状态所以说在CCM部署的时候一定要能够容忍这个级点处于not ready的状态通常的话也要把它运行在host.net那个模式下让它不依赖于这个CNX件的处置化这样的话就是假如说用户后面用了这些依赖于这个级点状态比如说这个级点上面的这个Zone啦或者说级点上面的这个partsade啦这些状态的时候它们就不会有这个死死的问题然后第二个的话就是怎么样从intrade KCM的这个collab provider迁移到outrade KCM的collab provider然后这个迁移实际上也是比较简单的就是实际上最主要就是去改一下我们现在已经部署的这些组件的几个配置选项一个是cubelit上面你可以打开collab provider配置成Ectonal原来可能是GCE啦或者是IZR啦现在把它换成Ectonal这个这个换的过程的话实际上就是去每个cubelit的那个配置去改一下这个配置配置选项然后第二个的话就是KCM这边KCM这边一开始是配了collab provider现在实际上就不虚了你可以把这个collab provider这个选项给删除掉或者说像cubelit这样你配成Ectonal也可以第三个的话就是去把CCM这个component的部署起来它的部署的话实际上跟KCM是类似的就是你可以作为demonset啦或者说deployment啦或者static pod啦把它运行到这个controller接点上然后这里有一个注意的地方就是CCM它需要去操作这个集群所以说它要有对应的这个upback的这个权限包括这个service啦级点的啦要有对应的这个读写的权限然后最后一个需要注意的就是要打开这个lead election然后这个lead election的话实际上如果说你是在线迁移的话然后还可以介绍于kbs社区里面我们提供了这个lead election的迁移的这个机制去把它保证这个lead election的功能在整个迁移的过程中间也不中断这一块的话在kbs上面也有一个完整的操作部署的文档就是大家在操作的时候可以去参考一下然后再接下来的话就是这个怎么样去build一个新的CCM实际上现在开放社区里面我们现在这些主流的公园平台都有这个CCM的实现其实大家去参考一下这些公园的实现就可以大概知道这些CCM到底是怎么实现的这边其实在社区里面我们有一个基础的库就是club provider的这个library这个library里面一方面包含了这个club provider interface前面一直提到的这几个control在社区里面提供了对应的这个interface然后这些interface里面其实每一个都是可选的大家可以根据自己的需要去实现相应的接口然后对应的library里面还有每个control的实现包括前面提到的四个control在report里面都有的你可以根据需要把它们看看是不是要打开或者说参考它们实现自己的controlOK 这里面就是有一点需要注意的就是这里intense API它有两个一个是intense一个是intense V2intense API实际上是很早以前我们还有那个绝大部分的club provider的实现都是intred的时候定义的一个interface然后后来我们在这个迁移到out of trade的时候我们发现这个接口它的实现的话不是特别友好所以后来我们又增加了一个intense V2的interface所以说后面我们去做这个CCM的时候就是实现intense V2的接口就好了但实际上这个不是必须的就是在我们的control里面实际上我们会检测这个实际上还是为了保证跟就的版本的control的实现兼容性我们会检测这个interface是不是实现了如果实现了V2这个interface然后我们就走V2的interface去操作这些基点但如果这个基点没有时间的话默认的话还是走的intense API对 这个就是一个可选的但是推荐的话大家还是用这个intense V2的这个接口这个接口用起来会更为方便一些OK 前面就是我就是collaborator这边的一些最主要的一些功能最后的话就是作为一个开源社区我们欢迎大家对collaborator这边各种形式的贡献包括去参加我们社区的会议我们有一个by weekly的一个meeting然后大家可以有任何的想法可以到社区会议上去提出来然后如果说你具体用了某一个具体的collaborator比如说collaborator 埃瑞拉或者collaborator 阿里云拉然后我们在同样的一个weekly page上面也列出了各个不同collaborator的一个think of the meeting这个meeting通常是monthly的然后你可以也可以到这些对应的meeting里面假如说你有些问题或者有些feature request可以去提然后第二个的话就是在代码上在report上面欢迎大家去发现了任何问题可以去到get them and去开对应的e-sale如果有大家有任何的feature request有功能的需求可以去提对应的feature request或者去参与讨论我们现在一定有的这些cap然后我们现在有很多的e2e的测试现在也在进一步的增强特别是我们要把e2e的功能跟具体某一个collaborator的实现进行解偶所以这一块我们后面还会有很多的work去把e2e的功能进一步的增强最后的话就是我们这边的文档实际上在不同的collaborator上面它的文档的往善程度也是不一样的也欢迎大家在碰到了各种文档写的不完善的地方可以去把这些问题提出来或者说contribute的去把这些文档进一步的往善好的 今天就到这里谢谢大家