On Fri, Aug 05, 2016 at 03:58:37PM -0400, Jason White via luv-main wrote:
>Robin Humble via luv-main <[email protected]> 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
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Reply via email to