-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Initial support for podman + docker-compose #15986
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Erik Berg <[email protected]>
Semantic versioning, they're called major, minor and patch. Signed-off-by: Erik Berg <[email protected]>
Signed-off-by: Erik Berg <[email protected]>
Alter the regex to check for what the binary/program reports itself to be. If it's podman and version 3 or above, there are compatability layers introduced to support docker-compose with podman. https://www.redhat.com/sysadmin/podman-docker-compose Signed-off-by: Erik Berg <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #15986 +/- ##
==========================================
+ Coverage 66.81% 66.83% +0.02%
==========================================
Files 934 934
Lines 77761 77761
Branches 2296 2296
==========================================
+ Hits 51955 51971 +16
+ Misses 21791 21779 -12
+ Partials 4015 4011 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Can this be reviewed, please? The only reason this currently does not work is because Harbor currently does a hardcoded check for the docker-version This version of Docker is ancient. Another way to make it work with podman is to just remove this version check. |
Hey everybody, Apologies for not working on this anymore. Last August, I moved to a different role where my involvement with Harbor has essentially ended. Hopefully, @bpereto or @wy65701436 will be able to make it happen :-) Best of luck! |
Hello what's the status here?
It failed almost at the end because it was using --log-driver=”driver”
Logging driver for the container. Currently available options are k8s-file, journald, none and passthrough, with json-file aliased to k8s-file for scripting compatibility. (Default journald) So |
Yeah there's more to it than just this. These changes just allow you to get further than dying at docker < 17.06. As Christian pointed out, this version is "ancient", and quite possibly the whole check should just be removed as you did. I think these individual commits are no-brainers, and have no idea what the holdup is in merging them. Maybe "Initial support" is a bit strong wording, and "allow for" would be better, as I didn't actually get it all the way working. I've since switched to quay. If any of the commits seem illogical, I can trim them out and rebase. (Incase they prefer part1/part2 over major/minor) |
maybe it isn't merged because it's not fully working that way, as said the |
I think the issue with the syslog logging driver is slightly related to the issue #16594 . If Harbor would just log to stdout/stderr like a proper container should, this issue would also be solved implicitly.
|
This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days. |
Still very relevant, at least for me. I still hope someone is able to make the log-driver configurable. |
adding flexibility here is a good thing, let's try to get that in. @leonidas-o did you try the PRs, does it work for you? |
@Vad1mo unfortunately no, back then, I have done it like described here, so really just removed the hard coded docker checks and realised that the hard coded log-driver is blocking me. I agree, adding flexibility is definitely a good thing. Do you have a setup to test the PRs? Otherwise I will have to spin up a VM for that. |
This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days. |
hi, thanks for the contribution. Since currently podman+docker-compose is not in the support scope, and we need time to evaluate it, like what's the impact and how do we test it. |
I wonder if it would be easier if this would be treated as a feature request for, let's say:
Obviously you guys don't have the resource to support podman and I think this isn't necessary. Maybe laying the focus on smaller items like, optimisation and clean up. With this two changes, you would open up the door for the community to come up with a podman solution. Then it can still be: "Podman is not officially supported" but everyone who is interested, like me, can try to make it run, document the approach and maybe upload it somewhere in the harbor docs, clearly saying, no not officially supported but using this approach should make it run. And who knows, maybe one day, one find some time to look into it and make it officially supported, if not, simply keep it unofficial. I think this is definitely better than completely locking out podman by using hard coded log-driver and docker checks. |
@leonidas-o It makes sense to expand the support list for the harbor. To me, it's more like a feature request. If we agree that this is a feature request or a new feature, I would like to follow this procedure. This PR is not enough to introduce podman support as we don't even have any tests, this at least includes podman setup, pull/push (single imge, imge index), retag, etc. cc @qnetter |
According to: goharbor/harbor#15986 (comment) I'm submitting this document to give the start for a possible harbor podman support. Signed-off-by: Leo <[email protected]>
@wy65701436 created a PR, feel free to update it if something isn't right: goharbor/community#208 |
Some minor cleanups and support for podman/docker-compose combination,
https://www.redhat.com/sysadmin/podman-docker-compose