Does it Work with GitOps?

[rowi1de]

Visited you talk today at SRE Munich 👏🏻
One open question: Does it Work with GitOps ?

Very good definition from https://github.com/readme/featured/defining-gitops

The desired state of a GitOps managed system must be:

1. Declarative: A system managed by GitOps must have its desired state expressed declaratively.

2. Versioned and Immutable: Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.

3. Pulled Automatically: Software agents automatically pull the desired state declarations from the source.

4. Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.

• Does mirrord modify the original pod?
• I assume the additional mirrord pod is running outside any deployment or similar and could be considered "orphaned" resources. Based on the policy of the GitOps Agent it might wipe the pod immediately due to reconciliation

[aviramha]

In general and best to our knowledge, we're agnostic to the resources being managed using GitOps.

1. No, it doesn't. It spawns a pod on the same node and enters it's Linux namespaces so it is dependent on it being alive.
2. AFAIK applying means making sure managed resources are up to date and shouldn't affect unmanaged, but this ofc depends on the GitOps agent you use - do you have one in mind? we can check that specifically.

To add more context, mirrord is a utility and not an infra software. It runs, provide you functionality then when it ends nothing remains in your cluster so in general it is not related to GitOps or how you manage your resources :)

[rowi1de]

shouldn't affect unmanaged, but this ofc depends on the GitOps agent you use - do you have one in mind? we can check that specifically.

Cool thanks for the explanation, I'm mainly using ArgoCD with https://argo-cd.readthedocs.io/en/stable/user-guide/orphaned-resources/

Orphaned Kubernetes resource is a top-level namespaced resource which does not belong to any Argo CD Application. The Orphaned Resources Monitoring feature allows detecting orphaned resources, inspect/remove resources using Argo CD UI and generate a warning.

this means it could be disabled on the target namespace or probably an ignore rule, does the new pod follow a naming pattern?

[aviramha]

According to the docs it's only warning in that case - maybe there's advanced configuration to also delete? though it sounds extreme.

Yes, you can put the mirrord pods in a specific namespace and ignore it, also the pod has the following name mirrord-agent-xxx. where xxx can be more than 3 characters

[rowi1de]

mirrord pods in a specific namespace

sounds like infra changes needed for a tool. It's warning only, but would pop up in grafan dashboards etc. for ArgoCD Stats

mirrord-agent-xxx

if three developers use 3 mirrord commands will it be three agents?
If it is pod specific, why not the the orignal pod name and extend it with -"mirrord"?

[aviramha]

if three developers use 3 mirrord commands will it be three agents?

If they're running without mirrord for teams (operator), then yes. if not, depends if they run on the same pod - if they do the operator will use one agent for them all.

If it is pod specific, why not the the orignal pod name and extend it with -"mirrord"?

It's a good suggestion but I fear that might cause issues since we can easily reach the pod name limit.

[eyalb181]

Hey @rowi1de , we were wondering if you kept exploring this direction with mirrord? We're curious about the use case and would love to know if it worked (or the reasons why it didn't), + help out with implementing it fully if that's still of interest.
We're also available on Discord or Google Meet.