On Fri, Aug 05, 2016 at 03:58:37PM -0400, Jason White via luv-main wrote:
Robin Humble via luv-main <luv-main@luv.asn.au> wrote:
been there :-/ not sure that's unique to golden image deployments. pretty sure any system can end up like that... I use etckeeper to track configuration changes under the /etc hierarchy in a Git repository.
I've tried just keeping /etc in git, but I found it's helpful to track package changes as well as /var, /root, kernel and... at that point I figured I may as well just track everything. there's always a lot of spam and churn from eg. /var/cache and /var/lib/rpm but it's pretty easy to just git commit that as "cruft" or "yum updates" :)
If that's valuable in your usage scenario, you can obviously install etckeeper and Git in the image that you plan to deploy (perhaps even with the deployed configuration already committed).
there is only one image in the oneSIS system and the whole of the single image is in git, so everything is already tracked. oneSIS 101 is that all nodes run an idential image. so there's not really a separate deployed image or deployed config. all nodes boot to one read-only (usually NFS or Lustre) root image and then small oneSIS tools set up all the differences between nodes as they boot or after you change the live image. oneSIS isn't for everyone - it's mainly for "100's of similar nodes". so the one problem I've had with "everything in git" is the particular set of git hooks to store permissions and ownerships that come with oneSIS can screw up if you ever try to revert or checkout an old revision of the OS. I haven't ever bothered to try and fix it. I just go linearly forward and treat git like a logging system and something that I can use to do 'git log' and 'git diff' against. so it's far from using the full power of git, but it's still great. cheers, robin