I think andible is best but maybe also a simple recognize the others too
On Fri, Feb 11, 2022 at 11:11 AM Bryan Smith via lpi-examdev <[email protected]> wrote: > > Being of blatantly clear Red Fedora bias, I'm hardly against such. ;) > > I just wanted to seem neutral and included Chef and Pupet. But if we pick > only one (1) tool, then I'd agree, Ansible ... and possibly tucked under SSH > instead of a new Sub-Objective for Configuration Management. > > I leave it to others to decide, but I'd limit the scope to running existing > Playbooks, and how to identify/use existing Inventory files with existing > Defaults/Variables, Tasks and Handlers. > > As always, my very opinionated $0.02 / €0.018. ;) > > - bjs > > On Fri, Feb 11, 2022 at 6:49 AM Éric Deschamps via lpi-examdev > <[email protected]> wrote: >> >> Hello, >> >> Le 11/02/2022 à 11:51, Eden Caldas via lpi-examdev a écrit : >> > Hi >> > >> > Hi. I don't think LPIC-2 should dive too deep into this. As you said, >> > There's the devtools exam. Linux exam should be about Linux. >> > >> > If you really want to add some automation, don't add all 3 of the main >> > ones, again we have the DevOps exam for that. Add Ansible only. It's the >> > best choice because it uses other mechanisms common to the Linux >> > environment (SSH). >> >> >> I agree with that. >> >> You might also keep in mind that it would be hard to add ansible + chef >> + pupett in an exam training. Or it would be training without practice, >> which does not make sense. >> >> Have a nice day, >> >> Eric >> >> > >> > My 2 cents. >> > >> > On Thu, 10 Feb 2022, 01:47 Bryan Smith via lpi-examdev >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > On Wed, Feb 9, 2022 at 2:11 PM Fabian Thorns via lpi-examdev >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > The current objectives are on the wiki: >> > https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5 >> > <https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5> >> > The page already contains some future change considerations, >> > including >> > some contents that will likely be removed from the exam. But please >> > feel free to bring up *any* aspect you’d like to discuss. This >> > explicitly includes weight changes if you feel some topics should >> > be >> > tested at another level. >> > However, there are two rather general concerns that I would like to >> > point out explicitly: One of them is configuration automation. >> > Manual >> > administration is clearly often not the preferred way to administer >> > systems, so it might be a good idea to include some portions of >> > it in >> > LPIC-2. We do already have a topic on this in the DevOps Tools >> > Engineer (topic 704, 10 weights in total!) which may serve as a >> > baseline for a similar topic in LPIC-2. >> > >> > >> > Yeah, to take a first, simple crack at it, I'd probably have >> > something like (needs major refinement) ... >> > >> > >> > Topic 206: System Maintenance >> > ... >> > 206.4: Configuration Management (weight: 2 ~ 4?) >> > >> > Description: Candidates should be able to identify and execute >> > pre-existing Ansible, Chef and Puppet components and solutions to >> > ensure a target server is in a specific state regarding its >> > configuration and installed software. >> > >> > Key Knowledge Areas: >> > >> > - Basic feature and architecture knowledge of Ansible >> > - Basic feature and architecture knowledge of Chef >> > - Basic feature and architecture knowledge of Puppet >> > >> > The following is a partial list of the used files, terms and utilities: >> > >> > - Inventory, Default/Variable, Task, Handler, Builtin >> > - Recipe, Cookbook, Manifest, Class >> > - ansible-playbook >> > - chef-solo >> > - puppet >> > >> > >> > >> > Another trend is containerization. This is a thin line, since >> > the LPIC >> > track is still closely aligned to system administration, while >> > Podman, >> > Docker, et. al. include far more aspects, like application >> > packaging, >> > building tools. Adding these topics in detail to LPIC would >> > require a >> > lot of room and actually change the program’s characteristics. >> > >> > >> > Like Configuration Management, probably should be limited to >> > starting and destroying premade instances, or things will quickly >> > get out of hand. >> > >> > >> > -- >> > Bryan J Smith - http://www.linkedin.com/in/bjsmith >> > <http://www.linkedin.com/in/bjsmith> >> > E-mail: b.j.smith at ieee.org <http://ieee.org> or me at >> > bjsmith.me <http://bjsmith.me> >> > >> > _______________________________________________ >> > lpi-examdev mailing list >> > [email protected] <mailto:[email protected]> >> > https://list.lpi.org/mailman/listinfo/lpi-examdev >> > <https://list.lpi.org/mailman/listinfo/lpi-examdev> >> > >> > >> > _______________________________________________ >> > 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 > > > > -- > > -- > Bryan J Smith - http://www.linkedin.com/in/bjsmith > E-mail: b.j.smith at ieee.org or me at bjsmith.me > > _______________________________________________ > 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
