Nova Scheduler Team Meeting跟踪

[Yikun]

从今年开始，要细度每次的Nova Meeting了，确实对于整体把握整体社区某个领域的进度非常有用。我是这样设想的，按月汇总，每次一篇文章，包含以下几部分

1. 记录。按照meeting日期，记录主要内容
2. 总结。总结每次meeting的每次内容，简短的一句话或者一段话，避免流水账
3. TODO。每次meeting不一定能完全理解，把他们记录下来，学习后闭环。

1. 会议记录

2018年1月8日

2018年的第一个team meeting，我们可以看到重点的工作还是在Nested Resource Provider这个BP，在这个时间，大家还是希望能够把Nested Resource Provider这个BP在Queens版本完成。

(1) Feature讨论

1. Nested Resource Provider

• @2uasimojo(efried) 正在完成ComputeDriver.update_provider_tree() https://review.openstack.org/#/c/521685/
• @jaypipes 正在完成GET /allocation_candidates部分 https://review.openstack.org/#/c/531443/
  @bauzas 表示Xen可能是Nested Resource Provider最棒的目标用户。

@jaypipes

• 目前NRP的目标还是Queens版本完成，可以把NRP的report部分、candidates部分、xen作为client/consumer在Queens完成
• 而NUMA/PCI部分的工作，估计搞不定，所以意味着我们在Queens还是需要PciPassthroughFilter及NUMATopologyFilter
• driver consumption的工作会在Queens完成，包括driver通过update_provider_tree来上报信息给RP，也包括了从scheduler中基于allocation来做设备的创建和分配。

2. Alternate hosts

解决了一个bug/1741125 Instance resize intermittently fails when rescheduling
https://review.openstack.org/#/c/531022/

3. limit on allocation_candidates

dansmith增加了一个CONF.scheduler.max_placement_results，用于限制每次备选节点的请求，默认1000
https://review.openstack.org/#/c/531517/

(2) Open discussion

关于Resource Provider的genration id的讨论。

在随后的开放讨论中，由于Resource Provider的aggregate信息在更新时，会有在不同节点上的多个请求并发进行更新的问题，我们需要一种方案去解决race conditions。是的，就是我们在 #65 提到的方法。

@2uasimojo(efried) 提到，这种方案并不是进程或者线程的锁，建议按照原来的实现，给更新RP的aggregate加上genration id，用于解决并发下的竞态更新问题。
即在PUT的时候，用户需要传入genration id，这个id就是Get时候的genration id。这种方案看似有点土，我更新个字段还得自己传genration，太不方便了。
但是，却是一种很好的方法来解决从Get直到PUT入库中间的竞争。
大家对这点，达成了一致，另外，我们在更新rp的aggregate的时候，仅更新正更新的rp的generation，而不需要更新aggregate中其他rp的genration。

最终，决定让 @cdent 去做generations-on-aggregate placement microversion相关的patch。

关于conflict 409后重试机制的讨论

@2uasimojo(efried) 提出了这个问题，对于409的处理，一直不是很清晰，因为我们重试的时候，不知道到底应该是仅仅重试之前的操作，还是说再看看这个数据是不是已经更新之类的。

@jaypipes 说，发生409后，更新的调用者，需要回答一个问题“OK，我们需要更新的东西已经变了，在我进行重试时，检查一下我想要更新的东西是否已经更新过了”，所有的generation变化，只是表达了“something changed”，而不是“this thins changed”。所以在我们进行409的重试时，我们需要重读下所有的provider信息（比如traits、inventory等），然后检查下，我们想更新的东西是否已经存在了，如果是这样的话，我们什么都不做，如果没有，我们需要重新的调用update/set。
这个想要更新的状态取决于virt driver，和他希望做什么。（比如更新inventory和traits肯定是不一样的）。
总结来说，就是我们最初的设计：client-driven state retries，而不是傻傻的重试。

本次Meeting总的来说还是充满干货的，尤其是对generation和409重试的讨论。

2018年1月15日

(1) Feature讨论

1. Nested Resource Providers

NRP的进度没有太大进展，目前包含update_provider_tree和GET /allocation_candidates两部分内容。

2. Granular resource requests

这个是为了支持用户进行复杂资源请求的bp，最近会专门写一个文章记录一下其实现。

3. Alternate Hosts

目前这个特性基本完成了，相关Patch：
patch/526436 Change compute RPC to use alternates for resize

(2) Bug讨论

bug/1743120: placement inadvertently imports many python modules it does not need
这个bug主要是说Placement导入了很多不需要的模块，主要是和Nova耦合太近，不利于后面拆分，并且直接使用Nova的也不够简洁。所以，清理、化简，保持干净。

