I'm not sure if something changed in dkms, but this log file is
helpful on centos 9-stream and the other check doesn't match anything.
Also update the README.rst slightly to be more in line with reality.
Change-Id: Ic8cab980ef43490eb1b3ca0b7a0d0c2329bb94ce
Grab the make logs from the dkms directory. This is helpful if the
modules are failing to build.
The /var/lib/dkms directory contains all the source and object files,
etc., which seems unnecessary to store in general. Thus we just trim
this to the log directory.
Change-Id: I9b5abc9cf4cd59305470a04dda487dfdfd1b395a
It seems we have some debugging to do on the openafs roles. The other
roles here, particularly the bazelisk one, aren't tested here, so
reduce the file matcher.
We can overhaul this more, but it seems like a post-puppet/xenial
thing to do.
Change-Id: I0a41ef48eab0560a23a4e29463435dfe0758d01e
We have pivoted to Ansible and We don't use puppet5 anywhere. Stop
testing on Bionic as we're not really interested in maintaing it, and
remove the puppet-install installation path there so we don't have
code that isn't being tested.
Change-Id: Ia2d05f7c75e46bc01717d11457b832e42522fa95
This change will convert kdc03 to a master from a hot standby and will
remove kdc01 from management.
Cutover plan:
Disable kdc01 in ansible emergeny file
Stop run-kprop cron on kdc01
Stop kadmind on kdc01
Execute run-kprop.sh on kdc01
Merge this change
Wait for puppet to convert kdc03 to the master
Confirm that run-kprop works from kdc03 to kdc04
Update dns records as documented in our kerberos docs
Test kadmin works
Delete old kdc01 server
Change-Id: Ib14b11fa1f0a6bc11b0f615ce5b6f6be214b5629
Currently our puppet-requiring hosts (all !bridge) do not manage their
puppet installs. This is OK for existing servers, but new servers
come up without puppet installed.
This is playbooks to manage puppet installs on hosts. It is mostly a
port of the relevant parts of ./install_puppet.sh for our various
control-plane platforms.
Basic testing with zuul-integration jobs is added. Using this in the
control-plane base.yaml playbooks will be a follow-on.
Change-Id: Id5b2f5eb0f1ade198acf53a7c886dd5b3ab79816
The top-level roles in roles/* should be usable as roles under Zuul
and as generic Ansible roles (for control plane).
Add an integration job to ensure this. Start with the kerberos and
afs roles.
Change-Id: I9f5d572d5f69ca4b58e6e62b06fc873fe7a1e2f0
Ian Wienand