#Manually provision an engine

1 messages · Page 1 of 1 (latest)

jagged charm
#

Is there a way to pre provision and engine such that dagger GitHub action doesn’t try to start its own engine and kill other running engines?

prisma temple
#

what's your current setup and what are you trying to achieve? so we can give the best advise here

jagged charm
#

When upgrading engines on busy repo it’s really difficult to land the upgrade as new PRs running on old engine versions with kill the engine upgrade PRs.

#

But the other use case is to pre start the right engine on the runner host with all of the required flags like setting the cache dir. rather than letting the action to start the engine.

prisma temple
#

gotcha.

starting the engine manually is basically starting a container with some specific flags and a particular name so the dagger CLI can find it and use it. This is the code that performs that: https://github.com/dagger/dagger/blob/9419454effd67b2d0abff2a18f46490c041823bb/engine/client/drivers/docker.go?plain=1#L64

the command that ends up executing is basically this one docker run -d --restart always --privileged -v /var/lib/dagger --name dagger-engine-v0.19.8 registry.dagger.io/engine:v0.19.8

the important thing to note from the above is the container name as well as the fact that the image and the name version should match

#

that's pretty much it. If you then run a dagger pipeline with a client on the v0.19.8 version, it will pick up that engine automatically and use it without provisioning a new one

jagged charm
#

Thank you for that.

But is there any way to prevent dagger from killing these in favour of other versions? I’d rather it just fail with an error saying engine mismatch.

prisma temple
#

take into account that if you do that, you might end up with multiple engines on the same node

jagged charm
#

Thanks!!

jagged charm
#

Ok, any other ideas? I think what is happening is that some older, stale PRs might be pushed to, and they still contain old config, as noone had updated from main.

#

So it nukes it down to v0.19.3

#

We didnt use v0.19.3 almost from the beginning. We were on .6 until yesterday.

#

I have no even idea where this is coming from would have to check every open PR branch to see

#

I need the server to somehow deny this. I guess I could set the env on the runner too

slow hearth
#

There is apparently a breaking change (withDirectory.directory -> source) and I need to account for long-lived release branches

jagged charm
#

Yes. it does in both directions

#

which I also think is the cause of our other problems, with the layers or cache

#

as it writes into the same dir

#

I think maybe engines need to namespaces the dir further by version

#

I just set the DAGGER_LEAVE_OLD_ENGINE flag on our runner, and now I see two engines running side by side

prisma temple
jagged charm
#

Not sure if they will succeed tho given that they use the same dir

#

@prisma temple Not sure, at least GH action will upgrade and downgrade

#

We do use that flag too

#

I don't know if this is the GH action itself that does it or the engine, but the result is that the versions keep going up and down

#

😄

slow hearth
#

I already use the _EXP... var, problem is it is globally set...

prisma temple
jagged charm
#

I do see from the logs that GC is still happening, unless I don't understand what is considered garbage

#

but it was doing clean up, you can see from the logs I shared

slow hearth
#

right, I think what I want to do for the 0.18 is drop the env var, then if one of those builds starts, dagger will start it up automatically

jagged charm
#

Oh wait, do you mean the docker-container://$container-name part is the imoportant bit not the var itself?

#

Because we set it to a hostname, where Docker runs

slow hearth
#

but... (see me newer post), if there already was a way to set just the registry dagger uses on that auto-start pull....

slow hearth
jagged charm
#

ya name matches too

prisma temple
jagged charm
#

I was clarifying if the _EXPERIMENTAL_DAGGER_RUNNER_HOST env var is important, or the actual value needs to be docker-container... because we use _EXPERIMENTAL_DAGGER_RUNNER_HOST but set it to a network hostname

slow hearth
jagged charm
#

Ok interesting...

#

But how to deal with the shared mount dir?

#

if both engines will use the same volume

#

Or is this volume not host mounted?

prisma temple
prisma temple
#

by default it GCs existing running engines unless you set the DAGGER_LEAVE_OLD_ENGINE env var

prisma temple
jagged charm
#

@prisma temple but you were asking me if we use a shared EBS volume. If the engine does not share the volume with the host, why this would be a problem? Or were you just assuming we host mounted the volume?

#

So there's really no issue then running multiple engines in parallel?

prisma temple
prisma temple
jagged charm
#

by that you mean we didn't manually start it with host mounted volume which is shared?

prisma temple
#

yes, I was assuming you were manually starting the engine wuth with shared host volume

#

Dagger doesn't share the cache volume across engines when starting multiple in the same machine

#

it's not supported

jagged charm
#

Yes, perfect. Understood.

#

To confirm, no, we didn't. It was auto-started by the dagger client.

#

Which then still is strange that we are seeing so many weird errors. I was already thinking that we can write that off to the volume sharing. 😄

slow hearth
prisma temple
jagged charm
#

What happens when I set this:

_EXPERIMENTAL_DAGGER_RUNNER_HOST=docker-container://$container-name

But the container does not exist? Will the client try to infer the version from the name somehow or will it just fail as it can't find this container?

young cosmos