Problems with airship-in-a-bottle install
I've attempted multiple times to install airship-in-a-bottle following the instructions at https://opendev.org/airship/treasuremap/src/branch/master/tools/deployment/a.... I'm running on a 64 GB, 6 core Ubuntu 16.04 VM. During installation, I consistently hit issues with the ucp namespace postgresql-0 and mariadb-server-0 going into CrashLoopBack due to permission issues. I worked around this using a thin wrapper to keep the expected permissions intact on the db data folders. #!/bin/sh while true; do kubectl exec --namespace ucp postgresql-0 -- chown postgres:postgres /var/lib/postgresql/pgdata kubectl exec --namespace ucp mariadb-server-0 -- chown mysql:mysql /var/lib/mysql sleep 30 done I have attached the final pod state and installer status. Any ideas on debugging this issue?
Hello Robby! Sorry that the installation is giving you trouble. I have yet to come across this issue but may be able to help with a little more info.
I've attempted multiple times to install airship-in-a-bottle following the instructions at https://opendev.org/airship/treasuremap/src/branch/master/tools/deployment/a...
What version of treasuremap (i.e. commit SHA) do you have cloned?
Any ideas on debugging this issue?
The only nfs-provisioner pod in your cluster also has an error; were you able to retrieve any logs from it? Also, are you using any custom images? Best, Drew Walters
Hey Drew, Unfortunately, I had to tear down the system and did not get an exact SHA or get logs from the nfs-provisioner. I was not using any custom images. That said, I was finally able to get up and running after another full reinstall (SHA 40797b9d44d2e3ccced0ce2d31b8e2a839a34361). I have only done limited interactions, but all the dashboards seem to be up and will give me a chance to evaluate the system. Just in case any one else hits this kind of issue, one problem I had noticed before teardown was a lot of openstack components stuck in early init phases or in ImagePullBackOff. Checking their state through `kubectl describe pod` showed connection timeouts, TLS handshake timeouts, etc. When trying to manually pull the images in the VM I noticed the download and extract rate was painfully slow (and quite a bit slower than running directly on the host). This led me down the route of looking for any possible performance optimizations for the VM. I've attached my final Vagrantfile and pasted my most relevant environment information below. I continued to run the permissions monitoring script I pasted in discussion opening as well. vboxmanage -version 5.2.34_Ubuntur133883 vagrant version Installed Version: 2.2.6 Latest Version: 2.2.6 You're running an up-to-date version of Vagrant! vagrant plugin list vagrant-disksize (0.1.3, global) vagrant-vbguest (0.23.0, global) On Tue, Jan 14, 2020 at 1:49 PM WALTERS, ANDREW <aw442m@att.com> wrote:
Hello Robby!
Sorry that the installation is giving you trouble. I have yet to come across this issue but may be able to help with a little more info.
I've attempted multiple times to install airship-in-a-bottle following the instructions at
https://opendev.org/airship/treasuremap/src/branch/master/tools/deployment/a...
What version of treasuremap (i.e. commit SHA) do you have cloned?
Any ideas on debugging this issue?
The only nfs-provisioner pod in your cluster also has an error; were you able to retrieve any logs from it? Also, are you using any custom images?
Best, Drew Walters
participants (2)
-
Robby Pocase
-
WALTERS, ANDREW