* Allow any recursion and cache queries for named svc
* Bump maas v3 to the actual version
Signed-off-by: Ruslan Aliev <raliev@mirantis.com>
Change-Id: I16a4ec843dc73a2349e8603d4200920599eab918
The named and nginx processes both try to use all available CPUs. In
addition, there is a bug in named that sometimes causes it to spin on a
FUTEX, pegging the CPU.
This change constrains those processes to a single CPU (overridable in
values.yaml), and includes /etc/bind/bind.keys in named.conf to avoid
the CPU spike.
Change-Id: I4a278023f5c0dd5e7bdee46891591b278f2ddcad
This updates the maas chart to include the pod
security context on the pod template.
This also adds the container security context to set
readOnlyRootFilesystem flag
Change-Id: I1eba6ab3a7c27ddcb3e8ddc8e743b91dc5e521c3
With the existing readiness probe mechanism, if log rotation occurs
then it may lead maas rack pod to show false not ready. Instead save
the success message of rack registration to a file and then use it in
the readiness probe.
Change-Id: I569b99186d398db44a10824dc3fe8c745b13a4ac
- Add a new pod running syslog to receive syslog
messages containing the console logs of bootstrapping
nodes. This aids in troubleshooting without requiring
accessing the OOB console.
- Add a UDP forwarder to the MAAS ingress controller
as nodes attempt to send syslogs to UDP 514 of the region
controller
Change-Id: I3f508225f4394a90c6f2534a51f262b42c1afa4e
The maas-rack and maas-region containers can successfully run and function
as non-privileged if given the appropriate Linux capabilities. This change
is a security enhancement as the maas-rack and maas-region containers now only
have access to the capabiities it needs to do its job - instead of having full
root access.
The capabilities listed in the `statefulset-rack` and `statefulset-region`
charts function as a whitelist in that the maas-rack and maas-region containers
only have access to the Linux capabilities listed in their SecurityContext
along with the default capabilties that Docker gives to unprivileged containers.
The default list of capabilties include the following:
- SETPCAP
- MKNOD
- AUDIT_WRITE
- CHOWN
- NET_RAW
- DAC_OVERRIDE
- FOWNER
- FSETID
- KILL
- SETGID
- SETUID
- NET_BIND_SERVICE
- SYS_CHROOT
- SETFCAP
The bcc-capable tool [0] was used to discover which Linux capabilities the
maas-rack and maas-region containers invoke. The capabale tool, has the ability
to record the Linux capabiltiies that are invoked by all the processes running
in the container. While still running as privileged, the capable tool was
installed and ran within the container during maas bootstrapping. When
bootstrapping was complete, the list of Linux capabilities were reviewed and
added to the appropriate charts.
[0]https://github.com/iovisor/bcc/blob/master/tools/capable.py
Change-Id: I11cf1da8ea8219320c4d3028502c133391116201
- Add a readiness check for the rack pods. This really only applies
when they are spawned and will not be useful for ongoing readiness
evaluation. Should eliminate false 'completions' of the chart
deployment.
Change-Id: I5b547976e770302d2cc293396e1041798ac7e4ea
- Some residual static configuration was left in the MAAS ingress
deployment template. Update it to render the ingress ports from
endpoints and also to remove the TCP forwarder for the MAAS
region API and instead use a standard Ingress resource.
Change-Id: I7764d48ea919147503e9bf2521c52cb6f0028538
All containers were already running in non-privileged
containers except region-controller and rack-controller.
Both of those require privileged containers but
can still function with the docker-default apparmor
profile applied.
This PS uses the new, more generic HTK snippet name
(see https://review.openstack.org/613703).
Change-Id: Icaa720f05b18f4264ae7098b427fe5f639cba2c6
- Create two replicas of rack and region pods
- Use required anti-affinity between rack pods
- Remove the MAAS ingress controller from the rack pod
and into dedicated deployment
- Update rack registration script to harvest the systemid
from the underlying host when available
Change-Id: I41e21b7bb5256d04b37a70fbd2088c617b5d239a
Upgrades to the MAAS chart to allow for the Pods
running the rack and region services to work across
all control plane hosts.
Change-Id: I84c856599a1122a2b4a64242a7cea357887b0462
This PS adds the ability to attach a release uuid to pods and rc
objects as desired. This can be used, for example, to force an
artificial manifest change in CICD scenarios, for upgradability
testing purposes.
Change-Id: I994f9eb9cd75947ee36276a542fa23cc547065e0
This PS updates the maas chart to support modern helm toolkits.
Change-Id: Id70343afdec622dc84b89b0d7f496e9ef498ea6b
Signed-off-by: Pete Birley <pete@port.direct>
This PS removes a duplicate initcontainer key and values from
the rack controller template.
Change-Id: I18b157b9cf7256e7acc574da9cdfecbe51dc13d6
Signed-off-by: Pete Birley <pete@port.direct>
- Use a statefulset and PVC to make rackd systemid assignment
stateful between pod restarts. This is to alleviate instability
in MAAS upgrades.
Change-Id: Iea5c3d3897b561d4ba479203ee6aec5885282e1a
SPEARS, DUSTIN (ds443n)