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

Reply via email to