DISCLAIMER/PREFACE: I have to admit, I'm so far up the Red Hat 'tailpipe' that I can only see oVirt (Upstream, Downstream RH[E]V) and Origin (Upstream, Downstream OpenShift). So I'm the worst one to ask for input on either Upstream-centric or Enterprise-adopted solutions, especially at 'cash strapped' hosting providers. I've been way too much FSI and Government, both of which have deeper pockets, yet still save 1/10th over non-FLOSS paying for Red Hat.
So, now 'wading in' the family pool ... (LONG POST WARNING -- I purposely 'stayed out' of this to start, for a reason) :) Apologies in advance for any 'mis-quotes' (I did a lot of copy'n paste from 4+ emails) 1) *** ON XEN *** On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > 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. > I'm not against this, but what's the 'market survey,' even if just informal? I mean, Xen's membership doesn't mean much to me ... On Mon, Dec 2, 2019 at 2:50 PM Dirk Streubel <[email protected]> wrote: > In the old 304 Exam Xen has a weight of 9, in the new one 4. I think this > is a good compromise. Yes, KVM is the winner against Xen, but Xen is not > dead. There are a few companies that using Xen and look at this: > > https://xenproject.org/about-us/project-members/ . So, I know Amazon will > left Xen, but Xen is under the Linux Foundation and in the next Years Xen > will not die and this year there will be a new Version 4.13. > > Who is still heavily reliant on it, and doing the Upstream development at kernel.org these days? I haven't kept up with the 5.0 kernel developments. 2) *** ON DOCKER PACKAGING AND KUBERNETES ORCHESTRATION *** On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > What I totally disagree with is docker ... If one truly dives into docker, > you will notice some big disadvantages (like no real init, one main daemon > etc.). > On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > Docker and Kubernetes do not fit in. > Docker is still relevant, and will still be relevant for another couple of years. Podman et al. is also built to be largely Docker 'packaging' compatible. I'd love to see Podman et al., but that's a Fabian-Matt call this late in the revisions. I think we can look to 2021 to re-rev for 2022, and the market's conditions at that point. But if we want to do it now, it could mean we're there much earlier, for 2020+, even if it delays things. Docker is still here, even if Kubernetes (K8s) is the preferred Orchestration. Docker is basically 'packaging' at this point, as their 'orchestration' is separate. Docker has a lot of inertia, and as much as Podman et al. are designed to be Docker compatible to a point, but adopt much newer kernel facilities (e.g., CGroup v2), we have to ensure we're looking at non-Red Hat developed Upstream too. That said, I still think Docker still has market penetration and it's still FLOSS, so we need to consider it outside of Kubernetes. E.g., Real-World here ... Although we're a Red Hat OpenShift user, we still have end-users who want to install the [limited support} "Docker" subsystem from RHEL Extras Channel on Servers, so they can 'built' Docker images without having to have OpenShift, let alone even just Kubernetes, installed. Again, that's a 'real world' example. On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > ... They do have serious financial issues and almost everything is sold to > Mirantis ... > <political=ON> I don't think Mirantis owning much of the Docker stack now, beyond just the packaging, should be a factor ... as long as it's still FLOSS. Now ... if it ends up being software that cannot work without a Marantis product or service, then that can be visited. But ... -- Red Hat 'shades' off -- ... one could argue that it's difficult to get either oVirt or Origin working like RH[E]V for OpenShift too. I was hoping the Red Hat partnership with CentOS since 2014 would change that, but they haven't really moved on it, and CentOS is still too heavily dependent on Fedora EPEL, which is more 'leading edge' than all of the Red Hat 'infrastructure' products built around RHEL. It's a very thin line, so if we apply anything about Mirantis to Docker, then Red Hat might be similar -- even if Red Hat's 'history' is, ummm ... 'better' (see PS**). I'm just trying to be 'objective' and 'unbiased' here, Red Hat 'shades' removed (again, see PS**). ;) </political> 3) *** ON PODMAN, BUILDAH, ET AL. *** On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > Podman from RedHat will overcome all these problems. > We're here in the middle of OpenShift 3.11 (just upgraded to 3.9) to OpenShift 4.x planning. I understand many of the base, technical reasons for the move to Podman et al., including native Kernel Control Groups (CGroups) v2. Red Hat has always been 'ahead of everyone' on adopting kernel facilities like CGroups and Namespaces, before LXC was an option, and used SELinux to provide MAC separation, in OpenShift 1.x. But we're probably 'too late' in the Objectives to do a major shift to Podman, Buildah, et al. unless we want to 'pushed back' the objections (and exam) revision. On Mon, Dec 2, 2019 at 3:00 PM Markus Schade <[email protected]> wrote: > 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. > Again, should we 'push back' on release dates to include more coverage of Podman et al.? That's a valid consideration, assuming we have a 'date set' on this revision. But ... just to play 'devil's advocate,' especially being one of the biggest 'Red Hat homers' on this list, but trying to be 'objective' ... I think we're going to get into very extensive changes. I mean, RHEL8 was just released mid this year, with CGroups v2, as well as the new OpenShift4 product in tow, with Podman and other aspects. At work, his 'messed us up' with our production systems as Red Hat also changed the RHEL7 Extras Channel (which is basically 'here you go, we tlimitedly support this, and can change interfaces/compatiblity') so the new Docker install isn't 100% interface compatible, and requires us to rebuild our Docker storage volumes when we upgrade to RHEL7.7. Again, this only affects Docker in RHEL Extras (free), not OpenShift. So ... this will be odd coming from me, but I don't think Red Hat 'throwing it's weight' is always a good argument for 'do it now.' Sure, Red Hat can claim >>50% of the 'paid' Enterprise Linux-based infrastructure market, and gets earlier adoption for many things it develops (SSSD is still my favorite example, even without IPA, that I wish more people knew of a decade ago), but that doesn't mean the 'free downstream' (let alone Upstream) in CentOS defines everything either. So ... sometimes something that Red Hat does can be 'pushed back' a couple of years. Or maybe we put more of it into the DevOps exam (?). Or a new 300-level DevOps Architect? (Fabian-Matt can hate me right now for suggesting such -- it's likely an *invalid* argument, but I'll bring it up) ;) We also have to 'draw a line' on where Red Hat training/certification 'takes over.' I love and advocate for LPIC-1, 2 and 3 where RHCSA (SysAdmin), RHCE (Engineer) and Specialist/RHCA (Architect), because it can be so much broader. E.g., I really don't like dealing with RHCSA-only sysadmins, and prefer to see at least LPIC-1 as well. Because there are going to be solutions outside of Red Hat that are innovative, and are adapted by some industries. Proxmox is a perfect example that is outside of the oVirt and Origin 'spheres' and I say this as someone who isn't 'hands-on familiar' with Proxmox myself. Containerization may even be its own objective set-exam in the future. We're getting to that point with DevOps. 4) *** ON MISC *** On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > What I would like to see is LXC/LXD, which are really popular and they > don't need a shady Docker-Hub. > There's a lot built around LXC directly now. But that's an even bigger argument. I'm trying not to assume too much, but Docker is still prevalent in 2019. On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich <[email protected]> wrote: > Proxmox offers them directly via GUI and with the Proxmox Cluster System, > a HA system like K8S is avaiable. > As I mentioned in my previous e-mail, I'm utterly ignorant -- Enterprise-wise -- on Proxmox. I know some of the base differentiation of the 'front-end' solution, that it can support more than just libvirtd (deamon-tooling, not 'end-user tooling' like virt-manager) facilties for virtualization. I come from the early oVirt (aka RH[E]V -- where I not only implemented one of the largest installs, but pre-sold it w/IBM, which wasn't my job, never saw a dime in commsion either, I was 100% post-sales) world, which relies on libvirtd, which was not 'well adapted' to containers. oVirt relies on libvirtd (the facility/services, not the 'end-user tools' like virt-manager), which Proxmox does as well for KVM and other hypervisors. But Proxmox supports more than just the libvirtd support, so it can support far more, unlike oVirt. So I'm really interested in how much Proxmox should be covered, or maybe if it should just be limited to what Proxmox is *using*, I.e., as of right now, I think 351.1 covers it well as 'awareness' ... 351.1 Virtualization Concepts and Theory (weight: 6) Weight 6 Description Candidates should know and understand the general concepts, theory and terminology of virtualization. This includes Xen, QEMU and libvirt terminology. Key Knowledge Areas: Understand virtualization terminology ... Awareness of oVirt, Proxmox, systemd-machined and VirtualBox ... But I'm all for hearing how Proxmox is a technology that should be covered, beyond just a 'front-end' for both virtualization and containers. Again, I'm so far up the Red Hat 'tailpipe' that I see oVirt and Origin, both of which were not designed for specifically KVM and LXC/Docker, respectively, to begin with. <SIDEBAR> For those that don't know ... oVirt started out as a generic FLOSS virtualization management framework, including web management framework and GUI, around libvirtd supported Hypervisors, which could do ESXi, KVM and Xen. But as VMware and Citrix-Xen didn't like the idea of its $4K/hypervisor GUIs being undercut, oVirt really became KVM-only, and sold as RH[E]V, a competitor to vSphere. Origin (OpenShift) started out as a JBoss solution for development, before LXC was even in the kernel, using CGroups, Namespace and security provided by SELinux. So adapting to LXC, then Docker and now Kubernetes was a no-brainer, and is far more than a JBoss developer solution. </SIDEBAR> Don't know if my extensive comments added any considerations, or just confused. But I figured it was time to finally make them. I'm really just very 'tunnel-visioned' by work, even though I try to keep my 'eyes wide' and recognize the 'blinders.' LPI is great for that, and I hope LPI continues to find a way to be that way too. - bjs **P.S. In full disclosure ... as I want to be 'transparent' ... <bias=ON> It's been over 5 years, so I'm going to talk about it, to a point that doesn't violate NDAs from what I can tell. Being 'knee deep' in the whole Red Hat - Mirantis split 'from the inside'** back in 2012-2014 as *THE* Red Hat post-sales architect for Software Defined Storage (SDS), and one of three (3) on Software Defined Infrastructure (SDI) around OpenStack and, to a lesser extent back then as OpenShift pre-dates LXC, let alone Docker and K8s -- which is how OpenShift was 'well ahead' of everyone, as it already did Kernel CGroups, kernel namespaces and SELinux before even LXC -- Mirantis doesn't 'leave a good taste in my mouth.' DISCLAIMER: I was one of the people on the original 'internal Red Hat e-mail' that went around (to maybe 50 of us), but I did *NOT* leak it. Red Hat was *not* the 'bad guy' here ... that's all I'll say. Let's just say Red Hat seeded Mirantis with 10% of its total capital, then ... well, it's a long story ... at some point Red Hat really so much 'return the favor' in how it was being treated, but could no longer 'work' with them. >From my professional, individual view (*not* speaking on-behalf of Red Hat), one had to finally just 'give up' because, Mirantis was, after all, all about proprietary lock-in with Fuel, especially around costly professional services. Again, professional, individual view (*not Red Hat's), I was -- one second -- trying to sell household names on partnering with Red Hat *and* Mirantis, then going to not mentioning their name. I.e., I know the e-mail was basically 'timed' with what I was doing, and whomever leaked it was ... well ... let's just say they had a 'conflict-of-interest.' It painted Red Hat is a 'poor light' that was *not* 'fair' to Red Hat. E.g., Mirantis 'made its bed' long, long before that! Again, 100% my professional, individual view. Not demonizing Mirantis, that is *not* what Red Hat does. I lived that 'attitude' too. I just no longer 'brought them up,' until a partner did, and then trying to 'be positive' by focusing on 'avoiding vendor lock-in.' I.e., one shouldn't ever say anything negative, just focus on the positive -- and I always did that when people brought up Ubuntu LTS too (E.g., "Why aren't you paying for Canonical Advantage then? You make money, so you should pay Canonical since you rely on Ubuntu LTS -- don't tell me because "it's free [beer],' I have friends at Canoncial who need to eat too!"). I was always 100% for *other* FLOSS companies making money, especially if they develop other GPL and FLOSS (e.g., like Canonical very much does!). So ... yes, I'm 'troubled' by Mirantis picking up much of Docker, but ... I also can't let myself have a 'bias.' I have just *one* viewpoint of this. Again, I'm sure someone will use this against me at some point, but I'd rather be 'transparent' about it, with LPI. I don't want people saying, "Hey, you worked in Red Hat Global Partner Enablement (GPE) back then, you were one of the guys that trained us at our household name on OpenStack, OpenShift and other solutions, and even named 'Red Hat OPEN'! You have a bias against Mirantis!" BTW, I have *0* financial stake in Red Hat since late 2017 as well, stupidly selling off the rest of my stock a year too early ("It'll never break $100, so time to sell" ... doh!). I only get some professional services work from Red Hat from time-to-time, which is no longer my 'bread'n butter' (4 figures/year USD, max). </bias>
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
