On 10/1/19 2:35 PM, Farkas Levente wrote:
> ok i don't know which host os to choose and not really helpful any
> docs about it what's more can't know anything about the future plan.
>
RHEL8 version of podman should be updated next month with the release of
rhel8.1, from that point forward it will be updated every three months,
to close to the current release. Some unfortunate circumstances
caused us to delay release for 6 months.
ok. at least some plan, but you see that's nonsence.
RHEL is moving away from Docker to podman, buildah and skopeo. For
OpenShift we are using CRI-O for the container engine.
We cover this in this blog
https://www.redhat.com/en/blog/rhel-8-enables-containers-tools-software-craftsmanship-0
Which was the first hit on Google while searching for "rhel8 container
technologies"
so you think the best way of communication of current and future plans and roadmap a blog post?
not to mention that on rhel8 it still not working:-)
>
> kubernetes, openshift or okd? of course it's depend on the host os and
> what is supported on it. even in openshift and okd (which are rh
> products) none of the use rh's rpm and it's version of docker, podman
> or anything like them. what is the future in this case? is there any
> roadmap?
> just read okd docs (which is owned by rh). it's always refer to
> dockerhub's and not rh's container image. it's always refer to docker
> and not podman.
>
If you want to buy a supported version of Kubernetes from Red Hat it is
OpenShift, our enterprise version of Kubernetes. OKD is the upstream of
OpenShift, which used kubernetes for its upstream. Neither okd or
kubernetes will be packaged directly on RHEL. You need to access to the
OpenShift repos to get the kubernetes package.
yes i know. i just missed the roadmap and plan here also since both openshft and kubernetes use
docker's docker rpm and neither redhat's docker nor podman. that way a roadmap would be very useful.
>
> ocr-i, podman, etc. can we replace docker by this tools? may be in the
> future...but when? what is the roadmap? what a developer should have
> to use in this own developer machines? on rhel/centos-8 nothing is
> working podman is till in 1.0.0.
Hopefully next month RHEL8.1 and then RHEL8.1.1 to get to podman-1.6
release.
so currently rhel8 is not usable.
> on rhel/centos 7.7 latest podman can't be use in rootless mode which
> can be the biggest advantage over docker (just see the bugzilla entry
> about it).
We are working to rootless fixed in RHEL7.8 but this is a very old
kernel, and going into the next phase of maintenance mode. So getting
major changes into the kernel to support usernamespace and fuse file
systems is difficult.
ohh come on! it's your os and your kernel version!
so than currently none rhel8 neither rhel7 are working and it's not sure that
the next version 8.1 and 7.8 will be working!?
> how can communicate different containers without --net host? docker's
> --link not implemented. docker network not implemented in rootless
> mode. cni network can't be defined without root access to the system.
podman network is in podman 1.6 release.
We also are working on support for podman working with a CNI that has
dns support for easier communication between containers.
glad to hear it.
is there any place were i can read about it?
ot this is the only way (someone as it on a mailing list or form and i find it) know
about it?
> which image to choose from which registry? dockerhub or rh's registries?
> have you ever try to use dockerhub mariadb or mongo vs rh's one? why
> they are so different? i understand that rhel is based on rh's rpms etc..
> but just refer to the original thread of this mail...
> do you/we need ContainerApplicationGenericLabels?
> do you will support atomic command? otherwise why we need those labels?
`podman container runlabel` supports the use of run labels. Most of the
functionality of the atomic command has been merged into podman.
YES I KNOW! BUT
what's the future plan???
just read the original post of this thread!
it seems to me even you guys don't know it!?
> how can a developer test the whole system in his own developer
> machine? have you EVER try it? i don't think so! if yes than you
> should have to:
> - run docker ce from docker
> - run podman in root mode
> - use dockerhub's images
> eg. rh's mariadb image use mariadb scl rpms which run in user 27 which
> mapped to some id outside the container which is the same as the
> rootless user who run the container eg 100027. so root access on the
> developer machine required and addition work by root to create such a
> filesystem setup and be able to use the same container environment as
> in production. which can be the biggest advantage using docker.
> and all of the rhel's image use ContainerApplicationGenericLabels and
> the same working model.
>
> and still not mention other part of the container cluster.
>
> yes it's very important that selinux work with contianers but IMHO
> it's much more important to at least something working without
> selinux. selinux was just one example because for me it seems there
> are a lots of useful work in the background but cant see priorities
> and clear goals and roadmaps.
>
> so my question is short:
>
> - is there any high level overview of a private containerized system
> using rh's tool in the next few year?
> - is there any plan about it?
> - is it public? can someone share it with us?
> - is there any roadmap, priorities?
> - can someone tell me or much better to everybody a plan/roadmap about
> coreos?
> - about okd?
> - about podman, buildah etc....
>
> and not to mention which is the right forum to discuss such thing???
>
> thanks in advance.
>
> On 9/27/19 7:20 PM, Colin Walters wrote:
>> bubblewrap moved: https://github.com/containers/bubblewrap
>> rpm-ostree moved: https://github.com/coreos/rpm-ostree
>>
>> Of the things remaining...probably the biggest is our docker branch:
>> https://github.com/projectatomic/docker
>> I feel like it'd be cleanest if we created a new org for this
>> stuff...queue naming bikeshed, I know.
>>
>> There's also:
>> https://github.com/projectatomic/ContainerApplicationGenericLabels -
>> did we ever standardize that stuff elsewhere?
>>
>> I think if we got those bits done we could probably mass-archive the
>> remaining repos.
>>
>
>