On 02.12.19 22:49, Bryan J Smith wrote:
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] <mailto:[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]
<mailto:[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 <http://kernel.org> these days? I haven't
kept up with the 5.0 kernel developments.
XEN does live in regard of Citrix and xcp-ng. The later is FLOSS as far
as I know. XEN classic...well...RHEL dropped support when RHEL 6 was
born ;-). A good alternative for lightweight VMs in terms of PVM (not
HVM) - means shared Kernel - is LXC/LXD which has its own IP on the
SAME subnet than the host plus SystemD, plus all major Distros as small
packages
plus pre build Apps from Turnkey.
Perhaps, the weight can be reduced of XEN with some extra awareness to
other products (like XCP-NG) ?
I would rise the basics of "351.1 Virtualization Concepts and Theory
(weight: 6)" with +1 or +2 to compare all VM techniques especially in
regards of "Container". In real life I noticed, that many folks believe
a container is docker (period). Technically a container is not only
docker (it is just a vendor) but exist in many forms like
Tomcat/Wildfly, LXC/LXD, SNAP ...heck, even a word document is some kind
of a container. The difference are the use-cases. If someone believes a
container is simply process isolation, than practices like PHP-FPM pools
or a jailed sftp are isolated techniques too. Again, many people don't
know about HVM or PVM. I seriously would place those "clarification" on
the list.
2) *** ON DOCKER PACKAGING AND KUBERNETES ORCHESTRATION ***
On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich
<[email protected] <mailto:[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] <mailto:[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 ...
Of course it does. But why should you place such a high weight on it ?
Docker-Swarm has (imho) no acceptance out there, while LXD has its own
orchestrator. However, what I miss is some hint about WHEN to use a
container (like docker) and when not.
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] <mailto:[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] <mailto:[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] <mailto:[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.
Proxmox is a "I can do everything better and cheaper package" to me.
Ceph Nautilus for shared VM and/or LXC storage in just a few clicks,
interconnected with 10G (or more) in a 3 piece quorum instance without
the need of a expensive 10G Switch. It includes nbtables, backups and a
ton of more features like Replication, FailOver, Monitoring, own custom
Kernel,
great documentation ...
PLUS: It has a powerful REST API to fully automated VM/LXC creation
...and all that is FLOSS.
<Fanboy on>
Once you know Proxmox, you wont use Cockpit(primitive), VMWare or
anything else
<Fanboy off>
4) *** ON MISC ***
On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich
<[email protected] <mailto:[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.
Sure it is, but LXC is even supported on some CISCO Nexus Switches
(which run IOS-NX).
On Mon, Dec 2, 2019 at 1:01 PM Stephan Wenderlich
<[email protected] <mailto:[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.
I know from some serious big companies, that they would love to adopt
Proxmox but can't because VMWare is supported by various products they
use and Proxmox officially not (yet). Again, it is far more than just a
front end.
Topics I miss in /"Topic 353: VM Deployment and Provisioning"
/Kickstart, Preseed and FAI
Those tools can truly automated the VM deployment
Vagrant: Weight 3 ...justified ?
_______________________________________________
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
