Hi Dirk, Hi Bryan, thanks for your feedback. The changes are in the wiki. I've also removed the draft state from the document since we can consider the objectives final now.
Thanks, Fabian On Tue, Jan 28, 2020 at 3:42 PM Bryan Smith <[email protected]> wrote: > Yeah, I think we need to cut the release at some point. > > Some won't be happy we're leaving some things in and/or they feel it too > much weight. > > And some will want coverage of non-Open Source solutions, instead of the > Open Source components they use (sorry to everyone involved that I got a > bit 'heated' about that prior). > > But I thing this is the best set of compromises after a lot of input. > > - bjs > > -- > Sent from my Moto G7 Power, apologies for any brevity as well as the > satanic versus of autocorrect > Bryan J Smith - http://linkedin.com/in/bjsmith > > > On Tue, Jan 28, 2020, 05:56 Dirk Streubel <[email protected]> wrote: > >> Hello Fabian, >> >> maybe my answer to this mail is a little bit to late, i don't know. >> >> >> Am 22.01.20 um 00:28 schrieb Fabian Thorns: >> >> Dear all, >> >> I hope you all had a great start into the new year. This year we'll see a >> series of new exam releases, including the new LPIC-3 exams. Therefore I'd >> like to (finally :) summarize the discussion with a proposal. >> >> It seems to be agreed that there is a set of base technologies which are >> seldom used on their own (e.g. KVM), but instead are usually integrated >> into various other platforms and tools (e.g. Proxmox or oVirt). While we >> cannot cover too many details of the various platforms, we shouldn't expect >> too much knowledge regarding stand-alone use for the base technology tools >> either. Therefore I'd like to propose reducing the weight of stand-alone >> Xen and KVM and instead add some more container concepts, as described >> below. >> >> >> * Reduce the weight of Xen from 4 to 3 >> >> - Change 'Understand the configuration of Xen nodes and domains' to >> 'Basic configuration of Xen nodes and domains' >> - Change 'Manage Xen nodes and domains' to 'Basic management of Xen nodes >> and domains' >> >> Would you keep 'Troubleshoot Xen installations' or drop it? >> >> We have this Discussion about Xen some time ago here in the List and and >> that Xen is not complete out of the new 305 Exam, good to see. From 4 to 3 >> is okay and i think 'Troubleshoot Xen installations' would i keep in. >> >> >> * Reduce the weight of Qemu from 6 to 4 >> >> - Change 'Understand QEMU configuration parameters' to 'Start QEMU >> instances from the command line' and 'Awareness of important QEMU >> configuration parameters' >> - Change 'Manage QEMU instances from the command line, including using >> the QEMU monitor and managing snapshots' to 'Manage snapshots using the >> QEMU monitor' >> >> I think a weight of 4 is okay. Maybe i am alone but must of the users i >> know uses qemu in combination with KVM, not only qemu to start a Virtual >> Machine. >> >> But this is my private experience i have make the last years. Maybe >> Somebody out there sees this in a different light ;) >> >> >> >> * Increase the weight of VM Disk Image Management from 2 to 3 >> >> The current contents already justify weight 3. >> >> >> * Increase the weight of Container Virtualization Concepts from 6 to 7 >> >> Here we should add some more contents regarding container standard >> formats and runtimes. I'd like to propose the following additions to this >> topic: >> >> * Awareness of the OCI runtime and image specifications >> * Awareness of the Kubernetes Container Runtime Interface (CRI) >> * Understand the principle of runc >> * Understand the principle of CRI-O and containerd >> * Awareness of podman, buildah and skopeo >> >> " Awareness of podman, buildah and skopeo" is a good point for the new >> Exam. I think at this time is enough for "Awareness". >> >> Maybe in a few years it look different with podman and docker, but how >> knows. >> >> >> * Increase the weight of Container Orchestration Platforms from 2 to 3 >> >> Again, here we should have already enough in the objectives to justify >> three questions. >> >> Finally, these changes would bring both virtualization and >> containerization to the same amount 25 weights each. And these changes can >> easily be made during the last finalization steps of the initial item pool. >> >> What do you think? >> >> I was in January at the Red Hat Forum 2020 in Darmstadt, Germany. One of >> the biggest Statement there was " Everthing, it is possible, put in a >> Container" So, with this experience i make it is good that the weight of >> both are equal. >> >> Nobody here can look ahead but at this moment i think the new 305 Exam is >> good to pass the next 5 Years. >> >> Dirk >> >> >> >> >> >> >> Fabian >> >> >> On Wed, Dec 4, 2019 at 7:12 AM Bryan J Smith <[email protected]> wrote: >> >>> On Tue, Dec 3, 2019 at 5:05 PM Bryan J Smith <[email protected]> wrote: >>> >>>> Have any of you actually seen ... >>>> I keep having this conversation over and over ... Same concept here. >>>> KVM and 'virt-manager' is *not* what Enterprises and even SMBs user in the >>>> CentOS/RHEL world. Cockpit isn't either. ;) >>>> >>> >>> I re-read some of my posts today, incluindg comments like the above, and >>> I want to apologize for being 'abrasive.' I do this at times, and I need >>> to find a better way to convey my viewpoints. >>> >>> >>> >>>> >>>> It abstracts a lot of the internals involved in setting up complex >>>>> things like a Ceph cluster. >>>>> >>>> >>>> And oVirt (RH[E]V) is designed for 'hyperconverged' -- aka add a node >>>> for more compute + storage. ;) >>>> >>>> Sure, if one wants to setup a full CEPH farm, to be used in various >>>> ways, they can. But they don't have to, not for a long time. >>>> >>>> I.e., why might they want to? To get Origin (OpenShift) on oVirt >>>> (RH[E]V), which is finally coming in Origin (OpenShift) 4.2-4.4 (about >>>> time). Telcos are not only big into that, but that's what I did in HP in >>>> 2014 -- HP Helion Open Stack Developer Platform (HP's CloudFoundry-based >>>> DevOps on OpenStack -- 1 GUI to rule them all) -- at a major Telco here in >>>> North America. >>>> >>>> >>>>> So from where I am standing, it is something like Plesk or >>>>> Virtualmin/Webmin/Cpanel/DirectAdmin/etc. >>>>> >>>> >>>> And oVirt (RH[E]V), only the latter is 100% FLOSS. ;) >>>> >>>> The major difference of Proxmox to the RH-world is its orchestration >>>>> called qemu-server that they use instead of libvirt: >>>>> https://github.com/proxmox/qemu-server >>>> >>>> >>>> Again, oVirt (RH[E]V) does _not_ use libvirt _except_ for the _small_ >>>> KVM support portion. I cannot stress this enough. I couldn't have >>>> implemented a 10,000 instance VDI solution in the US starting in 2012 >>>> without such. ;) >>>> >>>> Let me say that again ... oVirt does _not_ use libvirt for this, >>>> period. It uses various added services -- e.g., VDSM. [1] >>>> There is also AD and IPA authentication, including for SPICE >>>> connections. 'virt-manager' doesn't do that either. >>>> I could go on and on about the various services that oVirt provides. >>>> >>>> oVirt is a framework that only uses _basic_ (standalone) libvirt/KVM >>>> for the Hypervisor interface, and includes so much more -- all FLOSS -- for >>>> SMB and enterprise deployments. Same goes for so much "Enterprise >>>> Infrastructure" built around RHEL, but *not* in "base RHEL" itself ... but >>>> still 100% FLOSS. "base" RHEL is such a small subset now, and part of the >>>> reason CentOS is very frustrating, because they build so little of Red Hat, >>>> and rely on Fedora EPEL, which is becoming a 'leading edge testing ground' >>>> (something I warned about in 2011). >>>> >>>> Red Hat doesn't like to 're-invent the wheel.' So when it sees a >>>> product as 'insufficient,' it either writes or acquires something. That's >>>> where 389 Server (fka Netscape Directory Server / iPlanet lineage) comes >>>> from. That's where oVirt (RH[E]V) comes from too (acquisition). I just >>>> found out today in a meeting with Red Hat (quarterly on-site meeting) that >>>> Red Hat is going to open source IBM Cloud Manager. It seems IBM is wanting >>>> to start open sourcing a lot of its proprietary codebases. >>>> >>>> So while I think Proxmox has significance, I don't see it as a standard >>>>> like Docker. >>>> >>>> >>>> I'm 100% fine with the FLOSS components being covered. I think it's >>>> worth to include all FLOSS components that Proxmox uses. But non-FLOSS is >>>> a problem. >>>> >>>> E.g., libvirtd ("d") for supporting VMware ESXi, et al. but not >>>> vSphere, et al., proprietary frameworks. This is what I'm trying to figure >>>> out with Proxmox. What I find extremely frustrating is that people have >>>> never used oVirt (RH[E]V) and thing everything in "base" CentOS/RHEL is all >>>> that people use. When I say libvirtd, vdsm, et al., I don't mean the >>>> 'virt-manager' GUI. ;) >>>> >>>> Also I can't think what kind of questions we would be >>>>> asking. The typical user/admin will hardly if ever use the console or >>>>> be >>>>> required to understand how Proxmox works internally. So the coverage >>>>> could and should only be awareness and concepts. >>>>> >>>> >>>> I'm a huge fan of commonality. This is Level-3 (300). We should be >>>> more focused on the commonality of internals. If Proxmox is using KVM, >>>> it's using libvirtd ("d") too. It's impossible not to. >>>> >>>> I think people keep looking at libvirtd ("d") as this 'simple tooling,' >>>> when it's a library-service for general Hypervisor access. E.g., VMware >>>> supports it for ESXi instances in OpenStack. It has nothing to do with >>>> "virt-manager," that's just a "test GUI" for basic stuff. >>>> >>>> oVirt and you'll understand what I mean. It's awareness of multiple >>>> solutions I'm concerned with here. Just like with only knowing OpenLDAP, >>>> and never hearing anything else. We need to cover commonality, and expose >>>> people to the fact that they need to know the underlying technologies and >>>> components that they all use. >>>> >>>> - bjs >>>> >>>> [1] oVirt VDSM Developer Guide >>>> - https://www.ovirt.org/develop/developer-guide/vdsm/ >>>> >>>> [2] Self-Hosted Engine (oVirt-M, aka RHV-M) >>>> - >>>> https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine.html >>>> >>>> >>>> >>> _______________________________________________ >>> lpi-examdev mailing list >>> [email protected] >>> https://list.lpi.org/mailman/listinfo/lpi-examdev >> >> >> >> -- >> Fabian Thorns <[email protected]> GPG: F1426B12 >> Director of Certification Development, Linux Professional Institute >> >> _______________________________________________ >> lpi-examdev mailing >> [email protected]https://list.lpi.org/mailman/listinfo/lpi-examdev >> >> _______________________________________________ >> lpi-examdev mailing list >> [email protected] >> https://list.lpi.org/mailman/listinfo/lpi-examdev > > -- Fabian Thorns <[email protected]> GPG: F1426B12 Director of Certification Development, Linux Professional Institute
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
