Want to store and search for device hostnames

[bdha]

We currently only provide the ability to search for devices by serial number.

There is existing ops tooling that relies on the system hostname for lookups. We need to add another device field for the hostname, and make it queryable.

The new conch-reporter-smartos report (version:2) already includes the hostname parameter:

[root@east1a-admin01 (us-east-1a) /var/tmp/conch-reporter-smartos]# ./bin/conch -c /var/tmp/.conch.json api get /device/$( sysinfo | json 'Serial Number' ) | json id latest_report.os.hostname
8SCLRD2
east1a-admin01

Further, the shell should have a flag for conch device :id --type or similar that defines what :id is.

[karenetheridge]

The new conch-reporter-smartos report (version:2) already includes the hostname parameter:

As I still don't have VPN access, I can't get to east1a-admin01 to see what the new report format looks like.

[sungo]

If the host has posted a device report already, you can just get it via the shell or api

[bdha]

Hostnames in Triton tend to be a combination of "prefix" and part of the host serial number. Like MS12345 for Manta Shrimp, or HA67890 for Hallasan-A servers. Hostnames from other hosts (like admin servers) might be something else entirely.

Regardless, it's always a string.

[bdha]

@karenetheridge Should this piggy-back on https://github.com/joyent/conch/pull/367? /device?hostname=foo. It will need to dig into the device report to get the hostname, and should likely always return an array, just in case.

[karenetheridge]

Yes, it will probably use the same interface. ditto for searching for triton uuids or any other device attributes we want to search on.

[bdha]

Hostname should be a unique field. We will have to some work in the reporter to ensure this is true for things that do have the same hostname (like tagging on the datacenter name for headnode.)

[bdha]

This might mean that hostname should be copied off the report stack and shoved into device.hostname.

[karenetheridge]

conch api get /device/S329229X8822031 | json | grep host returns nothing -- and I don't see hostname as a valid entry in the DeviceReport schema. We will need to work out where this goes in the new report schema, bump the version, and add support in report processing, for it to be stored in a new column in the device table.

[bdha]

The SmartOS reporter has not been deployed everywhere yet, so only a couple of systems actually have the new field.

10:04:45 gaea:~$ conch api get /device/8SCLRD2 | json latest_report.os.hostname
east1a-admin01

I have made a task for the livesys reporter to supply this in preflight/integration: https://github.com/joyent/conch-livesys/issues/87

[bdha]

https://github.com/joyent/conch-livesys/issues/87 has been closed and will be deployed shortly. No builds are currently active, but things will start showing up in a few days.

[karenetheridge]

things will start showing up in a few days

Has this been tested against conch-staging? There is a defined schema for device reports, and introducing new fields without updating the schema will cause much breakage and sadness.

[bdha]

Historically the API will accept any data -- if it's defined in the JSON struct, it validates the input. But it doesn't know about the fields, it ignores them and stores it in the reports table raw.

It's quite obvious now that we can't do this anymore and the JSON struct should be the source of truth. If it's not in the struct, we should reject the report. (This is problematic for velocity reasons, but it's YOLO reporting is causing a lot of tooling problems.)

[perigrin]

That historical behavior changed in b46d511e857a14374fd0b1b05d3d6db7a01c6291.

[karenetheridge]

code is done; PR to be submitted pending other things being merged first.

[karenetheridge]

done in #410