Open edog360 opened 2 years ago
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)
We can't help with Elasticsearch artifacts as we don't own it, but maybe we can help with Elastic Agent.
This issue doesn't have a Team:<team>
label.
Transferred from beats to elasticsearch.
Pinging @elastic/es-delivery (Team:Delivery)
@mtojek @cmacknz I think we should probably align on this across stack artifacts if we were to do something here.
Our use case is that currently we grab the latest version of Elasticsearch via an ansible playbook, where the version number is broken out as a var that sits in an inventory file. Each time Elasticsearch gets incremented in its version, we have to then go update anywhere an Elasticsearch version sits in an inventory file.
@edog360 I'm not sure I completely follow this. So now instead the process would be that the ansible playbooks would always just use latest? I can see why you might want to do this but that's probably the minority. Most folks using toolsl ike Ansible probably want to explicitly specify versions so that applying playbooks doesn't accidentally upgrade things unintentionally.
Can you explain what you mean by "grab the latest version"? Is this still something hard-coded or is the playbook running some code to determine the latest release version?
Hi @mark-vieira
So now instead the process would be that the ansible playbooks would always just use latest?
For our dev & test inventory, that is correct. PROD will still use a 'fixed' version that we have vetted in our lower environments.
Can you explain what you mean by "grab the latest version"?
I can try. We are wanting to have the most latest / up to date Elasticsearch agent version available for public release that is available from the download page.
Is this still something hard-coded or is the playbook running some code to determine the latest release version?
We have our inventory files calling a variable that has the version number in it. (ie; 8.1.2)
Hi @mark-vieira
So now instead the process would be that the ansible playbooks would always just use latest?
For our dev & test inventory, that is correct. PROD will still use a 'fixed' version that we have vetted in our lower environments.
Can you explain what you mean by "grab the latest version"?
I can try. We are wanting to have the most latest / up to date Elasticsearch agent version available for public release that is available from the download page.
Is this still something hard-coded or is the playbook running some code to determine the latest release version?
We have our inventory files calling a variable that has the version number in it. (ie; 8.1.2)
Got it. Would it be possible to resolve this version dynamically instead? In our own build processes we actually use Maven Central as a source of record for all Elasticsearch releases. So one optionn would be to pull down that XML file and determine the latest release from that.
Thank you for the suggestion - we'll need some time to look into this implementation from our side. In the mean time, can we leave this issue open in case we have further questions?
There are no current plans to provide a "latest" URL for release artifacts so I'm going to close this for now.
this would be super useful! any chance this will be implemented soon?
Currently when downloading an Elasticsearch artifact, you can only download from a fixed version, ie; https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.3.2-linux-x86_64.tar.gz
It would be nice to have a latest tag instead of a fixed version, ie; https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-latest-linux-x86_64.tar.gz
Our use case is that currently we grab the latest version of Elasticsearch via an ansible playbook, where the version number is broken out as a var that sits in an inventory file. Each time Elasticsearch gets incremented in its version, we have to then go update anywhere an Elasticsearch version sits in an inventory file.
Having the ability to only call _https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-latest-linux-x86_64.tar.gz_ would be a nice QOL change.