Hey, everyone! I'm kinda confused on how to use custom images on a sandbox with Flyte 1.x.x. At first I thought the sandbox would pull the image from my local repository, but this doesn't seem to be the case, since I'm receiving the error

containers with unready status: [ash8dlh4m294mnd9psbs-f62iya2y-0]|Back-off pulling image "flyte-example:1.0"

when trying to execute a workflow, even though I have the flyte-example:1.0 image on my local repo. But, at the same time, it doesn't seem like I should have to build the image inside the sandbox container, right? The container from

flytectl demo start

doesn't even mount the working directory into

/root

. I can't find anything in the documentation that says how to do this...

if you do

flytectl demo start --source .

your working directory will be mounted onto the demo cluster container, and you can use

flytectl demo exec docker build /root --tag …

to build the custom container from within the demo container

Oh, ok, so it's the same behavior as before! But why doesn't it mount to the pwd automatically like

flytectl sandbox start

does?

interesting, I wasn’t aware of that default behavior for `flytectl sandbox`… @great-school-54368 @icy-agent-73298 was there a reason behind this, or should we implement that same behavior for

flytectl demo start

?

@sparse-window-1536 Thanks for bringing this up. Is there a specific doc page that caused this confusion?

@broad-monitor-993 sorry, I'm wrong. The documentation says that `flytectl sandbox start`without the source flag doesn't contain any source code

I honestly thought this new version of the sandbox used the local repository directly, without the requirement of building the image inside the container. I must have read something wrong

so I’m fuzzy on the details (maybe someone more knowledgeable can answer) but from what I understand

flytectl demo

starts a cluster using a single binary for many of the flyteadmin services but still needs to use the docker-in-docker system we used for

flytectl sandbox

to pull images for the postgres service (and I think 2 others), but the result is that it spins up a lot more quickly than old sandbox

that is correct yeah.

@echoing-queen-96254 this section specifically is kinda ambiguous. it says that local images will be available for the cluster without specifying that they have to be build inside the cluster container https://docs.flyte.org/projects/cookbook/en/latest/auto/deployment/deploying_workflows.html#building-images

yes this is good feedback thank you.

yes currently we couldn’t find a way to share the registry within another child container process. If you find a way we would love to have this contribution as it would make it even more simpler. Heres another way i do if i am serializing core examples from cookbook which builds the image in the demo container registry.

flytectl demo start --source ~/flytesnacks/cookbook/
flytectl demo exec --  make -C core/ serialize
flytectl register file  ~/flytesnacks/cookbook/core/_pb_output/*  -d development  -p flytesnacks --version v1
flytectl get launchplan -p flytesnacks -d development  core.flyte_basics.lp.go_greet --latest --execFile execFile.yaml
flytectl create execution -p flytesnacks -d development --execFile execFile.yaml

cc @echoing-queen-96254