Cp-ansible: Ansible Galaxy 支持

有任何更新吗？ 使用这些剧本会容易得多

目前没有发布到 ansible Galaxy 的计划。 我将提交内部 jira 以查看有关在未来版本中对此进行调查的情况。

一般的期望是克隆 repo，然后运行给定设置所需的剧本。

Ansible 2.9 引入了一种称为集合的新分发格式。 这似乎更适合解决这个问题，因为一个集合可以包括剧本、角色、模块和插件。

一些提示：

• https://www.ansible.com/blog/getting-started-with-ansible-collections
• https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
• https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html

我尝试将重组作为一个星系集合，测试使用all.yml剧本和一些基本的配置（ssl 和 sasl/plain listeners）。 它的一部分非常笨重，主要是据我所知，要引用任何过滤器和模块，您必须引用整个星系命名空间。 不过，它适用于我的用例，如果团队认为值得添加，我很高兴打开 PR。

https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack

@aig787我喜欢它！ 我一直觉得升级剧本应该在“剧本”目录中
角色可以访问插件目录中的内容，对吗？
还需要 confluentinc_cp 目录吗？

一个棘手的部分是 ansible.cfg，我一直喜欢把它放在剧本旁边，因为要求在安装过程中使用该文件中的 ansible 配置

这些角色都可以访问插件目录 (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory) 中的内容。 我认为您只需要使用全名即可访问它，例如，我必须将KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}"更改KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}"才能使过滤器为我工作。 可能有一些方法可以解决，但我找不到它。

刚刚尝试删除 confluentinc_cp 目录，它工作得很好，所以我想没有必要。 我最初用ansible-galaxy collection init引导它并使用创建的结构。

是否有理由不能将 ansible.cfg 与其余部分一起移到 playbooks 目录中？ 我_认为_为了使用剧本，人们仍然需要克隆 repo 并像现在一样运行。 在星系中使用它的好处更多是让人们可以在自己的设置中访问角色，而不是让剧本更容易。 反正那是我的 2 美分。

我个人并不关心 ansible.cfg 的放置位置，我只知道如果您运行剧本并且您当前的目录不在 ansible.cfg 的位置，那么就会出现问题。

我可以看到坚持 ansible 最佳实践和遵循集合目录结构的价值，但我很好奇将这个集合发布到星系中能给我们带来什么好处。 更能见度？

对我来说，在星系和我们的分支中管理版本控制似乎有很多开销。

这将是一个易于使用的增益。 如果我有一个对所有节点进行一些基本配置的剧本，我可以将其添加到需求文件中并运行“ansible-galaxy install -r requirements.yml”并在我现有的剧本中引用 kafka 角色，而不必克隆回购并扩展剧本或复制角色目录。

至于为什么你真的必须发布它，我不相信集合像角色一样支持 git 引用（https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -file 与 https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file）。 我确实同意版本控制的开销量，这似乎有点沉重。

我个人并不关心是否在 Galaxy 中使用它，但是，能够轻松引用需求文件中的不同角色将非常感激 :smile:

即将注册一个新问题，但我认为我的问题与此问题有某种关系。 因此，从这里的评论开始，从维护者和其他观看者那里获得一些初步反馈。

我想使用此存储库中的角色，但我想将它们用作自定义角色（角色扩展）中的角色依赖项。 我们开始使用 playbook (all.yml)，但是在正确的时间应用我们的扩展时遇到了很多麻烦。 我使用这种方法的第一个（阻塞）问题已通过https://github.com/confluentinc/cp-ansible/pull/442修复

[DEPRECATION WARNING]: Included file 
'/builds/kafka/provisioner/tasks/failure_handling.yml' not found, however since
 this include is not explicitly marked as 'static: yes', we will try and 
include it dynamically later. In the future, this will be an error unless 
'static: no' is used on the include task. If you do not want missing includes 
to be considered dynamic, use 'static: yes' on the include or set the global 
ansible.cfg options to make all includes static for tasks and/or handlers. This
 feature will be removed from ansible-base in version 2.12. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

看细节，我认为普遍的问题是角色目前不是独立的。 解决这个问题将是最终将角色或角色集合发布到 Ansible Galaxy 的强制性步骤。 而且我认为这可以很容易地修复，因为它归结/tasks从角色内部引用以下顶级目录/filter_plugins和/tasks 。

您如何看待以下任务作为拉取请求：

1. 将/filter_plugins文件夹移动到confluent.variables角色 - 使其成为该角色的一部分？ 过滤器插件至少在这个角色中使用。

2. 将/tasks的可重用任务文件移动到现有角色之一，可能confluent.common是现有角色中最适合的，或者为它们创建一个新的专用角色（ confluent.common_tasks ）？ 并使用include_role#tasks_from更新对重用任务文件的

Index: roles/confluent.zookeeper/tasks/health_check.yml
<+>UTF-8
===================================================================
--- roles/confluent.zookeeper/tasks/health_check.yml    (revision 0d369ae20c8215dd2ec469f269dc804539f58190)
+++ roles/confluent.zookeeper/tasks/health_check.yml    (date 1602793473938)
@@ -25,7 +25,9 @@
   ignore_errors: true

 - name: Fetch Files for Debugging Failure
-  include: tasks/failure_handling.yml
+  include_role:
+    name: confluent.common
+    tasks_from: failure_handling.yml
   vars:
     service_name: "{{zookeeper_service_name}}"
     config_file: "{{zookeeper.config_file}}"

@erikbb这是我们过去在内部讨论过的问题。 特别是，有很多关于自包含角色与最小化代码重复的讨论。 看起来我们将不得不为 2.12 更改此设置。 Ansible 的发布，基于警告，所以我认为将/filter_plugins和/tasks到confluent.common角色可能是最有意义的，然后使用适当的所有其他角色中的 import 语句。

@domenicbove你有什么想法？

只要功能保持一致@erikb @JumaX，我移动文件位置就没有问题。
这似乎是足够大的工作，它应该进入主分支，但针对我们的下一个版本。

@domenicbove同意它适用于我们的下一个主要版本。 @erikb我们将添加一个内部 JIRA 来跟踪这一点，看看我们是否可以将其

或者@erikb如果你有工作坐在一个分支，欢迎你在master分支做一个PR，我们会审核。 我认为这不会完全解决这个问题，我们仍然需要制作星系。

下一个主要版本？ 那会是 Confluent Platform 7 吗？ 我认为，这种更改可以向后兼容 - 只要将主要入口点视为剧本和角色。 我更愿意在 CP 7 之前解决这个问题。😄

@erikgb是 CP 6.1，我们倾向于不添加新功能，特别是如果它涉及到旧版本的重大重构。 我们有很多企业客户在我们为现有版本更改太多存储库时遇到策略/问题，我们尝试仅将其保留为错误修复。

@domenicbove @JumaX CP 6.1 更有意义。 本周晚些时候我会看看我是否有时间处理拉取请求。 我建议将重构拆分为有意义的部分。 WDYT？

@erikb如果您想将其拆分为多个 PR，假设每个 PR 仍然能够在没有额外 PR 的情况下运行，那很好。 不确定我说得很好。 :)。 应该瞄准主分支。