OpenStack Summit Vancouver 会议纪要

我主要在温哥华峰会关注了Design Summit Operator Track的内容，纪录了整个会议各类相关主题的讨论，

有一些是我参与的，有一些的翻译的会议纪要（难免有理解错误和疏漏，请多包涵）。

Ops-101

1. Operator会议和面向developer的Design Summit合并，从此，Design Summit有两个Track，Operator Track和Developer Track。

2. 大多数人觉得认可，就是Sessions太多，听不过来。

3. 社区面向运维的github：https://github.com/osops

4. 社区面向运维的mailing list：

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

5. 社区面向运维的IRC channel：#openstack-operators @ freenode

 

Federation - Keystone & other - what do people need?

1. 计划内讨论

（1）将glance的镜像进行共享？同意，但是这个似乎和Federation没关系，也许我们可以通过HMT实现（Hierarchical multitenancy）

- 是共享还是同步？同步（复制）不是讨论点。

- 多个云之间还是AZ之间，还是Region之间？答案是所有可能的情况。

（2）Kerberos或X509认证不是可以工作了么？Horizon支持X509？CLI支持X509？有人回答：支持。

（3）Barbican支持？

- 让运维人员部署他们的Barbican，统一管理secrets是合适的，一个公共的Barbican，比如，像私有云的Barbican请求一个密钥，然后把它用在公有云上。

- 确实，如果客户拥有私有云和公有云，我建议将密钥管理放在私有云内。在这种情况下，如果我想要在公有云上使用一个加密的卷，我会通过公有云的Barbican访问私有云的Barbican，然后获取密钥。

- 这个是我们的想法。

 

2. 定义Federation和Federating

（1）让外部用户可以访问内部资源

（2）在domain间共享资源

（3）资源混合使用和匹配，使用不同OpenStack云中的资源，比如，将哈佛大学资源池中的一个云硬盘挂载到麻省理工资源池的一个云主机上。

（4）Identity Federation提供了一个平台，允许各类不同云间的对象互操。

 

3. 投票调查

（1）谁已经在使用Federation了？有哪些场景？

- 正在尝试提交一个新的OpenStack项目，Mercador，用于Service间的Federation。

- CERN内部正在评估和测试，会和Rackspace一起。

（2）Federation的痛点有哪些？

- Projects间的命名空间管理

- 匿名化，当使用Reseller模式时，有多少信息可以从Reseller透露给服务商

（3）non-web Federation

- OpenStack Client支持

- Keystone开发库，keystoneclient和keystone-auth

（4）https://blueprints.launchpad.net/keystone/+spec/idp-metadata

（5）共享属性的合法限制

 

4. 运维工作流和问题陈述

（1）连接到新的云上，任何开启service-catalog的OpenStack服务都能自动配置其资源。

- 比如Heat模板？

- 这个功能是否要求Heat能支持multi-cloud？

- 不需要，只要求master-cloud实例（私有云实例）能够感知到multi-cloud，Heat不需要部署到所有云实例上，Heat需要获得远端cloud的catalog。

（2）quota管理能够感知multi-cloud

（3）multi-cloud的审计

 

5. 用户管理

（1）如何管理domain以外的用户？

（2）如何在登录时限制用户？

（3）https://etherpad.openstack.org/p/YVR-ops-customer-onboarding

（4）我们如何能够保证Keystone的账号与企业IT认证体系关联（比如Windows AD），但是我们又不允许用户直接获得企业IT的认证信息，从而直接访问操作系统？

（5）如何重置非法的token？

- 如何资源正常使用，会有哪些影响？

 

6. 命令行，工具等

（1）如何与这些工具有效地集成？

（2）OpenStackClient项目与keystone合作密切，实现了X.509和Kerberos。

- 需要CLI工具去创建relationship

 

7. 与其它的非OpenStack的云互联（结成联邦）

（1）如何才能让一个OpenStack私有云其它非OpenStack云结成同盟？

- 首先，SAML在很多场景下被使用；在Paris就已经有了与AWS同盟的demo了；在这个情况下，OpenStack云作为IDP，把metadata.xml上传到AWS IAM实例，然后通过AWS-IAM创建IDP。为了让配置生效（通过apache），还有一些小事需要去做，但这个是可以实现的。

 

8. 运维视角

（1）联盟功能需要更实用才行，比如镜像的联盟。

（2）Rackspace使用了CADF格式的审计数据并且提供API给客户。如果我们想要解决多个不同的云之间的审计问题，我们需要考虑使用同一个平台去提供审计数据的展示。

