Meeting started at 2026-04-22 16:59:03 UTC

The Meeting name is 'Fedora Server'

Roll call

!hi

!hi

Peter Boy (ServerWG, Docs): Peter Boy (pboy)

Paul Maconi (Aggraxis): Paul Maconi (aggraxis) - he / him / his

Peter Boy (ServerWG, Docs): Hello

Hello Paul

Peter. how many do we need for a quorum?

minimum more then 3 members

Peter Boy (ServerWG, Docs): Thx

No important issues, just the already known with aarch image. But we should "smoke test" if those still work.

I won't be able to do any testing until after work this evening, and I know QA wants results ahead of the go/no-go

Yes, the go(no-to meeting is tomorrow

Quite a tight time schedule

I don't have anything to "smoke test" aarch stuff. Does anyone else?

s/anything/hardware/

It was me so far. And I tested our iso images.

Jocelyn tested the VM.

So is it okay to say Peter will "smoke test" aarch images if time permits?

I'm not sure if I can manage to do all these tests in time.

But I will try hard, so we can say that.

Problem is, I managed to get a time slot on the release party for Server. So I have to prepare the talk, too.

Does anyone else have anything to discuss before we move on to the ansible topic.

not from me

no

Have either of you used ansible in the past?

I use it extensively in my line of work.

Not in real, just by reading and studying

Paul Maconi (Aggraxis): If I say something stupid or if you disagree, don't hesitate to speak up.

In my opinion, the hardest part of ansible is the learning curve to get started.

The next hardest part for new users is learning that ansible is basically a "state" machine and is not a "procedural" language.

I think for our purposes, I have a couple of questions.

It can be, but keep in mind you can use it as a "script monster" first, and then morph your work into state management.

The whole crawl, walk, run, thing.

Agreed

1) The ansible project provides a lot of documentation that is pretty good. But it describes so many possible alternatives that new users get lot.

I would like us to think about creating a document for Ansible Server aimed a new users of ansible with suggested configurations and coding styles.

For instance, should we suggest that configuration files go under /etc/ansible or under ~/ansible? One style is for system-wide configuration and the other style is for individual user configuration?

Any opinions?

As a kind of "development for Server Guide"?

You don't necessarily even have to have an "ansible server" per se

Peter Boy (ServerWG, Docs): Yes

You *CAN* manage things centrally from one server, or you can install it at your endpoints and run playbooks locally

Paul Maconi (Aggraxis): I think, it is good to have an explizit naming (and location) convention,

Can you define "it" in reference to the endpoints?

There is also a *TON* of documentation out there not just for Ansible and its modules, but also for just generally working through the kinds of problems Ansible is great at solving.

Familiarization with Python (not expertise, just some exposure) and how YAML formatting works will get you over the initial Ansible speed bumps

So, there is one decision, where we want to store the playbooks, on the admin workstation or on each server?

But I wouldn't take someone straight into managed inventories with git-hosted projects and tying everything into AWX or the Ansible Automation Platform

I was thinking of short "suggestions" or "best practices" in our document with references to the Ansible provided documentation.

That's all a bit much. Or even Role building. Roles are a down the road issue once you've learned to solve some of your initial issues like, say, setting all of your machine's domain search parameters, etc

Paul Maconi (Aggraxis): Agreed

That's a quick one or two task playbook

Or even something like this that checks for updates and sends a webhook to rocket chat: https://github.com/Aggraxis/public_ansible/blob/master/yum_update_counts_to_rocketchat.yml

Paul Maconi (Aggraxis): What do you think we need to provide beginning users of ansible to start learning how to maintain/install their servers?

they need to know where the existing documentation is, even if that means pointing them outside of the fedora project

Fedora has this behavioral quirk where we keep internalizing documentation and reinventing the wheel when we really should say "check out this documentation at Ansible that talks about community.general.lineinfile so you can make quick edits to your configs in /etc/sssd.conf" or whatever

John Himpel: Isn't our target the administrator, esp. the new administrator?

I have no problem pointing outside of the fedora project. After all ansible is not a fedora project but rather a RedHat project.

If our target is a brand new administrator Ansible is a powerful tool to use, but it's probably not the right thing to show someone first

We are consistantly all "upstream first"

so external is not an issue+

Peter Boy (ServerWG, Docs): I think the administrator (new or experiences) who is new to andible and possibly Fedora Server is our target.

OK

But if we're doing ansible, which is great, we should get folks familiar with their docs.

!hello

Emmanuel Seyman: Emmanuel Seyman (eseyman) - he / him / his

Hello, folks! Sorry, I'm late

Hi EmmanuelQ

And then maybe provide small examples of routine tasks someone might want to automate, like updates, or reporting uptime, etc.

Peter Boy (ServerWG, Docs): I think Paul's point is we don't need to bring the upstream documentation into Fedora. We can just use references.

A Windows update at $WORK took 10 times longer than expected

Even doing things like setting up a remote nfs mount are pretty easy to do in Ansible

I think for the beginner a short discussion of how to build an "inventory" of self-hosted servers/clients might be useful content in our docs. Also possibly how to interface the "inventory" to a couple of popular cloud services might be nice.

Regarding directory locations: Usually distribution priovided script (tht is developed by us as WG) belong into /usr/share and localy provided variations into /etc.

