To test it you can do the following:

git version on stdout

> git --version 2> error 1> output 
> cat output
git version 2.51.0

ssh version on stderr

> ssh -V 2>> error 1>> output
> cat error
OpenSSH_9.9p1, OpenSSL 3.2.4 11 Feb 2025

Hope this will be helpful.

The first hurdle I faced was that there was no documented release process. What we had were release managers' private notes. It was over in personal repositories, internal Red Hat Google Docs, and personal code. Since all those past release managers left the organization (apart from one), it was very difficult to gather and figure out what, why, and how the release process worked. I had one supporter, my trainer (the then-release manager), Christian. He shared with me his notes and the steps he followed. He guided me on how he did the release.

Now we have a community release managers working group where contributors from the community also take part and release Ansible. And we have the two aforementioned GitHub actions.

• First one builds the package and also opens a PR to the repository, and then waits for human input.
• Meanwhile, the release manager can use the second action to create another PR to the Ansible documentation repository from the updated porting guide from the first PR.
• After the PRs are approved, the release manager can continue with the first action and release the Ansible wheel package and the source tarball to PyPI in a fully automated way using trusted publishing.

I would like to thank Felix, Gotmax and Sviatoslav for feedback during the journey, thank you.

Many say automation is bad. In many companies, management gets the wrong idea that, when good automation is in place, they can fire senior engineers and get interns or inexperienced people to get the job done. That works till something breaks down. The value of experience comes when we have to fix things in automation. Automation enables new folks to get introduced to things, and enables experienced folks to work on other things.

The above is an example of how to create a draft PR via GitHub Actions. We need to give permissions to the GitHub action to create PR in a repository (workflow permissions in the settings).

Hopefully, this blogpost will help my future self.

Day before the conference

What makes this PyCon, is that we were traveling there as a family and the conference days coincided with the Easter holidays. We utilized that to explore the city—the ancient cathedrals, palaces, old cafes, and of course the Lithuanian cuisine. Šaltibarščiai, Balandeliai and Cepelinai.

Tuesday

22nd, the day before the conference was all about practicing the talk and meeting with the community. We had the pre-conference mingling session with the speakers and volunteers. It was time to meet some old and many new people. Then it was time for PyLadies. Inga from PyLadies Lithuania, Nina from Pyladies London and I had a lovely dinner discussion—good food with the PyLadies community,technology, and us.

Wednesday

The morning started early for us on the day of the conference. All the 3 of us had different responsibilities during the conference. While Py was volunteering, I talked and Kushal was the morning keynoter A Python family in a true sense :)

I had my talk, “Using PyPI Trusted Publishing to Ansible Release” scheduled for the afternoon session. The talk was about automating the Ansible Community package release process with GitHub action using the trusted publisher in PyPI. The talk described - what is trusted publishing.I explanined the need for it and the usage of trusted publishing. I explained the Ansible manual release process in a nutshell and then moved to what the Ansible release process is now with  GitHub actions and Trusted Publishing. Then the most important part is, the lessons learned in the process and how other open-source communities can get help and benefit from it.Here is the link for the slides of my talk I had questions regarding trusted publishing, experience as a release manager, and of course Ansible.

It was the time to bid goodbye to PyCon Lt and come back home. See you next year. Congratulatios organizers for doing a great job in organizing the coference.

On October 10th, 2024, I had my talk at PyCon NL. I woke up early to practice. I saw an email from PyLadiesCon, titled "Invitation to be a Keynote Speaker at PyLadiesCon". The panic call went to Kushal Das. "Check if there is any attack in the Python server? I got a spamming email about PyLadiesCon and the address is correct. "No, nothing.", replied Kushal after checking. Wait then "WHAT???". PyLadiesCon wants me to give the keynote. THE KEYNOTE in PyLadiesCon.

Thank you Audrey for conceptualizing and creating PyLadies, our home.

And here I am now. I will give the keynote on 7 December 2024 at PyLadiesCon on how PyLadies gave me purpose. See you all there.