（3）如果我将MIT用户映射到BU cloud，我想要知道，有多少用户在使用。这个自然是计费问题。

 

 RabbitMQ

 

1. 大家想要从这个Session了解哪些东西？

（1）在线升级Rabbit/Erlang

（2）Pivotal如何帮助OpenStack？提供文档。

 

2. 回顾RabbitMQ Heartbeat，https://review.openstack.org/#/c/146047/

（1）一些人验证了这个补丁，说有效。

（2）有人将这个补丁打在Icehouse和Juno上么？

- Godaddy做了，基于Juno

（3）如果用在Icehouse版本上，需要做那些工作？

- Icehouse版本，Rabbit使用多主机，配置在nova.conf，似乎无效。

- 需要升级kombu/amqp库，社区stable release的requirements文件版本偏老。

（4）这个补丁解决了RabbitMQ的问题么？

- 对于Godaddy来说，如果使用Rabbit host列表的方法，我们用RabbitMQ没有问题，RabbitMQ session中断，会重连。如果使用Nova-cell，无法正常工作，而且这个情况是在merge了connection leak的patch以后。

-- 这里有修复的patch，https://review.openstack.org/#/c/152667/，当你使用1.5.1以上版本的oslo.messaging时，你需要应用这个patch。

-- 这个patch修复了大多数问题，我们不用重启服务了。

（5）NeCTAR使用了Juno，oslo.messaging 1.8.1，没有遇到RPC问题。

（6）还有哪些问题没有解决？

- RabbitMQ重连问题，在Cell环境下依旧存在。

- Haproxy依旧存在问题，但是在配置文件中显式表明RabbitMQ集群节点更好。

 

3. 由于Heatbeat的修复，还有其它更新，是否需要更新HA Guide？

是的，HA Guide会重写这块内容。

 

 Logging

 

1. Jamie Lennox有一个非常不错的提案，将request ID在多个项目间进行传播。

https://review.openstack.org/#/c/164582/

 

2. 这个开发周期的一些提案：

（1）修改oslo.log，让其它的开发库可以不用向OpenStack服务的日志文件中写日志。

（2）如果日志信息内缺少一些数值，将默认填入placeholder。

 

3. Kilo总结：

（1）oslo.log库毕业

（2）Syslog的全局配置

（3）更新文档

 

4. Logstash

（1）OpenStack社区提供的logstach filters：

https://github.com/openstack-infra/system-config/blob/master/modules/openstack_project/templates/logstash/indexer.conf.erb

 

（2）Osops项目提供的配置文件：

https://github.com/osops/tools-logging/tree/master/logstash

 

5. 问题

（1）能够隐藏掉对开发者有用但是对运维人员没用的日志。

（2）任何时间，当你发现一条有用的DEBUG日志，我们需要把它的优先级提升（比如info，warn等）。

（3）如果我们能减少日志文件内没用的信息，那么将相关联的日志文件合并成一个是有意义的，一些情况下，在多个日志文件中查询同一个事件是非常困难的。

Ceilometer - what needs fixing？

 

1. Ceilometer是不是长期发展的解决方案？

- 这个应该是吧。

 

2. 哪些问题是Gnocchi解决不了的？

（1）关于Gnocchi的一些资料：

- http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi

- http://julien.danjou.info/blog/2015/openstack-gnocchi-first-release

 

3. Gnocchi是什么？

https://julien.danjou.info/blog/2014/openstack-ceilometer-the-gnocchi-experiment

（1）它是个新的driver，负责存储measurement数据。

（2）和我们将数据分发到mysql，mongodb等后端一样，dispatcher会将数据分发给gnocchi。

（3）有可能需要新的API，当前元数据和传统Ceilometer的处理方式紧密耦合。

（4）Gnocchi需要调用其它的（Ceilometer）API么？Ceilometer的负载（API处理效率？）有一些问题。

- 不会，Gnocchi是一个存储后端抽象，它不负责收集数据。

（5）Gnocchi将元数据从采样点中分离。

（6）我们能单独使用Gnocchi么？

- 可以，如果你有第三方的收集和整理数据的机制（系统）。

（7）Gnocchi是一个Ceilometer的项目，它有可能不会成为发行版的一部分。

（8）Gnocchi拥有自己的driver体系，比如Swift，Ceph，但是主要还是influxdb和opentsdb。

（9）Gnocchi API？

- 和Ceilometer不同。

 

4. service/polling一团糟，我们如何改善？

（1）Kilo已经支持了jitter，不会一下子拉取所有的数据。

