Sean P. Kelly

Another alternative for lower-stakes dev environments could be to specifically remove the PDBs in those environments.

>The TLS failure is an interesting one that we might need to take a further look I was chatting with @ytsssun and he mentioned that this is an expected output...

I'm not confident that this is all that's needed, but in order to support this we'd at the very least need to: * Our self-signed certs need to be created...

We've been investigating this issue and the chain of trust appears correct as-implemented in Brupop today. We shouldn't need to refer to the "top-level" self-signed certificate authority for SSL to...

Ah, I think the change mentioned in [this comment](https://github.com/bottlerocket-os/bottlerocket-update-operator/pull/595#discussion_r1894190514) by @v0lumehi is actually more in-line with how we wish to use the chain of trust: > Since it might help...

From [the ENA driver docs](https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/ena/README.rst#mtu): > The driver supports an arbitrarily large MTU with a maximum that is negotiated with the device. The driver configures MTU using the SetFeature command...

Not immediately helpful to solving the issue, but another point to note is that our Bottlerocket variants that use `wicked` are approaching their end-of-life (`aws-ecs-1`, `aws-k8s-1.27`). Only needing to support...

One challenge here is that `schnauzer` depends on `apiclient` in order to fetch the settings needed to render a template. We may similarly need to publish Bottlerocket's `apiclient` as a...

With changes to Bottlerocket's settings system introduced in core-kit [6.0.0](https://github.com/bottlerocket-os/bottlerocket-core-kit/releases/tag/v6.0.0), we no longer need to move `schnauzer` -- we can just remove it from this repository.

I spoke with @monirul yesterday about an idea to programmatically verify that feature unification has not taken place. Since we need to do a settings-sdk release for the new models...