Dreams do come true.

My Talk: Intellectual Property Law 101

I had my talk on Intellectual Property Law, on the first day. After a long time, I was giving a talk on the legal topic. This talk was dedicated to the developers. So, I concentrated on only those issues which concerned the developers. Tried to stitch the concerned topics Patent, Trademarks, and Copyright together. For the smooth flow of the talk, since it becomes easier for the developers to understand and remember for all the practical purposes for future use. I was concerned if I would be able to connect with people. Later, people came to  me with several related questions, starting from

• Why should I be concerned about patents?

• Which license would fit my project?

• Should I be scared about any Trademarks granted to other organizations under some other jurisdiction?

So on and so forth. Though I could not finish the whole talk due to time constraints, I am happy with the overall review.

Panel: Open Source Sustainability

On Day 1 of the main conference, we had the panel on Open Source Sustainability. This topic lies at the core of open-source ecosystem sustainability for the projects and community for the future and stability. The panel had Deb Nicholson, Armin Ronacher Çağıl Uluşahin Sönmez,Deb Nicholson, Samuel Colvin, and me and Artur Czepiel as  the moderator.  I was happy to represent my community's side. It was a good discussion, and hopefully, we could give answers to some questions of the community in general.

Birds of Feather session: Open Source Release Management

This Birds of Feathers (BoF) session is intended to deal with the Release Management of various Open Source projects, irrespective of their size. The discussion includes all projects, from a community-led project to projects maintained/initiated by big enterprises, from a project maintained by one contributor to a project with several hundred contributors.

• What methods do we follow regarding versioning, release cadence, and the process?

• Do most of us follow manual processes or depend on automated ones?

• What works and what does not, and how can we improve our lives?

• What are the significant points that make the difference?

We discussed and covered the following topics: different aspects of release management of Open-Source projects, security, automation, CI usage, and documentation. We followed the Chatham House Rules during the discussion to provide the space for open, frank, and collaborative conversation.

PyLadies Lunch

And then comes my favorite part of the conference: PyLadies Lunch. It was my seventh PyLadies lunch, and I was moderating it for the fifth time. But this time, my wonderful friends [Laís] and Çağıl were by my side, holding me up when I failed. I love every time I am at a PyLadies lunch. This is where I get my strength, energy, and love.

Workshop

I attended two workshops organized by Anezka Muller , Mia Bajić and all amazing PyLadies organizers

• Self-defense workshop where the moderators helped us navigate challenging situations we face in life, safeguard ourselves from them, and overcome them.

• I AM Remarkable workshop, where we learned to tell people about our successes.

Representing Ansible Community

I always take the chance to meet the Ansible community members face-to-face. Euro Python gave me another opportunity to do that. I learned about different user stories that we do not get to hear from our work corners, and I learned about these unique problems and their solutions in Ansible. 
Fun fact : Maarten gave a review after knowing I am Anwesha from the Ansible project. He said, 'Can you Ansible people slow down in releasing new versions of Ansible? Every time we get used to it, we have a new version.'

Acknowledging mental health issues

The proudest moment for me personally was when I acknowledged my mental health issues and later when people came to me saying how they relate to me and how they felt empowered when I mentioned this.

PyLadies network at Red Hat

A network of PyLadies within Red Hat has been my dream since I joined Red Hat. She also agreed when I shared this with Karolina at last year's DevConf. And finally, we initiated on day 2 of the conference. We are so excited for the future to come.

Meeting friends

Conference means friends. It was so great to meet so many friends after such a long time Tylor, Nicholas, Naomi, Honza, Carol, Mike, Artur, Nikita, Valerio and many new ones Jannis Joana,[Chirstian], Martina Tereza , Maria, Alyona, Mia, Naa , Bojanand Jodie. A special note of love to Jodie, you to hold my hand and take me out of the dark.

The best is saved for the last. Euro Python 2024 made 3 of my dreams come true.

• Gender Neutral Washrooms