Open discussion

ProviderTree accessors

Patch在这里：https://review.openstack.org/#/c/533244
主要为了对比ComputeDriver.update_provider_tree和缓存在report client的ProviderTree的变化。抽象出来了一个结构ProviderData，专门来返回数据。

总的来说，本次Meeting的讨论内容较少，集中在Nested Resource Provider上面。

2018年1月22日

重要事件：1月25日，Queens版本的Feature Freeze即将到来。

(1) Feature讨论

1. Nested Resource Providers

目前还是包括update_provider_tree series和Nested RP selection两部分。update_provider_tree series接近完成了（不包括resource tracker端到端的上报），Nested RP selection，会推到Rocky版本。

2. Request Traits in Nova

Nova中支持请求traits，另外这个请求也额外的提到了Granular resource requests特性，有部分功能是重合的，后续分析Granular resource requests时候，重点关注下。

3. Use alternate hosts for resize

Alternate hosts这个bp已经基本完成，后续也需要学习下。

(2) Bug讨论

Remove microversion fallback code from report client

https://review.openstack.org/#/c/528794/ 在Queens版本，nova默认支持1.14了，所以移除了一些之前版本的兼容代码。

2018年1月29日

(1) Feature讨论

1. Nested Resource Providers

Provider Tree series部分的工作已完成，https://review.openstack.org/#/c/533808/
First provider tree patch in progress： https://review.openstack.org/#/c/537648/ 这部分是端到端的从resource tracker中调用driver的update tree，应该会推到Rocky去做
Nested RP traits selection: https://review.openstack.org/#/c/531899/ 没有什么进展
从开放讨论中，@efried 提到，想要端到端的使用NRP，需要完成三部分：a. Resource Tracker刷新update_provider_tree b. jaypieps的NRP in alloc cands c. driver实现update_provider_tree。这三项工作，都没有在Queens完成，不过都比较接近完成了。

2. Singular request group traits

基本完成

3. Granular resource requests

完整实现推迟到Queens版本，https://review.openstack.org/#/c/517757/

4. Use alternate hosts for resize

https://review.openstack.org/#/c/537614/ 已经merge，至此，已经可以支持resize时候的alternate hostsl了

(2) 开放讨论

1. Idea for a simple way to expose compute driver capabilities in the REST API

http://lists.openstack.org/pipermail/openstack-dev/2018-January/126653.html Matt提出希望用一种简单方法保持driver的兼容

1. 会议记录

2018年2月5日

(1) Feature讨论

目前已经Freature Freeze了，因此，对于BP来说，没有什么太多更新了，只是简单的罗列了下相关的Patch。
Provider Tree series starting with: https://review.openstack.org/#/c/537648/
Nested RP traits selection: https://review.openstack.org/#/c/531899/
目前，Nested RP的这2部分工作也不会在Queens版本合入了，会推迟到Rocky。

Granular resource requests review: https://review.openstack.org/#/c/517757/
resource和requeired分组的支持，API部分的PatchQueens版本未完成。

Remove microversion fallback:https://review.openstack.org/#/c/528794/
由于目前Queens已经使用1.14作为默认的microversion，因此，对于之前的一些兼容版本不会再使用了，所以对之前的兼容代码进行了清理。

Use alternate hosts for resize:https://review.openstack.org/#/c/537614/
Alternate hosts已合入，上面是补了一些test case

(2) Bug讨论

1. Generation及重试问题

Add generation support in aggregate association https://review.openstack.org/#/c/540447/
没有什么新的bug了，在之前讨论的aggregate相关的API增加generation的问题，cdent提了一个BP，会在Rocky版本完成。
placement server needs to retry allocations, server-side https://bugs.launchpad.net/nova/+bug/1719933
对于并发更新时的重试问题，还是有一些讨论，
@EdLeafe 认为，对于一些场景，请求aloocation时，用户认为有足够容量呀，不能够失败。
@jaypipes还是原来的意见：

it should "fail" in so much as a 409 Conflict is returned and allows the caller to retry if it wants.

也就是说，409肯定是要失败，重试的事情需要调用他的人来做。
当然，也会在PTG讨论下，generation到底怎么样去使用和暴露。已经把这个问题记到nova-ptg-rocky：Do we have a concurrency problem with PUT /allocations/{consumer_uuid} and/or POST /allocations ?

(3) 开放讨论

Placement queens summary https://anticdent.org/placement-queens-summary.html
Placement extraction https://anticdent.org/placement-extraction.html

关于将Placement抽离

