-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker: More convenient access to ipfs commands #3573
Conversation
License: MIT Signed-off-by: kpcyrd <git@rxv.cc>
Mh, I generally agree this is useful, but I'd love to see it backward-compatible. |
I'm not sure what's the sanest way for backwards compatibility, personally I would probably go with a breaking change for the sake of future users. If it really needs to be reverse compatible, I would test for |
Yeah, I agree with @kpcyrd, it'll probably be more confusing to be so backward-compatible that it becomes harder to use certain flags. Makes sense to merge this when we do a minor version bump with other breaking-changes, because this change will in general make a lot of things simpler when interacting with the docker image. |
Lets just do this in 0.4.6 and have a bit in the release blog thing about it |
Can someone write up something small about the changes in the dockerfile here? @lgierth ? |
This command does work though, so it's merely a matter of convenience. I'm not convinced that's enough to justify breaking backward compatibility. (Also, I think it's safe to say that the most common operation with the docker image is starting the daemon.) |
I agree the way I went with is unfortunate in retrospect (hardcoding
That doesn't make it less of a breaking change. |
@lgierth do you want to close this then? |
@lgierth the The only less breaky way I can think of is changing the script to discard the first argument if it's |
After the discussion in ipfs#3573 this patch prints a deprecation warning if: 1) the image has been executed with additional arguments 2) the first argument isn't daemon This way people are able to migrate to the new syntax without any breaking changes.
After the discussion in ipfs#3573 this patch prints a deprecation warning if: 1) the image has been executed with additional arguments 2) the first argument isn't daemon This way people are able to migrate to the new syntax without any breaking changes. Signed-off-by: kpcyrd <git@rxv.cc>
After the discussion in ipfs#3573 this patch prints a deprecation warning if: 1) the image has been executed with additional arguments 2) the first argument isn't daemon This way people are able to migrate to the new syntax without any breaking changes. License: MIT Signed-off-by: kpcyrd <git@rxv.cc>
@whyrusleeping I'm going to keep my branch and reopen this PR a few months after #3685 has been released :) Thanks everybody. |
@kpcyrd sounds good to me, thanks! |
This commit adds `daemon` to the end of the `docker run` args whenever the user passes in `<ipfs-args>` to `iptb start -- <ipfs-args>`. Without this additional argument, the IPFS daemon logs a deprecation warning. We don't want to pass `daemon` into `docker run` when the user hasn't provided additional args, because `docker run` has default args when nothing else is passed. For more info, see: - ipfs/kubo#3573 - ipfs/kubo#3685 License: MIT Signed-off-by: David Grisham <dgrisham@mines.edu>
I had to run
ipfs repo fsck
on my repo inside a docker container, what I had to do:This is because
/usr/local/bin/start_ipfs
is set as an entrypoint and it explicitly startsipfs daemon
.This change keeps start_ipfs as an entrypoint (since it's only doing some docker specific checks), but doesn't restrict you in what you can do.
The above command becomes this:
While, starting the ipfs daemon still looks the same:
Bad news (sort of): people already passing arguments to the docker image have to edit their setup from this
to this:
I still think this is the better approach since overwriting the entrypoint is sort of the non-obvious way for docker beginners (making the ipfs docker image harder to use for beginners).