（2）解决方案：

- 使用repose去限制API端请求；

- 针对Ceilometer，提供一个只读的API端点；

（3）Ceilometer向Nova发出请求，去获取Neutron的配置信息，然后再获取数据。这个需要解决。

（4）对Keystone压力很大，这个修复了么？

（5）作为运维，我们需要社区能够共享性能问题，这样我们可以根据数据来确定优先级。

（6）请联系tim.bell@cern.ch

我们有100K CPU核的生产环境，可以提供性能数据。

 

5. 对于一些event和notification，需要支持action和push（其实，应该是告警、事件触发机制）

（1）有个Session专门讲Alarming（告警）

（2）目前，我们有一个基本的实现方式，针对某个指定的值触发某个告警

 

6. 关于Horizon，Cloud Admin可以看每个project的监控数据（从Ceilometer获取的），但是Project Admin不能。

（1）还有就是，指定某个阶段的使用量（比如，前一个月）

（2）针对某个指定阶段的记录曲线（可以看出趋势），类似Ganglia的实现方式，RRD。

 

7. Gnocchi已经被用来解决一些问题，但是在Gnocchi成熟之前，有哪些临时解决方案？

（1）贡献我们的监控模板？（不清楚是哪家公司说的）

 

8. 用例：告警（alarming），事件（event），计量（measurement）

（1）我们正在慢慢取消Meter，因为之前它都是硬编码成volume=1，这些都会在之后被修改成事件（event），允许更好的针对元数据的查询。

- 还有哪些问题么？

（2）Ceilometer哪部分对运维来说更重要？哪些部分对你特别有意义，以至于你选择使用Ceilometer，而不是其它的系统？

- 有能力让Ceilometer监听在特定的notification queue上，并且将其暴露给第三方系统，比如Kafka，这样我们就能让第三方系统获得notification，而不是完全和OpenStack RabbitMQ服务紧密结合。

- 这个在Kilo中就能用，你可以修改publisher，使用notifier://，kafka://，file://。

- 已经和Heat集成了。

- 大多数运维的场景，使用Ceilometer来做autoscaling和restart，已经足够了。

（3）Ceilometer-agent-central和Swift plugin：如何扩展？我们的规模是600+K的project，我们不得不重写自己的Pollster。

（4）Juno版本，在uwsgi和pecan中使用API v2，没有Keystone middleware？

（5）设置Alarm triggers，Next steps，Beyond thresholds，如何做？

- 这个明天在Alarming Session上讨论。

（6）Ceilometer规模部署的最佳实践？

（7）从Icehouse升级到Juno，有错误：message signature not valid

- 需要支持不同版本的服务的互操作

 

9. 问题

（1）可以联系Tim Bell来获得性能数据，但是我们到底需要哪些数据？

（2）API一致性，关于Gnocchi和V2，如何把兼容问题降到最低？

（3）Non-admin的Horizon？通过RBAC来控制。

（4）升级，支持混合版本，升级步骤是什么？

（5）Ceilometer请求Nova去获得Neutron信息，然后再请求Neutron，如何处理？

（6）Keystone负载高。

（7）10min poll，不是运维希望的。

（8）Domain/Project数据获取的策略是什么？

 

10. 下一步要做的事情，主要就是解决上述问题。

 

11. 计划和想法：

（1）不让Ceilometer去询问Nova和Neutron API来获得信息，应该通过自身机制解决。

（2）在Admin Guide中添加最佳实践。

（3）升级方案。

（4）确认Gnocchi支持情况。

（5）大家都对如下使用场景感兴趣：使用Ceilometer获得数据，然后转发给第三方系统处理，比如Monasca，而不是让Ceilometer自己去处理。

Billing / Show Back / Charge Back - how do I do that?

1. 并不一定是全套解决方案（比如，信用卡支付），但是资源利用情况报表需要使用这个功能。需要尽可能的针对每个组件有详尽的数据，比如用户使用的带宽、磁盘空间、VM启动、删除、运行时间等）。

（1）http://www.stacktach.com/about.html#usage

（2）CloudKitty什么情况？

（3）StackTach团队可以提供需求，因为收集用户使用资源的数据是他们项目的核心需求。

（4）CloudKitty团队也在这里，愿意回答任何问题。

 

2. 4个团队使用CloudATM来计费，一般的参加者需要计费功能来支持公有云，2/3的参加者已经部署了Ceilometer。

 

3. 哪些方案？

（1）Ceilometer和一个第三方的工具，Talegent

