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
MAAS API is not longer used and login is not necessary.
This causes issues if MAAS region API is temporary unavailable.
Change-Id: If5d35fb54681954867981902110f2a55efa5e5f3
After a maas-rack pod rescheduling from one node to another,
only delete the node's local maas registration state, and
keep re-registering the maas-rack until success.
Change-Id: I8495ae61f38377d292a26ad09438ece40b2c53c6
- When the register-rack-controller service runs, it removes rack
controllers from all VLANs. However it leaves the VLAN in a
unsupported config with dhcp_on as true and no rack controllers.
Also disable dhcp_on when detaching the rack controllers.
Change-Id: I9f91ac60372873497b67b793940b2675eb98ff64
- The service to register the rack controller pod does not
have access to the MAAS_API_KEY env var so it fails to deregister
when needed.
Change-Id: I16bc63ef14a2dab463dfdca11b7e3ca13d508a9e
- 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
- 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
- If conf.cache.enabled is true, deploy a sidecar container
in the region pod with a simplestreams repo populated w/ a Ubuntu image
- If conf.cache.enabled is true, configure MaaS to source the image
from the sidecar
- Update README
Closes #1
Change-Id: I968614d6fb7ca86589dc6e2efd1f66ae920d03a8
Phil Sphicas