• Sanitary products in restrooms (I remember carrying sanitary napkins in my bag pack in PyCon India and telling girls if they needed it, it was available in the PyLadies booth).

• Neo-diversity bag (which saved me at the conference; thank you, Karolina, for this)

I cannot wait for the next Euro Python; see you all at Euro Python 2025.

PS: Thanks to Lias, I will always have a small piece of Euro Python 2024 with me. I know I am loved and cared for.

Day 0 of the main conference

After a long time, I will give a legal talk. We are going to dig into some basics of Intellectual Property. What is it? Why do we need it? What are the different kinds of intellectual property? It is a legal talk designed for developers. So, anyone and everyone from the community with previous knowledge can understand the content and use it to understand their fundamental rights and duties as developers.Intellectual Property 101, the talk is scheduled at 11:35 hrs.

Day 1 of the main conference

Day 1 is PyLadies Day, a day dedicated to PyLadies. We have crafted the day with several different kinds of events. The day opens with a self-defense workshop at 10:30 hrs. PyLadies, throughout the world, aims to provide and foster a safe space for women and friends in the Python Community. This workshop is an extension of that goal. We will learn how to deal with challenging, inappropriate behavior.
In the community, at work, or in any social space. We will have a trained Psychologist as a session guide to help us. This workshop is so important, especially today as it was yesterday and may be in the future (at least until the enforcement of CoC is clear). I am so looking forward to the workshop. Thank you, Mia, Lias and all the PyLadies for organizing this and giving shape to my long-cherished dream.

Then we have my favorite part of the conference, PyLadies Lunch. I crafted the afternoon with a little introduction session, shout-out session, food, fun, laughter, and friends.

After the PyLadies Lunch, I have my only non-PyLadies session, which is a panel discussion on Open Source Sustainability. We will discuss the different aspects of sustainability in the open source space and community.

Again, it is PyLady's time. Here, we have two sessions.

[IAmRemarkable](https://ep2024.europython.eu/pyladies-events#iamremarkable), to help you learn to empower you by celebrating your achievements and to fight your impostor syndrome. The workshop will help you celebrate your accomplishments and improve your self-promotion skills.

The second session is a 1:1 mentoring event, Meet & Greet with PyLadies. Here, the willing PyLadies will be able to mentor and be mentored. They can be coached in different subjects, starting with programming, learning, things related to job and/or career, etc.

Birds of feather session on Release Management of Open Source projects

It is an open discussion related to the release Management of the Open Source ecosystem.
The discussion includes everything from a community-led project to projects maintained/initiated by a big enterprise, a project maintained by one contributor to a project with several hundreds of contributor bases. What are the different methods we follow regarding versioning, release cadence, and the process itself? Do most of us follow manual processes or depend on automated ones? What works and what does not, and how can we improve our lives? What are the significant points that make the difference? We will discuss and cover the following topics: release management of open source projects, security, automation, CI usage, and documentation. In the discussion, I will share my release automation journey with Ansible. We will follow Chatham House Rules during the discussion to provide the space for open, frank, and collaborative conversation.

So, here comes the days of code, collaboration, and community. See you all there.

PS: I miss my little Py-Lady volunteering at the booth.

What is Event Driven Ansible?

What is Event Driven Ansible? In simple terms, some action is triggered by some events. The idea of EDA comes from Event driven architecture. Event driven ansible runs code automatically based on received event notifications.

Some important terms:

What is event in Event Driven Ansible?

The event is the notification of a certain incident.

Where do we get the events from?

We get the events from event sources. Ansible EDA provides different pulgins to support various event sources. There are several event source plugins such as :
url_check (checking the http status code), webhook (providing and checking events from webhook), journald (monitoring the journald logs) and the list goes on.

When to take actions?

Rulebook defines conditions and actions in case of fulfilling those actions. Conditions use operators as strings, boolean and numerical data. And actions are occurrence of events once the conditions are met. Running a playbook, setting a fact, running a module etc.

Small example Project

Here is a small example of Event Driven Ansible and how it is run. The idea is on receiving of a message (here the number 42) a playbook will run in the host. There are the following 3 files :

demo_rule.yml

---
- name: Listen for events on a webhook
  hosts: all

  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 8000

  rules:
    - name: Say thank you
      condition: event.payload.message == "42"
      action:
        run_playbook:
          name: demo.yml

This is the rulebook. We are using the webhook plugin here as the event source. As a rule in the event of receiving the message 42 as json payload in the webhook, we run the playbook called demo.yml

demo.yml

- hosts: localhost
  connection: local
  tasks:
    - debug:
        msg: "Thank you for the answer."

demo.yml, the playbook which run on the occurrence of the event mentioned in the rulebook and prints a debug message.

---
local:
  hosts:
    localhost

inventory.yml mentions the hosts to run the action against.

Further there are 2 files to one to test 42.json and 43.json to test the code.

{
  "message" : "42"
}

{
  "message" : "43"
}

First we have to install all related dependencies before we can run the rulebook.

$ python -m venv .venv
$ source .venv/bin/activate
$ python -m pip install ansible ansible-rulebook ansible-runner psycopg
$ ansible-galaxy collection install ansible.eda
$ ansible-rulebook --rulebook demo_rule.yml -i inventory.yml --verbose

Go to another terminal and on the same directory path and run the following command to test the Rulebook. After receiving the message, the playbook runs.

curl -X POST -H "Content-Type: application/json" -d @42.json 127.0.0.1:8000/endpoint

Output

2024-06-07 16:48:53,868 - ansible_rulebook.app - INFO - Starting sources
2024-06-07 16:48:53,868 - ansible_rulebook.app - INFO - Starting rules

...

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "Thank you for the answer."
}

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
2024-06-07 16:50:08,224 - ansible_rulebook.action.runner - INFO - Ansible runner Queue task cancelled
2024-06-07 16:50:08,225 - ansible_rulebook.action.run_playbook - INFO - Ansible runner rc: 0, status: successful

