BSDify the common.yml playbook

[AnotherKamila]

Make it possible to successfully run debops against a FreeBSD host when it's not in any groups.

[drybjed]

That should be fairly simple to do in the DebOps project directory. You will have to copy the common.yml playbook as well as service/core.yml playbook which is included from the common.yml to ansible/playbooks/ directory. After this, if you run debops common, the script should apply the playbook you copied, which can be modified to remove roles related to Debian like debops.apt, etc.

Let me know if that method works. :)

[AnotherKamila]

Hi, thanks! I do believe that would work.

However, I believe there's a bit of confusion about how I intend this project to be used -- clearly because what I intend is in my head instead of in a README somewhere. Issue #11 is about this confusion too. @drybjed, I would actually really appreciate your input on what I intend, as I'm new and all that, so I don't actually know if it's a good idea.

Here's an attempt at explaining it:

I assume that what you think I am doing is overriding things from debops in the user's project directory. This is an easier approach, but it is not what I want in the end:

Ideally, I would like the user to have a "lean & clean" project directory, just like with upstream debops: they only put their own modifications related to their own infrastructure in there. I do not want them to have my code in their project directory. Instead, I want them to use my forked debops repo instead of the upstream debops (not "on top of"), by putting it into debops/ (or even into .local/share/debops, if they're feeling brave). Note that because I am trying to preserve compatibility with non-FreeBSD hosts, this is (in an ideal world) not a terrible idea.

Why: because that way the user doesn't have to manually merge my changes into their project repositories.

Is this a good approach (even though more difficult for me as the developer), or am I overdoing things?

[drybjed]

If you want to manage a debops/debops fork properly and pull changes from the upstream project from time to time, the easiest way to do this would be by creating a separate branch in the repository, for example bsd-master. The suffix would indicate on which branch you base your own forked branch.

The workflow of pulling DebOps changes to your own fork and applying BSD-related changes on top of it would be as follows:

cd ~/src/github.com/AnotherKamila/debops
git checkout master
git fetch upstream
git rebase upstream/master
git checkout bsd-master
git rebase master

Of course after that last step you would have to fix any merge conflicts when something in the upstream project changes.

One step up from that would be a way to have your own bsdops Python package which you can then build and install your own set of BSDOps playbooks and roles (which are included in the debops Python package). That would probably require changing the current Python distribution in DebOps to support renaming the Python scripts, modules, etc. during build time. You can look into it if you want, and we could incorporate that into upstream project if that makes forks easier to manage.

[AnotherKamila]

@drybjed Thank you!

Re workflow: That's what I've been doing, except I've been merging instead of rebasing. I can switch to rebasing, if that's better. (Probably I could even rewrite the history of my fork, as I doubt anyone has cloned it -- but I'm not sure I want to risk that.)

The bsdops Python package idea had already crossed my mind. I am glad that you support that idea. I will look into that at some point, then. (I think I should first focus on making my fork actually useful, though -- right now that would be entirely useless, as at this point things in my fork will break and therefore the user really should have the source at hand.)

[drybjed]

Hmm, indeed, rebasing already public changes might be a bad idea. Merging new changes with --no-ff could probably handle this better, although I'm not sure how that would work in practice with a fork.

Currently DebOps is designed with two "layers" in mind: the DebOps monorepo as a base, and the DebOps project directory on top of that as the end result. I wonder if changing this system and adding a middle layer that would allow remixes(?) as BSDops between the DebOps base and the project directory could be an interesting proposal... Although it all hinges on Ansible allowing some intelligent playbook composition vs direct playbook replacement as it's done currently. In theory there could be a custom plugin similar to task_src that could allow for selective importing via import_playbook, by picking the first found playbook from a set of directories and if nothing found selecting the default playbook.

That way you could have an additional set of playbooks in separate directory ~/.local/share/debops/bsdops/ which could take precedence over the DebOps playbook not by being put in the DebOps project directory, but by reordering the list of paths where the playbook_src lookup plugin looks for playbooks. Compare this with how currently custom lookup plugins can let you replace templates, files or even inject tasks into existing DebOps roles.

[AnotherKamila]

I think I might just risk it and rebase, I very much doubt anyone is seriously using this (otherwise they'd be complaining that the site playbook isn't working, I guess?) I guess it's better to do it now than later. I didn't know that rebasing would be preferred to merging. I suppose I should have asked, I just somehow really didn't expect you to be interested in helping me.

Adding a middle layer might be interesting, though yes, to make it practical Ansible would need to allow more granular composition for that. It also seems like more work for you upstream devs. I am currently working with the assumption that there are two layers and I want to be the bottom one, so that the top one can stay clean, and hopefully I'll figure out a way to make that workflow easier for me.

[drybjed]

Rebasing is actually bad if you want your project to be public, because rebase rewrites the history, and you should never do that in a public project. This article explains differences between merging and rebasing: https://dev.to/neshaz/git-merge-vs-git-rebase-5134

In DebOps, I'm doing merges in the main debops/debops repository, but in my fork I'm constantly rebasing the master branch on top of the upstream changes; this is fine since I don't expect anybody to use my fork (drybjed/debops) directly. No complaints so far.

I'm interested in making DebOps more user-friendly and accessible; having a good way to handle forks is one way to do that. I cannot promise that required changes will be done right away, but I'm open to interesting PRs in that regard.

[AnotherKamila]

Re rebasing: right, the problem would still exist later, even if it wouldn't be a problem now because I probably have no users now. I will stick with merging then. Thanks!

Re "fork-friendliness": I see :-) I feel a bit too new to everything to propose things at this point, but I will try to do a better job with asking before coding. (This is difficult for me!)

Thank you for your help, I really appreciate it! You are definitely making things user-friendly and accessible for me :D