remove/reset conf if removed from yaml

[ewelinawilkosz]

currently the plugins works in a way that doesn't allow us to remove configuration with yaml for example if I have warnings parser configured and I remove that section from yaml the parser configuration stays - it should be removed

[jetersen]

The way it would be possible is to have the old yaml file stored somewhere so you can compare the two to see what was removed and then apply the removal.

[ndeloof]

with yaml file merger (https://github.com/jenkinsci/configuration-as-code-plugin/commit/bdf0f0f47fea6d7641fc9741113ac4293409fee7) it should be possible to keep the current yaml data in memory while (re)parsing configuration, and then detect such removals.

[ndeloof]

In a perfect world we could compare export with incoming config to compute a delta, but we are far from being able to generate a valid export. So hard for us to detect changes made to yaml without storing a copy of the applied configuration, which isn't a pleasant approach. Maybe as a temporary workaround ? (I hate the idea such a "temporary workaround" will be there for ages...)

[ewelinawilkosz]

let's not do temporary, we won't have this feature until we have time to think of and implement long-term solution

[ndeloof]

I don't expect we can get a reasonable export implemented on current jenkins codebase, we could rely on for this feature. Maybe we could get this improved in Cloud Native Jenkins with direct support in core for this use-case.

[philomory]

I think there does need to be some nuance here, in terms of allowing certain configuration sections, or certain plugins, or what-have-you, to be ignored by CASC so they can be manually managed. For example, I may (as a system administrator) want to use CASC to strictly manage securityRealm, authorization, cloud and credentials-related settings, but still allow individual developers to create jobs without having to go through CASC to do so. In that case, I'd want a credential that wasn't in CASC to be removed from Jenkins, but I don't want the same to happen with jobs.

The trick, of course, is that different use cases will need these behaviors for different sections of the configuration, so I think ultimately what would be needed would be a general system for indicating a preference of "ignore unmanaged items" vs "purge unmanaged items" on a case-by-case basis. Exactly what granularity would be appropriate for that, I'm not certain; certainly the top-level keys are not granular enough (having to make a single choice for all of 'uncategorized' is certainly no good).

[ndeloof]

You're perfectly right this is both a question of use-case and granularity. As we configure a target component we can reset it to defaults and apply configuration, but it is not obvious in yaml config what are the boudaries of a "component". Especially when it comes to the jenkins root element and some nested attributes (securityRealm, ...) which are all atomic when set. Today, if you remove securityRealm from yaml, jenkins will keep using the previous configuration, and won't revert to default settings. This is bad for our goal to offer reproducibility.

[codiophile]

In a perfect world we could compare export with incoming config to compute a delta, but we are far from being able to generate a valid export. So hard for us to detect changes made to yaml without storing a copy of the applied configuration, which isn't a pleasant approach. Maybe as a temporary workaround ? (I hate the idea such a "temporary workaround" will be there for ages...)

I don't understand what's wrong about storing the applied yaml. Seems like the most logical, reliable and straight forward way of doing it. Not being able to unset configuration seems much worse. Like orders of magnitude worse.

Is there at least a workaround for this or how are people managing this in the wild?

[emmaLP]

Experiencing a similar problem except using multiple yamls file for config. If I remove a config file the config still stays after a reload of config and even restarting.

[ChristianTackeGSI]

This happened the other way around for me just a few days ago:

• I expected manual configuration to not be touched by JCasC configuration, unless explicitly overriding a specific value.
• Use case: We're slowly migrating manual configuration to JCasC configuration. So if we need to change a config value, we put exactly that value into JCasC. We can't do "all or nothing" yet.
• We recently got a new jenkins agent node. All our other nodes are still manually configured. Looked like a good opportunity to add that single node to JCasC and to start learning how this works.
• Result: All other nodes got removed from jenkins. So I needed to go to the backups and restore the part with the node config.
• Finally adding the new node manually, because we can't yet migrate all nodes to JCasC.

So in the sense of https://github.com/jenkinsci/configuration-as-code-plugin/issues/191#issuecomment-438075202 granularity at specific levels seems a good thing!

[jetersen]

You usually have to go block by block.

We do offer a export feature, so could take the entire agent blocks and bob's your uncle. https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/features/configExport.md

Why can't you migrate all nodes to JCasC with the export feature?

[kyounger]

Would it make sense, as an interim measure, to have a "strict" mode, where if the config is NOT explicitly defined, it does not configure (or reverts to default)?

[maifujalam]

Faced similar issue,removed docker cloud from jenkins CasC.yml and reloaded.Then also docker cloud is present.Please fix it ASAP.