Metricbeat tarball is oddly named.

[ghost]

For config management, it would be really nice to have filenames for all the Beats that are consistent, predictable and composable.

Metricbeat is kinda unique in its naming right now. Specifically, the generic Linux tarball has:

• Architecture: x64 not x86_64.
• linux in the filename, where Filebeat for example does not.

Filebeat:

https://download.elastic.co/beats/filebeat/filebeat-1.2.3-x86_64.tar.gz

Metricbeat:

https://download.elastic.co/beats/metricbeat/metricbeat-5.0.0-alpha3-linux-x64.tar.gz

It would be good if the linux string was either present of absent from all packages.
Having the architecture be x86_64 is really useful, since that's what Puppet and Ansible will return if you ask for the host architecture.

I'd like to be able to say this in Ansible:

metricbeat_version: 5.0.0-alpha3
metricbeat_file: metricbeat-{{ metricbeat_version }}-{{ ansible_architecture }}.tar.gz
# -> metricbeat-5.0.0-alpha3-x86_64.tar.gz

Thanks.

[tsg]

@Jarpy Regarding the linux in filename sometimes missing, note that you are comparing filebeat 1.2.3 with metricbeat 5.0. The filenames should be consistent among Beats in 1.x, respectively in 5.x, but because we want to do some changes for 5.0 and because we cannot retroactively change old artifacts, we have to live with the inconsistency.

Doing the change from x64 to x86_64 now.

[tsg]

PR open. For reference, this is how we expect the 5.0 artifacts to be named:

filebeat-5.0.0-amd64.deb
filebeat-5.0.0-darwin-x86_64.tar.gz
filebeat-5.0.0-i386.deb
filebeat-5.0.0-i686.rpm
filebeat-5.0.0-linux-x86.tar.gz
filebeat-5.0.0-linux-x86_64.tar.gz
filebeat-5.0.0-windows-x86.zip
filebeat-5.0.0-windows-x86_64.zip
filebeat-5.0.0-x86_64.rpm

@Jarpy please let me know if that looks sane.

[ghost]

Lookin' good :)

Sorry though, I should have realised this earlier...

I would also go with i686 (or at least i386) over x86 for the Linux binaries. Since:

uname

vagrant@localhost:~$ uname --hardware-platform
i686

Facter

vagrant@localhost:~$ facter .os.architecture
i386

vagrant@localhost:~$ facter .os.hardware
i686

ohai (Chef)

vagrant@localhost:~$ ohai | jq .kernel.machine
"i686"

Ansible

vagrant@localhost:~$ ansible localhost -m setup -a 'filter=ansible_architecture'
localhost | SUCCESS => {
    "ansible_facts": {
        "ansible_architecture": "i386"
    },
    "changed": false
}

vagrant@localhost:~$ ansible localhost -m setup -a 'filter=ansible_machine'
localhost | SUCCESS => {
    "ansible_facts": {
        "ansible_machine": "i686"
    },
    "changed": false
}

Sadly, nobody seems to really want to draw a line between i386 and i686. Is the Go compiler optimizing for the i686 instruction set? (I assume so).

[ghost]

More discussion in https://github.com/elastic/dev/issues/635#issuecomment-226556132, suggesting i(3|6)86 may not be such a great idea :)

[ruflin]

Closing as I think this problem was resolved.