I've been utterly slammed as of late due to Sev 1s at work, so I haven't had time to enter this discussion prior (and really have little time now). But I wanted to point out a few things.
o TOP POST PORTION ... All of these technologies have been around a few years in the Upstream, so Fedora and even some other distros, depending on Red Hat employees and others becoming maintainers in those distros, or maintainers of those distros taking an interest in Fedora. RHEL 8 is based on Fedora 28. What belongs in LPI and what Certification Levels (1, 2 or 3)? More details follow ... o BOTTOM POST PORTION (TECH) ... On Mon, Jul 29, 2019 at 12:40:21PM -0700, dutso wrote: > Does anyone have any comments on Red Hat 8?Thank you, Dave Utso Sent from my Verizon, Samsung Galaxy smartphone On Wed, Jul 31, 2019 at 10:47 AM Lennart Sorensen < [email protected]> wrote: > Wasn't that a very very long time ago, or do you mean RHEL 8? On Wed, Jul 31, 2019 at 10:54 AM [email protected] <[email protected]> wrote: > Perhaps VDO - ? > Virtual Data Optimizer (VDO) is a block virtualization technology that > allows you to easily create compressed and deduplicated pools of block > storage. On Thu, Aug 1, 2019 at 9:39 AM Sam Wachira <[email protected]> wrote: > RHEL 8 also introduces Stratis storage management solution - > https://stratis-storage.github.io/faq > Stratis manages pools of physical storage devices and transparently > creates and manages volumes for the file systems being created. > Most of these storage solutions are either Kernel DeviceMapper (DM) or XFS file system enhancements. Some history ... - DM presents contiguous storage, even if non-contiguous, like striped, multiple copies or re-validated (e.g., parity), etc... - DM is how Logical Volume Manager v2 (DM-LVM2), Multipath I/O (DM-MPIO), etc... work - DM has been extended to do various things, including de-duplication, etc... - DM can not only identify different types of storage containers, but even call other subsystems (e.g., MultiDisk, MD, to handle software or fake RAID) - SGI also had some volume management capabilities in Irix XFS, but these were not originally ported to to GNU/Linux back circa 1999 - Solaris ZFS combines many storage concepts, from volume management to file systems, into a single solution - ZFS is GNU incompatible, license-wise - Oracle et al. started BTRFS as a GNU/Linux alternative to ZFS - Oracle bought Sun, owns ZFS, and even though ZFS is not GNU/Linux compatible, it gets weird (legally) when the pre-installed GNU/Linux platform (e.g., Exadata) from Oracle itself - But since this doesn't solve the ZFS licensing issues for non-Oracle entities, Red Hat picked up the BTRFS development - By 2015, a year after RHEL7 was released with BTRFS as an [unsupported] 'Tech Preview,' Red Hat finally 'gave up' on development of BTRFS - I.e., unlike SuSE AG and others, Red Hat is really, really 'anal' on volumes / file systems technologies So ... - DM is being used for a lot of new capabilities in newer kernels, with the userspace utilities in Fedora and, now, RHEL8 - XFS itself has been extended with more volume management capabilities, outside of DM-LVM2, where DM-LVM2 is not viable Which brings us to Stratis Storage ... [1] *"Stratis provides ZFS/Btrfs-style features by integrating layers of existing technology: Linux’s devicemapper subsystem, and the XFS filesystem. The stratisd daemon manages collections of block devices, and provides a D-Bus API. The stratis-cli provides a command-line tool stratis which itself uses the D-Bus API to communicate with stratisd."* The* 'integrating layers of existing technology' *was purpose to take what was available, augment it if necessary, and then put an userspace management wrapper around it, and leveraging APIs for message passing as needed. These, like the augmentation of NetworkManager with an API, CLI, etc..., just like firewalld, systemd, et al., was because Red Hat had major accounts that needed facilities. And many of those cases, the* 'argument' *was always* 'another OS has this, or something like it.'* E.g., a long-requested, Solaris-like feature, upgrade a system, and be able to 'roll back' and boot an earlier 'snapshot.' It seems like LVM snapshots should be capable of this, but they are not, because of how the 'root VG' works. So XFS has some of those features now added into its file system, which is managed in Stratis, among other tools. Which brings us to ... o BOTTOM POST PORTION (CERT) ... On Wed, Jul 31, 2019 at 11:01 AM Marco Verleun <[email protected]> wrote: > It’s covered in the RHCSA courseware from Red Hat at a very basic level. > At a LPIC-1 level it’s maybe something that you should be aware off? > In the Red Hat program, there's 200-level RHCSA, 300-level RHCE as well as 200-level (sysadmin), 300-level (engineer) and 400-level (architect) specialties, some of which grant a RHCSA or RHCE and/or renew them, in addition to the RHCE + 5-exam = RHCA. If it's in a Red Hat 200-level, it doesn't necessarily mean it should be in the LPI Certified Level (LPIC-1). It's really a question of 2 things for me ... 1) Upstream acceptance and ... 2) An Objective, whether 2a) Part of an existing objective or ... 2b) Justified for a new objective So, XFS and LVM (DM-LVM2) are existing objectives. So if the new features can be put into those objectives, at their respective levels, they should be included. Stratis Storage might require it's own, new objective, which brings us back to #1 ... Upstream acceptance. It's clearly an upstream project. [1] But is Stratis well accepted yet? Now some people might ask why we're not covering ZFS, but legally, I don't think we can. So if Stratis gains mindshare, then it should be considered. But it's probably better to put it into a Storage-specific LPI 300 (LPIC-3) exam, unless it becomes common usage. - bjs *[1] GitHub: Stratis Storage* - https://stratis-storage.github.io/ P.S. Regarding ... On Wed, Jul 31, 2019 at 11:01 AM Marco Verleun <[email protected]> wrote: > If something from RHEL 8 should be integrated into LPIC-1 it’s probably > the new package manager which is still called yum, but which has the > concept of modules (AppStreams). Fedora Modular (Modularity) resulted in RHEL Application Streams (AppStreams), which a long and deep, 3 year discussion with a total muntiny involved at one point (again, long and deep discussion). It's kinda a distro-specific concept in a Fedora Packaging/Distribution guideline sense as much as Red Hat Content Distribution Network (CDN) / Satellite RHEL "Child Channels" are, as would Debian's Packaging/Distribution guidelines would be. And as far as YUMv4, it's DNF. DNF is a complete, largely C-based (with built-in features, but still the option for Python plug-ins) re-write of YUM (Python) that was really a nice* 'roll-up' *of all of the extensions that had been added to YUM over the years, that should be built-in, as well as a complete re-write of the API. What prompted it? It was long in coming, but a very tragic event basically tripped the consideration. The death of YUM's founder, and a colleague of many of us. Basically, he was* 'the man'* and with his passing, someone had to really* 'take the reins' *and basically put the idea of* 'an overhaul'* into overdrive. After all, YUM originally stood for YellowDog Updater Modified (YUM), YellowDog being a RHL/Fedora distribution for PowerPC, before Red Hat released one. There are many stories, but that's really the one that, again, *'tripped the consideration.'*
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
