Hi, I am not ertain that the future of Docker Inc. is tied to the future of docker. Nevertheless, I have to agree that since Redhat is throwing all its weight behind podman, it will most likely become the de-facto standard. So we could add some podman/buildah/skopeo questions.
I am not so sure whether to further offset the balance between Xen and Qemu than already planned (we are coming from a 50:50 split and much higher weight). I may have seen little Xen use lately, but I think reports of its death are premature. Kubernetes is a quite complex (and fast changing) piece of software. So I would further expand on it on this revision. As Dirk put it. At some point we have to start writing questions. I am fine with reducing Xen by one point and introducing podman on an awareness level. Maybe a bit more if we deduct a point from LXD. Regards, Markus Am 02.12.2019 um 19:08 schrieb Stephan Wenderlich: > Update: > Noticed LXC/LXD is on the new curriculum NICE ! > But Docker got a higher weight...and Docker Swarm is included > ...nope...not good. Docker-Swarm is almost dead. > > Why no PodMan ??? > > On 02.12.19 19:01, Stephan Wenderlich wrote: >> >> Hi, >> >> XEN classic is almost dead. Their documentation is very weak and many >> links do not work anymore for years. At the other hand, KVM and >> exspecially Proxmox are huge. So, I would put the whole XEN Topic to >> an awareness level. >> What I totally disagree with is docker. They do have serious financial >> issues and almost everything is sold to Mirantis. If one truly dives >> into docker, you will notice some big disadvantages (like no real >> init, one main daemon etc.). Podman from RedHat will overcome all >> these problems. >> >> Docker and Kubernetes do not fit in. >> >> What I would like to see is LXC/LXD, which are really popular and they >> don't need a shady Docker-Hub. Proxmox offers them directly via GUI >> and with the Proxmox Cluster System, a HA system like K8S is avaiable. >> >> On 28.11.19 16:51, Fabian Thorns wrote: >>> Dear all, >>> >>> before removing the 'draft' status from the 305 objectives page >>> (https://wiki.lpi.org/wiki/LPIC-305_Objectives_V3.0), what do you >>> think about the current relevance of Xen (weight: 4) and Qemu >>> (weight: 6) compared to Kubernetes (currently contained in a weight 2 >>> objective). To me it seems that Xen becomes less and less relevant >>> while Qemu/KVM is almost entirely used through other means (libvirt, >>> proxmox, ...), so testing their specific options and configuration >>> knobs might be arguable. >>> >>> On the other hand, Docker is more and more used through Kubernetes. >>> Currently we just cover the overall concepts of Kubernetes. What if >>> we would reduce the weights of Xen and Qemu to 1 and 2 or 2 and 3 >>> respectively to just cover the architecture in order to free up 5 to >>> 7 weight points which we could spend on Kubernetes instead? We could >>> create another objective about understanding the architecture of >>> Kubernetes, set up a Kubernetes cluster through kubeadm and >>> understand the roles and functions of the most important Kubernetes >>> objects (pods, replicasets, deployments, daemonsets, services, >>> ingress). I wouldn't test creating and managing these objects since >>> that would be more related to the DevOps certification, but cover >>> enough for a kubernetes node admin to understand what their users are >>> doing. >>> >>> Let me know your thoughts :) >>> >>> Fabian >>> >>> >>> _______________________________________________ >>> lpi-examdev mailing list >>> [email protected] >>> https://list.lpi.org/mailman/listinfo/lpi-examdev >> >> _______________________________________________ >> lpi-examdev mailing list >> [email protected] >> https://list.lpi.org/mailman/listinfo/lpi-examdev > > _______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev > _______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