（2）使用CloudKitty

（3）有两种计算VM使用的方式，第一种是在一天末计算所有启动的VM的数量，还有一种是读取quota，但是都没有计算这一天的变化。

（4）收集API日志和RabbitMQ总线上的Notification

（5）我们使用Fluentd来收集日志和Notification

（6）Ceilometer有一个notification agent监听在RabbitMQ总线上，建立Metrics和Events。可以参考StackTach的集成。

（7）想要一种方式来确认是哪一种OS启动了，这个是用于OS计费。

- 可以使用Glance的embedded script来通知

（8）LogStash

（9）Ceilometer

（10）当IP与VM解绑的时候，日志有记录；但是当IP与Project解绑时，没有记录。

- 给Neutron提Bug，已经提了，还没修好。

- 可以在database那监控到么？

- 是可能的，但是这样做不好。

- 这个资源使用了多长时间，需要这样的数据。

- Notification可能被忽略掉，有没有其它的工具可以去检查Nova，看这个VM是不是还在。

- 这个不是必要的，有没有可能VM进入了ERROR状态？

（11）为Notification添加Policy。

- 收集一整天所有的事件（Event），然后基于Policy来检查完整性。

（12）大家如何用Ceilometer？

- 从Ceilometer查询必要的数据，然后存储到外部数据库中。

- 让MongoDB保持在一个较小的规模

 

4. 如何来做showback（提供资源使用账单）和chargeback（提供资源费用账单）？

（1）根据配额（Quota）

（2）统计资源使用情况

（3）两个计费参数：国家，资源使用 - 基本费率

 

5. 在镜像上配置元数据，然后使用这些参数来计费（这样我们可以用来跟踪：镜像到VM，VM到快照，快照到VM等）

 

6. 按Licensing计费

7. 2个服务提供商允许用户创建自己的flavor

8. 关于用户请求的资源数，还有实际使用的资源数，比如VCPU利用率，到底如何计费合理？

9. 2-3个服务商使用了内存超分，但大多数都是CPU超分，还有一个服务商不使用超分。

10. 使用主机聚合来超分

11. 本来使用了150%的内存超分，但是发现问题，下降到95%。

12. 使用基于flavor的计费，而不是计算实际使用率。

13. 如何基于实际使用率计费还没解决。

（1）但是当利用率较低时，如何做？

14. 网络资源利用情况？

（1）使用软交换机上的TAP设备

（2）使用Neutron collector

（3）与网络组合作将数据推送给Ceilometer

（4）针对南北向流量，需要计费

（5）Networking限速是否可以支持KVM？

- https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L155-L168

 

15. CloudKitty

（1）在Stackforge上孵化的计费项目

（2）http://cloudkitty.readthedocs.org/en/latest/devstack.html

（3）每周三9:00，开发者会议

Cinder Feedback

 

1. 实现force_detach，处理在attach和detach时卡死的情况。

（1）https://review.openstack.org/#/c/172213/

 

2. 需要同步cinder和nova的状态

3. 实现嵌套quota，支持Keystone的层次管理

（1）https://review.openstack.org/#/c/173141/

 

4. 可以为哪些没有配额的用户隐藏掉某些volume type么？在私有云里，如果存在一些性能出众的卷，用户都希望去获取而不管自己是不是需要。有没有可能我们定义一些volume type，然后只对一些指定的project生效。

（1）你可以针对某个租户列表，隐藏某个类型的卷（详见private types）

 

5. 我们如何配置灾难恢复池？

（1）Cinder没有特别的配置，Juno有一个说明：

（2）https://wiki.openstack.org/wiki/DisasterRecovery

（3）ReplicationV2的设计已经完成。

 

6. 有没有可能针对某个卷，修改其volume type，然后在不同的backend间迁移？

（1）Horizon已经有一个选项，但是我没有测试通过，而且我也没找到对应的API。

（2）如果这个确实是支持的，可以考虑看成是Bug；如果这个不被支持，可以去实现。

（3）这个是支持的。

（4）所以，最终的结果应该和如下流程产生的结果完全一致，创建一个新卷，将源卷的数据复制进去。

（5）我认为正确的做法是，backend driver可以查询源卷和目的卷在类型上的差异，如果他支持所有的差异，那么就能去做；如果不支持，那么让Cinder去做dd。

 

7. 从一个single backend升级成multi-backend。

（1）旧的卷在数据库里没有对应的type

（2）当你迁移到multi-backend，cinder.conf中的backend name需要修改。

