Greenwave 1.9.0 released
by Lukas Holecek
Hi All,
New release of Greenwave is now available and has been deployed to
production.
What's new:
* RHEL product versions in Brew/Koji build tasks are now recognized
properly.
* Internal subject type configuration can use regular expression to extract
short product version from artifact name.
* Satisfied requirements with type "fetched-gating-yaml" now contain
"testcase"
field so as not to break existing clients.
* Unexpected or unsupported Koji task types are now ignored when guessing
product version for new test results allowing decision updates to be
properly
published.
Report bugs:
- https://pagure.io/greenwave/issues
Documentation:
- https://gating-greenwave.readthedocs.io
Get in touch: exd-guild-gating(a)redhat.com
Enjoy,
EXD SP Gating guild
2 years, 2 months
Fedora infra backlog refinement
by Michal Konecny
Hi everyone,
today on Fedora infra weekly meeting I proposed to start doing a backlog
refinement on https://pagure.io/fedora-infrastructure/issues
This should be done in the similar way how the backlog refinement is
done in weekly RelEng meeting.
So how do you want to approach this? Separate new meeting or use
existing weekly meeting and just dedicate a part of it to going through
old tickets.
If we want a new meeting, I would go with weekly and we need to decide
when this meeting will take place.
Regards,
Michal
2 years, 2 months
A couple of questions before contributing to projects
by Onur Özkan
Hey folks,
I am someone new for fedora-infra. I have introduced myself a couple of months ago. But I haven't received any reply about where and how to start so today I wanted to start by picking issues from repositories and solving them. But, I need some answers before I go for that. (I already asked the questions on #fedora-admin but sadly didn't get the answer there. So that's why I ask them from here.)
Questions are:
* We have 2 infra organizations 1 on Github 1 on Pagure. What are the differences?
* We have fedora-infrastructure repository on Pagure without any organization which contains so many issues. But we also have issues on organization repositories. So which issue goes where?
* As a volunteer contributor, where should I pick the issues from for the start? For example, can I start working on this<https://github.com/fedora-infra/the-new-hotness/issues/323> issue?
Please let me know if this is not the right place to ask such questions.
Best regards,
Onur
2 years, 2 months
linux-system-roles/networking, bare metal machines and vm's
by Kevin Fenzi
So, a while back now we decided to move to using
linux-system-roles/networking to setup networking for instances in
ansible.
For bare metal machines this has been working mostly fine.
We install the machine, gather the mac addresses of it's various
interfaces and add them to ansible. Since the mac addresses don't
change, this works fine. This has been a nice help because this sets up
all the bridges we use and avoids us trying to manually configure them.
If you need to change ip's or the like, you can change in ansible, run
the playbook and it will change them on the machine fine (then you can
change them in dns).
For vm's things have been shakier. We initially started trying to use
this for all vm's too, but ran into a problem: virt-install, which we
use to install vm's, creates a new random mac every install. This meant
if you were adding it to ansible git you would have to install, have the
playbook fail, gather mac address and commit it and re-run. This is not
good workflow. I was pondering on this the other day, then realized that
we already have the mac in ansible facts. ;)
So, for vm's the new process is to never commit the actual mac address
to ansible git, instead just pass it in network_connections like:
- name: eth0
mac: "{{ ansible_default_ipv4.macaddress }}"
Then ansible does all the lifting for us and everything just works the
first time. :) If you want to change a ip on a vm, you can just change
it in ansible, run the playbook and it will change it (and then you
change dns).
So, summary:
* for baremetal machines, specify the mac addresses in ansible git.
* for vm's, just pass the existing mac address from ansible facts.
Does this make sense to everyone?
kevin
2 years, 2 months
DNS patch to rename ocp4 clusters, and revert vhmost-ocp changes
by David Kirwan
https://gist.github.com/davidkirwan/ecc1c135b6f2c82b1ef337ebdcd8414b
Hi folks if someone would be so kind as to take a look over our changes
here, we want to revert some vhmost-ocp4 changes and rename the ocp hosts.
Just two things to be aware:
This is commented out line is intentional, as we wish to reuse the
bootstrap.ocp node to become the worker01.ocp node after the control plane
has been installed.
+;worker01.ocp IN A 10.3.166.118
Second question, we've removed the vmhost-ocp nodes from the 160.
management network, not sure if we should have done that.
cheers,
David
--
David Kirwan
Software Engineer
Community Platform Engineering @ Red Hat
T: +(353) 86-8624108 IM: @dkirwan
2 years, 2 months
standard branch names in fedora-infra git repos
by Ryan Lerch
Looking through the fedora-infra org on github, there seems to be a
plethora of different branch names that all roughly cover the same
idea.
Loosley put, there are a bunch of different ways to name branches for:
* develop / dev / main / master
* staging / stage
* prod / stable
Just wondering if there is a default recommendation for naming these 3
branches in a project, and if there isn't can i propose:
* dev
* staging
* stable
cheers,
ryanlerch
2 years, 2 months
Community Platform Engineering Quarterly ~~Bragging Rights~~ Report
Q2 2021
by Aoife Moloney
Hi Everyone,
Below you will find a report of the work the Community Platform
Engineering (CPE) team was involved in over the last three months. If
you would like to view this in a 'toggle-able' view, I would suggest
you visit this hackmd link
https://hackmd.io/@Ap8CkTlpSfmjb44UGV-kWA/BJlrOsBpu
## Intro
The Community Platform Engineering team is a group of people who work
on infrastructure, release engineering, documentation, development and
just about anything else you can think of that supports both the
CentOS and Fedora projects.
In an effort to try work even more effectively and improve on our work
planning, we have been scheduling some of our work on a quarterly
basis for the last 15-18 months. And its been working pretty
well...once we got the hang of it :)
This in a nutshell, just means that there is work the CPE team *will
commit* to delivering every quarter that relates to both distros,
while also still providing support to the projects infrastructure that
come in as bugs, tickets, etc.
Quarter two 2021, or April, May and June to give them their government
names, has been a particularly good quarter for our team with a lot of
work getting completed. Below is a breakdown of what our team
delivered over the quarter per project.
A note, that is a given but should never go without saying - is that
the CPE team work in the Fedora and CentOS communities, and rely on
community member feedback and discussion while working. Without your
continued support and engagement with our team - be it when we are
announcing something available and need input on how it works or an
idea we have had and we want more discussion on a proposal before we
start developing - the work we deliver at the end of each quarter
would not be possible.
So on behalf of the CPE team, thank you for your involvement in our
quarterly work! This is as much your bragging rights as it is ours :)
## Fedora
### RPMautospec
This project was originally prototyped early last year and presented
at Nest with Fedora last August. It was a body of work that would
relieve packagers from the burden of manually updating the Release
field and %changelog section in RPM spec files.
Some of the highlights of this project that the team delivered was:
* Implemented a simplified release enumeration algorithm (from the
discussion on the devel list and with FESCo)
* Reflect flags to %autorelease in generated changelog entries
* `fedpkg local`, `fedpkg mockbuild` (possibly `fedpkg srpm`)
supports rpmautospec features, i.e. prepare the SRPM on the fly as
Koji would do it before building.
* Allows for uncommitted changes in local builds with fedpkg, i.e.
bump the release number by one and generate a boilerplate “-
uncommitted changes” RPM changelog entry.
* Up-to-date and more complete documentation :)
You can read more detailed information on this project from the repo
https://pagure.io/docs/fedora-infra/rpmautospec/ and from the fedora
mailing list https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
### Infrastructure & Release Engineering
* F34 was released! https://fedoramagazine.org/announcing-fedora-34/
* New Status Page released! https://www.fedorastatus.org/
* Fedora Accounts got new features in staging that will be deployed to
production soon:
* Noggin (upstream project name) now supports Matrix IDs as well
as IRC nicknames https://github.com/fedora-infra/noggin/pull/668
* Integrated the Spammish app into Noggin
https://github.com/fedora-infra/noggin/pull/672
* FPCA status displayed on Noggin’s user page
* https://fedoraloveskde.org site was deployed in staging and production
* A *lot* of builder fixing and module cleanup
* Behind-the-scenes work:
* updates to services and applications, eg Bodhi
* Upgraded machines to F34
* Fedocal now runnning on Openshift rather than VMs
* Mass update/reboot to systems
## CentOS
### CentOS Stream 9
* Development composes are available https://composes.stream.centos.org/
* Container Images are available
https://quay.io/repository/centos/centos?tag=stream9-development&tab=tags
* Quickstart Contribution Guide available
https://docs.centos.org/en-US/stream-contrib/quickstart/
* New SIG approved: Feature Request SIG for CentOS Stream
https://lists.centos.org/pipermail/centos-devel/2021-April/076716.html
* Centpkg development and release
* CentOS Stream 9 build system is publicly viewable
https://kojihub.stream.centos.org/koji/
* CentOS Stream 9 package sources are publicly available in GitLab
https://gitlab.com/redhat/centos-stream/rpms
### CentOS Stream 8
* CentOS Stream 8 repository pipeline upgraded to merge new composes
rather than replacing the previous content giving users the ability to
`dnf downgrade` packages easily. More info
https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
* Centos8-stream buildroot available for missing -devel pkgs
https://pagure.io/centos-infra/issue/316
### CentOS Linux
* CentOS Linux 8 had a new release derived from Red Hat Enterprise
Linux 8.4 Source Code! Read more here
https://lists.centos.org/pipermail/centos-devel/2021-June/077021.html
### Infrastructure & Release Engineering
* EPEL repositories (plain rpms, no module content) can be enabled on
demand on CBS for:
* epel 7 (x86_64, ppc64le, aarch64)
* epel 8 Everything (x86_64, ppc64le, aarch64)
* epel Next 8 Everything (x86_64, ppc64le, aarch64)
* Auth system switch completed in April bringing both CentOS and
Fedora backend system under one stack and allowing contributors to
both projects use one email for both projects! More info:
https://lists.centos.org/pipermail/centos-devel/2021-April/076694.html
* Deployed some instances for Artwork SIG to test centos visual theme
for www/blog/mirror/mailman https://pagure.io/centos-infra/issue/366
This report is really only a snapshot of the volume of work the people
on the Community Platform Engineering do, and also at a more high
level overview, but even still there are *a lot* of very noteworthy
successes in there that we are very proud of delivering this quarter,
and we hope the communities we are part of and serve find value in the
work we do too.
Have a lovely weekend everyone, and I will be back with our plans for
July, August and September with links to the projects work trackers
and their respective goals that we are going to shoot for in Q3 very
soon (like, next week) :)
Kindest regards,
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
2 years, 2 months
