Fedora 38 beta freeze now in effect
by Kevin Fenzi
Greetings.
We are now in the infrastructure freeze leading up to the Fedora 38
Beta release. This is a pre release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 38 Beta when it's available.
You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:
git clone
https://infrastructure.fedoraproject.org/infra/ansible.git
ansible/scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2023-03-14 (or later if
release slips). Frozen hosts should have no changes made to them without
a sign-off on the change from at least 2 sysadmin-main or rel-eng
members, along with (in most cases) a patch of the exact change to be
made to this list or a pull request for review.
Thanks,
Kevin
1 week
Take 1 minute to help with Infra & Releng Team with a decision
by Michal Konecny
Hi everyone,
it came to Infra & Releng Team (sub-team in CPE that is taking care of
Fedora Infra, Fedora Release Engineering and CentOS Infra) attention
that there is a confusion about the labels we are using for issues in
our trackers. Namely fedora-infrastructure, releng and centos-infra.
There was even a request to change them to something less confusing.
So we want to decide if this is really need to change, so we ask you to
take this quick survey [0] (this is an anonymous survey, nothing is
collected by us) to see if the change is really needed or people are
happy with current labels.
The survey will be closed on 7th March 2023.
On behalf of I&R Team,
Michal
[0] - https://forms.gle/J2HWDkw1UNuj8HYD8
2 weeks, 2 days
Freeze break request: forward openshift logs to log01
by Kevin Fenzi
I'm not really sure this needs a freeze break (we haven't really
established a formal policy about if our openshift cluster is frozen or
just some applications on it, or none of it) but I thought I would run
it by everyone just in case.
I'd like to setup log forwarding on our production cluster to log all
application level logs to log01. I've already done this for staging to
test everything out and it seems to be working fine.
Now of course this means a bunch more logs on log01, but on the other
hand, it means we can actually look back and see what happened when say
a update didn't process as we expected, but the bodhi web pod has been
restarted. ;)
Thoughts?
kevin
3 weeks
Freeze Broken by Accident: pagure02.fedoraproject.org
by Stephen John Smoogen
I ran `dnf update` on pagure02.fedoraproject.org thinking I was working on
a different system. The box has been updated to the latest packages. Once I
realized my mistake I reviewed the changes and did not see anything that I
felt would affect pagure's operation.
--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
3 weeks, 1 day
Freeze break request: moving /mnt/koji/compose/
by Kevin Fenzi
Greetings.
As some of you may know, our fedora_koji volume is hitting up against
some limits (namely the netapp 100TB per volume limit). If it hits 100TB
used, the netapp folks tell me it will go offline and we will need to do
special things to free up any space and get it working again.
Obviously, we wish to avoid that.
So, I think we can move /mnt/fedora_koji/koji/compose with minimal
disruption and give us a bunch of room and actually make things faster.
Here's my tenative plan:
* create ~15-20TB volume on one of our ssd aggregates.
* rsync all of /mnt/fedora_koji/koji/compose/ to it.
* Schedule a changeover time/date.
* Make sure no composes or updates pushes are running.
(This should be possible after branched/rawhide, but before updates
and before we are making rc's)
* Do another sync of content so the new copy is up to date.
(I am not sure how long a rsync will take, but we can figure it out)
* move the old directory to compose.old
* mount the new space on koji01/02, kojipkgs01/02, all compose channel
builders, compose-x86-01. Nothing else should need it.
* Wait a short while
* delete compose.old
This should free up about 13TB or so on the main volume, reduce snapshot
churn on it, make composes faster because they will be on ssd instead of
sas drives, and all around be nicer.
I think this can be done during some day without really causing much
outage. Because the koji space is so tight I would like to do it soon,
and I think it best to do it before we are too close to release.
So, later this week or early next week?
Thoughts? +1s? alternative ideas?
kevin
3 weeks, 3 days
Pyramid 2.0 update proposal for F38
by Mattia Verga
As you may have read in the announcement on the devel mailing list, I've
started a change proposal about bumping Pyramid to version 2.0 for F38.
I cross-announce here because Pyramid and its dependencies are mostly
maintained by infra-sig and I don't want to bypass main-admins, but I
think it's time to move forward (and I have some projects about using
pyramid-openapi3 to provide REST APIs in Bodhi which will need Pyramid 2).
I intend to upgrade Pyramid and rebuild dependent packages also updating
spec files to latest packaging guidelines and possibly upgrade packages
to the latest versions. The list of packages is:
* python-pyramid - Maintained by kevin / infra-sig
* bodhi-server - Maintained by humaton
* python-cornice - Maintained by hguemar / python-packagers-sig
* python-pyramid-fas-openid - Maintained by abompard / infra-sig
* python-pyramid-mako - Maintained by kevin / infra-sig
* python-pyramid-tm - Maintained by kevin / infra-sig
* python-pyramid_sawing - Maintained by abompard
The dependent packages rebuild is not really needed, but it will ensure
that the tests will not fail with Pyramid 2.0. In fact,
python-pyramid-mako is the only one which needs an upgrade to be
compatible with Pyramid 2.0.
I have set up a COPR repository to test the upgrade:
https://copr.fedorainfracloud.org/coprs/mattia/Pyramid2/
Let me know if there's any objection to the proposal.
Mattia
3 weeks, 3 days
Freeze Break: re-enable bodhi automated pushes
by Kevin Fenzi
Greetings.
I'd like to ask for +1s from sysadmin-main/releng for:
https://pagure.io/fedora-infra/ansible/pull-request/1329
basically this just re-enables the daily automated pushing that bodhi
normally does. We used to disable this during freezes because we didn't
want it to push the frozen releases stable updates too, but now bodhi
has a way to mark releases as 'frozen' and this automated push will just
not push any stable updates for it automatically.
I did test and started a compose (and then said no to run it) that it
correctly didn't show any f38 stable updates in the mix.
+1s?
kevin
4 weeks
Re: Meeting Agenda Item: Introduction Zahid
by Kevin Fenzi
On Tue, Feb 21, 2023 at 06:17:26PM +0000, Zee Ban wrote:
> Hello,
>
> irc handle: zeeb180
>
> I don't have much experience, as I've only been using Linux for the past month or so and would like to further better my skills. This is my first time working in an open-source community so this is all new to me.
>
> I'm currently looking to gain experience working with servers/system administration, and hopefully have a mentor guide me.
>
> Any help would be much appreciated.
Welcome!
Do take a look at
https://fedoraproject.org/wiki/Infrastructure/GettingStarted if you
haven't had a chance to already.
I hope you can make our next meeting (thursdays at 18UTC in
#fedora-meeting-3)
Or drop by our admin channel (#fedora-admin).
kevin
4 weeks
Meeting Agenda Item: Introduction Zahid
by Zee Ban
Hello,
irc handle: zeeb180
I don't have much experience, as I've only been using Linux for the past month or so and would like to further better my skills. This is my first time working in an open-source community so this is all new to me.
I'm currently looking to gain experience working with servers/system administration, and hopefully have a mentor guide me.
Any help would be much appreciated.
4 weeks, 1 day
