I broke out the start/stop behaviour into it's own PR -- #132

This is now rebased on latest, and converted to a Python package along with updates to testing and Github actions. This also introduces a script to setup the virtualenv easily for local development and use in CI.

I opted for a change in strategy to drop the setup command/playbook and move those dependencies around. Two notable things:

1. This moves the etc_host setup useful for testing into a small playbook that is run by Vagrant at provisioning time.
2. This moves (in an ugly-ish way) the "what do we do about these dependencies" into the deploy playbook for now.

Random shower thought: can we use a simple shell script wrapper instead?

My idea is to configure obsah via environment variables. Something like:

#!/usr/bin/sh

OBSAH_NAME=rop
OBSAH_DATA=data
OBSAH_INVENTORY=
export OBSAH_NAME OBSAH_DATA OBSAH_INVENTORY

exec obsah "$@"

Most probably: yes. We originally went this route, as the current ApplicationConfig in obal contains executable code (os.getcwd() for the inventory etc), which would need more logic in this wrapper. rop probably won't have that, so it can be easier.

That said, this is an improvement we can do later. Or are you hinting at "then we don't need a python package after all"?

Right now OBSAH_NAME doesn't exist but we can enhance it to. I had a thought to enhance obsah where you symlink /usr/bin/obsah and it looks at __name__ to derive it, but since you need to set OBSAH_DATA anyway I think you need a wrapper anyway.

How I started to think about this was development. Can we install production rop (or whatever), ship all data somewhere and set ROP_DATA / OBSAH_DATA to that location? Then if you take that to a more logical extreme: do we even need rop then?

If we go that route then it may be feasible to package it up as a true Ansible collection while in the RPM we only add the trivial wrapper and package dependencies.

Thinking more about that, perhaps we can still use the symlink /usr/bin/obsah idea but add a /usr/libexec/obsah-collection (or something) that will look at an ansible collection with the same name in /usr/share/ansible/collections/ansible_collections (though that may be too hard with namespaces). Or we can introduce /usr/share/obsah for that purpose.

We should not put (or require! or even accept!) things in /usr/share/ansible/collections/ansible_collections. People will have all sorts of weird stuff there. Incompatible versions etc.

But yes, we should place things in /usr/share/something and point the vars there for prod

Random shower thought: can we use a simple shell script wrapper instead?
My idea is to configure obsah via environment variables. Something like:

#!/usr/bin/sh

OBSAH_NAME=rop
OBSAH_DATA=data
OBSAH_INVENTORY=
export OBSAH_NAME OBSAH_DATA OBSAH_INVENTORY

exec obsah "$@"

Most probably: yes. We originally went this route, as the current ApplicationConfig in obal contains executable code (os.getcwd() for the inventory etc), which would need more logic in this wrapper. rop probably won't have that, so it can be easier.

That said, this is an improvement we can do later. Or are you hinting at "then we don't need a python package after all"?

I think it's an interesting idea, that we should capture but I'd like to see us get further and through more of the complex bits before we decide that it can be that simple.

We also have some non-collection things in our tool like the metadata. I guess we could put it in there but would the collection validators complain?

That said, this is an improvement we can do later. Or are you hinting at "then we don't need a python package after all"?

I was thinking about that. At least for the prototype it would keep things simple if we don't need a Python package.

Then when we get closer to an actual installer (and perhaps tool to replace foreman-maintain) we can look at how to build it. For example, foreman-maintain configure could be the new installer entry point (with an foreman-maintain install as an alias).

theforeman/obsah#75

I like the "simple shell script" idea, as it not only reduces the amount of (boilerplate) code, but also simplifies the directory structure in the repo. OTOH the current state in the PR works fine and would allow us to continue iterating.

Read this comment as: ACK, merge it, unless you want to rewrite it again right now :)

We also have some non-collection things in our tool like the metadata. I guess we could put it in there but would the collection validators complain?

Collection validators don't care much about additional files

theforeman/obsah#75

that's merged, and the following works after a git mv cli/data .:

#!/bin/bash

OBSAH_NAME=rop
OBSAH_DATA=data
OBSAH_INVENTORY=./inventories/
export OBSAH_NAME OBSAH_DATA OBSAH_INVENTORY

exec obsah "$@"

do whatever you want with that info :)

Then when we get closer to an actual installer (and perhaps tool to replace foreman-maintain) we can look at how to build it. For example, foreman-maintain configure could be the new installer entry point (with an foreman-maintain install as an alias).

Are you thinking this would be recreated in Ansible and follow the same CLI model? Or that it would require some real code in python that would be handled?

Are you thinking this would be recreated in Ansible and follow the same CLI model? Or that it would require some real code in python that would be handled?

That will depend on how much of the functionality we keep. I'd love to keep it minimal but at this point I'm unclear on where we'd end up and if it's realistic.

Closing in favor of #143