Hey Ingo, thanks for the feedback!
On Wed, Nov 22, 2017 at 4:42 PM, Ingo Wichmann <[email protected]> wrote: I'm totally agree with the goal, that candidates should know > > > how a cloud/container is different from a regular installation > That's already a great consent! It's really hard to cut the line between 101 and 304. I share all of your concerns, yet, I didn't came with anything better. Let's try to work it out together :) > But reading your proposal, i'd say that this goes far beyond that goal: > > > * Understand concepts of virtualization and containerization. > > It takes much more to understand the concepts of virtualization and > containerization than what you wanted to achieve. Too me, this would > require that I can configure a simple lxc (or lxd, or docker, or ...) > and a simple kvm (or xen, or vmware, or virtual box) setup. > > As I understand you (and what I would support) is that we want > candidates to be able to use containers or virtual machines. So we stay > on the client/guest side. > That was actually my intention. I didn't even thought someone would think of asking an LPIC-1 candidate to understand binary translation, trap and emulate and VM exists/entries. I thought more about testing that the candidates has an understanding of multiple Linux instances running on the same computer with a limited view on the underlying hardware. Would '* Understand implications of running Linux in a virtual machine and/or container?' be a better way to phrase it? Saying '* Run Linux in a virtual machine and/or container.' might already be too much, given that containers can easily become complex (we'll address that in a second). > > * Understand common components of IaaS clouds (computing instances, > > block storage (ephemeral + persistent), networking) > > So we want them to know what a computing instance, a block storage > access and network access looks like from a guest instance? > > What we don't want them to know is how a block storage backend looks > like and how it is connected to an instance. > Exactly. All IaaS clouds offer these building blocks (with different names, though). A candidate running Linux in the cloud should understand these building blocks and know how to combine them to a virtual machine (e.g. have an instance with ephemeral storage for the OS, add persistent block storage for data, assign a network to connect to other VMs and a floating IP for external access). Once these things are glued together, they look like a regular VM to Linux. I thought about bridging the gap from having access to OpenStack/AWS/DigitalOcean/Whatever and being logged in a Linux machine to apply all the other stuff we test in the exam. > > * Understand and how Linux is deployed in computing instances and > > understand the role of cloud-init. > > Is cloud-init generic enough? Can it be used in all of the following > virtualization/container technics: > * kvm > * xen > * virtual box > * lxc > * lxd > * docker > * vagrant > > To me, cloud-init looks like it's too much on the host/platform side. > These are different use cases. The big difference between IaaS instances and classic virtual machines is the installation of the operating systems. A VM might be manually installed from an installation media, unattended PXE boot or created based on an image, which in case of kvm, xen, virtualbox, ... tends to be tailored for a specific company / use case. IaaS clouds instead tend to use global images shared by numerous clients. Therefore they require more adjustments, not only to adjust to their instance (disk size etc.), but also to create users, deploy SSH keys etc.. Most public cloud providers use cloud-init here and I thought about expecting the candidate to be aware of that and know where this 'user-data' field in his cloud provider's admin console is for. Although this might be seen as part of 'running Linux in the cloud' without being specific about cloud-init. Should we instead mention 'Custom image management' and 'Login credentials'? Other suggestions? > > * Know Docker features, including the role of container images and > > Dockerfiles. > > I don't like that. Do we want them to have worked with docker or not? > Having heard of features, but never having used them is not helpful in > my opinion. > Again, I didn't want to go so far. My primary concern is that there is a misunderstanding of VM vs. container vs. container. There are people who think of Docker like a regular Linux installation, including all system services, SSHD, interactive sessions etc. I basically thought about knowing that Docker is intended for process encapsulation and to be aware of how software ends up in a Docker container (i.e. is packaged in an image which is created from a base image according to a Dockerfile). Again, I don't insist in any of that, I just wanted to get the discussion started. What would you like to see in here and how would you phrase it? Or shouldn't we add this at all? Fabian
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
