Bug 1593483 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

There was unfortunately another bug that meant that if generic-worker found the generic-worker config file on the host, it didn't update the function to fetch the latest deployment ID from the default, which just checks the local file.

The solution I've implemented is to have a `gwconfig.Provider` interface that has a `UpdateConfig(c *gwconfig.Config) error` method for updating the generic worker config settings, and a `NewestDeploymentID() (string, error)` method for fetching the newest deployment ID.

The provider is set on startup, so the correct method will be used for fetching the deployment ID. The UpdateConfig method of the provider will be called if there is not already a generic-worker config file available, otherwise the config file will be loaded. This is also how updating config worked before, but the difference is that the deployment ID fetching logic is now independent from the config updating.
There was unfortunately another bug that meant that if generic-worker found the generic-worker config file on the host, it didn't update the function to fetch the latest deployment ID from the default, which just checks the local file.

The solution I've implemented is to have a `gwconfig.Provider` interface that has a `UpdateConfig(c *gwconfig.Config) error` method for updating the generic worker config settings, and a `NewestDeploymentID() (string, error)` method for fetching the newest deployment ID.

The provider is set on startup, so the correct method will be used for fetching the deployment ID. The `UpdateConfig` method of the provider will be called if there is not already a generic-worker config file available, otherwise the cached config file will be loaded. This is also how updating config worked before, but the difference is that the deployment ID fetching logic is now independent of whether there is a cached config file or not.

Back to Bug 1593483 Comment 3