- cinder-manage支持一个迁移命令可以去做，如果这个不生效，提Bug。

 

8. 需要一个API显示出当前每个backend下面的卷

（1）这个有用。

Hypervisor Tuning

 

1. 我们可以不做这个么？

（1）可以，只要你的应用不是CPU intensive。

2. Hypervisor使用调查。

（1）RHEL/CentOS 7：+8

（2）RHEL/CentOS 6：+3

（3）RHEV：+0

（4）Ubuntu：+10

（5）HyperV：+2

3. 如何验证和测试？

（1）使用标准测试工具，比如HEP-Spec2006。

（2）这个依赖于你的应用负载。使用你的云上最普遍的应用来测试。

（3）比如Java类应用，DaCapo是一个比较好的基准测试工具。

4. VM格式调查。

（1）qcow：+9

（2）raw：+1

5. Qcow优化：

（1）preallocation：full allocate

（2）metadata

6. 内核态进程调度器用的啥？

（1）所有人都用deadline。

7. Hypervisor

（1）cpu-mode：

- host-model：需要注意，如果主机不支持某些extension，VM起不来。

- passthrough：出现很多问题，比如apparmor bug，qemu没法resume，等。

（2）disk-cache：none或writeback

（3）large pages

（4）Intel KVM EPT

（5）KSM

（6）NUMA

（7）TSC

（8）网络方面，特别是万兆网络调优

- MTU

- Buffers

- TCP congestion control

- Latency tunables

（9）本地存储类型：

- SSD

- Spinning disk

- 块设备或文件系统的缓存，SSD swap？bcache？dm-cache？

（10）IPtables配置

- conntrack_max？

-- 512k

-- 256k，哈希表大小为16k

-- 256k，哈希表大小为64k

- 哈希表一般多大？

-- 64k（conntrack_max/8）

（11）降低net.netfilter.nf_conntrack_udp_timeout=5

- 这个是用于UDP请求回复类的网络流量，而且不会重用UDP端口，比如DNS就是这类的应用。

（12）超分比？

（13）你一般为主机预留多少内存？

- reserved_host_memory_mb=6144（nova.conf）

- Xen提供了一个精确的方程式来计算，但是KVM没有。

- https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L155-L176

（14）CPU预留是否有效？使用nova.conf提供的vcpu_pin_set？

- 这个定义了，哪些物理CPU核可以用来虚拟化。

- 是的，nova-compute会读取这个配置。

 

8. Guest OS相关

（1）Guest OS 内核的调度器设置成none

（2）Virtio scsi or blk？

（3）Virtio net？

（4）关闭block I/O barrier，并且设置为virtual-guest。

- 这个设置会不会出问题，特别是当主机掉电的时候？

- 我觉得物理服务器传递RAID卡上有电池。

- RAID卡没用，因为数据存在Guest OS的缓存里。

（5）关闭updatedb，或者让cron任务随机化。

（6）你是否使用Instance Resource Quota？

- https://wiki.openstack.org/wiki/InstanceResourceQuota

- 是的，我们限制了所有的flavor，只能利用80%的CPU，我们还为所有的flavor配置了一个CPU share set。这个仅仅是准备，我们还没有用。而且我们还在测试disk I/O，但是还不清楚如何配置才好。

 

9. 有人用SRIOV么？

- 我们测试了，但是觉得没用，特别是系统变的不稳定了。

- 这个可以用于高性能场景，也可以用DPDK，但是其部署复杂。

OPS: Security

 

1. IDS

（1）TaaS：https://www.youtube.com/watch?v=xEmTDKqGEYs

（2）邮件列表讨论：

http://lists.openstack.org/pipermail/openstack-security/2015-February/003267.html

 

2. 有没有其他的人怀疑oslo messaging bus？有一个邮件关于SAP使用同样的messaging bus。还有一些提案使用Kite提高安全性，解决共享密钥的问题。

 

3. 我刚才做了一个关于在OpenStack部署中引入Kerberos的PoC。Kerberos不能提供组密钥，缺少为组添加和删除密钥的方法。如果我们用对称加密，如果密钥在大于两个系统间共享，那么任何一个系统都可以假扮另一个系统。消息总线应该可以用一些工具来解决问题，比如，ZeroMQ本身就支持Kerberos，RabbitMQ天生为OpenStack服务，也应该在未来支持。OpenStack不该假定用户使用AuthN/AuthZ的方式。我希望有一个优秀的安全的解决方案。

 