@cdent 完成了两篇文章，一个是queens版本的placement总结，另外一个是cdent做的，关于将Placement从Nova抽离出来的一些工作。
关于将Placement抽离出来，大家发表了自己的看法：
@cdent 他认为，较早的把Placement分离出来，对于Placement和Nova来说都好，目前抽离的工作量比较小，好分离，另外，目前Nova投入的大量的时间和优先级放在Placement相关的事务上，分离出来，对Nova好一些。
@bauzas 不太同意现在去分离，他主要是担心Nova和Placement分离后，有点难协调。

2018年2月12日

(1) Feature讨论

目前的Feature的讨论，已经开始Rocky版本的了。

1. Support traits in Glance

https://review.openstack.org/#/c/541507/
这个BP主要是希望为Glance增加Traits支持，在Glance的Properties中，增加类似"trait:HW_CPU_X86_AVX2=required", "trait:CUSTOM_TRUSTED_HOST=required"的支持，让Placement调度的时候支持。

2. Resource Class Affinity Spec

https://review.openstack.org/543062
efried写的一个bp，看名字知其意，调度的时候考虑Resouce Class的亲和。

(2) bug讨论

Handle volume-backed instances in IsolatedHostsFilter：https://review.openstack.org/#/q/topic:bug/1746483+(status:open+OR+status:merged)
Matt发现了一个Filter的问题，主要是对volume-backed的情况进行一些异常处理。在Scheduler会议中，已经很久没有讨论过非Placement的问题。- -!

(3) 开放讨论

Add optional healthcheck middleware https://review.openstack.org/#/c/542992/
一个用于健康检查的midleware，对于API服务挺有用，尤其是对于LB场景下的检查活跃来说。
Feature的spec在这里：https://review.openstack.org/#/c/531456/

2018年2月19日

(1) Feature讨论

Glance image traits https://review.openstack.org/#/c/541507/
Resource class的亲和性 至少到S版本才会落（包括在Placement中支持NUMA亲和），优先级不高，提了下Placement RBAC的需求(Policy/RBAC support in Placement REST API)可能会更高一些。
update provider tree的优先级很高解决了很多问题

(2) Bug讨论

Placement returns 503 when Keystone is down https://bugs.launchpad.net/nova/+bug/1749797
Keystone挂的时候，Placement会返回一个503，这个问题最后是在keystone middleware里面加了一些detail信息: https://review.openstack.org/546108

(3)开放讨论

调度失败的"Nova valid host"足够了吗？
@arvindn05 这哥们提到在虚拟机调度的时候，我们仅仅返回了"no valid host"，为啥不503一个，然后返回为啥调度失败。
@EdLeafe 说了2点，503肯定不合适，错误是用户，不是系统。详细信息不显示是因为不想把底层的硬件架构拓扑之类的信息暴露给用户。管理员可以通过日志之类的看到失败原因。

2018年3月5日

PTG刚开完，没什么太多的事儿，jaypipes说了几点：

1. jaypipes会发一个recap总结下R版本的重点
   http://lists.openstack.org/pipermail/openstack-dev/2018-March/128041.html
2. 最开始的3-4周，都会集中在update_provider_tree系列的patch落地
3. 在Resource tracker刷新额外traits的合并问题需要讨论，可以在update-provider-tree完成之后去做

2018年3月5日

Feature讨论

1. Support traits in Glance https://review.openstack.org/#/c/541507/
2. Add placement-req-filter spec https://review.openstack.org/#/c/544585/
   这是调度流程的一个很大变化，这个BP源自CERN从v1升v2的一个需求，最开始CERN用的是Cell v1规模挺大，大概有上万个计算节点，原来的用法是：
   第一级调度：一个租户映射到指定的特定Cell中，一般一个Cell中也会把特殊硬件的计算节点集中起来，第二级调度：这样在Cell v1中通过租户找到的Cell，然后剩余的节点就不多了，然后进行第二级调度，调度在Cell内压力就小多了。
   但是目前Placement是一个全局的，并不能感知到Cell，也就是说最差情况，Placement过滤得不好，可能导致真正Scheduler的时候，有上万的节点，所以，就在Placment前面加了一个步骤Pre filter。目前的作用就是，把Placement做不到的，自定义程度很高的Filter放到这里来。
3. Forbidden Traits https://review.openstack.org/#/c/548915/
   required里面通过叹号来表示不想要某种traits
4. Support default allocation ratios https://review.openstack.org/#/c/552105/

2. TODO

1. 了解Idea for a simple way to expose compute driver capabilities in the REST API详细内容
2. Granular resource requests分析
3. Alternate hosts分析
4. Nested Resource Provider分析