#API inconsistency with AsService using

1 messages · Page 1 of 1 (latest)

tawdry saffron
#

I was discussing with @manic mist and it would makes sense to tie this one to the 0.14 release. Would anyone have room for the implementation? @radiant dune @echo summit @thin yarrow @night stratus ?

manic mist
night stratus
#

I can take on the first part 👍

night stratus
#

When are we targeting 0.14 release

manic mist
#

Friday

night stratus
night stratus
manic mist
#

cc @echo summit @radiant dune (won't ping Erik and Justin since they are on vacation)

echo summit
#

Are all the options from withExec necessary?

manic mist
#

same problem we had with Terminal.

night stratus
manic mist
#

We definitely do need those

#

Oh sorry the first one we need

#

the second, I don't even know what that is

night stratus
#

that is the comment from code ^^

manic mist
#

It doesn't seem to be visible to regular clients. I have no idea what it is or how it works, so I'll just ignore it 🙂

echo summit
#

Yes, you only need those exposed to the client so you can pass them to withExec.

night stratus
#

👍 okay, sounds good. so I will add these changes and try running integration tests. I am hoping those will help us identify other scenarios that we might not have considered yet.

#

I'm starting to feel like we have an API mess to cleanup... Lots of duplication between "execute a command and return"; "execute an interactive shell and return"; "execute a long-running service";

@manic mist, without a lot of background (and experience) on why some decisions were made in dagger, I would expect a lot of these to work like how they work in Docker (while I understand its a different frontend for buildkit). is that expectation not correct?

manic mist
night stratus
#

right but coming from an enduser perspective (who has past experience using Docker), the long-running service in dagger should behave similar to docker run.... and interactive terminal should behave similar to docker exec/run -it...... - right?

manic mist
#

For API or CLI?

#

The problem with Docker is that those two experiences are nothing alike..

#

Because Dagger promises an API-first design, with the CLI being just another API client, we have an additional constraint. With Docker we didn't have this constraint. We made it a CLI tool only in the beginning. Then later added a very basic REST API that is not powerful enough for our use cases.

#

I agree it would be nice to have a more direct equivalent from the most familiar Docker commands, to the equivalent Dagger commands.

night stratus
#

thank you for the additional context.

#

I'll continue on these changes and will try to make PR reviewable by tomorrow.

manic mist
#

@night stratus do you have a specific idea in mind for making Dagger more familiar to Docker users? If so I'm interested in hearing it!

#

(one thing that might help indirectly, is making our core types interfaces, which we talked about doing. This would create more flexibility. For example the same object could "be" a container and "be" a service)

night stratus
#

I really love the idea of writing reusable code for managing docker images and local setups. As someone who has written a lot of dockerfiles and docker-compose files, i want to explore how i can use dagger for local env setup without a lot of hacky scripts etc.

#

I recently migrated one of my project to start using dagger for local dev env, (ui, db and backend components), i do miss the “watch” functionality

#

Next i want to try dagger for a complex env setup. Eg in my last job i was managing a docker compose setup that used services from 10-12 different services. (And have seen multiple such projects in past) I want to see if dagger can help with that kind of usecase.

#

But having the ability to rebuild and restart just one service is imp for that kind of setup and i am not entirely sure if that kind of usecase is a good use of dagger but i do want to try it out 🙂

manic mist
#

cc @runic gust 👆

night stratus
#

I have seen a project as Cisco (via a friend) that uses golang + templating to generate dynamic docker compose files for local env spin up

manic mist
#

@night stratus do you think of Dagger as a replacement, or possible replacement, for Docker itself? That topic keeps coming up.

night stratus
#

I mostly run my personal services on Kubernetes, and use docker for building and pushing images, so yes i think dagger can replace docker for my limited usecase.

#

One other thing i really miss (probably due to my lack of understanding of some parts of dagger api) is that i can check what containers are currently running and exec into a running container. A “dagger ps” and “dagger exec” command could be useful for debugging usecases

#

Also helps bridge the gap for someone coming from docker background

#

I was thinking to do something hacky with dagger + nsenter

manic mist
#

cc @runic gust @tawdry saffron 👆 🙂

night stratus
#

I have another question regarding these changes. When starting service, why are we keeping default value of UseEntrypoint as false. I would think we should keep it as true (the same default as Docker and our earlier AsService implementation).

I am asking this question as I am adjusting some tests in our integration suite to add UseEntrypoint: true to make them work

echo summit
# night stratus I have another question regarding these changes. When starting service, why are ...

Short answer: we want to discourage people on using entrypoints.

The reason it's unwanted is because it's a legacy Dockerfile thing that stuck, and doesn't make sense in Dagger. So we only support it for compatibility reasons but we'd prefer if people move off of it, especially if building containers via Dagger instead of a Dockerfile. By defaulting to false we make it more explicit when the entrypoint is required.

night stratus
#

👍🏻 got it, thnx

night stratus
#

to update on progress here: The changes are done, but there are existing test cases which are failing. I am chasing down the failures and fixing them.

night stratus
#

@fleet dome

fleet dome
#

relaying this from @lapis goblet as a wrap up comment from yesterday's exchage:

to really get this working in 0.14, I'd either use-entrypoint or I'd add stuff to make up for some of the things in the docker-entrypoint.sh. Maybe some with-execs ...not sure how many needed. Would def make it more explicit.

just had a quick sync with @night stratus and he'll try to squeeze this in (get the PR in a green state) for today's 0.14 release with the modification of UseEntrypoint being default true for the case of services.

cc @magic pasture. @manic mist @echo summit @lapis goblet. So we can have one last ack before merging.

manic mist
#

no ack... we spent an hour discussing this to get consensus, no last minute changes on the side please.

echo summit
manic mist
#

also there is no rush on merging for the release

fleet dome
#

ok, we're holding this one off then

fleet dome
#

but if we're ok with postponing to 0.15 then SGTM!

fleet dome
manic mist
fleet dome
manic mist
#

Let's try to discuss it today with some of the people from the original decision? Ideally @fleet dome @lapis goblet we would have asked you from the beginning.

echo summit
#

Yeah, ping me.

manic mist
#

i just want to avoid "split brain" in the design

manic mist
#

@echo summit @radiant dune do you mind if we take a few minutes to discuss this with @lapis goblet and @fleet dome ? I just freed up

lapis goblet
#

👍

echo summit
manic mist
#

OK cool, joining dev-audio then

#

@dense flame @night stratus feel free to join if you're around and interested (since I see you on the thread)

radiant dune