4. 另外一个更严重的问题在于，如果你搞定了集群中的一个节点，你可就搞定了整个集群，你可以向集群中的任意消息队列里塞消息。我们需要定义谁能访问谁，从哪里开始到哪里结束，类似的访问控制列表可以解决这个安全问题。RabbitMQ支持mutually auth’d TLS。很多小的部署一般都用RabbitMQ的Guest账户。

 

5. OpenStack开发者很关心系统的安全性。但是我的工作是防止我的用户攻击我的服务。你们关注在如何让OpenStack变得安全，但是我们可以考虑另一个方向，也就是如何在租户网络内部，运行IDS，系统漏洞检测等。每一次发布一个新版本的OpenStack，我都要backport我们的IDS相关的代码。

 

6. 在安全讨论中，把Neutron拉进来是必要的。

7. 使用L2/3的NetFlow数据是有用的。在Neutron节点上，你可以在OVS上做这个事情，同时部署另外一套IVS switch来过滤流量。

8. 我们正在尝试为Security Guide添加一些IPS相关的内容。

9. 我们可以针对Neutron做RBAC，来控制谁能访问IP么？

10. 我们也在找寻一些合作伙伴来共同推进安全功能。

11. Compliance as a service API（这个应该是一个假设，有这么一套API），用来管理信息的隔离。但是我要如何确保我需要的数据可以转给‘租户委派的安全管理员’？作为云服务商，我不想要了解。

 

12. 动态策略，这个提供了细粒度的控制，是正在开发的工作。我想提醒下，上层应用也可以利用这个功能。上层应用可以通过scoped RBAC来控制访问，我们应该要有能力在Nova或者其它项目中去支持。我刚刚完成一个演讲，说的是RBAC的过去，现在和未来。我们现在也需要更多的文档来说明如何使用oslo.policy。当前的策略是静态的，我们需要让它变成动态的。大量的设计正在进行中。当前，基于条件的策略非常难用，而且决策仅仅取决于Token中的信息。有个更好的例子，当你禁止某用户在Glance做镜像上传，默认你也禁止了该用户做快照，或者做其它相关的操作。

 

13. 从运维人员的角度说，整体方案是重要的，但是我问题在于，你有权限访问一台服务器，同时你也能访问全体集群的。但是apparmor或者selinux可以解决。

Deployment & CI/CD

 

1. 大家都用哪些部署工具？

（1）jenkins调用ansible，ansible调用chef

 

2. 这里有个工具可以检查健康状态：

https://wiki.openstack.org/wiki/Cloudpulse

 

3. 代码分支管理

（1）持续集成进master，打tag

 

Operating multi-site OpenStack installations in practice

 

1. 每个服务商，运维了多少个regions？

（1）1个

（2）2-5个：+1

（3）>5个：+1

 

2. 共享（cross-regional）的服务有哪些？

（1）Horizon

（2）Keystone

（3）Glance

（4）Ceilometer

 

3. 运维多个region的难点

（1）缺少跨region的统一视图

- 配额，租户

-- Nova、Cinder、Neutron都缺少配额

-- 针对某个租户，跨多个region，没有soft/hard配额限制。

-- Nova团队在讨论实现，但是仅仅只有Nova是不够的。

（2）跨多个region的资源利用

- 目前全局视图是基于租户或者Cloud Admin的

（3）没有针对某个租户的计量数据的全局视图，用户需要统一地访问所有（多个regions）的日志和指标。

（4）没有针对租户的全局IP地址管理的视图

 

4. 还有哪些事情可以做的更好，关于多region部署和运维？

（1）Horizon

- 默认region，project

- 根据用户输入来显示region/project

- 有能力运维多region

-- 克隆安全组策略

-- 克隆SSH Keys

- 根据搜索栏查询对象

（2）Nova

- 把SSH Keys从一个region复制到另一个region

（3）Neutron

- 把安全组从一个region复制到另一个region

（4）Glance

- 将镜像数据同步到多个region

-- 通过脚本或者Swift？

（5）Keystone

- 根据Region过滤catalog和tokens

Nova Feedback

 

1. Nova没有很糟

（1）其它项目更糟

（2）在线升级很棒

 

2. 不能仅仅测试Ubuntu发行版中的qemu和libvirt

（1）Fedora有一个新版本，但是还没稳定

（2）可以在devstack plugin中集成

 

3. Scheduler还需做什么？

（1）我们已经开始修复CRUD，但是还需要做更多

（2）把Scheduler分离出去，在不会Liberty。

 

4. API查询容量

（1）比较担心和Scheduler的修改和分离起冲突

（2）怎么做？

