Looking for ideas - Sharing reusable policy and modules

[olehermanse]

I'd like some input from the community, here. By the end of the year we are planning to launch a website and tools to make it easy to share and reuse policy and modules from other users. It will be a separate website (not a part of Mission Portal / Enterprise) open for everyone to use and contribute, similar to crates.io or npm.

We want to focus on use cases that help new users. So I'd like some ideas for the content we should have at launch. What was the first thing you wanted to automate with CFEngine? What services are difficult to interface with today? What new resources would you like to have promise types for?

Please share any ideas you have here, and if you want to contribute some modules to be available at launch, tell me and we will work with you 😄

(Long time users might be familiar with Design Center and sketches, and this is certainly building on that idea.)

[olehermanse]

@neilhwatson @atsaloli @zzamboni @basvandervlies @tzz Maybe you have some ideas :)

[zzamboni]

@olehermanse I think this is great news! In my opinion, this is one thing that has held CFEngine back in terms of "popularity" (in quotes because it's relative) in comparison to other systems like Puppet or Ansible. Not that they are better, but they make it much easier to find, load and use modules of anything you may want, and for users to contribute those modules. This is why we started the Design Center project way back then, but it never reached the level of maturity to make it really take off.

In the meantime, CFEngine has matured a lot, and now with custom promise types and other new mechanisms, it would be really interesting to see what the community can do. If you build a platform and associated tooling that makes it really easy for users to both use and contribute new modules, I'm sure a lot of interesting contributions will happen.

A few semi-random thoughts about the tooling:

• Command line utility to search/install/list/remove/update modules.
• Command line utility to create skeleton for different types of modules (I guess this could be different for new promise types, loadable libraries, etc.)
• Command line utility to automatically download/install all requirements, maybe something like Node.js' package.json or Ansible's ansible-galaxy install -r file.yml
• Browsable/searchable website, where users can look for things by category, by popularity (e.g. number of downloads), view information about a module, etc.
• Make it possible to install modules directly from a github/gitlab/bitbucket repository. This reduces the contributor effort dramatically - e.g. if I just put things in the correct structure in a github repo, someone should be able to install my stuff directly by asking for (e.g.) github:zzamboni/modulename, without requiring it to be registered in the CFEngine module website.

About content, a few off the top of my head:

• git promise type, for manipulating git repositories. See https://docs.ansible.com/ansible/latest/collections/ansible/builtin/git_module.html for inspiration.
• pamd promise type, for manipulating PAM configuration. See https://docs.ansible.com/ansible/2.4/pamd_module.html for inspiration
• Module for configuring sudo (maybe a new promise type too, e.g. see https://github.com/ahuffman/ansible-sudoers).
• Cloud-platform management modules, e.g. for manipulating AWS/Azure/GCP/other resources

It might be interesting to see the top-module lists at https://forge.puppet.com/ and https://galaxy.ansible.com/ for further ideas. But I think the focus should be on the tooling first - it should be really easy to use, both for users and for contributors. This is what can enable community-driven growth, which is where Puppet and Ansible have excelled.

Hope this helps!

[olehermanse]

@zzamboni Thank you for the input :)

[tzz]

I would love to see a module system for CFEngine and I'm sure you'll do a superb job of it :) I hope it can support driving Ansible or Salt modules as a primary use case.

I would also suggest better systemd support, especially managing units, as a good use case in addition to what Diego said.