Chaoshub with private repo and docker.io images

[djkormo]

I decided to add private repository with the chaoshub for my litmus (3.16) projects. Next I have changed all images in the repo to use my private docker images. But when I setup my experiments using ready faults I still see the image: docker.io/litmuschaos/litmus-checker:2.11.0 is still using docker.io.

Where is it hardcoded ? The same with image: litmuschaos/k8s:2.11.0 . How to get out of this behaviour ?

[Jonsy13]

Hi @djkormo

Here are documentations -

• For configuring image registry - https://docs.litmuschaos.io/docs/user-guides/image-registry
• For configuring default chaoshub incase of airgapped setup - https://docs.litmuschaos.io/docs/troubleshooting#we-have-installed-chaoscenter-successfully-but-the-litmus-chaoshub-is-in-error-state-and-manual-cloning-of-a-git-repository-does-not-work

Can you try it out & let us know if this is working. Surely, we need to restructure more & even create a separate documentation for air-gapped installation. cc: @S-ayanide

[djkormo]

I have two chaoshubs. One is public and default (this is my local developer setup) . I have access to public repositories. The second chaoshub will be private. How to remove this public one or make it not default ? On the real environment I will not have the access to public repositories.

Using mongodb client I see only private chaoshub added via GUI (!).

Where is this configured this public one and how can I remove it or disable it ?

[djkormo]

Hello! @Jonsy13

I cannot understand the concept of this default chaoshub.

1. It is hardcoded in golang code.

https://github.com/litmuschaos/litmus/blob/master/chaoscenter/graphql/server/pkg/chaoshub/service.go#L963
https://github.com/litmuschaos/litmus/blob/master/chaoscenter/graphql/server/utils/variables.go#L32

2. It not visible in the mongodb document in the dedicated chaoshub collection

3. Default configuration in the helm chart uses the emptydir volume type. It means that after restart everything is cleaned.

     volumes:
       - name: hub-storage
         emptyDir: {}

From not only my perspective it should be configurable via dedicated environment variables for server deployment or server binary should accept several configuration flags. It is a common way to build kubernetes operators using kubebuilder or simmilar tools.

[SarthakJain26]

Thanks @djkormo a lot for raising this and sharing your thoughts 🙏

Let me clarify the idea behind the default ChaosHub:

• The default hub is bundled inside the control plane binary mainly to ensure that users can start experimenting with LitmusChaos immediately after installation, without needing to configure or connect an external hub.

• Because it is embedded, you won’t see it in the chaoshubs collection in MongoDB. Only additional/custom hubs that a user connects are persisted in the DB.

• The Helm chart uses an emptyDir volume so that the artifacts of the default hub don’t persist between pod restarts. This is intentional to keep the setup lightweight and ephemeral. The expectation is that users who want persistence or custom content will add their own hub, which then gets stored and managed in MongoDB.

That said, your suggestions are very valid 👍:

• We could look into making the default hub configurable through environment variables or flags, so advanced users have more control over the behavior.

• Persisting the default hub (via PVC or a similar approach) could also be an optional configuration for users who want hub content to survive restarts.

We’ll take this feedback into our design discussions.

For your use case:
You can simply add your private ChaosHub (via UI/API), and it will be persisted in MongoDB. Your experiments can use faults from the private hub without depending on the default one.

[djkormo]

"You can simply add your private ChaosHub (via UI/API), and it will be persisted in MongoDB. Your experiments can use faults from the private hub without depending on the default one."

But I cannot remove this default public chaoshub using GUI/API. All users in the disconnected setup are complaining this behaviour. I have to click my dedicated private repo after getting error from the public one.

[SarthakJain26]

Yes @djkormo, currently the option to remove the default hub is not supported mainly for the reasons I mentioned above.
@ksatchit what's your views on making the default hub configurable

[SarthakJain26]

Had a discussion with the team, we can make the custom hub configurable. I see @Calvinaud has raised a PR to make the default hub configurable.
#5066
@djkormo any views on this