We believe that the best way to build software is to do it in close collaboration with the people who use it. We invite you to submit your ideas using the form below. Please be sure to include the problem for which you are solving and the benefits of implementing the idea.
We do our best to implement as many Ideas as we can. Our Product team will evaluate all submitted ideas in a timely manner and will disposition each into one of the following categories: will integrate into the product roadmap, further research is needed, unlikely to implement.
Thanks for collaborating with us!
Chef has recently released Automate 4.x, this new version makes use of OpenSearch replacing Elasticsearch
Automate also allows for the use of external OpenSearch in 4.x and external Elasticsearch in 2.x and 3.x as outlined in the docs below
What I believe is not noted, is if you forgo the SSL certs on these setups, Elasticsearch will Default to having NO SSL in place, but with OpenSearch, the Default is SSL on.
for reference, chef automate also allows for external Postgres, as outlined in the docs below
a notable difference in the external Postgres is the ability to control the use of SSL with the following flag
# To use postgres with SSL, Set enable = true then, uncomment root_cert and fill out the certificate value.
enable = false
# root_cert = """$(cat </path/to/root/cert.pem>)"""
This is not present in the external OpenSearch configuration.
Ideally, the above tokenization in the TOML for Postgres makes sense, so replication of this for OpenSearch, ideally something like the following,
enable = false
However, this is not in place at the moment as shown in testing
chef-automate config patch patch.toml
ConfigError: The configuration is invalid: Config file must be a valid automate config: unknown configuration key "global.v1.external.opensearch.ssl.enable"
enable = true SSL should work as expected requiring the root_cert, however when
enable = false SSL should not be in use for communication
This is required for organisations that have been previously happy with the non-SSL traffic and will experience breaking in their Automate systems when upon in-place upgrades
This is also critical for testing in many organisations that don't want to have to deploy root certs across DEV/TEST and ephemeral environments.
Further to this, as it's present for the external Postgres, it seems odd not to replicate this functionality for all external items.
Can this please be prioritised as its affecting clients and as it was part of a previous function, it should be included with Opensearch, especially to make the user experience of upgrading easier.
Attachments Open full size