right, but you might not even put your ansible inventory in /etc depending. you could have an inventory.yml arbitrarily anywhere

it lets you keep your project portable in case the machine croaks or you migrate hosts

From what I've seen, most people wanting to share ansible stuff distribute snippets or roles via a git-based repository and leave the invoking script up to the local admin.

Emmanuel Seyman: Haven't you done ansible stuff in the past? If so, please don't hesitate to jump in.

But isn't our intention a bit different? We want to provide a playbook that makes installation and configuration work as we do describe it in out documentanten, saving the admin from typing as much as possible?

Yeah, it really depends on how you set yourself up. At home I do command line invocations much like infra does here in Fedora. At work we use the Ansible Automation Platform. Everything is managed in git. It's all software-defined mayem.

I've packaged Ansible roles and those rpms put their contents in /usr/share/ansible/roles/

Yeah, it really depends on how you set yourself up. At home I do command line invocations much like infra does here in Fedora. At work we use the Ansible Automation Platform. Everything is managed in git. It's all software-defined mayhem.

My playbooks are in $HOME/playbooks/

These days, I'm testing rackpeek to manage my inventory

Do you have to have a RedHat license to use Ansible Automation Platform?

I don't think so, it's Open Source, isn't it?

You can use AWX if you do not want support

Yes.

Oh, yes the platform

I wouldn't like to introduce external dependencies.

RedHat has a lot of open source stuff that requires a license. Open Source only means you have to provide the source is you distribute a product. You can certainly charge for the product. i.e. RedHat's os is open source (so they provide source), but you have to purchase a license to access their repositories for the product. At least that's how I understand it.

Hm, Open Source is free as in beer. But you have to pay for support or for using ready to use tools and services, yes.

Paul Maconi (Aggraxis): Isn't the Automation Platform just a software product. It's not actually a hardware or vm based product.? is it?

SOrry I had to run down the hall

It's software. Preferred deployment seems to be via container these days, but that's not what I have here

Before we get too far into the weeds, let me make a proposal.

We author a document aimed at admins who are new to ansible.

We should make abundant use of links from our document to Ansible documentation.

Reminder: the clock is ticking

We should show a step-by-step example of creating an inventory of local hosts

We should show a step-by-step example of creating an inventory of cloud-based hosts

We should show an example of a command line invocation of ansible (not using a role)

We should show an example of creating and executing a simple role

End of content

At the end we have to provide an Ansible distributable which creates and configures a service as described in our technisal specifications and documentation. So the admin spares a lot of typing and just has to provide the local specific values for some variables.

And we have to do that for every of our services.

So, our work doesn't end with an examples case. We have to add all the cases.

Configuration is going to depend on local facts (ip address, whether the machine can reach out to the internet, ...). We cannot do this for all usecases

Emmanuel Seyman: yes, indeed. Therefore you need the placeholders.

But each service is going to be tailored to each individual's environment and configuration choices. i.e. not everyone will have the same options for apache or dns or postfix, etc

And of course, we can not provide for all use cases, but for the common basics.

im missing context here but is this about shipping ansible configuration for an entire fedora system, or just for fedora infra?

You seem focused on making the playbooks for people to do the XYZ. Folks like me use Fedora and Ansible to learn how to get Ansible to do the XYZ

cause the former makes it sound a lot like you're trying to compete with nixos (which is a very nice thing)

John Himpel: Yes therefore the placeholders (variable the admin has to provide values for).

Taken to its logical end, that means we have to supply a role and let the admin configure it for his usecase

I mean I get it. You want a self-licking icecream cone product for a portion of the user base that really just wants to push button, get banana.

Emma [it/its]: Just for a specific Fedora Server Service. And a collection, that covers the basic services following our technical specification.

not quite sure i understand the scope here, but sounds neat nonetheless

Emma [it/its]: It's not for infra. Infra has their stuff covered.

Between Infra and releng they're on a completely different plane of existence from where we're looking, which seems to be a packaged works out of the box after minimal input home server product

And honestly, Ansible might not be the answer since F44 has NIX integration anyways

Well, to keep our goal in mind: We want to have for each or our services an Ansible thingy which does all the typing as described in our services installation documdentation, e.g. NFS, so that the admin just has to fill in some local specific variables.

And than has to add maybe some very very special use cases.

Five minute warning!!!!!

And we need a documentation how we did the development, so that a admin can add their owhn special sercices (as Johne descrtibed in his proposal).

I do not believe we should do development. We should integrate existing roles.

The only roles we should develop are those that do not exist yet.

Peter, Ansible's flexibility is what makes it so appealing. But as you can see from the above discussion, each of us invokes, configures, organizes our usage in a different way. That's what make standardization so hard.

Emmanuel Seyman: Agreed. Specifically we have go add Server specific things like our storage organisations

John Himpel: Agreed. That he problem we struggeling with for such a long time.

I think, we should continue this discussion next meeting, what do you think?

I have to run,, so I will shut this down for now. It's been a great discussion, but I think we're still a long ways from agreement on how-to. Feel free to continue in fedora-server (matrix or mailing list). We could also continue next meeting.

Let's continue during the week in our channel and next week here

Let's continue next meeting!