Create refactor_log-driver_docker-check_podman-support.md

[leonidas-o]

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 leonid.orsulic@freenet.de

[Vad1mo]

Good idea, we should not make Harbor dependent on Docker.

[wy65701436]

@qnetter ping for awareness.

[OrlinVasilev]

+1

[OrlinVasilev]

@leonidas-o can you provide a bit more information here about the implementation please as @wy65701436 would love to review! Thanks! Also are you able to work on this one if accepted @leonidas-o ? :)

[Vad1mo]

@leonidas-o can you provide a bit more information here about the implementation please as @wy65701436 would love to review! Thanks! Also are you able to work on this one if accepted @leonidas-o ? :)

@OrliX, I think the initial implementation is already there in the referenced PR

[OrlinVasilev]

@Vad1mo wrong Orlix :) @OrlinVasilev here :D anyway ... in the morning PR triaging @wy65701436 wanted to have some more meat here so the proposal is complete in the terms of implementation! @wy65701436 can you comment what exactly you were referring ? Thank you! :)

[leonidas-o]

@OrlinVasilev unfortunately I can't provide more info on the implementation itself, see the point Proposal in my submitted doc:

Either setting Harbors default log-driver to something Docker and Podman can work with or making it configurable by the user.
 This leads to the following two proposals:

 1. The `--log-driver=syslog` must be configurable or a default value chosen which is supported by Docker and Podman.
 2. All version checks for explicitly docker or docker-compose has to be removed or extended to work with Podman.

So it's a decision you guys have to take. For each point, both ways work (1. syslog configurable or new default value, 2. checks removed or extended), the question is, which way you want to go, which way makes to most sense for the product?
Afterwards, as soon as someone has done that (it shouldn't be even a breaking change.) Then as I said, I can try to bring it over to podman and work on that.

[OrlinVasilev]

@leonidas-o thank you so much!
@wy65701436 please check above ^^ :)

[wy65701436]

besides the installation, have you tried to use podman(like we are doing on docker) to interact with Harbor, pull/push oci invidual artifact and index?

[wy65701436]

To have the podman into the support list is a good idea, I would like to see this proposal can cover all parts of podman support, rather than just refactor the log driver part.

Do we need to enable podman pipelines for any pull requests?
Which podman version do we recommend starting support from?
What are the implications for harbor helm or operator?
Do we have an engineering epic that includes all the subdivision items? This way we can track the engineering process and see in which version we can have it.

[leonidas-o]

Don't know if the question according to the interaction podman to harbor is for me, but yes, I'm using podman all the time with harbor. In fact the most of my VM's are running with podman. I've also got a gitlab-runner on podman, which is pulling from harbor, tagging and pushing to harbor.

"Which podman version do we recommend starting support from?"
Podman isn't critical I would say, using the latest as we are starting from scratch anyway. E.g. time of writing 4.3.0. I would rather say, podman-compose is way more critical. I would even suggest waiting for the next release after v.1.0.3, as I expect there will be some bigger changes in auto pod creation: https://github.com/containers/podman-compose/tags
v1.0.3's behaviour with that is not good to be honest.

[Vad1mo]

@wy65701436 I think it would make sense to push this forward, more and more people are nowadays using podman.
I am happy to provide and extend the implementation.