Refactor AIO script and fix for Epoxy #1705
Conversation
product-auto-label
bot
added
size: l
documentation
|
I'd like to remove the "manual setup" section of the docs. It's duplicated effort trying to maintain two versions (script and docs). There's a few useful bits at the bottom about Ironic testing and Tenks, but I don't think they're tested/maintained well. Any objections? |
| /stack/kayobe-automation-env/src/kayobe-config/.automation/pipeline/tempest.sh -e ansible_user=stack | ||
|
|
||
| activate_kayobe_env | ||
| sudo -E docker run \ |
There was a problem hiding this comment.
You could run everything inside kayobe-automation or were you going the other way and removing kayobe-automation?
The nice thing about using the kayobe automation execution environment is that would be the same execution environment as the CI jobs.
There was a script to make things easier to run:
Although maybe it needs extending to add some additional variables. Then it would be something like:
.automation/run-local.sh .automation/scripts/runbook-overcloud-deploy.sh
and you wouldn't need to set up the kayobe environment. You can also use it to interactively. The gist is:
docker run -v $PWD:/stack/kayobe-automation-env/src/kayobe-config --network host -v /tmp:/tmp -v ~/backups:/stack/backups -d --name kayobe-zed-staging-$USER -v /usr/bin/docker:/usr/bin/docker -v /var/run/docker.sock:/var/run/docker.sock -v /etc/pki/:/etc/pki/:ro -v /etc/ssl/certs/:/etc/ssl/certs/:ro -v $HOME/.ssh/gitlab:/stack/.ssh/id_rsa:ro -v $HOME/.ssh/gitlab.pub:/stack/.ssh/id_rsa.pub:ro --privileged kayobe:zed-$USER sleep infinity
docker exec -it kayobe-zed-staging-$USER kayobe-automation-activate
There was a problem hiding this comment.
That's an interesting idea, I hadn't really considered using Kayobe automation for more of the deployment.
Like you say, the environment would be more CI-like, which could be handy when resolving CI-related issues. It might also make it quicker to deploy if we could have an option to pull an existing kayobe automation container, rather than create it fresh each time.
The flipside is that it becomes less production-like, so it really depends on what you want to do with the environment. I guess it might also make it harder to develop something like Kayobe or Kolla Ansible themselves, since it gets wrapped up inside the container.
Either way, my focus with this was just to improve the formatting and usability of the script we have, rather than change how it actually works. I think if we do something like that it should be a follow-up PR once we decide how it looks.
There was a problem hiding this comment.
We may of course also want to use this script (or something like it) in other situations.
We could make it the definitive way to run an AIO and use it directly in CI, which might make sense when we're moving to zuul. In that case we'd definitely want kayobe automation support.
It might also be a good starting point for an Azimuth app, but I'm less sure of how they work behind the scenes
|
CI error can be ignored. Known upstream issue, should be fixed soonish |
No description provided.