terraform: remove cloud loggers #2892
Conversation
msanft
requested review from
3u13r,
daniel-weisse,
thomasten and
malt3
as code owners
✅ Deploy Preview for constellation-docs canceled.
|
msanft
force-pushed
the
feat/terraform/remove-cloud-loggers
branch
from
52e7349
to
c5be663
Compare
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com>
Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com>
Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com>
|
|
||
| You can view this information in the following places: | ||
| To debug issues occurring at boot time of the nodes, you can use the serial console interface of the CSP. |
There was a problem hiding this comment.
I think this option is actually disabled everywhere where its possible for non debug deployments.
There was a problem hiding this comment.
Also seeing the output? Or only logging in?
There was a problem hiding this comment.
Verifying this currently. I think we should have a read-only console on all CSPs
There was a problem hiding this comment.
Ah, you mean the serial console is disabled via the CSP, but not in a CC-secure way, right?
There was a problem hiding this comment.
Well, the read-only configuration is embedded in our image and thus also "CC-secure", but the cloud provider may preserve the logs after boot, which we seemingly explicitly turn off where possible. However, the serial console in all cases is read-only and, using our image, doesn't disclose any sensible information, so I don't think it's a problem.
There was a problem hiding this comment.
Yes, I didn't mean that there's a security issue. I only remembered that, in addition, we may have turned off serial console access/preserving via VM settings as a kind of best-effort approach.
Coverage report
|
* terraform: remove cloud logging apps * internal/cloud: remove loggers * bootstrapper: remove logging * qemu-metadata-api: remove logging endpoint * docs: add instructions on how to get boot logs * bazel: tidy * docs: fix typo * cloud: remove unused types * Update go.mod Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com> * bazel: tidy * Update docs/docs/workflows/troubleshooting.md Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com> * Update docs/docs/workflows/troubleshooting.md Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com> * Update docs/docs/workflows/troubleshooting.md Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com> * docs: elaborate on how to get boot logs * bazel: tidy --------- Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com> Co-authored-by: Thomas Tendyck <51411342+thomasten@users.noreply.github.com>
Context
With the deprecation of Azure's Application Insights, we need to migrate away from using them for cloud logs. After a discussion, we concluded to remove cloud logging altogether, as we aggregate such logs in our CI through OpenSearch, and customers can use CSP APIs or deploy their own logging infrastructure to get to the boot logs.
Proposed change(s)
Important
When Azure disallows the creation of new application insights resources, users won't be able to create new clusters with an old Constellation version still relying on said resource. Thus, this change should be included in a release before the resource is abandoned. Existing clusters should not break, given there is a brownout period for existing application insights resources.
Additional info
Checklist