Now if we run the other json file 43.json we see that the playbook does not run even after the http status code being 200.

curl -X POST -H "Content-Type: application/json" -d @43.json 127.0.0.1:8000/endpoint

Output :

2024-06-07 18:20:37,633 - aiohttp.access - INFO - 127.0.0.1 [07/Jun/2024:17:20:37 +0100] "POST /endpoint HTTP/1.1" 200 159 "-" "curl/8.2.1"

You can try this yourself follwoing this git repository.

• Base, includes the following

  • fedora base image
  • ansible core
  • ansible collections : The following set of collections
    ansible.posix
    ansible.utils
    ansible.windows

• Minimal, includes the following

  • fedora base image
  • ansible core

I have been the release manager for Ansible Execution Environments. After building the images I perform certain steps of tests to check if the versions of different components of the newly built correct or not. So I wrote eercheck to ease the steps of tests.

What is eercheck?

eercheck is a command line tool to test Ansible community execution environment before release. It uses podman py to connect and work with the podman container image, and Python unittest for testing the containers.

eercheck is a command line tool to test Ansible Community Execution Environment before release. It uses podman-py to connect and work with the podman container image, and Python unittest for testing the containers. The project is licensed under GPL-3.0-or-later.

How to use eercheck?

Activate the virtual environment in the working directory.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

Activate the podman socket.

systemctl start podman.socket --user

Update vars.json with correct version numbers.Pick the correct versions of the Ansible Collections from the .deps file of the corresponding Ansible community package release. For example for 9.4.0 the Collection versions can be found in here. You can find the appropriate version of Ansible Community Package here. The check needs to be carried out each time before the release of the Ansible Community Execution Environment.

Execute the program by giving the correct container image id.

./containertest.py image_id

Happy automating.

Ansible has historically been released by Red Hat employees. We planned to open up the release to the community. And I was asked about that. My primary goal was releasing Ansible, which should be dull and possible for the community. This was my first time dealing with Github actions. There is still a lot to learn. But we are there now.

