In general on moving it. It might be useful to make distinguish existing commands from new ones. Bold or italic?
Personally I question the need for katello-service given it’s a thin wrapper around systemd. Could we not achieve the same by using systemd targets for list and systemd ready protocol for actual alive checks? Using native tools is generally better than inventing them ourselves.
Can we make sure we provide deprecation’s, I’m sure you would anyway.
foreman-maintain is not mentioned once in the manual. so some documentation needs to be written.
Questions:
Do all those commands currently work without Katello?
How are we going to handle differences between what is required with and without Katello or other plugins, for example backup, restore, service are going to be different.
If foreman-maintains goal is to provide a single command that works across multiple versions and subparts of Foreman and plugins. I’m worried that adding more and more functionality makes that goal harder and harder to reach.
Good question, I’m not familiar with these kinds of checks so I’ll let others who are comment on this.
+1 We likely will redirect the katello scripts to the appropiate foreman-maintain command with a warning.
foreman-maintain is not mentioned once in the manual. so some documentation needs to be written.
+1 We will also have to require foreman-maintain in some way with foreman + katello installations if that is the expected way to backup/restore/etc.
Do all those commands currently work without Katello?
How are we going to handle differences between what is required with and without Katello or other plugins, for example backup, restore, service are going to be different.
Currently these commands do not, but this will be part of the transition, i.e. backup will backup the databases that are present, skipping pulp/candlepin for foreman installs.
If foreman-maintains goal is to provide a single command that works across multiple versions and subparts of Foreman and plugins. I’m worried that adding more and more functionality makes that goal harder and harder to reach.
That is a great point. I’m not sure what versions foreman-maintain supports (n-1, n-2?), but generally these scripts keep the same fundamental parts and changes are more usability + bug fixes. If we did need to support something that is broken in earlier versions, we would probably check gem or package versions and handle appropiately. I’m curious to hear what others think as well.
Foreman-maintain provides a code to auto-detect features (plugins presence, databases, proxies etc) which can be used in the scripts to decide what to do. The idea is that there would be just one backup script that, in case of Pulp or Candlepin being around, would perform additional backup procedures for those backends.
It’s also meant to be able to run that on proxy side: the idea is that one could run foreman-maintain backup on an server/proxy and it would do the corresponding steps to do the right thing based on what’s installed.
So far, that was not that much of an issue, but I see your point. What would help is an extensive set of end-2-end tests, that we could run against different versions to make sure that the thing is still working on every release we support (which would be a good thing to have anyway). Once we would have this, keeping that compatible with older releases would be much easier: the hardest thing is just to learn that something got broken.
I agree we need to find some balance with this. The goal is to provide single place and unified interface for common maintenance tasks. I don’t think we aim to backport all the scripts to all version and plugin combinantions and it is okay to say that this command is not supported on your setup. On the other side it is possible and might make sense to do it sometimes as in case of backup/restore.
I also beleave the scripts we already have will be easier to maintain when are on one place as parts of them overlap and we implement some checks over and over.
By debug you mean foreman-debug? That means that all plugins or packages which extends foreman-debug (e.g. katello or smart-proxy) would need foreman_maintain dependency. I am fine with that, we just need to keep that in mind. Katello ships foreman-debug part in subpackage I think, katello-debug.
yes debug here means foreman-debug so this is a good point.
We will also end up with foreman-maintain as a dep for foreman core and proxy anyway for other reasons such as backup/restore and katello-service. foreman-maintain itself has minimal deps so it should not have big impact.
In the past we’ve talked about introducing a client repository (similar to katello-client). At some point I’d like to consider this again for tools that have a loose coupling to Foreman. To me foreman_maintain and hammer are good candidates for this repository. We’ll probably need to look at our SCL (since hammer is SCL’ed) so this is just a thought for now.
It’d also be good to support this repo on more distros than core. Supporting Fedora again is still on my wishlist.
Could you please give short details about scripts you mentioned under ‘content’.
As per my opinion,
backup, restore, service, debug, certificates are good candidates for sub-commands like health/upgrade/advanced. But remaining ones we can implement using existing definitions i.e check/procedure.
We already have tags method in metadata so that if someone wants to run group of checks/procedures.
on moving it. It might be useful to make distinguish existing commands from new ones. Bold or italic?