Don't change output of `garage layout show` if staged layout is the same as the current #295

New Issue

Closed

opened 2022-04-23 21:15:02 +00:00 by mediocregopher · 2 comments

mediocregopher commented

2022-04-23 21:15:02 +00:00

Background

I'm currently working on a project which involves automating the creation and management of garage instances. Each host in the cluster will have 1 or more garage instances, and my intention is that each host will configure the cluster layout for its instances on startup.

To do this I've written some scripts which look at the current cluster layout, and compare that to what the expected layout is based on the host's local configuration file. The scripts do a diff between the two, and attempt to reconcile the current layout into the expected one.

Problem

Writing these scripts has been difficult, primarily because the output of garage layout show is unstructured and so is not easy to parse. I was forced to write a fairly involved go script in order to overcome this.

Solution

One solution which I suggested over matrix is to provide a structured output option for garage layout show. I was informed that there is an issue already, #231, which should cover that.

A second solution I suggested over matrix, and was asked to make this issue for, is to only change the output of garage layout show if the staged layout is different than the current one.

If this solution were implemented then my scripts could be vastly simplified. I would not need to parse the output of garage layout show at all, I would only need to issue garage layout assign commands which correspond with what layout my cluster should have, and then check garage layout show for the string ==== STAGED ROLE CHANGES ==== to see if any changes actually need to be applied.

# Background I'm currently working on a project which involves automating the creation and management of garage instances. Each host in the cluster will have 1 or more garage instances, and my intention is that each host will configure the cluster layout for its instances on startup. To do this I've written some scripts which look at the current cluster layout, and compare that to what the expected layout is based on the host's local configuration file. The scripts do a diff between the two, and attempt to reconcile the current layout into the expected one. # Problem Writing these scripts has been difficult, primarily because the output of `garage layout show` is unstructured and so is not easy to parse. I was forced to write a [fairly involved go script](https://gist.github.com/mediocregopher/5fa34526054a85a15292a861a1529074) in order to overcome this. # Solution One solution which I suggested over matrix is to provide a structured output option for `garage layout show`. I was informed that there is an issue already, #231, which should cover that. A second solution I suggested over matrix, and was asked to make this issue for, is to only change the output of `garage layout show` if the staged layout is different than the current one. If this solution were implemented then my scripts could be vastly simplified. I would not need to parse the output of `garage layout show` at all, I would only need to issue `garage layout assign` commands which correspond with what layout my cluster _should_ have, and then check `garage layout show` for the string `==== STAGED ROLE CHANGES ====` to see if any changes actually need to be applied.

quentin added the

Improvement

label 2022-04-24 15:09:04 +00:00

lx commented

2022-04-25 15:48:04 +00:00

Owner

Hi @mediocregopher, thank you for your interest in automating Garage deployments! I think there is two parts to this:

Fixing garage layout show to not show entries in "staged role changes" which are identical to entries already existing in the layout, and to mask the "staged role changes" section when it only contains such entries. This is a bug in how the command is currently implemented and we want to fix it.
Having a machine-readable format for administration commands, be it using the CLI or through a REST API. We discussed internally that on the long term we'd rather have a REST API as it gives more flexibility on how to use it (and we can still implement a CLI that does calls to the API). Ultimately, we want to have all of the commands currently in the garage CLI available from the API, which is the subject of #231 but is also a lot of work. A first step we will be taking soon is to implement a first very limited subset of the admin commands in the admin endpoint (which we recently added to export Prometheus metrics). We could start with cluster status and layout management commands, as you have expressed a demand for them.

I am reclassifying this issue as "bug" so that it is only about point 1. Point 2 will be discussed in #231.

Hi @mediocregopher, thank you for your interest in automating Garage deployments! I think there is two parts to this: 1. Fixing `garage layout show` to not show entries in "staged role changes" which are identical to entries already existing in the layout, and to mask the "staged role changes" section when it only contains such entries. This is a bug in how the command is currently implemented and we want to fix it. 2. Having a machine-readable format for administration commands, be it using the CLI or through a REST API. We discussed internally that on the long term we'd rather have a REST API as it gives more flexibility on how to use it (and we can still implement a CLI that does calls to the API). Ultimately, we want to have all of the commands currently in the `garage` CLI available from the API, which is the subject of #231 but is also a lot of work. A first step we will be taking soon is to implement a first very limited subset of the admin commands in the admin endpoint (which we recently added to export Prometheus metrics). We could start with cluster status and layout management commands, as you have expressed a demand for them. I am reclassifying this issue as "bug" so that it is only about point 1. Point 2 will be discussed in #231.

👍 2