（3）定时事件？+1

 

5. Scheduler

（1）把IP容量加入调度考虑中

（2）针对Cell，打开或关闭

（3）针对compute，测试admin-only状态

（4）保留一部分主机，这个功能要修复

（5）实时迁移要能够处理旧的请求（应该是没有处理的请求）

（6）Resize需要节点间的SSH

 

6. 从Glance中删除镜像，会出现问题

（1）在之前删除了快照

（2）Kernel+Ramdisk+快照的组合

 

7. NoValidHost，糟糕的提示

（1）有功能测试么？错误状态不清晰

（2）为什么调度say no？

 

8. 有必要知道在VM启动期间，时间的消耗

（1）调度过程占用大量时间

（2）想要知道是不是配置问题（filters，weights）

（3）需要记录下，怎么获取这些数据

 

9. 如何实现在DB升级中不中断业务？

 

10. 当VM进行快照时，启动镜像已经删除了，这样会出现问题。我们需要解决。

（1）块存储迁移也是同样。

（2）Kernel+Ramdisk可以工作。

 

11. EC2接口

（1）正在做新的实现了，旧的不建议使用。

 

12. 软删除虚拟机在数据库中的记录

（1）API返回VM已经删除

（2）Horizon使用这个

（3）有配置么？可以配置在X天后，删除记录。

Customer Onboarding & Offboarding

 

1. 这个是关于创建Project，创建Account

（1）有没有一个特定的流程，让租户去走。

- 用户有凭证和访问策略，可以用来通过或拒绝访问资源和租户

- 当创建租户或添加用户到系统各种时，需要检查

- 用户有可能不能使用某些资源，并且不允许被添加进系统

- 需要每天运行一个检查脚本，去看用户是否被更新，而不允许访问系统

 

2. 当用户离开时，需要清理所有的相关资源，+2

（1）我相信很多用户已经有了一些工具可以自动化的做这个工作。我想看看这些解决方案是怎么做的。

（2）CERN有个方案，如果我们能把他做的更好，可以提交给社区。

（3）还有一些讨论，是自动化地让某些镜像过期。

 

3. 有人为客户提供培训么？

（1）MIT CSAIL有一些文档：

http://tig.csail.mit.edu/wiki/TIG/OpenStack#Quick_Start

（2）Verisign，我们创建了培训模块提供给客户。

- 1小时的Session，分别讲述GUI，CLI和入门课程。

（3）一些把培训外包出去了。

（4）有哪些培训内容？

- 一般都是‘如何使用系统’，这类的问题

- 还有些更高级的，比如云架构，Swift架构等。

 

4. 私有云生命周期管理（企业员工入职到离职）

（1）资源从一个账号转到另一个账号

（2）修改VM的归属

 

5. 对Tenant进行命名很有必要，这样可以区分Project类型（个人的，还是组织的）

（1）一些情况下，由于安全的考虑，我们会暂停一些VM，然后通知用户，说你不再是合法的用户。

 

6. 有些人已经创建了脚本，通过修改DB，修改VM的归属。

（1）有一个问题，就是要处理SSH Keys

（2）最好的方案，其实是删除这台VM，然后再创建个同样的。

 

7. Shelving在这里有用么？

（1）不确定，其实我根本不明白Shelving是干嘛的。

 

8. Onboarding流程

（1）培训模块

（2）欢迎Email

（3）资源销毁Email

（4）警告Email

（5）‘请停止***行为’Email

（6）为创建账号（租户、用户等）输入所有必要的信息

- 所有用户信息

- 所有资源信息

- 允许和禁止的工作流

- 可以通过脚本自动执行

-- 通过Murano也能完成

-- 检查用户、添加用户、删除用户

-- 创建租户

-- 添加资源，移除资源

-- 选择最合适的Region去部署Project

（7）某个Project的管理员或者用户允许添加他们自己的用户

- 这个是可能的。

 

Containers：What do we need？

 

1. 当前用例：

（1）把OpenStack服务运行在容器里。

- Kolla项目，其定义了将OpenStack服务打包进容器中，任何时候你可以通过容器来部署、升级和修改OpenStack服务。

（2）Magnum项目

- 需要和Neutron以及其它网络技术方案集成。

（3）OpenStack for VPS

（4）产品迭代发布的平台，提供给开发和测试用

- 通过容器建立CI系统

（5）提供PaaS，比如Solum

- nova-compute-lxd，在Liberty实现

（6）在Nova中，实现Parallels libvirt container接口

（7）Nova驱动中支持Neutron

 

