mirrord when using dagger

[valid forge]

We use mirrord to access the cluster from our machine for testing. Is there a way to use mirrord with dagger?

mirrord: https://metalbear.com/mirrord/

[misty star]

@valid forge how do you see mirrord working with Dagger?

I don't see why they wouldn't work together. I'm mostly trying to understand what UX/DX you're thinking of

[valid forge]

Accessing my groups cluster from local for testing with definitions from dagger

Basically avoid triggering the entire CI during development work for testing specific components.

I am starting to consider just opening tunnels using teleport for instance. Dagger can bind to the local ports...

This discussion is more about alternatives I guess

Alternatives to mirrord when using dagger

[valid forge]

Had an Epiphany: https://github.com/metalbear-co/mirrord/issues/3649

[valid forge]

mirrord when using dagger

[misty star]

@valid forge I'd like to see how a minimal example of what you're trying to achieve looks like but for what I understand about mirrord, it should be possible to just start mirrord within dagger so it connects to your kube environment and from there proxy whatever services you need into it.

For example: if you have a dagger pipeline which starts an API server as a *dagger.Service and then binds it to a client which performs some tests against it. It should and seems not so complicated to wrap this dagger *dagger.Service with mirrord so your client which binds to this service now is running its test against a different environment

so wrapping dagger services with mirrord services for CI testing seems reasonably straighforward given Dagger's current capabilities

[valid forge]

Ideally you wouldn't need to modify the dagger-side definitions. From what I gather, you would need to add Service with your approach.

[misty star]

I mean... It really depends what you have in mind. As I mentioned above, it'd be great to get more context of a concrete use-case you have in mind to understand what's capable today and what it's worth building

[misty star]

It can also be done without dagger services, I just need to understand the use-case better

[fading panther]

hey, thanks for bringing me here @misty star !

[misty star]

looking forward to collaborating in making mirrord + dagger a killer combo

[fading panther]

Ok so to my understanding @valid forge has a workflow that currently works, but they want to be able to execute it in mirrord context without needing to insert mirrord into the workflow itself.
It’s similar to how you can mirrord in a container, but we provide the ability to do it from the outside - it helps with few things:

1. allow you to have one docker file/workflow for both modes
2. You don’t need to think how to pass credentials or have mirrord binary inside your workflow context itself

[misty star]

This could be one option. I am approaching it from the angle that running mirrord within Dagger seems the most Dagger native to approach this IMO. This has the following advantages:

1. No need for users to install a specific version ofmirrord separately. Dagger strengths lie in the fact that you can wrap any tool with it in favor of performance, reproducibility and portability. Having a separate tool invoking Dagger moves away from this core principles.

2. From the UX/DX point of view it also feels better to me to leverage in Dagger. Having a custom module where you can wrap any Dagger primivite with mirrord seems quite powerful. On the contrary, if you limit yourself with mirrord being the one that calls Dagger, the scope of things you can accomplish seems way more limited/restricted.