m-lab / bmctool Goto Github PK

@nkinkade and I were discussing using the mlab-oti Datastore only for production BMCs / mlab-staging only for staging BMCs. To avoid the need to specify which project to use when creating mlab4d entities, bmctool should be able to automatically detect the correct GCP project to use, keeping the --project flag as a way to override it.

The README is very outdated and should be updated to reflect the current features of bmctool.

I have noticed a few inconsistencies in how bmctool reads (or doesn't) the environment variables and converts shorthand names into full hostname that should be fixed.

Creating this issue to track work done on this PR.

bmctool should have a subcommand like bmctool reboot <host> that makes an HTTP call to the Reboot API to reboot that host via its BMC.

The URL for the Reboot API should be configurable but provide a sensible default based on the project.

A subcommand to execute arbitrary commands on a BMC would be nice to have and would replace a very old script.

Today, it's necessary to set REBOOTAPIURL= in the environment. Additionally, it's necessary to discover the API user and password to construct a URL with the user/password embedded. e.g.

REBOOTAPIURL=https://user:[email protected]

If the project were different, presumably the URL would need to be updated, possibly with alternate passwords. Ideally, for any M-Lab staff with access to GCP, these values can be discovered at runtime.

Ideally, a user who is already authenticated with GCP could successfully run:

go get github.com/m-lab/bmctool
bmctool reboot <host>

This behavior would make the command more accessible to all engineers on the team, and encouraging consistent actions during oncall or other activity.

bmctool generates v1 hostnames by default, which prevents it from working as intended since Credentials entities in Datastore now have v2 keys.

Project auto-detection currently relies on an outdated assumption that all the mlab4s are staging nodes and mlab[1-3] are production nodes. This is not true anymore, and siteinfo is the source of truth to follow.

bmctool must support subcommands, such as:

bmctool forward <host>
bmctool reboot <host>

To do so, it should use https://github.com/spf13/cobra (or something equivalent).

bmctool should have a delete subcommand so that all the CRUD operations are implemented and we never need to edit something manually on Google Cloud Datastore.

bmctool should have a subcommand like bmctool forward <host> <bmc> --ports 443,5900 to create an SSH tunnel via <host> to the specified <bmc>.

bmctool should then keep running on the foreground.

Also, there could be an alias like bmctool web <host> <bmc> to forward ports that are useful to access the BMC web interface, or we could just make 443,5900 the default value for the --ports flag. @stephen-soltesz @nkinkade any thoughts on this?

This subcommand would be useful to allow the automated creation/removal of entities when siteinfo is deployed by comparing the two lists.

Currently, to get DRAC credentials you have to specify the FQDN of the DRAC, which is a lot to type. It would be nice if the -node option allowed one to specify something like:

$ bmctool -node mlab1.den01

... a short name, and optionally not including the d. It should probably accept any of the following and still do the right thing:

• mlab1d.den01.measurement-lab.org
• mlab1.den01.measurement-lab.org
• mlab1d.den01
• mlab1.den01

Currently, if a datastore credential for a DRAC exists, but has wrong information, then only way to fix the record is to either manually delete it and then use bmctool to recreate it, or to manually update it in the GCP console. I would be nice if bmctool could allow for updating an existing record. Perhaps the add facility could be leveraged to create a record if it doesn't exist, or to update an already existing record?

A subcommand to set up the M-Lab Ops team's SSH keys would be useful. It was previously considered adding this feature to the Reboot API, but this feels like a much better place for it.

I would put this under a "manage" subcommand, e.g.
bmctool manage ssh <bmc host> <key slot> key.pub

This command would actually do something only if on the Credentials entity for this has Model: DRAC.