Improve tls certificate documentation #644
Conversation
scoopex
changed the title
scoopex
changed the title
|
Rereading this I'm actually not so sure what value this does bring. Maybe we could add a generic warning, which really isn't specific to TLS imho, that if you want to do sweeping changes to your Cloudconfiguration, e.g. when testing things, building an evaluation lab etc. you are way better off always to reprovision from scratch your complete cloud. E.g. if you decide in the middle of the cloud install to switch to let's encrypt, or change your cinder backend I wouldn't bet my life on it that everything is properly cleaned up by neither kolla, nor osism. These are - at it's core - configuration management tools, which have trouble tracking current state. These are not infrastructure as code tools such as Terraform, which do track state. So there is always the need in ansible to write dedicated cleanup tasks, if you want to purge/remove something. This also assumes that you can just reconfigure any deployed openstack service on the fly, when these store some settings also persisted in databases, which also might not be as easily available to outside changes, even if you would use something like terraform. The result of all these constraints is, that you usually figure out a working deployment setup, with all your tested settings in git, and then deploy that once. It's relatively smooth to upgrade this then, and with care, you also can introduce changes, but sometimes you need to do manual cleanups, given the above constraints. So in general I would put this up as a warning. A Cloud Infrastructure isn't something where you can easily rip out parts and just replace them with something else. That's even the case if you run everything inside k8s openstack-operators instead of ansible, as these are usually also full of assumptions on what a "supported" configuration looks like. In practice, this often means only one or two knobs are actually configurable by the end user and the rest is enforced via the operators code, which can't be easily changed as well. |
There was a problem hiding this comment.
See my global comment.
I don't think a detailed warning in the loadbalancer guide makes sense. This is a rather global feature about how cloud provisioning works in general.
So we could add a global warning to make large changes with care and that they might require manual cleanup.
Thanks
I agree with you in general. Actually, it would be better to bundle such things in a kind of “pre-installation checklist” and provide information on this topic. As a result of a small pilot project that I have with a prospective scs-user of the public sector, I recently started writing something like this. However, it is still in a very very early and very immature stage and I am very happy to receive ideas and contributions. Nevertheless, I also think it is important to describe this here, because there are specific references to the configuration of domains and certificates (we don't always know which path a user takes or whether the user is aware that information is provided elsewhere). I rephrased the last state a bit to make it better understandable/readable. I also added a new documentation section for Let's encrypt based on the kolla-ansible documentation. |
Signed-off-by: Marc Schöchlin <[email protected]>
scoopex
force-pushed
the
loadbalancer
branch
from
ff02dda
to
7cfbbbc
Compare
There was a problem hiding this comment.
The concrete commands are mostly looking fine, I made just some spelling corrections.
But I think the general warnings throughout the text are to vague and unspecific to be helpful, see my more detailed comments.
Thanks for working on this!
Apart from my comments, the rest LGTM. :)
Co-authored-by: Sven <[email protected]> Signed-off-by: Marc Schöchlin <[email protected]>
scoopex
force-pushed
the
loadbalancer
branch
2 times, most recently
from
17c3768
to
725af1e
Compare
Signed-off-by: Marc Schöchlin <[email protected]>
Signed-off-by: Marc Schöchlin <[email protected]>
Signed-off-by: Marc Schöchlin <[email protected]>
There was a problem hiding this comment.
LGTM, only one nit and the stuff about let's encrypt isn't true anymore in the latest release (since https://review.opendev.org/c/openstack/kolla-ansible/+/925971 was merged) you can in fact run let's encrypt offline now. but this is only a recent addition, so the docs could be adjusted later on.
| kolla_enable_tls_internal: "yes" | ||
| ``` | ||
| As a result, at a minimum, the involved Ansible Plays must be run in the appropriate order, and not all Ansible Plays | ||
| are designed to to handle all possible configuration transitions on their own. |
There was a problem hiding this comment.
nit:
| are designed to to handle all possible configuration transitions on their own. | |
| are designed to handle all possible configuration transitions on their own. |
| For a working Let's Encrypt configuration, the API endpoints (configured by `kolla_internal_fqdn` and `kolla_external_fqdn`) | ||
| must be accessible from the internet. |
There was a problem hiding this comment.
This is not necessarily true anymore since you can configure distinct ACME servers for internal or external usage, they only need to be reachable from the control nodes, see:
so you can now use a private ACME-CA-Server in an air gapped environment.
No description provided.