Bugzilla

OK, that's a reasonable argument. Let's meet to discuss options. This will also be a good opportunity to formalise the hand off between OpenCloudConfig and ci-configuration.

For example, I could imagine when OCC runs, that it generates an artifact containing machine image names, plus suitable config defaults for generic-worker for e.g. `taskclusterProxyExecutable`. This information could be associated to the machine image names, and stored directly in ci-configuration. Then when ci-admin builds worker pool definitions, it could merge workerpool-specific workerConfig settings with the machine image-specific config settings, so that the separation is clean between workerpool-specific workerConfig and machine image-specific workerConfig. However, it then becomes a function of ci-admin to merge the config, which:

1) keeps config negotiation in generic-worker simple
2) provides transparency of settings to people inspecting workerpool definitions
3) allows for any config settings to be overridden that would otherwise require new machine images to be built

So my feeling is that the separation should be there, just that it shouldn't be low down in the worker implementation to care about it, it should be for the workerpool definition generation code (i.e. ci-admin/ci-configuration) to care about, and if that requires information sharing between OCC and ci-admin, we should formalise that in the design of the interface between OCC and ci-admin.

OK, that's a reasonable argument. Let's meet to discuss options. This will also be a good opportunity to formalise the hand off between OpenCloudConfig and ci-configuration.

For example, I could imagine when OpenCloudConfig CI runs, that it generates a JSON artifact containing not just machine image IDs/names, but also a suitable `workerConfig` object containing appropriate image-specific settings such as `taskclusterProxyExecutable`. This information could be directly stored in ci-configuration, keeping the association between machine image names/IDs and the default `workerConfig` settings. Then when ci-admin builds worker pool definitions, it would merge workerpool-specific `workerConfig` settings together with the machine image-specific `workerConfig` object associated to the images, so that there is a clean separation between workerpool-specific `workerConfig` and machine image-specific `workerConfig`. However, it then becomes a function of ci-admin to merge the configs, which:

1) keeps config negotiation in generic-worker simple
2) provides transparency of settings to people inspecting workerpool definitions
3) allows control of all config settings in a workerpool definition, for cases when the default isn't appropriate

So my feeling is that the separation should be there, just that it shouldn't be low down in the worker implementation. The logical place for config merging to sit is in ci-admin, and if this requires information sharing between OpenCloudConfig and ci-admin, we should formalise that in the design of the interface between OCC and ci-admin. This makes the config overall more transparent, requires fewer steps to load, makes it easier to reason about, more explicit, and simpler to change (no config change requires building new machine images).