[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Getting to full deprecation of the projectatomic/ Github organization

     Sorry for top posting. Your email is very long, but the short answer to your question is Red Hat has two main strategies from a product perspective:

1. Single Node -> RHEL -> Podman. The product installs on bare metal and virtual machines.
2. Multi Node -> OpenShift -> CoreOS -> CRI-O. The product installs on cloud providers (AWS, GCP, Azure, and soon to be OSP, and RHEV. Code Ready Containers (CRC), which is a single node OpenShift even installs on libvirt).

From an upstream perspective, these are all lego blocks, and they can be mixed and matched to build whatever you want or need.
1. Fedora CoreOS
2. CRI-O
3. Regular Fedora
4. Podman, Buildah, Skopeo

There are no plans to offer CRI-O and CoreOS support separately from OpenShift, and no roadmap. We will continue to invest in new features targeting the two use cases mentioned above. Hopefully, that will clarify the big picture of why we are doing things the way we are.

Best Regards
Scott M

On Tue, Oct 1, 2019 at 6:32 PM Daniel Walsh <dwalsh redhat com> wrote:
On 10/1/19 2:35 PM, Farkas Levente wrote:
> Hi,
> It'd be very nice to get something useful information about the
> current state and future plan of RH about containerization.
> TL;DR is there anybody who knows anything about it?
> IMHO the current communication about containerization is a very bad
> state.
> That's the reason why i choose to reply this thread since imho like
> the content of this mail should have to be announced etc.
> Let me describe what i see (which may be wrong) about the whole rh
> containerization.
> if i'd like to use amazon, google etc there is a full framework for
> everything. i mean registry (virtual) hosts or container runtime
> environment, file storage, sql, nosql storage, messaging logging,
> kubernetes etc...
> when i like to use my own eg. private environment than i have to build
> up all of this part of the system. suppose i prefer redhat/centos
> based stuff and plan to be ready in a year. what should i have to do?
> probably read the docs...ooohhh which docs and where and what....
> here comes the real problems.
> so what i need?
> a host operating system. which one?
>   - rhel/centos 7 vs 8?
>   - atomic ?
>   - coreos ?
> which one to choose? atomic was rh recommendation and after rh buy
> coreos it's not possible to choose. but atomic was also deprecated. or
> not? it's not even documented on atomic homepage that it's deprcated
> !!! just one hidden blog post about it which refer to that coreos will
> be the future. but there is no coreos since the old one is no longer
> available. there is no rhel/centos coreos. but fedora coreos is not
> even in beta stage! only one page long docs about it!
> do you really thing than a blog post is the best place to know the
> future plan of the whole rh's host os and the future plan?
> is there any roadmap/future plan/direction what we can expect? what's
> your plan with some kind of milestone/timeline etc?
> or should i choose rhel? which one? rhel-8 has podman-1.0.0 which is
> totally unusable. so it's better if you do NOT choose rhel/centos 8
> over 7.7 (which is imho nonsense). and there not even an update but
> let me write about it later..
> 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.

> i need a container framework. which one?
> docker as a primary choice but rh do not support it. the latest
> version is 1.13 and won't be updated. even rh's own docs (openshift
> and kubernetes docs also) start with "delete rh's docker, download
> docker ce from docker and install it". really? that's the way? what is
> the plan for the future?
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


Which was the first hit on Google while searching for "rhel8 container

> 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.
> 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
> 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.
> may be fadora working....but after in production you can't use what
> you use for development.
> so conclusion:
> - atomic depricated
> - coreos still not in beta no docs
> - rhel/centos 7 not working in rootless mode
> - rhel/centos 8 almost nothing is working 1.0.0 version
> is there anybody at rh really cares about developer? do you guys try
> to give developers any help? in any way?
> i'm not mean in a "steve ballmer developers" way but still ...
> 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.

> anybody use podman for development? use it for with multi container
> way? or everybody use sudo podman (so why it's better then docker? ok
> i know why but i hope you understand the point).

Currently we tell people that need containers to communicate to use
pod's but we are working to fix this.  Come to the libpod github to open
issues or send mails to podman.io to discuss developments.

> 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.

> 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.

Scott McCarty, RHCA
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smccarty redhat com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Have questions on Red Hat UBI? Check out the official FAQ: https://red.ht/2yaUcez

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]