Feature #20263
openforeman integration with GIT
Description
I would like to have the possibility to revert any changes in foreman. After a mistake I could go back to the previous config of a smart class parameter etc. Also, there would be some detailed information about the life cycle of a node (what's all being changed in the last couple of month for example).
The yaml of every node in GIT would be nice. Just to track down some history.
Updated by Marek Hulán over 7 years ago
I would like to have the possibility to revert any changes in foreman. After a mistake I could go back to the previous config of a smart class parameter etc.
Would a versioning similar to what we have for provisioning templates work? It's based on audit logs where we already track all attributes changes.
Also, there would be some detailed information about the life cycle of a node (what's all being changed in the last couple of month for example).
What are the information you're missing from audit logs?
The yaml of every node in GIT would be nice. Just to track down some history.
I think you can get yaml representation of all Foreman objects easily through hammer, e.g. hammer --output yaml host info --id 1
, scripting exporting of resources and putting into cron should be easy.
Updated by Jason Lang over 7 years ago
Totally Jumping on this as i agree with this 100% even if i am not OP - have been meaning to submit this request for awhile now.
Would a versioning similar to what we have for provisioning templates work? It's based on audit logs where we already track all attributes changes.
In my opinion (again not OP) this would be sufficient yes. The idea is I want to be able to see what it WAS as well as what it IS to allow easy reversion.
What are the information you're missing from audit logs?
In my opinion - the audit log is usable if you know exactly what you are looking for. As an example, I have a host buried 3 layers deep in a hostgroup (root\hostgroup1\subhostgroup123), and I change "param123" on hostgroup1, it changes the param on a bunch of machines. But it does not show up in the audit log on the host(s) it is now changed on. It does however show up if i search that exact param change (but again, just mentions it changed, not what it was FROM or TO so it can't be used to easily undo the change). Similarly this happens for params set on Operating SYtems, subnets, location(s) - they do not show in the HOST audit even if they end up changing the effective value on that host.
The net result here is you need to reverse engineer (through code, scoping, etc) exactly what parameter(s) or smartclass parameters "changed" before you cna then search the global audit log to see when it changed. This still doesn't get you what it WAS BEFORE to revert. I understand implementing this functionality would add quite a bit to audits, but I personally would deal with slower audit queries/loads if the "audit" page for a server was more complete.
I think you can get yaml representation of all Foreman objects easily through hammer, e.g. hammer --output yaml host info --id 1, scripting exporting of resources and putting into cron should be easy.
Yes this is technically true. Right now i'm working on a script to export (and save) the YAML when we delete a host via the API - in case we need to undo/revert that for whatever reason. That being said - it would be nice if when i loaded a hosts YAML - it showed me a version history of said YAML including all the changes made (additions, modifications, removals) over X amount of days (configurable). This would also help answer the question "what changed and when" in an easy and quick fashion.
Updated by Michael Rivera about 4 years ago
Integration is one of the most difficult concepts of mathematics. You have to go through many courses of essaywriter.org/graduate-paper-writing-service if you want to get a master's in it. This is the subject of deep mathematics.