I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime - The podman container runtime can pull/run a container from Fedora's registry as root - The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria.
There is at least one deliverable that delivers podman in the image (Silverblue). Silverblue isn't release blocking. I don't know if there are others that do ship podman and are release blocking.
On Thu, 2019-08-29 at 10:33 -0400, Dusty Mabe wrote:
I don't know the formal process for proposal
Congratulations, you found it - mail this list, ideally including at least one of the strings 'criter' or 'propos'. :P
but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Do you think this should apply to all release-blocking installs, or should it be specific to e.g. release-blocking cloud images?
On 8/29/19 11:13 AM, Adam Williamson wrote:
On Thu, 2019-08-29 at 10:33 -0400, Dusty Mabe wrote:
I don't know the formal process for proposal
Congratulations, you found it - mail this list, ideally including at least one of the strings 'criter' or 'propos'. :P
but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Do you think this should apply to all release-blocking installs, or should it be specific to e.g. release-blocking cloud images?
Certainly anywhere where podman is shipped on media. Does podman ship in the server DVD? yes [1] It looks like workstation also ships it if I'm reading the logs [2] correctly.
Dusty
[1] https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-31/compose... [2] https://kojipkgs.fedoraproject.org//work/tasks/9101/37319101/anaconda-packag...
On Thu, Aug 29, 2019 at 11:45:44AM -0400, Dusty Mabe wrote:
Certainly anywhere where podman is shipped on media. Does podman ship in the server DVD? yes [1] It looks like workstation also ships it if I'm reading the logs [2] correctly.
Yeah, it's needed for Toolbox, which is a vital feature for Silverblue but also one we want to encourage on general Workstation as well.
Pretty sure it's also required for IoT.
Could we go on a more generic fashion?
Something like "Supported container engines must work on their basic features on all the blocker deliverables were they are installed by default"
Our supported engines are, podman? cri-o?
On August 29, 2019 6:40:21 PM GMT+02:00, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Aug 29, 2019 at 11:45:44AM -0400, Dusty Mabe wrote:
Certainly anywhere where podman is shipped on media. Does podman ship
in the server DVD? yes [1]
It looks like workstation also ships it if I'm reading the logs [2]
correctly.
Yeah, it's needed for Toolbox, which is a vital feature for Silverblue but also one we want to encourage on general Workstation as well.
Pretty sure it's also required for IoT.
Julen Landa Alustiza jlanda@fedoraproject.org
On Thu, 2019-08-29 at 20:15 +0200, Julen Landa Alustiza wrote:
Could we go on a more generic fashion?
Something like "Supported container engines must work on their basic features on all the blocker deliverables were they are installed by default"
Our supported engines are, podman? cri-o?
We could, but I think it's only necessary if there are either a *lot* of criteria and/or we decide to have more than one.
Matthew, Dusty, any thoughts on whether we would want to support any beyond podman? So far docker and cri-o have been brought up. My guess would be we'd probably want podman and not docker, but I'm not sure about cri-o...
On 8/29/19 2:28 PM, Adam Williamson wrote:
On Thu, 2019-08-29 at 20:15 +0200, Julen Landa Alustiza wrote:
Could we go on a more generic fashion?
Something like "Supported container engines must work on their basic features on all the blocker deliverables were they are installed by default"
Our supported engines are, podman? cri-o?
We could, but I think it's only necessary if there are either a *lot* of criteria and/or we decide to have more than one.
Matthew, Dusty, any thoughts on whether we would want to support any beyond podman? So far docker and cri-o have been brought up. My guess would be we'd probably want podman and not docker, but I'm not sure about cri-o...
Well CRI-O and Kubernetes are not ready for the CGRoupsV2 change, Nor is Moby.
I would say podman and buildah should work.
We need changes upstream to get the other packages to be supported.
On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Is Podman are only officially supported container runtime?
What about, say, Docker?
As for which container(s) should be runable, I'd think the criteria should mirror the current virt criteria, e.g., self hosting, and as a container-on-previous-release. I also reckon we should mirror the virt criteria when it comes to a runtime, and 'recommend' a runtime rather than require a specific one.
-- Tapadh leabh, Mairi Dulaney.
On 8/29/19 2:16 PM, Mairi Dulaney wrote:
On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Is Podman are only officially supported container runtime?
What about, say, Docker?
We no longer ship Docker, You need to get that from the vendor. We do ship Moby. But this is not ready for the cgroup change, nor is RUNC.
As for which container(s) should be runable, I'd think the criteria should mirror the current virt criteria, e.g., self hosting, and as a container-on-previous-release. I also reckon we should mirror the virt criteria when it comes to a runtime, and 'recommend' a runtime rather than require a specific one.
-- Tapadh leabh, Mairi Dulaney. _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On 8/29/19 2:36 PM, Daniel Walsh wrote:
On 8/29/19 2:16 PM, Mairi Dulaney wrote:
On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Is Podman are only officially supported container runtime?
What about, say, Docker?
We no longer ship Docker, You need to get that from the vendor. We do ship Moby. But this is not ready for the cgroup change, nor is RUNC.
I think to the user a lot of people consider shipping moby as the same thing as shipping docker. If you want docker you can still get it through moby.
Dusty
On 8/29/19 3:15 PM, Dusty Mabe wrote:
On 8/29/19 2:36 PM, Daniel Walsh wrote:
On 8/29/19 2:16 PM, Mairi Dulaney wrote:
On Lùna 29, 2019 aig 10:33:09m -0400, sgrìobh Dusty Mabe:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Is Podman are only officially supported container runtime?
What about, say, Docker?
We no longer ship Docker, You need to get that from the vendor. We do ship Moby. But this is not ready for the cgroup change, nor is RUNC.
I think to the user a lot of people consider shipping moby as the same thing as shipping docker. If you want docker you can still get it through moby.
Sure, But Docker INC would prefer us to call it Moby...
Dusty _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
On Thu, Aug 29, 2019 at 4:33 PM Dusty Mabe dusty@dustymabe.com wrote:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's
registry as root
- The podman container runtime can pull/run a container from Fedora's
registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Correct me if I'm not thinking straight, but Fedora containers are not release blocking right now. If we require that latest stable fedora container must be pulled and run correctly, we will corner ourselves if the container is broken. Because we will block the release on a compose artifact which is itself not release blocking. So unless I'm talking nonsense, it might be better to specify "any container" (and recommend to test with latest stable fedora container).
On 8/30/19 9:36 AM, Kamil Paral wrote:
On Thu, Aug 29, 2019 at 4:33 PM Dusty Mabe <dusty@dustymabe.com mailto:dusty@dustymabe.com> wrote:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1]. New section for Containers and Container tools: - A Fedora system can install the podman container runtime - The podman container runtime can pull/run a container from Fedora's registry as root - The podman container runtime can pull/run a container from Fedora's registry as a non-root user As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Correct me if I'm not thinking straight, but Fedora containers are not release blocking right now. If we require that latest stable fedora container must be pulled and run correctly, we will corner ourselves if the container is broken. Because we will block the release on a compose artifact which is itself not release blocking. So unless I'm talking nonsense, it might be better to specify "any container" (and recommend to test with latest stable fedora container).
Your suggestion is exactly my suggestion above where I say: "As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31)."
Dusty
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as
root
- The podman container runtime can pull/run a container from Fedora's registry as a
non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
Hi a few thing to consider,
registry.fp.o is not the default registry used on Fedora (by podman, docker, etc ...), if your Dockerfile only specifies FROM fedora it will first pull the image from DockerHub. You will only get the image from registry.fp.o if you specify FROM registry.fedoraproject.org/fedora in your Dockerfile.
The CPE team is still hoping to switch to Quay.io (when support for multi arch and flatpak is available), when this happen I doubt that we will keep registry.fp.o around.
All that to say that I think the release criteria should be quite generic, and I would say that it should really cover the default use case which is in my opinion is doing a podman pull fedora or FROM fedora in the docker file.
Thanks Clément
On 8/29/19 10:33 AM, Dusty Mabe wrote:
I don't know the formal process for proposal but here is a shot at a bare minimum start for trying to add containers to the existing release criteria. This is a suggestion after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user>
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
With all of the discussion that has taken place I think the only change I would make to the above proposal is to be more explicit about which container image to pull:
- A Fedora system can install the podman container runtime - The podman container runtime can pull/run the previous release (N-1) base container from Fedora's registry as root - The podman container runtime can pull/run the previous release (N-1) base container from Fedora's registry as a non-root user
For now I'd keep the list of container runtimes at just podman.
Dusty