Having trouble persisting config map edits

charmhub requests
1

I found that whenever I made changes to config maps, they seem to get reverted to the original after a few days.

Example 1: Save pipeline logs to MinIO and show logs in UI

I changed environment variable ARGO_ARCHIVE_LOGS in deployment/kfp-ui to true and changed configmap/argo-controller-configmap-config to look like this:

...
data:
  config: |
    artifactRepository:
      archiveLogs: true
      s3:
...

This worked for a few days before they both returned to the original settings where logs are not displayed and not saved to S3.

Example 2: Setting default image for Jupyter notebook server

I changed configmap/jupyter-ui-config-config to this:

...
    spawnerFormDefaults:
      image:
        value: my/image:latest
        options:
        - my/image:latest
...

It also worked for a few days before changing back to the original default images.

Based on @wallyworld’s comment here, Juju creates these config maps. So I assume my changes are overwritten by Juju? If so, is there a way to prevent that from happening? Or are there other ways to achieve what I want to do?

2

Hi @alexsudoku,

Sorry about these issues. Your suspicions are correct - those are objects that are managed by Juju so it occasionally reconciles them back to the state it expected. Unfortunately, we do not have those settings exposed in the charm config so there’s no simple way to do what you’re attempting.

It isn’t so hard to do it yourself though. If you want something right away, I think you’d need to fork the charms, modify what you need, and build/deploy your new charms. Both those charms have templates for the configmaps you’re editing, so if you edited the template directly (plus set the environment variable in the charm code) you can get a persistent version of the changes you wanted. Downside being that you now have a fork to maintain. It’ll probably be quite easy (every few months you might need to do a diff and a quick patch), but otherwise work. If you are interested in this, check out these resources:

You’d want to fork each repo, make the changes, and deploy them into your cluster from a local copy of the charm.

If you come up with a flexible way to expose these options without heavy config changes, we’d also love to have those as PRs on the above linked repos. It isn’t that we’re against exposing configurations like these, just that either we’ve tried to keep things simple or that we haven’t gotten to exposing them yet. If you have a nice way of exposing them without going into a “user must be an expert and do everything” sort of scenario, we’d love to look at it!

3

Thank you for your reply! I’m able to get the results I want by packing and deploying my own charms just like you said.

I would definitely like to have these configurations exposed so that users only have to do a simple juju config to set them. Maybe I’ll be able to come up with a PR once I have the time to figure out how charms work.

1 Like
4

Glad to hear that you got unblocked @alexsudoku! If you feel comfortable with sharing your current charm we are happy to work with you to get it into a state where it could be added to our charms.

5

I made some simple changes only.

I added archiveLogs: True, between line 97 and 98 in https://github.com/canonical/argo-operators/blob/main/charms/argo-controller/src/charm.py#L97-L98.

And I changed the image names in https://github.com/canonical/notebook-operators/blob/main/charms/jupyter-ui/src/spawner_ui_config.yaml# line 20-28 to my own images.