The Release Management working group started releasing the Ansible Community package using GitHub Actions workflow from Ansible version 9.3.0 . The recent 9.4.0 release has also been released following the same workflow.

Thank you Felix Fontein, Maxwell G, Sviatoslav Sydorenko and Toshio for helping out in shaping the workflow with you valuable feedback, doing the actual release and giving answers to my enumerable queries.

The preparation should be twofold. One, before traveling, two, the day before the conference, and third, during the conference.

Before traveling

Flu shot

Fosdem is infamous for its flu. Trust me, I and many of my team members got it, and it's nasty. I didn't get the flu shot and suffered (and how). Get your flu shots early enough to be effective during the conference.

Prior appointments

The conference is enormous. Trillion activities are going on at the same time. So unlike other conferences, everyone only comes across one another despite spending two days at the same venue. So, if you want to meet people, make plans way early. Fix the appointment (date, time, and exact location)

Fringe Events

There are many events in and around the conference days in Belgium. Such as CentOS Connect, the EU Open Source Policy Summit, Config Management Camp, etc. Look for such events to visit.

Hotel Booking

There needs to be more places to stay near the conference venue. The most convenient places are near the city center. Try to book the hotels in advance, especially in the city center. If you wait, there is a high likelihood you won't be able to get the place. Also, check the distance from the conference venue. Coordinate with your friends if you want to stay at the same hotel.

Perp before the day of the conference

Packing

We need to pack a water bottle and some food. You might need more time/energy or a chance to stand in the long queue for food. So better be ready with your stock.

Notes

There will be a lot of interesting discussions and new and old contacts that you will need help remembering. So you need to take a lot of notes. Take your notebook or pen, or charge the note-taking device.

Pack light

There will only be a few chances to sit, so pack light. If you do not want to have a sore back after the conference. Charge your laptop

The days of the conference

Navigate the venue

The conference venue is huge and needs to be clarified (at least for the first-timer). Find out where are rooms are beforehand since it is going to be long queues.

Start early

Start earlier than usual if you want to meet someone at a particular time. You will encounter some of your friends and get stopped from engaging in the conference.

Supplies

If you carry your cards, run a booth, or have any giveaways, slot them throughout the day so you stay supplied on the first go. However many you carry, you will finish the stuff.

Talks

The rooms get filled up very quickly. If you wish to attend any talks, make a list and try to get into the room at the very beginning of the schedule. Otherwise, you have very few chances to get inside the room.

Hallway Tracks

Hallway tracks are the most exciting place to be in. All the intriguing discussions happen here, starting from technology, community, the legal, and policy, you name it. You will find your next best project idea. Remember the famous Pacman rule: leaving space for someone to join your group in a circle, like the Pacman logo. You may find the person you look up to, your mentor, a fellow developer to work with you on your project, or your friend. But one thing is for sure: you will find your community there.

So have a proper breakfast and run to the venue because "Fosdem ain't like any other conference."

We started from Brussels in the afternoon on the last day of Fosdem. My most complicated part was to bid goodbye to my daughter, who was accompanying me at the Fosdem. She tried to convince me to take her by saying, "I will be helpful in the booth duty." Failing that proposition, she finally said bye with a note: "Help [Carol], she works a lot."
We reached Ghent in the early afternoon. Thank you, Boris, for giving us the ride and community help. After a walk around the city in the light festival and experiencing my first bubble tea, we reached the conference dinner. And how nice to meet [Florian] over there.

Days of the Conference

I traveled to this place with a pretty extensive list of agendas:

• Finish working on some (long stuck) PRs
• Plan on some of the technical decisions
• Discuss some future community plans
• Hacking on some issues
• And, of course, a lot of meetings with my fellow community members

Most of us stayed in the same hotel, making travel more accessible and having exciting conversations on tram rides. We started for the venue early in the morning. We had a booth next to our friendly neighbor Foreman's (once again after Fosdem). [Rick], [Greg], [Don], [Carol], and I shared the booth duties. And of there was [Tim] [Felix], and [David] helping us with the questions from our users and contributors. We had 2 Ansible tracks this year at the Config Management camp.

