Re: [debops-users] Tips for a new role

On Nov 26, Stuart Read wrote: Neat application. I briefly looked if there are efforts to package it in Debian, but there appear to be none. Maybe an opportunity to do so? Don't forget the webserver. :-) Integration should be straightforward via the role dependent variables. For php role, you can look how the 'debops.dokuwiki' handles the 'debops.php' configuration. Default variables: https://github.com/debops/debops/blob/master/ansible/roles/debops.dokuwik... Playbook: https://github.com/debops/debops/blob/master/ansible/playbooks/service/do... Currently I don't have good PHP-based role that uses MariaDB around (existing ones need to be updated), but you could look at 'debops.etherpad' which uses MariaDB as optional dependency. Default variables: https://github.com/debops/debops/blob/master/ansible/roles/debops.etherpa... Playbook: https://github.com/debops/debops/blob/master/ansible/playbooks/service/et... Remember that the 'debops.mariadb_server' is handled separately and shouldn't be used as a dependency directly. The existing 'debops-contrib' roles in the monorepo will be integrated with the main playbook at some point, that is renamed, cleaned up, their playbooks moved to the `ansible/playbooks/` directory, etc. The 'debops-contrib' organization on GitHub in its current state shouldn't be needed anymore. I'm considering adding a 'CODEOWNERS' file so that GitHub can automatically request reviews from people based on files they are interested in: https://help.github.com/articles/about-codeowners/ I have some quailms, since it looks like if you specify a list of people interested in a particular file(s), this overrides the global list instead of adding people to it, but maybe if you "watch" a repository you get a notification about a PR as well? Not sure, I guess we will find out. I'll check out how other projects use this functionality first. If you want to contribute a role to the project, just fork the main monorepo and add your role as usual in the 'ansible/roles/' directory, its corresponding playbook in 'ansible/playbooks/service/'. Documentation should go into 'docs/', however that's not finished yet. You can see that the 'debops.apt' documentation was moved there already but that caused problems with many missing references to variables from the 'defaults/main.yml' file, so I stopped doing that to first add yaml2rst support in the Sphinx code. When that's done, all role documentation will go there and monorepo will be hooked up at https://docs.debops.org/. These rules should probably go into DebOps Policy documentation, which also needs to be updated to the new reality. All in good time. :-) I think that question deserves a more extensive discussion. I would like to see DebOps in Debian 'main' component of the Debian Archive at some point. That means that DebOps, at least the main project repository, should conform to the Debian Free Software Guidelines: https://www.debian.org/social_contract.html#guidelines Packages in the 'contrib' component usually depend on non-free software, either in Debian 'non-free' component or on external software. So how does that look if DebOps has roles that depend on non-free software? I believe that the same rules would apply, and that would force the DebOps package to be included in the 'contrib' component of the Debian Archive, so let's avoid that. But, the non-free roles and playbooks could be managed in a separate git repository. You could install that repository alongsite DebOps monorepo, say in ~/.local/share/debops/debops-contrib/; all there is is to update the 'debops' scripts to handle multiple playbooks at once and allow configuration of multiple role/playbook directories where the script points Ansible at. This would probably call for restructuring of the 'site.yml' playbook, so that not all roles are executed at once and runs can be faster. When the CLI supports selecting multiple playbooks to run, some more esoteric roles will probably be removed from the main playbook. Of course for this, an entire separate organization on GitHub is unnecessary; there could be just another repository, say, debops/debops-contrib, with similar usage patterns as the main repository. Fork it, add your roles to it, make a pull request. Cheers, Maciej