Split out unit_config config.yaml parameter into multiple parameters
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu CI Engine |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
8:43 AM <ev> vila, doanac: on the unit_config vs juju set deathmatch, another thing I'd like to be able to do is change the CI_LAUNCHPAD_* config details without having to redeploy. juju set would make that possible. Though I was thinking this morning that there's no reason to get rid of the unit_config file, just the base64'd config parameter
8:44 AM <ev> with it being replaced by separate config parameters for each item in it
10:11 AM <hazmat> ev, configuration inheritance should work.. its a merge of the dicts
10:12 AM <ev> hazmat: oooh, via "inherits: "? Grand.
10:13 AM <hazmat> ev, inherits between deployers.. each with a named service that has options.. the child.. gets the parents config options that aren't overridden by the child.
10:14 AM <hazmat> ev, nutshell yes
So this would allow us to say juju set imagebuild-worker launchpad_user=ev and have the change set and the service restarted, all without having to redeploy.
description: | updated |
description: | updated |
Changed in uci-engine: | |
milestone: | none → backlog |
no longer affects: | ubuntu-ci-services-itself |
Changed in uci-engine: | |
status: | New → Confirmed |
we can do that. the reason we originally used unit_config was that every time we needed a new config option you had to update multiple charms to deal with it. Things are more stable now, but getting granular settings like that makes our charms useless to anyone other than us. However, they are pretty much that way already, so i'm not sure it matters.