The talk lists

This time, again, I could only spend a little time attending the talks due to the booth duty (which I enjoy to the fullest) and the room moderator duty. The room duty allows us to listen to the talks on the best seat :). There is a list of talks that I could not get to attend but kept on my watch list :

1. Terraforming with Ansible by Tim Appnel
2. [Where does your Ansible code come from?] by Fabio Alessandro "Fale" Locati
3. [Simplifying Cloud Deployments with Ansible for React Next.js on AWS EC2] by Rose Crisp
4. We Fear Change by Coté
5. [If Dev and Ops had a baby, it would be called Winglang] by D.Aud
6. [Automating Hybrid Clouds with Event-Driven Ansible] by Ricardo Carrillo Cruz
7. Ansible - State of the Community(https://cfp.cfgmgmtcamp.org/2024/talk/3ZD3WX/) by Greg Sutcliffe
8. [Automating project documentation for the win] by Don Naro
9. Unstructuring your mind: Ansible vs. JSON by Felix Frank
10. Where does your Ansible code come from? by Fabio Alessandro "Fale" Locati

Ansible Colab Day

The last day of Config Management Camp was Ansible Colab Day. We started a little late. It was the day with all Ansible. The day started with [Sutapa] sharing her journey as she changed her career path from being a GIS professional to an Open source contributor with Ansible Community. She joined us online. Witnessing her journey and playing a small part in that felt really nice. Greg shared with us the state of the Ansible Community. Don shared with us what is going on with the Ansible Documentation. Felix, David, and I presented to the community the 'Past, Present, and Future of the Ansible Release Management.' After lunch, we sat for a chatting and hacking session in a more informal session. And with that, we called an end to the conference.

Au revoir

After Five days of friends, festivals, and feasts, saying goodbye is always hard. I finished my todo list and filled my notepads with ideas and upcoming todos. I met some wonderful people and made some great friends. A special note of gratitude to the organizers for this fantastic event over the years. Until we make it the next time (I wish to do it soon), thank you for all your contributions, and see you online.

Moment to cherish

At one of the conference dinners. I introduced myself as a Red Hatter, and he said, "Ahh, Red Hat, you are the good ones." It made my day. 'Yes, we are good ones; we always strive to keep the trust and name going.'

Fosdem == Friends

Conferences are always the place to meet, interact with people, make new friends, and meet old pals. I always prefer hallway tracks more than going to talks. Especially in the era where all the talks are getting recorded. Fosdem is no exception. I was attending a conference after some time, so it made it more special.

My adventure started two days before the conference by meeting saptaks after a year. It was the same as before, chatting about different technologies, communities, projects, and much more till midnight. The next day, I met Spot for lunch. I met him in 2019 for the first time after he started mentoring me. So we had a lot to catch up with. The Dinner was with Greg ,(whom I was meeting for the first time), Don , and the Red Hat OSPO team. Since I joined Red Hat (instead of before I joined), I have been curious about how our OSPO works. This is one of the primary teams that helps to keep the Red Hat culture and integrity" alive. I have followed Brian Proffitt's work since I joined the Open Source Software community. At the Dinner, I got to converse with him on various topics, starting from open-source communities, OSPO's different types and evolution of Fosdem and communities over the years, and Red Hat past, present, and future. It was fascinating and enlightening.

Conference Days == booth duty

Day 0 started early. We needed to reach early to set up the Ansible booth. Our super organizer Carol could not arrive during the booth set up due to a workers' strike in her hometown. Greg and Don already did the initial setup before I reached out. We tried to manage the booth in her absence. We were sharing the booth with Foreman . Carol reached before afternoon and took charge, and everything was smooth (as ever). How does she make it seem easy every time? People think organizing events and managing booth duties is always fun and easy, but it is a lot of planning and detailed work. And every time I see her doing planning, chalking out every single detail within the organization, community, organizing committee, and with the sponsors, I am in awe. Andrei and Rick also joined us in the booth. It was great to point the users to the respective upstream authors whenever there was a question regarding the collections or AWX :).

It was the first time I got to meet David and Felix.
I have learned so much from them regarding the different parts of the project, especially the release process. This was the highlight of my Fosdem.

Booth duty is something I enjoy. It is always wonderful to talk to your users and contributors. It is our chance to say "thank you" to them. However, managing the Ansible booth was strikingly different from managing booths for other projects. The attendees who visited our booth can broadly be grouped into the following three categories :

• People who do not know about Ansible/ or are new in their Ansible journey
• Users who use it extensively (in their day job, open source community project)
• Contributors

Each of the section of people, given their varied interests and experience, asked questions which can roughly divided into the following :

• What is Ansible? What does it do?
• How is Ansible similar to projects A, B, or C?
• How can we contribute?
• How can we talk to the upstream?
• I have x questions. Where can I get help?

These are not unique. But different sets come here. Mostly, the people came with saying, "Thank you for Ansible," "We love your project," "I use Ansible every day for x period, and it makes my life so easy," or "We like the new Ansible Forum, it makes our life so easy. " The next most common set was "We need this "y" feature; it will help our project. I will work on this." "I think our project needs this, I will work on this." and "We need to fix this, I need to work on this." This is where the difference comes in.
A. Our users seem (actually proved) happy and satisfied with the project.
B. We have an excellent contributor base that is loyal to the project. They do not only look for issues but also offer and take responsibility for the solution.
We did not have much criticism or feature requests, which is rare per my experience in booth duties. It clears up two aspects for Ansible,
the first one is that people trust our project and find it dependable.
Second, our project solves and takes care of the imminent issues around the part of infrastructure that.....

The fan-girl moments

Conferences allow me to meet all the upstream authors of the projects I use daily, people I admire and aspire to follow their career paths. And Fosdem gives you plenty of such opportunities. Deborah Bryant, Nithya Ruff, Brian Proffitt, Jan Wildeboer, Rich Bown, Zaheda Bhorat. The conference becomes more magical when you get the 'you worth it' ... feeling from them. Be it having one-on-one conversations regarding open-source communities and business policies with Nitya. Or when Deb telling people, 'Hey, you Red Hatters, I wanted to hire her, but you got her before me.' These are the moments for which I get up each time I fail.

Thank you, Fosdem. Thank Open Source. Long Live community.

I released the Ansible 8.3.0 on 15th August, 2023. This is the Ansible stable release. You can read the full Changelog here

You can install it via pip.

python3 -m pip install ansible==8.3.0 --user

You can have a look at the announcement.

Fun fact while working on the release Github worked below 30 KiB/s speed the whole day.

To follow all our updates on Ansible project and community susbcribe to Bullhorn, our weekly Newsletter. Join us in our community discussion at this Matrix room.

After coming from DevConf.cz, on 22nd of June I released Ansible Community Package 7.7.0 and 8.1.0. This is the last release of the Ansible 7 series and first minor release of the Ansible 8 series.

Ansible Community Package 7.7.0

Ansible 7.7.0 requires latest version of ansible-core 2.14 and includes a curated set of Ansible collections that provides a vast number of modules and plugins.

One can have a look at the full Changelog.

You can install it via pip.

pip install ansible==7.7.0 --user

Ansible Community Package 8.1.0

Ansible 8.1.0 requires latest version of ansible-core 2.15.1 and includes a curated set of Ansible collections providing a huge number of modules and plugins.

You can get the Changelog here.

One can install Ansible 8.1.0 via pip

$ python3 -m pip install ansible==8.1.0 --user

Roadmap for future releases

You can read our Roadmap for the Ansible 8 release cycle here and the changelog here To follow all our updates on Ansible project and community susbcribe to Bullhorn, our weekly Newsletter. ETA for next Ansible Community Package release, i.e 8.2.0, is 18th July, 2023.