Support levels and RFR adjustments
by Kevin Fenzi
So, I sent an email a while back about this to get people thinking, but
I didn't get too much feedback from my questions, so this time I am
going to actually outline a proposal for people to look at. ;)
Currently users expect pretty much any public service we have is fully
supported. This means things like updating status when it's down,
working anytime something is down to fix it as quickly as we can.
New applications/services currently all pass through the (somewhat
long) RFR process which we setup to make sure we could support the
service moving forward.
This is great and all, but some services just aren't as sustainable, or
don't really fit into our RFR process very well. Also, our RFR process
makes us pretty slow to bring a new service online properly.
In order to have support levels, we need a way to communicate that to
our users easily and the only/best way I can think of to do that easily
is via domain name. If we try and have a table or something it could
get pretty confusing for people. Tying it to domain names would make it
much easier.
So:
fedoraproject.org - Anything with this domain is something that has
passed though our RFR process and we support fully. This means we
update status, we alert on them anytime they have issues, we work on
them anytime they are down, etc.
fedorainfracloud.org - This comes with a lesser level of support,
simply because our cloud doesn't have any kind of HA setup, so
it will be down when doing maint or when there's problems. Services in
this domain may be down when there is scheduled cloud maint. We
monitor, but don't page off hours, we may work on issues only during
business hours, etc. Services here may not have passed through our RFR
process (perhaps we should have a parallel cloud process)
stg.fedoraproject.org - These can be down anytime and we monitor on
them, but may not work on them off hours, etc.
someother domain that sounds fedora related (fedorarelated.org?
fedoralinks.org? ?) - These are things that are fedora related, but not
fully controlled by fedora infrastructure. Things like the fedora
bootstrap site or the porting python3 in fedora site, or possibly cloud
instances that aren't managed by us. These we don't monitor or have
status on, and direct people to contact the managers directly.
Any other types of sites / domains people can think of?
Any general thoughts on the idea?
kevin
7 years, 5 months
[release] mdapi: 2.4
by Pierre-Yves Chibon
Good Morning Everyone,
I just released a new version of mdapi: 2.4
Here is the corresponding changelog:
* Mon Feb 29 2016 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 2.4-1
- Update to 2.4
- Adjust copyright year
- Expand mdapi to return dependencies information (conflicts, enhances,
recommends, suggests, supplements, requires, provides and obsoletes)
- Improve the cron script to retry after 30 seconds waiting, 3 times max if it
fails to get info for a repo
Happy querying,
Pierre
7 years, 7 months
[release] the-new-hotness: 0.7.0
by Ralph Bean
This release swaps out usage of 'rpmdev-bumpspec' for the new 'rebase-helper'.
Credit due to Petr Hracek.
0.7.0
-----
Pull Requests
- (@ralphbean) #90, Allow mappings for npmjs.com as well as npmjs.org.
https://github.com/fedora-infra/the-new-hotness/pull/90
- (@ralphbean) #92, Remove bundled (and outdated) openid client code.
https://github.com/fedora-infra/the-new-hotness/pull/92
- (@ralphbean) #96, Rewrite topics to handle development mode.
https://github.com/fedora-infra/the-new-hotness/pull/96
- (@phracek) #94, Rebase helper integration.
https://github.com/fedora-infra/the-new-hotness/pull/94
- (@ralphbean) #101, Remove pkg_manager detection.
https://github.com/fedora-infra/the-new-hotness/pull/101
- (@ralphbean) #103, Make this log statement less verbose.
https://github.com/fedora-infra/the-new-hotness/pull/103
Commits
- f3b595f65 Support YUM and DNF
https://github.com/fedora-infra/the-new-hotness/commit/f3b595f65
- b5dbf963c Specbump.
https://github.com/fedora-infra/the-new-hotness/commit/b5dbf963c
- 6a582b6e2 Fix YUM and DNF usage.
https://github.com/fedora-infra/the-new-hotness/commit/6a582b6e2
- 776c7e1e4 Merge remote-tracking branch 'upstream/develop' into develop
https://github.com/fedora-infra/the-new-hotness/commit/776c7e1e4
- c075434e7 Allow mappings for npmjs.com as well as npmjs.org.
https://github.com/fedora-infra/the-new-hotness/commit/c075434e7
- 2692cdaf0 Remove bundled (and outdated) openid client code.
https://github.com/fedora-infra/the-new-hotness/commit/2692cdaf0
- e4133a36f Fix some usage of OpenIdBaseClient where we need more flexibility.
https://github.com/fedora-infra/the-new-hotness/commit/e4133a36f
- 065a7bc46 Typofix.
https://github.com/fedora-infra/the-new-hotness/commit/065a7bc46
- 4cfa9c93e Add some nice warnings for debugging.
https://github.com/fedora-infra/the-new-hotness/commit/4cfa9c93e
- b89e56625 Rebase-helper integration
https://github.com/fedora-infra/the-new-hotness/commit/b89e56625
- 763ee55c2 Iterate over build_logs
https://github.com/fedora-infra/the-new-hotness/commit/763ee55c2
- 656b62373 Return back trigger.
https://github.com/fedora-infra/the-new-hotness/commit/656b62373
- 326758e87 Return reference as not list. In case of failure return logs
https://github.com/fedora-infra/the-new-hotness/commit/326758e87
- d3805d300 Rewrite topics to handle development mode.
https://github.com/fedora-infra/the-new-hotness/commit/d3805d300
- 311eb4e96 (,,Ő x Ő,,)
https://github.com/fedora-infra/the-new-hotness/commit/311eb4e96
- b39f1b102 rebase-helper split
https://github.com/fedora-infra/the-new-hotness/commit/b39f1b102
- 8f182e912 rebase-helper split
https://github.com/fedora-infra/the-new-hotness/commit/8f182e912
- 71f41582e Merge branch 'rebase-helper' of github.com:phracek/the-new-hotness into rebase-helper
https://github.com/fedora-infra/the-new-hotness/commit/71f41582e
- 8f374fc95 rebase-helper returns logs and packages after finishing scratch build.
https://github.com/fedora-infra/the-new-hotness/commit/8f374fc95
- 64d34e815 Final commit with rebase-helper implementation
https://github.com/fedora-infra/the-new-hotness/commit/64d34e815
- a48c0daf4 Move this outside the try/except block.
https://github.com/fedora-infra/the-new-hotness/commit/a48c0daf4
- 4ce84bdfc Update config for namespaced pkgs.
https://github.com/fedora-infra/the-new-hotness/commit/4ce84bdfc
- 77886e530 Remove pkg_manager detection.
https://github.com/fedora-infra/the-new-hotness/commit/77886e530
- ee7f33504 Not https here.
https://github.com/fedora-infra/the-new-hotness/commit/ee7f33504
- 75e90b743 Make this log statement less verbose.
https://github.com/fedora-infra/the-new-hotness/commit/75e90b743
- dbe3d62e5 Promote this log statement to an exception.
https://github.com/fedora-infra/the-new-hotness/commit/dbe3d62e5
- 218049a7f New version requires rebase-helper
https://github.com/fedora-infra/the-new-hotness/commit/218049a7f
7 years, 7 months
Fwd: Fwd: Re: Very late Koji certificate expiration warnings
by Corey Sheldon
-------- Forwarded Message --------
Delivered-To: sheldon.corey(a)gmail.com
Received: by 10.25.1.212 with SMTP id 203csp981473lfb; Mon, 29 Feb 2016
01:39:32 -0800 (PST)
X-Received: by 10.37.231.70 with SMTP id
e67mr8421643ybh.57.1456738772077; Mon, 29 Feb 2016 01:39:32 -0800 (PST)
Return-Path: <infrastructure-bounces(a)lists.fedoraproject.org>
Received: from bastion.fedoraproject.org (bastion01.fedoraproject.org.
[209.132.181.2]) by mx.google.com with ESMTP id
l190si7997053ywg.52.2016.02.29.01.39.31 for <sheldon.corey(a)gmail.com>;
Mon, 29 Feb 2016 01:39:32 -0800 (PST)
Received-SPF: pass (google.com: domain of
infrastructure-bounces(a)lists.fedoraproject.org designates 209.132.181.2
as permitted sender) client-ip=209.132.181.2;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of
infrastructure-bounces(a)lists.fedoraproject.org designates 209.132.181.2
as permitted sender)
smtp.mailfrom=infrastructure-bounces(a)lists.fedoraproject.org
Received: from mailman01.phx2.fedoraproject.org
(mailman01.phx2.fedoraproject.org [10.5.126.36]) by
bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id 81E0160C9833
for <sheldon.corey(a)gmail.com>; Mon, 29 Feb 2016 09:39:31 +0000 (UTC)
Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id
7E685245DC26D for <sheldon.corey(a)gmail.com>; Mon, 29 Feb 2016 09:39:31
+0000 (UTC)
Subject: Fwd: Re: Very late Koji certificate expiration warnings
From: infrastructure-owner(a)lists.fedoraproject.org
To: sheldon.corey(a)gmail.com
List-Administrivia: poster
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="===============2375863589195699255=="
Message-ID: <20160229093930.26287.49947(a)mailman01.phx2.fedoraproject.org>
Date: Mon, 29 Feb 2016 09:39:30 +0000
List-Id: Fedora Infrastructure <infrastructure.lists.fedoraproject.org>
Precedence: bulk
X-Mailman-Version: 3.1.0
Your message to the infrastructure mailing-list was rejected for the following
reasons:
The message is not from a list member
The original message as received by Mailman is attached.
7 years, 7 months
Fwd: Fwd: Re: Very late Koji certificate expiration warnings
by Corey Sheldon
-------- Forwarded Message --------
Delivered-To: sheldon.corey(a)gmail.com
Received: by 10.25.1.212 with SMTP id 203csp981473lfb; Mon, 29 Feb 2016
01:39:32 -0800 (PST)
X-Received: by 10.37.231.70 with SMTP id
e67mr8421643ybh.57.1456738772077; Mon, 29 Feb 2016 01:39:32 -0800 (PST)
Return-Path: <infrastructure-bounces(a)lists.fedoraproject.org>
Received: from bastion.fedoraproject.org (bastion01.fedoraproject.org.
[209.132.181.2]) by mx.google.com with ESMTP id
l190si7997053ywg.52.2016.02.29.01.39.31 for <sheldon.corey(a)gmail.com>;
Mon, 29 Feb 2016 01:39:32 -0800 (PST)
Received-SPF: pass (google.com: domain of
infrastructure-bounces(a)lists.fedoraproject.org designates 209.132.181.2
as permitted sender) client-ip=209.132.181.2;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of
infrastructure-bounces(a)lists.fedoraproject.org designates 209.132.181.2
as permitted sender)
smtp.mailfrom=infrastructure-bounces(a)lists.fedoraproject.org
Received: from mailman01.phx2.fedoraproject.org
(mailman01.phx2.fedoraproject.org [10.5.126.36]) by
bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id 81E0160C9833
for <sheldon.corey(a)gmail.com>; Mon, 29 Feb 2016 09:39:31 +0000 (UTC)
Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id
7E685245DC26D for <sheldon.corey(a)gmail.com>; Mon, 29 Feb 2016 09:39:31
+0000 (UTC)
Subject: Fwd: Re: Very late Koji certificate expiration warnings
From: infrastructure-owner(a)lists.fedoraproject.org
To: sheldon.corey(a)gmail.com
List-Administrivia: poster
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="===============2375863589195699255=="
Message-ID: <20160229093930.26287.49947(a)mailman01.phx2.fedoraproject.org>
Date: Mon, 29 Feb 2016 09:39:30 +0000
List-Id: Fedora Infrastructure <infrastructure.lists.fedoraproject.org>
Precedence: bulk
X-Mailman-Version: 3.1.0
Your message to the infrastructure mailing-list was rejected for the following
reasons:
The message is not from a list member
The original message as received by Mailman is attached.
7 years, 7 months
non free builders
by Kevin Fenzi
Greetings.
So, we pride ourselves on having a 100% free and open infrastructure
software wise. However, we have had some exceptions (the autocloud vbox
test machine, etc).
For f24, the plan is to make workstation downloads at least prefer to
download a usb media creator, and then that downloads the images,
verifies them and writes them to usb in a sane/best manner.
Producing the Fedora/linux version of this is no problem, it's just a
package.
However, windows and osx are a different matter.
For windows, we could run a windows vm and attach it to koji (it
supports windows builders I think). This would of course mean that we
would need to run a windows builder vm. ;( Or we could have a isolated
hw instance that we only power on for windows builds.
For osx, I don't think you can virtualize it at all, and koji has no
support, so we would need to have an isolated osx instance available
for building the osx media creator. (possibly only running on demand).
We could of course just say: sorry, no non free oses in our
infrastructure, but I fear this will result in builds done ad-hock on
someones test machine that aren't reproducible or all the other things
we expect from products we release. ;(
Mostly this is just a heads up, but if anyone has ideas, feel free to
bring them up. ;)
kevin
7 years, 7 months
Plan for tomorrow's Fedora Infrastructure meeting - 2016-02-25
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2016-02-25 at 18:00 UTC in #fedora-meeting on the freenode network.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
kevin
--
= Introduction =
This shared document is for the next fedora infrastructure meeting.
We will use it over the week before the meeting to gather status and info and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2016-02-25)
#meetingname infrastructure
#topic aloha
#chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch threebean pingou puiterwijk pbrobinson
#topic New folks introductions / Apprentice feedback
Can apprentice work on Ticket #5126 ? - aldapetr
= Status / information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need to discuss)
(Please use #info <the thing> - your name)
#topic announcements and information
#info builders almost all re-installed - kevin
#info aarch64 cartridges almost ready for service - kevin
#info mass branching happened tuesday for f24 - pingou / dgilmore
#info kojij database / iscsi woes - kevin/patrick/smooge
#info rawhide/branched composers reinstalled as f23 - kevin
#info
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus or decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
#topic
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or setup
that we have. Just going over what it is, how to contribute, ideas for improvement,
etc. Whoever would like to do this, just add the info in this section. In the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
Schedule:
2016-02-25 - RFR - patrick
2016-03-03 - ???
#topic Learn about:
= Meeting end stuff =
#topic Open Floor
#endmeeting
7 years, 7 months
koji db issues (2016-02-23 and 24)
by Kevin Fenzi
I thought I would send out a note on what we know so far, and status on
koji db.
Last night the vm that runs koji's database went unresponsive.
Rebooting it made it come up in a very degraded state where it couldn't
find some of it's disks and never fully started. An additional reboot
brought it back up, but as soon as it started serving database requests
it went into a state where it was waiting for i/o and not processing.
We rebooted the virthost that runs that vm a number of times as well as
engaged networking and storage folks to look at those things.
In working on this issue we:
* ran a database vacuum on the koji db.
* fixed a misconfiguration in our multipathd config.
* fixed a configuration issue on a related virthost that made it's vm's
unable to connect to the storage network.
Finally things seemed to settle down early this morning and we were
able to bring the database back online. Later in the morning there was
another short period of heavy i/o wait, but it recovered without
intervention on our part.
The root cause seems to be the iscsi netapp volume that the instance
was defined on had some connectivity or loading issues and wasn't able
to handle the load for the vm. We have storage folks looking for issues
on the netapp side of things and we are closely watching the server
end.
Hopefully we are all back on track now.
kevin
7 years, 7 months
[release] pagure: 1.1.1
by Pierre-Yves Chibon
Good Morning everyone,
I just cut a new (bugfix) release of pagure: 1.1.1
Here is the corresponding changelog:
* Wed Feb 24 2016 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 1.1.1-1
- Update to 1.1.1
- Fix showing some files where decoding to UTF-8 was failing
- Avoid adding a notification to a PR for nothing
- Show notifications correctly on the PR page when received via SSE
The UTF-8 fix should reduce the number of emails I was getting about this error,
the other are more fixing inconvenience.
This is currently happily running in stg and prod.
Happy hacking!
Pierre
7 years, 7 months
FAS3
by Ryan Lerch
HI all!
Just wondering if there has been any recent work on the new FAS lately. I am interested in jumping in and helping out from a UX perspective.
cheers,
ryanlerch
7 years, 7 months