2. 期待用例：

（1）针对多租户环境，可以提供类似裸机的性能和足够的安全隔离。

（2）实时迁移，http://www.criu.org

（3）比较应用容器和操作系统容器

- 应用容器可以被分解成很小的部分，每个部分的启动开销很小，在几秒内，但是操作系统容器则需要数分钟来初始化。

（4）容量管理

- 在线调整cgroups

 

3. Heat+Docker，还是Docker native driver

（1）为compute提供一个基于容器的集群管理系统接口，让该系统去处理实际的容器。（这个概念类似于Nova和VMware vCenter的关系）。

- 人们通常使用哪些容器集群管理系统：

- Kubernetes

- Deis

- Mesos

- Docker Swarm

（2）如何处理Docker registry？

- 让Glance直接处理Docker镜像是否合适？

- 还是让Glance作为服务端点接入Docker registry？

- 回答：操作系统镜像和应用程序镜像不同，需要讨论的是，在Glance服务范围内，是否可能添加新的类型（来处理Docker镜像）。

- 澄清：Docker镜像就是一种操作系统镜像，它用一种分层的形式来创建镜像，有可能这个不被Glance所支持。

 

4. 用户只需要Docker时，我们如何提供一个OpenStack环境给用户？

5. 限制：网络，存储，等？

（1）CPU，内存

（2）磁盘

（3）带宽

（4）还需要更多的动态选项，nova flavor太少了。

 

6. 哪些好处？

（1）密度

 

7. 正确的容器模型是啥？

（1）目前Docker是唯一的支持对象么？Parallels，LXC，LXD，Rocket？

- 还有镜像格式问题

（2）Redhat不建议使用libvirt-LXC

 

8. 有人想要支持systemd-nspawn？

9. 调查，什么样的操作系统来运行容器？

- Ubuntu、Snappy

- Debian

- RHEL/CentOS/Atomic

- LXD

- CoreOS

- Vituozzo

- 内核需要至少3.12左右来提供完整的命名空间支持。

 

10. 跨项目集成（Murano，Magnum，Nova-container-driver）

（1）Heat相关模板：https://github.com/stackforge/heat-coe-templates

（2）Magnum开发团队，不是Nova-container-driver团队。两个独立的团队做不同的事情。

 

Neutron Feedback

 

1. 支持Cell部署模式

（1）Nova根据AZ、IP地址、容量来调度，Neutron不了解这些属性。

（2）需要了解需求

（3）Godaddy提出了一个关于IP使用情况的API扩展。

- https://review.openstack.org/#/c/180803/

 

2. LBaaS，当前的状态是什么？

（1）为LBaaS提供了安全机制

（2）考虑了高可用

 

3. 你想要Neutron对AZ的支持么？

设计文档：https://blueprints.launchpad.net/neutron/+spec/add-availability-zone

这个实现了针对DHCP和L3的AZ的支持，就像Nova和Cinder一样，它让用户可以指定网络服务的故障隔离域。

 

4. IBM正在开发一些与ML2兼容的Agent，在stackforge上孵化。这样看来，机制驱动还是需要在Neutron Core项目中，这个是正确的方向么？

 

5. L3 HA + L2pop，需要完成

6. DVR + L3 HA，需要完成

7. Nova和Neutron的交互不是特别灵活，比如当前，针对某个VM，Neutron只能提供一个供应者网络（provider network）给Nova。

 

8. 在Juno版本中，VPNaaS不能在RDO和CentOS 7环境下正常工作。还没有尝试Kilo。

9. L3-HA中，我们可以配置VRRP优先级么？

10. 针对供应者网络（provider network），ml2_type_vlan最好可以添加新的网络，network_vlan_ranges最好可以更新，并且Neutron服务需要重启。

（1）最好可以用SIGHUP这样的信号机制来让服务更优雅地重启。

 

11. 网络节点的瓶颈

（1）IPv6支持，针对DVR

 

12. 使用Rally测试发现，iptables策略没有被清理干净，neutron-port-create没有删除iptables策略。这个已经提了Bug了，正在修。

13. 在计费Session上提出的问题，在把IP地址与Project解绑时，Neutron没有发送对应的Notification。

14. 这里有一个新的设计，用于报告IP地址利用情况：https://review.openstack.org/180803/

15. IPAM插件，需要完成

16. DVR相关：允许物理网络做SNAT

17. 为了添加供应者网络（provider network），需要修改ML2配置文件，还需要重启所有Neutron-server和L2-agents。（这个是问题，需要解决）。