Re: Freeze Break Request: Increase mailman to 8 CPU
On Thu, Sep 1, 2022 at 8:16 PM Stephen Smoogen wrote: > > > I am trying to deal with some crashing issues with the mailman. It is > currently at 100% CPU usage with 4 cpus and about 12-16 waiting services at > all times. I would like to increase the number of CPUs to 8. There does not > look to be memory problems at this time so no increase is needed there. > > Actions: > update ansible > update vm system via virsh > reboot vm +1 > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. -- > Ian MacClaren > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Freeze break request: kernel builders
On Thu, Sep 1, 2022 at 8:55 PM Kevin Fenzi wrote: > > So, last week I managed to break bkernel01 kernel builder (and we have > been using just 02 since then). There were 2 issues: > > 1. I switched rawhide to use systemd-nspawn for isolation instead of > chroot and this broke kernel builds due to ( > https://github.com/rpm-software-management/mock/issues/140 ) > > 2. pesign in f36 had some issues with unlocking the smart cards. > ( https://bugzilla.redhat.com/show_bug.cgi?id=2122777 ) > > The pesign maintainers fixed issue 2 this morning and I tested the > workaround I have for issue 1 in mock on bkernel01. > > So, what I would like to do now is: > > * upgrade bkernel02 to the same pesign version as on 01 along with > moving it to f36 (like 01 is). > * Push a commit in ansible to adjust mock config for the workaround for > issue 1 above. > > +1s or further questions? +1 > > kevin > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FBR: run batcave playbook for rbac
+1 On Tue, Sep 21, 2021 at 4:10 PM Mark O'Brien wrote: > > Hi All, > > I am requesting permissions to run the batcave > playbook to update rbac permissions to allow the > sysadmin-analysis group run the logserver playbook > as requested in this ticket: > > https://pagure.io/fedora-infrastructure/issue/10231 > > As always comments/+1's welcome > > Thanks, > Mark > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The packages app has a short runway
On Fri, Oct 25, 2019 at 8:43 PM Randy Barlow wrote: > OK. Given our extreme time constraints, I think it is likely that we > will have to retire the Packages app. > > However, there is one feature in it that I personally believe does map > to the CPE team's mission statement: the table of which versions of a > package are in which versions of Fedora/EPEL. I am planning to deploy Package Version Matrix in communishift [1]. Example how it can look like: [2] [1] https://pagure.io/fedora-infrastructure/issue/8314 [2] https://koji.kjnet.xyz/kojifiles/versions/ -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Update releases.json to make f31 active and no retirement
+1
On Thu, Oct 24, 2019 at 10:53 PM Mohan Boddu wrote:
>
> Hi,
>
> Another FBR to update releases.json to make sure retirement is not allowed
>
> diff --git a/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json
> b/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections
> index aac977e..9e0cbf2 100644
> --- a/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json
> +++ b/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json
> @@ -12,14 +12,14 @@
>"version": "devel"
> },
> {
> - "allow_retire": true,
> + "allow_retire": false,
>"branchname": "f31",
>"date_created": "2014-05-14 12:36:15",
>"date_updated": "2018-08-14 17:07:23",
>"dist_tag": ".fc31",
>"koji_name": "f31",
>"name": "Fedora",
> - "status": "Under Development",
> + "status": "Active",
>"version": "31"
> },
> {
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: F31 Final is GO, bodhi config changes
+1 On Thu, Oct 24, 2019 at 8:35 PM Mohan Boddu wrote: > > Also, one more simple FBR, > > Disabling branched compose > > diff --git a/roles/releng/files/branched b/roles/releng/files/branched > index 966f5c3..1f52f56 100644 > --- a/roles/releng/files/branched > +++ b/roles/releng/files/branched > @@ -1,3 +1,3 @@ > # branched compose > MAILTO=releng-c...@lists.fedoraproject.org > -15 7 * * * root TMPDIR=`mktemp -d /tmp/branched.XX` && cd $TMPDIR > && git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && > git checkout f31 && /usr/local/bin/lock-wrapper branched-compose > "PYTHONMALLOC=debug LANG=en_US.UTF-8 ./nightly.sh" && sudo -u ftpsync > /usr/local/bin/update-fullfiletimelist -l > /pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora > fedora-secondary > +#15 7 * * * root TMPDIR=`mktemp -d /tmp/branched.XX` && cd > $TMPDIR && git clone https://pagure.io/pungi-fedora.git && cd > pungi-fedora && git checkout f31 && /usr/local/bin/lock-wrapper > branched-compose "PYTHONMALLOC=debug LANG=en_US.UTF-8 ./nightly.sh" && > sudo -u ftpsync /usr/local/bin/update-fullfiletimelist -l > /pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora > fedora-secondary > > I am currently running a branched compose, so that the RC and branched > compose will have the same content. > > Once the run is done, I will push all these changes and then either > run full updates push or let the automated pushes take care of it > based on the timing. > > I cannot run f31 stable updates push yet, since it might screw up the > silverblue refs if branched is completed after the f31 stable updates > push. > > Thanks. > > On Thu, Oct 24, 2019 at 2:27 PM Mikolaj Izdebski wrote: > > > > +1 > > > > On Thu, Oct 24, 2019 at 7:51 PM Mohan Boddu wrote: > > > > > > Hi, > > > > > > Now that F31 is GO, I would like the make the necessary changes to > > > bodhi configs. > > > > > > "vars/all/Frozen.yaml" 1L, 15C written > > > [mohanboddu@batcave01 ansible][PROD]$ git diff > > > diff --git a/vars/all/00-FedoraCycleNumber.yaml > > > b/vars/all/00-FedoraCycleNumber.yaml > > > index 22476b0..4bd0d46 100644 > > > --- a/vars/all/00-FedoraCycleNumber.yaml > > > +++ b/vars/all/00-FedoraCycleNumber.yaml > > > @@ -1 +1 @@ > > > -FedoraCycleNumber: 30 > > > +FedoraCycleNumber: 31 > > > diff --git a/vars/all/FedoraBranched.yaml b/vars/all/FedoraBranched.yaml > > > index 42ac534..0bbcc1d 100644 > > > --- a/vars/all/FedoraBranched.yaml > > > +++ b/vars/all/FedoraBranched.yaml > > > @@ -1 +1 @@ > > > -FedoraBranched: True > > > +FedoraBranched: False > > > diff --git a/vars/all/FedoraBranchedBodhi.yaml > > > b/vars/all/FedoraBranchedBodhi.yaml > > > index 380f61d..76ba14d 100644 > > > --- a/vars/all/FedoraBranchedBodhi.yaml > > > +++ b/vars/all/FedoraBranchedBodhi.yaml > > > @@ -1,2 +1,2 @@ > > > #options are: prebeta, postbeta, current > > > -FedoraBranchedBodhi: postbeta > > > +FedoraBranchedBodhi: current > > > diff --git a/vars/all/FedoraPreviousPrevious.yaml > > > b/vars/all/FedoraPreviousPrevious.yaml > > > index a8e3d3b..a061e04 100644 > > > --- a/vars/all/FedoraPreviousPrevious.yaml > > > +++ b/vars/all/FedoraPreviousPrevious.yaml > > > @@ -1 +1 @@ > > > -FedoraPreviousPrevious: False > > > +FedoraPreviousPrevious: True > > > diff --git a/vars/all/Frozen.yaml b/vars/all/Frozen.yaml > > > index 97d3bc3..7578a88 100644 > > > --- a/vars/all/Frozen.yaml > > > +++ b/vars/all/Frozen.yaml > > > @@ -1 +1 @@ > > > -Frozen: True > > > +Frozen: False > > > diff --git a/vars/all/RelEngFrozen.yaml b/vars/all/RelEngFrozen.yaml > > > index bd7553f..72af779 100644 > > > --- a/vars/all/RelEngFrozen.yaml > > > +++ b/vars/all/RelEngFrozen.yaml > > > @@ -1 +1 @@ > > > -RelEngFrozen: True > > > +RelEngFrozen: False > > > > > > Thanks. > > > ___ > > > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > > > To unsubscribe send an email to > > > infrastructure-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wik
Re: FBR: F31 Final is GO, bodhi config changes
+1 On Thu, Oct 24, 2019 at 7:51 PM Mohan Boddu wrote: > > Hi, > > Now that F31 is GO, I would like the make the necessary changes to > bodhi configs. > > "vars/all/Frozen.yaml" 1L, 15C written > [mohanboddu@batcave01 ansible][PROD]$ git diff > diff --git a/vars/all/00-FedoraCycleNumber.yaml > b/vars/all/00-FedoraCycleNumber.yaml > index 22476b0..4bd0d46 100644 > --- a/vars/all/00-FedoraCycleNumber.yaml > +++ b/vars/all/00-FedoraCycleNumber.yaml > @@ -1 +1 @@ > -FedoraCycleNumber: 30 > +FedoraCycleNumber: 31 > diff --git a/vars/all/FedoraBranched.yaml b/vars/all/FedoraBranched.yaml > index 42ac534..0bbcc1d 100644 > --- a/vars/all/FedoraBranched.yaml > +++ b/vars/all/FedoraBranched.yaml > @@ -1 +1 @@ > -FedoraBranched: True > +FedoraBranched: False > diff --git a/vars/all/FedoraBranchedBodhi.yaml > b/vars/all/FedoraBranchedBodhi.yaml > index 380f61d..76ba14d 100644 > --- a/vars/all/FedoraBranchedBodhi.yaml > +++ b/vars/all/FedoraBranchedBodhi.yaml > @@ -1,2 +1,2 @@ > #options are: prebeta, postbeta, current > -FedoraBranchedBodhi: postbeta > +FedoraBranchedBodhi: current > diff --git a/vars/all/FedoraPreviousPrevious.yaml > b/vars/all/FedoraPreviousPrevious.yaml > index a8e3d3b..a061e04 100644 > --- a/vars/all/FedoraPreviousPrevious.yaml > +++ b/vars/all/FedoraPreviousPrevious.yaml > @@ -1 +1 @@ > -FedoraPreviousPrevious: False > +FedoraPreviousPrevious: True > diff --git a/vars/all/Frozen.yaml b/vars/all/Frozen.yaml > index 97d3bc3..7578a88 100644 > --- a/vars/all/Frozen.yaml > +++ b/vars/all/Frozen.yaml > @@ -1 +1 @@ > -Frozen: True > +Frozen: False > diff --git a/vars/all/RelEngFrozen.yaml b/vars/all/RelEngFrozen.yaml > index bd7553f..72af779 100644 > --- a/vars/all/RelEngFrozen.yaml > +++ b/vars/all/RelEngFrozen.yaml > @@ -1 +1 @@ > -RelEngFrozen: True > +RelEngFrozen: False > > Thanks. > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
FBR: Update koji-sidetag-plugin on Koji hub
In order to fix issue 8322 [1] python2-koji-sidetag-plugin-hub needs to be updated. This would be done with the following commands: $ koji move epel7-infra-stg epel7-infra koji-sidetag-plugin-0.1-2.el7.infra [root@batcave01]# ansible koji -m package -a 'name=python2-koji-sidetag-plugin-hub state=latest update_cache=yes update_only=yes' [root@batcave01]# ansible koji -m service -a 'name=httpd state=reloaded' [1] https://pagure.io/fedora-infrastructure/issue/8322 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
[FBR] bastion: Add sysadmin-odcs to fas_client_groups
--- inventory/group_vars/bastion | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inventory/group_vars/bastion b/inventory/group_vars/bastion index aeacc87e4..8e63d1a11 100644 --- a/inventory/group_vars/bastion +++ b/inventory/group_vars/bastion @@ -23,7 +23,7 @@ custom_rules: [ # TODO - remove modularity-wg membership here once it is not longer needed: # https://fedorahosted.org/fedora-infrastructure/ticket/5363 -fas_client_groups: sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs +fas_client_groups: sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs,sysadmin-odcs # # This is a postfix gateway. This will pick up gateway postfix config in base -- 2.21.0 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: update python-tag2distrepo on bodhi-backend02
Thanks, but I don't have time to apply the change any longer. I am about to leave for vacation [1] and I don't want to change a frozen system on a Friday night just before taking a week-long vacation. Either someone else will need to apply the change, or you can wait for me to come back - by then the freeze will be lifted, making the FBR unneeded. [1] https://apps.fedoraproject.org/calendar/vacation/2019/4/29/#m9520 -- Mikolaj On Fri, Apr 26, 2019 at 1:43 PM Stephen John Smoogen wrote: > > > Thanks for the bump. I missed that this had not been reviewed. > Mizdebsk +1 > > On Thu, 25 Apr 2019 at 23:51, Dusty Mabe wrote: >> >> bump - can we get some votes on this? I would vote but my vote doesn't count >> :) >> >> On 4/16/19 5:10 PM, Mikolaj Izdebski wrote: >> > Problem: tag2distrepo fails to generate dist-repo for CoreOS >> > continuous builds [1] bacause CoreOS tags contain unsigned packages >> > and tag2distrepo can't handle them. >> > >> > Fix: to fix the problem I would like to install >> > python-tag2distrepo-1-0.10.fc29 [2] on >> > bodhi-backend02.phx2.fedoraproject.org and restart >> > fedmsg-hub-3.service. The build backports upstream patch [3] >> > >> > $ koji move f29-infra-stg f29-infra python-tag2distrepo-1-0.10.fc29 >> > # dnf --refresh update python3-tag2distrepo >> > # systemctl restart fedmsg-hub-3 >> > >> > [1] https://pagure.io/releng/issue/8165 >> > [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1251150 >> > [3] https://pagure.io/releng/tag2distrepo/pull-request/3 >> > ___ >> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org >> > To unsubscribe send an email to >> > infrastructure-le...@lists.fedoraproject.org >> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> > List Archives: >> > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org >> > >> ___ >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org >> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > > > > -- > Stephen J Smoogen. > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
FBR: update python-tag2distrepo on bodhi-backend02
Problem: tag2distrepo fails to generate dist-repo for CoreOS continuous builds [1] bacause CoreOS tags contain unsigned packages and tag2distrepo can't handle them. Fix: to fix the problem I would like to install python-tag2distrepo-1-0.10.fc29 [2] on bodhi-backend02.phx2.fedoraproject.org and restart fedmsg-hub-3.service. The build backports upstream patch [3] $ koji move f29-infra-stg f29-infra python-tag2distrepo-1-0.10.fc29 # dnf --refresh update python3-tag2distrepo # systemctl restart fedmsg-hub-3 [1] https://pagure.io/releng/issue/8165 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1251150 [3] https://pagure.io/releng/tag2distrepo/pull-request/3 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [PATCH] tag2distrepo: also regen f*-coreos-continuous repos
I've applied the patch and deployed it.
Dist repos failed to generate due to missing signatures, but I'll try
to fix that.
On Thu, Apr 11, 2019 at 9:05 PM Jonathan Lebon wrote:
>
> We want to be able to get automatically regenerated yum repos whenever
> we build into the continuous tags. This will be used by the Fedora
> CoreOS team for building and testing.
>
> See https://pagure.io/releng/issue/8165 for more details.
> ---
> roles/bodhi2/backend/templates/tag2distrepo.py.j2 | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/roles/bodhi2/backend/templates/tag2distrepo.py.j2
> b/roles/bodhi2/backend/templates/tag2distrepo.py.j2
> index 943e543b9..1a845d089 100644
> --- a/roles/bodhi2/backend/templates/tag2distrepo.py.j2
> +++ b/roles/bodhi2/backend/templates/tag2distrepo.py.j2
> @@ -24,6 +24,8 @@ config = {
> 'epel6-infra-stg': ['47dd8ef9'],
> 'epel7-infra': ['47dd8ef9'],
> 'epel7-infra-stg': ['47dd8ef9'],
> +'f29-coreos-continuous': [],
> +'f30-coreos-continuous': [],
> }
> }
> }
> --
> 2.20.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: modules/ruby - private-jaruga-master branch wrongly released on f30.
Hi Jun, On Thu, Apr 11, 2019 at 6:09 PM Jun Aruga wrote: > ruby:private-jaruga-master is included in Fedora repos > https://bugzilla.redhat.com/show_bug.cgi?id=1698958 > > Can you help to remove my name's private-jaruga-master branch from > Fedora repositories? Fedora release process is managed by release engineering team. You should open a releng ticket [1] and ask them to untag the module: "koji untag f30-modular ruby-private_jaruga_master-20180925112246.a5b0195c" > Also can you remove "private-jaruga-master" and f26, f28, f29 branch > from below repository? > https://src.fedoraproject.org/modules/ruby/branches > I am a main admin of the modules/ruby repository, but I do not have > the permission to do it. Sorry, but no. We don't remove dist-git branches by policy. Especially branches from which builds done. -- Mikolaj Izdebski [1] https://pagure.io/releng ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Unfreeze RelEng to push updates
+1 On Thu, Mar 28, 2019 at 10:51 PM Mohan Boddu wrote: > > Hello, > > I dont know if this FBR is needed or not, but now that we have a GOLD compose > for F30 Beta and all the requested f30 builds pushed stable and I cloned > f30-Beta tag from f30, now we can start pushing updates to F30 stable as well > along with the others. > > +1's please > > diff --git a/vars/all/RelEngFrozen.yaml b/vars/all/RelEngFrozen.yaml > index bd7553f..72af779 100644 > --- a/vars/all/RelEngFrozen.yaml > +++ b/vars/all/RelEngFrozen.yaml > @@ -1 +1 @@ > -RelEngFrozen: True > +RelEngFrozen: False > > Thanks. > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Need someone to run Thursday meeting
On Wed, Mar 27, 2019 at 7:10 PM Kevin Fenzi wrote: > > On 3/25/19 4:01 AM, Stephen John Smoogen wrote: > > I will be gone Wed->Sun this week and will need someone to run the > > Thursday Infrastructure meeting. The basics of the meeting are in the > > gobby-0.5 on infinote.fedoraproject.org > > > > On Wednesday, call for items to be added to the document on IRC in > > #fedora-admin, #fedora-apps, #fedora-noc, #fedora-releng . Send out an > > email around 20:00 UTC. > > > > On Thursday, go to IRC an hour before meeting and remind people on > > #fedora-admin, #fedora-apps, #fedora-noc, #fedora-releng . Start the > > meeting and follow the form. After each section either mark sub-items > > to be used next meeting or remove it. > > I can do it if no one else wants to... but it's a great chance to get > involved and it's kinda fun the first few times. ;) > > Any takers? I'll do it. -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Apply MBS PR#1185 to fix Module Stream Expansion with new platform streams
+1 On Wed, Mar 27, 2019 at 7:02 AM Jan Kaluža wrote: > > Hi, > > Mohan filled MBS issue https://pagure.io/fm-orchestrator/issue/1184 and asked > us to fix and deploy that during the freeze to unblock him. I therefore want > to ask for +1 to deploy this small patch (already merged upstream): > https://pagure.io/fm-orchestrator/pull-request/1185#request_diff . > > I think the issue is well described in the PR, unit-test and MBS issue > tracker, so I won't repeat myself here. I hope that's OK. > > Regards, > Jan Kaluza > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [FBR] Adjust #fedora-diversity fedmsg IRC bot topics
+1 On Tue, Mar 19, 2019 at 10:54 PM Justin W. Flory wrote: > > Hi, the attached patch makes a small change to ircbot.py to change the > #fedora-diversity IRC bot to only listen for new Pagure tickets, pull > requests, and comments. This helps reduce the noise in the IRC channel > and hopefully makes the bot more useful for the team. > > Let me know if anyone has feedback on this patch. > > -- > Cheers, > Justin W. Flory > jflo...@gmail.com > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
FBR: Renew TLS certificate for whatcanidoforfedora.org
LetsEncrypt TLS certificate for whatcanidoforfedora.org expires on April 8, 2019. I would like to renew it by running the following command on batcave01: ansible-playbook playbooks/groups/proxies.yml -t whatcanidoforfedora.org No code changes in ansible.git are need. I've already tested this on staging and it worked. Expiry date is after expected Fedora 30 beta release, but I would still like to renew this certificate to prevent future outage if we forget to renew it after freeze is lifted, and to clear Nagios alerts. -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR to add host to mirrors tier1
Like Kevin, I think that the patch may contain unrelated change.
+1 to the part changing inventory/group_vars/download
+0 to the part changing roles/rsyncd
On Mon, Mar 11, 2019 at 11:44 PM Stephen John Smoogen wrote:
>
> I tried to make format-patch work but I have some problems in places
> still in my setup :/
>
> From 49ab54526b57d0cde534b2887a4e77cf021090ea Mon Sep 17 00:00:00 2001
> From: Stephen Smoogen
> Date: Mon, 11 Mar 2019 22:39:30 +
> Subject: [Freeze Break Request] FBR: rsyncd/download servers Add dotsrc to
> tier1
> To: infrastructure@lists.fedoraproject.org
>
> Add dotsrc to tier1 so that europe has another large mirror.
> ---
> inventory/group_vars/download | 2 ++
> roles/rsyncd/templates/rsyncd.conf.download.j2 | 10 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/inventory/group_vars/download b/inventory/group_vars/download
> index 7d3fe98..a806797 100644
> --- a/inventory/group_vars/download
> +++ b/inventory/group_vars/download
> @@ -70,3 +70,5 @@ dl_tier1:
>- 147.75.69.165 # sjc.edge.kernel.org
>- 147.75.197.195 # ewr.edge.kernel.org
>- 147.75.101.1 # ams.edge.kernel.org
> + - 130.225.254.116# dotsrc.org
> + - 2001:878:346::116 # dotsrc.org
> diff --git a/roles/rsyncd/templates/rsyncd.conf.download.j2
> b/roles/rsyncd/templates/rsyncd.conf.download.j2
> index 9a7b0fc..aa2f8f0 100644
> --- a/roles/rsyncd/templates/rsyncd.conf.download.j2
> +++ b/roles/rsyncd/templates/rsyncd.conf.download.j2
> @@ -149,6 +149,7 @@ refuse options = checksum
> gid = 263
> hosts allow = {% for host in vars['dl_tier1'] %}{{host}},{% endfor %}
>
> +{% if datacenter == 'phx2' %}
> [fedora-compose0]
> comment = Fedora composes
> path = /mnt/koji/compose
> @@ -156,7 +157,16 @@ refuse options = checksum
> uid = nobody
> gid = nobody
> hosts allow = 10.0.0.0/8, 209.132.0.0/16
> +{% endif %}
>
> +{% if inventory_hostname == 'download-cc-rdu01.fedoraproject.org' %}
> +[centos]
> + comment = CentOS
> + path = /srv/pub/centos
> + list = no
> + uid = nobody
> + gid = nobody
> +{% endif %}
>
> # For distributing applications
> [log]
> --
> 1.8.3.1
>
>
> --
> Stephen J Smoogen.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [FBR] Adding f30 key to bodhi modular pungi config
+1
On Mon, Mar 11, 2019 at 4:22 PM Mohan Boddu wrote:
>
> This patch will add fedora-30 key to bodhi modular pungi config.
>
> diff --git a/roles/bodhi2/backend/templates/pungi.module.conf.j2
> b/roles/bodhi2/backend/templates/pungi.module.conf.j2
> index bb021eb..43c6a7e 100644
> --- a/roles/bodhi2/backend/templates/pungi.module.conf.j2
> +++ b/roles/bodhi2/backend/templates/pungi.module.conf.j2
> @@ -14,6 +14,8 @@ sigkeys = [
>'9db62fb1',
> [% elif release.version_int == 29 %]
>'429476b4',
> +[% elif release.version_int == 30 %]
> + 'cfc659b9',
> [% endif %]
> {% if env == "staging" %}
>None
>
> Please +1 this patch to resume the failed f30-modular-updates-testing.
>
> Thanks.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Rebuild Bodhi frontend containers
+1 On Mon, Mar 11, 2019 at 3:45 PM Randy Barlow wrote: > > Greetings! > > The Bodhi frontend container was not rebuilt when the Fedora 30 > configurations were added to production.ini. This means that the > frontend is not aware of the policy of 3 days to stable, while the > backend is aware. This means that the backend is adding comments to > updates to tell packagers they can push their packages, but the > frontend is not allowing them to push the packages. > > To fix this, I will run this command: > > $ sudo rbac-playbook openshift-apps/bodhi.yml > > I will also send a patch to the releng SOP which doesn't explicitly > mention this step - it really should just link to the Bodhi SOP where > this is mentioned. > -BEGIN PGP SIGNATURE- > > iQIzBAABCAAdFiEEtaW+t5vwm7qNSBIDeETMuDvdJGIFAlyGdF0ACgkQeETMuDvd > JGLrvw//a7SRweYx4BizmaVVf35+IcSfknT/VV03HJQ3dbtPUAOjV4HH+slnMLBa > wWWbcJkYi368zntm0EqO0Smaf0DxVmq6qz6HzXx5Di6H4sMTxUqReXxKnTT3itUc > VK16YkfAdPgb4OVC4qUkPjVCU+XsWJXfUzRTiB1zy5nCv5+9WDguqh9eLP+gN1Gs > PYxmnOZ8KtEs1p0qS2hb8kj/NkSS6wT4uSY3e58x1n6rZEWPHtKyWNxsLgnirRFS > f55RFfsHxFxrp2UYtEsI5HcXAXa9W0PkCR+HbP8A45sodnJpzUHRL39MMLupRyjE > nkIOsskJDazM5HxQzHocscpyvHLOla+rkpeqA7+3yZygPKPN4KFn5ljlsX4HkKYs > EZXEtqebK8mUbqNJ1ZSa+QTU48QMV25Um0UXMBlLh1y0INpTK79nwFiaw/FjxlNg > PKSipw6BY4S2X0l/OZ0KLF77ng91UJJdCxhCOAXo1zZ6A1Vf6FjigV6eoaM0+Lwk > KL2qU4Gd2xEkiGBv7spGn7GRv/lrV556vXNsdfIH8tFySjDXqcHdASB6gv5Lu0cD > W4WOwQPUMalyIUFOoPSFPbrvf7HcEJPt6Mb7ZQvN3SE0Ztaf2SgDh/faFZBbEKYC > ABf8mcb2Q20bDFTjqtqrDuiF7mWLCfMoCoZjPUz1APO9oKh+FyU= > =+ODM > -END PGP SIGNATURE- > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Proposal to increase number of concurrent MBS builds
On Mon, Mar 11, 2019 at 12:41 PM Stephen John Smoogen wrote: > > On Mon, 11 Mar 2019 at 06:55, Mikolaj Izdebski wrote: > > > > On Mon, Mar 11, 2019 at 10:43 AM Stephen John Smoogen > > wrote: > > > > > > On Mon, 11 Mar 2019 at 04:52, Mikolaj Izdebski > > > wrote: > > > > > > > > I would like to propose increasing NUM_CONCURRENT_BUILDS for MBS to > > > > value 100 after beta freeze is over. > > > > > > > > The above MBS setting controls how many parallel component builds MBS > > > > can run at the same time. Current value is only 20. That value was > > > > defined 3 years ago, in March 2017 when there were much fewer modules > > > > in Fedora. Our Koji has capacity to run many more builds. Currently we > > > > have 158 Koji builders in default channel that are able to run RPM > > > > builds. Their total capacity is 566. Therefore it should be safe to > > > > increase MBS NUM_CONCURRENT_BUILDS to at least 100. Especially since > > > > Koji builds submitted by MBS have lower priority than default for > > > > non-modular component builds submitted by packagers, so > > > > packager-submitted builds will take precedence over builds submitted > > > > by MBS. > > > > > > > > > > Does the koji numbers above take into account architectures? While > > > have 158 builders they are spread out over a lot of architectures with > > > ~12 s390x builders, ~30 ppc64le, ~20 arm and ~20 aarch64 builders and > > > I guess ~70 x86_64 builders. So while we could build a lot more x86_64 > > > builds at once, could we completely swamp the other arches and > > > actually cause problems for even completing the x86_64 ones? > > > > > > If the architecture would be a problem, should we look at the > > > smaller/slowest number of builders and work out what its capacity is > > > and not go much above that? > > > > That should not be a problem. Koji can handle thousands of builds > > submitted at the same time. This happens, for example, during mass > > rebuilds. > > > > Yeah.. sorry I didn't explain things clearly. Koji can handle it but > does it make the developer experience worse across the board? We could > do a mass rebuild every day and koji wouldn't break a sweat.. but > developers actually wanting to get stuff out of Fedora would hate it > because the queues for builds would be so long. My questions should > have stated that. As I mentioned in the first email, builds submitted by MBS have lower priority than default. If all Koji builders are loaded with modular builds then developer may need to wait a bit before one of them completes. But once any builder has free capacity, it will pick up developer-submitted builds before MBS-submitted ones. -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Proposal to increase number of concurrent MBS builds
On Mon, Mar 11, 2019 at 10:43 AM Stephen John Smoogen wrote: > > On Mon, 11 Mar 2019 at 04:52, Mikolaj Izdebski wrote: > > > > I would like to propose increasing NUM_CONCURRENT_BUILDS for MBS to > > value 100 after beta freeze is over. > > > > The above MBS setting controls how many parallel component builds MBS > > can run at the same time. Current value is only 20. That value was > > defined 3 years ago, in March 2017 when there were much fewer modules > > in Fedora. Our Koji has capacity to run many more builds. Currently we > > have 158 Koji builders in default channel that are able to run RPM > > builds. Their total capacity is 566. Therefore it should be safe to > > increase MBS NUM_CONCURRENT_BUILDS to at least 100. Especially since > > Koji builds submitted by MBS have lower priority than default for > > non-modular component builds submitted by packagers, so > > packager-submitted builds will take precedence over builds submitted > > by MBS. > > > > Does the koji numbers above take into account architectures? While > have 158 builders they are spread out over a lot of architectures with > ~12 s390x builders, ~30 ppc64le, ~20 arm and ~20 aarch64 builders and > I guess ~70 x86_64 builders. So while we could build a lot more x86_64 > builds at once, could we completely swamp the other arches and > actually cause problems for even completing the x86_64 ones? > > If the architecture would be a problem, should we look at the > smaller/slowest number of builders and work out what its capacity is > and not go much above that? That should not be a problem. Koji can handle thousands of builds submitted at the same time. This happens, for example, during mass rebuilds. -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Proposal to increase number of concurrent MBS builds
I would like to propose increasing NUM_CONCURRENT_BUILDS for MBS to value 100 after beta freeze is over. The above MBS setting controls how many parallel component builds MBS can run at the same time. Current value is only 20. That value was defined 3 years ago, in March 2017 when there were much fewer modules in Fedora. Our Koji has capacity to run many more builds. Currently we have 158 Koji builders in default channel that are able to run RPM builds. Their total capacity is 566. Therefore it should be safe to increase MBS NUM_CONCURRENT_BUILDS to at least 100. Especially since Koji builds submitted by MBS have lower priority than default for non-modular component builds submitted by packagers, so packager-submitted builds will take precedence over builds submitted by MBS. -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [PATCH] Add zchunk support to updates and updates-testing repositories
Note that we are in infrastructure freeze and this patch affects
frozen hosts, therefore you need to follow "Fedora Release
Infrastructure SOP" [1] and submit a freeze break request. Otherwise
the patch will need to wait until the freeze is lifted.
[1]
https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/fedora-releases.html#change-freeze
--
Mikolaj Izdebski
On Sun, Mar 10, 2019 at 6:24 PM Jonathan Dieter wrote:
>
> This adds zchunk support for the updates and updates-testing repositories
> for both rpms and modularity
>
> Signed-off-by: Jonathan Dieter
> ---
> roles/bodhi2/backend/templates/pungi.module.conf.j2 | 3 +++
> roles/bodhi2/backend/templates/pungi.rpm.conf.j2| 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/roles/bodhi2/backend/templates/pungi.module.conf.j2
> b/roles/bodhi2/backend/templates/pungi.module.conf.j2
> index bb021eb13..7dad35403 100644
> --- a/roles/bodhi2/backend/templates/pungi.module.conf.j2
> +++ b/roles/bodhi2/backend/templates/pungi.module.conf.j2
> @@ -59,6 +59,9 @@ greedy_method = 'build'
> createrepo_c = True
> createrepo_checksum = 'sha256'
> createrepo_deltas = False
> +[% if release.version_int >= 30 %]
> +createrepo_extra_args = ['--zck',
> '--zck-dict-dir=/usr/share/fedora-repo-zdicts/f[[ release.version_int ]]']
> +[% endif %]
>
> #jigdo
> create_jigdo = False
> diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> index 8d9e9a3f2..020736aee 100644
> --- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> +++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> @@ -66,6 +66,9 @@ createrepo_deltas = [
> ('^Everything$', {'*': True})
> ]
> createrepo_database = True
> +[% if release.version_int >= 30 %]
> +createrepo_extra_args = ['--zck',
> '--zck-dict-dir=/usr/share/fedora-repo-zdicts/f[[ release.version_int ]]']
> +[% endif %]
>
> # CHECKSUMS
> media_checksums = ['sha256']
> --
> 2.20.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: How do we turn zchunk on for updates-testing for F30?
On Sat, Mar 9, 2019 at 2:29 PM Jonathan Dieter wrote: > > Hey, I just noticed that, while we have zchunked metadata for the F30 > base repository, it's not enabled to for updates-testing. > > I've looked in the ansible repo and in pungi, but I can't see where > createrepo_c is actually called for updates-testing. Can someone > please point me in the right direction? createrepo for updates-testing is ran by pungi. I believe you need to enable zchunk in pungi.conf (createrepo_extra_args option). For non-modular updates-testing the config is roles/bodhi2/backend/templates/pungi.rpm.conf.j2 in ansible.git. Similarly, for modular equivalent, pungi config is located at roles/bodhi2/backend/templates/pungi.module.conf.j2 -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [Freeze Break Request ] infrastructure.fedoraproject.org: Allow new cloud network access to repos and resources
+1 On Thu, Mar 7, 2019 at 10:18 PM wrote: > > From: Kevin Fenzi > > Signed-off-by: Kevin Fenzi > --- > roles/batcave/files/allows | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/roles/batcave/files/allows b/roles/batcave/files/allows > index 33592e1..5439b2a 100644 > --- a/roles/batcave/files/allows > +++ b/roles/batcave/files/allows > @@ -34,6 +34,7 @@ require ip 213.175.193.204 > require ip 213.175.193.205 > require ip 213.175.193.206 > require ip 213.175.193.207 > +require ip 38.145.48.0/23 > > # ibiblio > require ip 152.19.134.136 > -- > 1.8.3.1 > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [Freeze Break Request: ] pagure.io: Increase upload size from 60MB to 100MB for virt-viewer
+1 On Wed, Mar 6, 2019 at 2:46 AM wrote: > > From: Kevin Fenzi > > See ticket https://pagure.io/fedora-infrastructure/issue/7612 > virt-viewer folks need to upload larger than 60MB content. > > Signed-off-by: Kevin Fenzi > --- > roles/pagure/frontend/templates/pagure.cfg | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/roles/pagure/frontend/templates/pagure.cfg > b/roles/pagure/frontend/templates/pagure.cfg > index 9c3eb4b..9c85d52 100644 > --- a/roles/pagure/frontend/templates/pagure.cfg > +++ b/roles/pagure/frontend/templates/pagure.cfg > @@ -158,7 +158,7 @@ ITEM_PER_PAGE = 50 > > ### Maximum size of the uploaded content > # Used to limit the size of file attached to a ticket for example > -MAX_CONTENT_LENGTH = 60 * 1024 * 1024 # 60 megabytes > +MAX_CONTENT_LENGTH = 100 * 1024 * 1024 # 100 megabytes > > ### Lenght for short commits ids or file hex > SHORT_LENGTH = 7 > -- > 1.8.3.1 > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Future of fedora-packages
On Wed, Feb 27, 2019 at 1:20 PM Stephen John Smoogen wrote: > 2. Packaging of elasticsearch was a mess. At the time we had rules > that all packages needed to be packaged in Fedora and follow Fedora > packaging rules. [This one has been relaxed.] I just want to point out that Elasticsearch has been packaged [1] in Fedora for more than 4 years. https://src.fedoraproject.org/rpms/elasticsearch -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: RFR: Message-Tagging-Service
On Thu, Feb 21, 2019 at 6:42 AM Chenxiong Qi wrote: > This mail is for a new micro-service called Message-Tagging-Service (aka > MTS). It serves to tag module build triggered by specific MBS event. > More detailed information is provided inside RFR ticket[1]. Thanks for working on this. In the ticket I agreed to be a sponsor for this RFR. > MTS works with a series of predefined rules to see if a module build > should be tagged with one or more tags. There is requirement coming from > module maintainers to ensure a module build is tagged into correct > platforms to fulfill the dependencies of module metadata. Comment[2] has > a specific use case for that. As a packager and module maintainer I agree that currently there are problems with tagging modules into appropriate tags. From what I heard there are no plans for MBS to fix this and we are expected to use MTS instead. > So far, MTS has been containerized and deployed in internal. The image > is available from quay.io[3]. We would love to run MTS in Fedora as well > in order to make it easier to manage module build tag for module > maintainers and rel-eng. I believe that using containers is allowed and expected these days and that the part of RFR process that relates to having the software packaged for EPEL 7 can be skipped. > If anything is missed for this mail thread, please point out. Questions > welcome! Thanks for your time. I have a couple of questions: 1. As I understand, MTS is driven by a configuration file (mts-rules.yaml) that specifies which modules should be tagged with which Koji tags. Where is this configuration going to be stored? Upstream image on quay.io? Fedora ansible.git? A different git repository? 2. Who is going to maintain the above rules configuration? MTS maintainers listed in the ticket? Release engineering? 3. MTS requires a Koji user (and corresponding Kerberos keytab) with no special permissions, which it would use to tag module builds. Koji users are managed by release engineering. Does release engineering agree to have MTS used in Fedora? I think it would be good to open a releng ticket for them to explicitly agree on the proposal. 4. Do the people listed as MTS maintainers agree to sign-up for its maintenance? It would be good if they at least acknowledged this in the ticket. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Future plans about fedmsg
Hello, Today I've looked into porting Koschei from fedmsg to fedora-messaging. Unfortunately I've encountered problems that prevent me from progressing. Most importantly our RabbitMQ servers are not accessible from outsides of Fedora infrastructure VPN. Moreover, all clients must authenticate with a TLS certificate, even pure consumers that don't intend to publish any messages. For these reasons I've decided that upstream Koschei project will keep using fedmsg for consuming messages. For publishing I'm still considering fedora-messaging as authentication in this case is expected. My main questions are: What are the plans regarding our fedmsg deployment? Are we planning to have it continue to run in parallel with fedora-messaging in foreseeable future? If not, then will at least fedora-messaging to fedmsg relay keep to be maintained? Also, is there a list of advantages of fedora-messaging over fedmsg available somewhere? I'm wondering if there are any significant advantages that would justify the effort to port Koschei and other software I maintain away form fedmsg. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: MBI (Playground 2.0)
On Thu, Jan 31, 2019 at 1:36 PM Josh Boyer wrote: > Why does this need to be deployed in the fedora infrastructure cloud? > Seems like you could stand it up in AWS or somewhere else. Because we (Fedora contributors) don't have budget to pay AWS bills. If someone is willing to sponsor this then AWS would work well. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [PATCH] Add CDN testing cloudfront redirect for atomic repo
I've applied the patch and deployed it in production. On Thu, Jan 3, 2019 at 4:55 PM Sinny Kumari wrote: > > > > On Thu, Jan 3, 2019 at 9:16 PM Dusty Mabe wrote: >> >> >> >> On 1/3/19 10:40 AM, Sinny Kumari wrote: >> > Hi, >> > >> > Currently, we are using two different cloudfront distributions to CDN >> > content for >> > /atomic/repo/objects/ and /atomic/repo/deltas/ . With the current setup we >> > see >> > an issue https://github.com/ostreedev/ostree/issues/1541 . To overcome this >> > issue and provide faster delivery of ostree content, we have created a >> > cloudfront distribution where we CDN /atomic/repo/ . >> > >> > This patch (available in attachment) adds some redirect rules to use new >> > cloudfront urls for testing purpose and see how much improvement we get in >> > content delivery. This patch shouldn't impact existing infra setup. >> > >> >> I'd like to highlight this is for testing purposes only and should have a >> short >> life. We just wanted to make sure the "redirect penalty" that we experience >> with >> our prod redirects is also reflected in our testing so we can get more >> accurate >> results. >> >> Sinny, >> >> One thing we might want to do is use https for the cloudfron URLs like we >> are for >> the prod redirects. Otherwise LGTM. > > > Ah yes, nice catch. Updated patch is available in the attachment. > This is the sad part part of doing copy paste :/ > > >> >> Dusty >> >> > > > -- > http://sinny.io/ > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: wrong description of java-openjdk in bugzilla
On Thu, Jan 3, 2019 at 9:25 AM jiri vanek wrote: > > Please see: https://bugzilla.redhat.com/show_bug.cgi?id=1661697 ; > > Description of component (here, in BZ) is wrong: OpenJDK Runtime Environment > 11 > Should be: OpenJDK rolling package for latest JDK > > Can you please manage to fix it? Component description in Bugzilla is taken from summary of SRPM in rawhide. You can change the summary yourself and it should be eventually propagated to Bugzilla. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Patch for issue 7378
On Fri, Dec 7, 2018 at 11:33 PM Zach Villers wrote: > I looked at the original ticket and inferred too much possibly. Or > perhaps I'm just not clear on how this redirect works. I see now this a > for an apache mod_proxy config? Maybe I was thinking this was for a > mod_rewrite? It is httpd/redirect role, the relevant template is roles/httpd/redirect/templates/redirect.conf It uses Redirect directive, which is implemented by mod_alias > Either way; new patch attached without the '$1'. Thanks for reviewing! I've applied it and deployed. Thanks. In future please commit your changes and then use "git format-patch" or "git send-email" to send patch with full metadata, so that you can be credited properly. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Patch for issue 7378
It's almost good, but the patch is not entirely correct. On Thu, Dec 6, 2018 at 5:08 PM Zach Villers wrote: >- role: httpd/redirect > shortname: jenkins > website: jenkins.fedorainfracloud.org > -target: https://jenkins-fedora-infra.apps.ci.centos.org > +target: https://jenkins-fedora-infra.apps.ci.centos.org/$1 What does $1 refer to? It's not needed. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Koji / epel-7 - What's going on?
On Mon, Nov 26, 2018 at 8:17 PM Kevin Fenzi wrote: > > On 11/26/18 1:59 AM, Mikolaj Izdebski wrote: > > "ExclusiveArch: aarch64" works while "ExclusiveArch: x86_64" does not. > > The problem is that Koji may try to build packages with > > "ExclusiveArch: x86_64" in i386 chroot. This is not fixed AFAIK. A fix > > would be splitting x86_64/i386 hosts into two distinct groups and > > assigning exactly one arch to each builder. > > That seems very odd to me. Do you have an example build of this? Example task: https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90003488 Package has "ExclusiveArch: x86_64", buildArch task has correct "Arch x86_64", yet the build is ran in i386 chroot (see root.log) and fails with "error: Architecture is not included: i386". > Shouldn't mock pass the right thing here? This is a bug in Koji, not mock. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Koji / epel-7 - What's going on?
On Sat, Nov 24, 2018 at 8:08 PM Kevin Fenzi wrote: > > On 11/21/18 3:11 AM, Vít Ondruch wrote: > > > > Dne 20. 11. 18 v 23:52 Kevin Fenzi napsal(a): > > Was this resolved? > > > > https://pagure.io/releng/issue/7671 > > I thought so, but the builds there have their logs cleaned up and the > devel spec no longer has this in it. > I tried a test package that I scratch built and it seemed to work fine. > (ie, when I had ExclusiveArch: noarch aarc64 it always went to a aarch64 > builder). "ExclusiveArch: aarch64" works while "ExclusiveArch: x86_64" does not. The problem is that Koji may try to build packages with "ExclusiveArch: x86_64" in i386 chroot. This is not fixed AFAIK. A fix would be splitting x86_64/i386 hosts into two distinct groups and assigning exactly one arch to each builder. -- Mikolaj ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Disable F29 branched compose
+1 - Original Message - > This is to disable F29 branched composes since we got F29 GA gold compose > > diff --git a/roles/releng/files/branched b/roles/releng/files/branched > index 561b8e0..cbcafff 100644 > --- a/roles/releng/files/branched > +++ b/roles/releng/files/branched > @@ -1,3 +1,3 @@ > # branched compose > MAILTO=releng-c...@lists.fedoraproject.org > -15 7 * * * root TMPDIR=`mktemp -d /tmp/branched.XX` && cd $TMPDIR && > git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && git > checkout f29 && /usr/local/bin/lock-wrapper branched-compose > "PYTHONMALLOC=debug LANG=en_US.UTF-8 ./nightly.sh" && sudo -u ftpsync > /usr/local/bin/update-fullfiletimelist -l > /pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora > fedora-secondary > +#15 7 * * * root TMPDIR=`mktemp -d /tmp/branched.XX` && cd $TMPDIR && > git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && git > checkout f29 && /usr/local/bin/lock-wrapper branched-compose > "PYTHONMALLOC=debug LANG=en_US.UTF-8 ./nightly.sh" && sudo -u ftpsync > /usr/local/bin/update-fullfiletimelist -l > /pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora > fedora-secondary > > Thanks. > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
FBR: Fix regeneration of dist-repos
This fixes issue with regenerating dist-repos: https://pagure.io/fedora-infrastructure/issue/7332 Works around Koji bug: https://pagure.io/koji/issue/1114 From 50d1c0ac60d39abfd194675ee40f8b5bc1c0dec5 Mon Sep 17 00:00:00 2001 From: Mikolaj Izdebski Date: Fri, 26 Oct 2018 22:03:21 +0200 Subject: [PATCH] Fix regeneration of dist-repos (#7332) This is workaround for Koji bug https://pagure.io/koji/issue/1114 --- roles/bodhi2/backend/files/dist-repo-regen.py | 1 + 1 file changed, 1 insertion(+) diff --git a/roles/bodhi2/backend/files/dist-repo-regen.py b/roles/bodhi2/backend/files/dist-repo-regen.py index a8984c776..4268b6631 100644 --- a/roles/bodhi2/backend/files/dist-repo-regen.py +++ b/roles/bodhi2/backend/files/dist-repo-regen.py @@ -68,6 +68,7 @@ for koji_env in config['tag2distrepo.tags'].keys(): 'inherit': False, 'latest': True, 'multilib': False, +'split_debuginfo': False, 'skip_missing_signatures': False, 'allow_missing_signatures': False } -- 2.14.2 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Staging Koji maintenance
Hello, On Wed Oct 31 I would like to do some maintenance on staging Koji. For more details see https://pagure.io/fedora-infrastructure/issue/7326 Does anyone have any objections? Also please let me know if there is any staging-specific Koji configuration that should be preserved but it is not ansiblized, otherwise it will be lost during sync. -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze Break Request: fix up registry
+1 - Original Message - > Greetings. > > I would like to do the following: > > * Apply the attached ansible diff. This changes things to run the new > 'reg' (which just has a 'server' subcommand, not a reg-server binary), > and also fixes varnish to not eat the requests to show more than 100 > items from our registry. It also fixes some sync jobs where the flatpak > info would 'disappear' for 10min at a time due to a --delete that > shouldn't have been there. > > * Upgrade 'reg' on sundries01.phx2 (prod). I've already tested this > version in staging and it works. > > * Run playbooks: sundries, and proxies > > The only thing that could affect things much here is the varnish change, > but it's one line and contained to the registry block. > > This would make our registry nice and pretty before release. > > +1s? > > kevin > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [Freeze Break Request: ] Switch anitya backups to use --exclude-table-data rather than excluding entire tables
+1 On 10/10/2018 02:17 AM, ke...@scrye.com wrote: > From: Kevin Fenzi > > This allows people to use the db dump without having to manually create the > missing tables. > > Signed-off-by: Kevin Fenzi > --- > roles/postgresql_server/files/backup-database.anitya | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/roles/postgresql_server/files/backup-database.anitya > b/roles/postgresql_server/files/backup-database.anitya > index c28f31b..a2e05a8 100644 > --- a/roles/postgresql_server/files/backup-database.anitya > +++ b/roles/postgresql_server/files/backup-database.anitya > @@ -10,7 +10,7 @@ DB=anitya > # Make it use a limited number of threads because pxz will use all the > # cpus which causes pg_dump to starve which causes... > > -/usr/bin/pg_dump -T users -T tokens -T 'social*' -T sessions -C $DB | > /usr/bin/pxz -T4 > /backups/$DB-public-$(date +%F).dump.xz > +/usr/bin/pg_dump --exclude-table-data users --exclude-table-data tokens > --exclude-table-data 'social*' --exclude-table-data sessions -C $DB | > /usr/bin/pxz -T4 > /backups/$DB-public-$(date +%F).dump.xz > > # Also, delete the backup from a few days ago. > rm -f /backups/$DB-public-$(date --date="1 days ago" +%F).dump.xz > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: fedora-infrastructure#7267: "fedora-packager and statscache sunset" patch review.
On 10/02/2018 02:22 AM, David Shier wrote: > All/sysadmin-main - > > Could someone please review the attached patch file for the removal of > tagger and statscache from the ansible repos/proxy lists/ etc.? I was > going to attach to issue, but pagure is only letting me do pictures, and > this one is large and gnarly as a picture. 1. Commit subject is way too long and not well formed. There are many guidelines on writing commit messages, eg. [1] 2. Ideally there should be one service removed per commit, not both in a single commit 3. You missed multiple references to tagger, see "git grep tagger" [1] https://chris.beams.io/posts/git-commit/ > > Thanks, > > Dave Shier/odin > > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The trouble with torrents
On 09/29/2018 01:24 AM, Kevin Fenzi wrote: > On 09/26/2018 10:59 PM, Pablo Iranzo Gómez wrote: >> Hi Kevin, >> >> What about using transmission-daemon which is available in Fedora? >> >> (also console with optional Web UI) > > Yeah, we looked at it the last time, but it there were issues... > > I think the daemon version still pulled in the entire gtk stack or you > couldn't > manage it via config files. Looks like it might be better now... I've been successfully using transmission-daemon since January. It can definitely be managed via config files, but it expects to own config files - it overwrites them when the process terminates. This can be worked around easily, eg. by updating config files when the deamon is not running: - name: Create transmission config directory file: dest=/var/lib/transmission/.config/transmission-daemon/ state=directory owner=transmission group=transmission - name: Copy transmission config file template: src=settings.json.j2 dest=/var/lib/transmission/.config/transmission-daemon/settings.json register: settings_j2 - name: Stop transmission-daemon service: name=transmission-daemon state=stopped when: settings_j2.changed - name: Copy transmission config file again template: src=settings.json.j2 dest=/var/lib/transmission/.config/transmission-daemon/settings.json when: settings_j2.changed - name: Start and enable transmission-daemon service: name=transmission-daemon state=started enabled=true -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Add proxy101/proxy110 to the OSBS whitelsit
On 09/25/2018 09:36 PM, Patrick マルタインアンドレアス Uiterwijk wrote: > Hi all, > > Can I get +1s for the patch underneath? > This adds proxy101/proxy110 to the whitelist for OSBS for candidate-registry > pushing. +1 definitely > > Patrick > > > commit ef9fa10389a6a60843c96e4855dbdcb604583baa (HEAD -> master) > Author: Patrick Uiterwijk > Date: Tue Sep 25 21:34:39 2018 +0200 > > Whitelist proxy101/proxy110 for OSBS > > It turns out that these were never added to the OSBS whitelist, breaking > about > 50% of all builds > > Signed-off-by: Patrick Uiterwijk > > diff --git a/files/osbs/fix-docker-iptables.production > b/files/osbs/fix-docker-iptables.production > index ee03776a5..f1a50781c 100644 > --- a/files/osbs/fix-docker-iptables.production > +++ b/files/osbs/fix-docker-iptables.production > @@ -46,6 +46,8 @@ iptables -A FILTER_FORWARD -p udp -m udp -d 10.5.126.21 > --dport 53 -j ACCEPT > iptables -A FILTER_FORWARD -p udp -m udp -d 10.5.126.22 --dport 53 -j ACCEPT > > # mirrors.fp.o > +iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.8 --dport 443 -j ACCEPT > +iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.9 --dport 443 -j ACCEPT > iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.51 --dport 443 -j ACCEPT > iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.52 --dport 443 -j ACCEPT > > @@ -53,6 +55,8 @@ iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.52 > --dport 443 -j ACCEPT > iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.23 --dport 443 -j ACCEPT > > # Kerberos > +iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.8 --dport 1088 -j ACCEPT > +iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.9 --dport 1088 -j ACCEPT > iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.51 --dport 1088 -j > ACCEPT > iptables -A FILTER_FORWARD -p tcp -m tcp -d 10.5.126.52 --dport 1088 -j > ACCEPT > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: upgrading pagure to 5.0
On 09/25/2018 08:11 AM, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > I just cut a new release of pagure: 5.0, the formal announce is pending > polishing things with mailman so we can include in the announce the new > mailing > lists to discuss/follow pagure. > > Pending this, I'd like to request a Freeze Break Request for upgrading pagure > to > 5.0. > It's not critical for the release of the beta tomorrow, and it saves one day > (vs > waiting for Wed) for the upgrade which considering some deadlines intern to > the > infra team may be good. > > What do you think? I'm sceptical about this upgrade on a release day. But on the other hand it's only beta release. I'm +1 to try it. -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Add key for f29 modular
+1
On 09/21/2018 12:58 PM, Patrick Uiterwijk wrote:
> Hi all,
>
> Can I get +1s to merge the following, which should allow us to
> actually push out f29 module updates?
>
> Patrick
>
>
> commit b39a70e1f58bd3f7e9960499f23717bda7d01b06 (HEAD -> master)
> Author: Patrick Uiterwijk
> Date: Fri Sep 21 12:56:58 2018 +0200
>
> Define the key for modular bodhi composes
>
> Signed-off-by: Patrick Uiterwijk
>
> diff --git a/roles/bodhi2/backend/templates/pungi.module.conf.j2
> b/roles/bodhi2/backend/templates/pungi.module.conf.j2
> index e7bac1721..bb021eb13 100644
> --- a/roles/bodhi2/backend/templates/pungi.module.conf.j2
> +++ b/roles/bodhi2/backend/templates/pungi.module.conf.j2
> @@ -12,6 +12,8 @@ variants_file='module-variants.xml'
> sigkeys = [
> [% if release.version_int == 28 %]
> '9db62fb1',
> +[% elif release.version_int == 29 %]
> + '429476b4',
> [% endif %]
> {% if env == "staging" %}
> None
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze break request: backup pagure / src.fedoraproject.org db
+1 On 09/20/2018 11:29 PM, Kevin Fenzi wrote: > Greetings. > > While I was doing a sync of production src.fedoraproject.org to staging > today I found out that we are not actually backing up the production > database. ;( > > Can I get +1s for the following and running the postgresql-server playbook? > > From 57e03cec512b9837d45d45b0b462dde67828c593 Mon Sep 17 00:00:00 2001 > From: Kevin Fenzi > Date: Thu, 20 Sep 2018 21:27:55 + > Subject: [PATCH] Back up pagure / src.fedoraproject.org database > > Signed-off-by: Kevin Fenzi > --- > inventory/host_vars/db01.phx2.fedoraproject.org | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/inventory/host_vars/db01.phx2.fedoraproject.org > b/inventory/host_vars/db01.phx2.fedoraproject.org > index 5ac5154..6c7545a 100644 > --- a/inventory/host_vars/db01.phx2.fedoraproject.org > +++ b/inventory/host_vars/db01.phx2.fedoraproject.org > @@ -29,6 +29,7 @@ databases: > - notifications > - nuancier_lite > - odcs > +- pagure > - pdc > - statscache > - tahrir > @@ -53,6 +54,7 @@ dbs_to_backup: > - notifications > - nuancier_lite > - odcs > +- pagure > - pdc > - statscache > - tahrir > > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze break request: upgrade qemu on buildvm-ppc64le-01/02
On 08/31/2018 12:41 AM, Kevin Fenzi wrote: > Greetings. > > Right before freeze we got a security qemu update (which was auto > applied) on buildvm-ppc64le-01/02. Unfortunately this broke creating > images and since those two are our ppc64le image builder machines it's > not been fun. > > I'd like to update them with qemu-2.11.2-3.fc28 which fixes the problem > commit (hopefully). If it doesn't it cannot make it worse, as they > always fail image building now anyhow. > > Bug https://bugzilla.redhat.com/show_bug.cgi?id=1614948 has details and > https://pagure.io/releng/issue/7703 has information on all the images > that haven't been building. > > +1s? +1. It should be easy to revert if necessary. -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR Add OSBS to aarch64.
This change is for staging only, so I'm not convinced a FBR is needed. But here is my review anyway. 1. you added host vars for osbs-aarch64-node01.stg.arm.fedoraproject.org, but this host is not in inventory 2. kickstart file kvm-fedora-aarch64-28-osbs does not exist 3. You set osbs_odcs_enabled to true, but ODCS does not support aarch64 AFAIR (it works on x86_64 only I think) 4. playbooks/groups/osbs-cluster.yml should probably be updated to to provision newly added hosts It looks that some changes are needed for this to work. On 08/30/2018 10:50 PM, Stephen John Smoogen wrote: > Third time is supposedly the charm they say > On Thu, 30 Aug 2018 at 16:42, Dennis Gilmore wrote: >> >> +1 also thanks >> El jue, 30-08-2018 a las 16:23 -0400, Stephen John Smoogen escribió: >>> Talked with cverna on IRC and made changes from that. Please review >>> this one. >>> On Thu, 30 Aug 2018 at 14:48, Stephen John Smoogen >>> wrote: >>>> >>>> This needs review by both infrastructure and people who are >>>> familiar >>>> with osbs. I am mostly copya pasta editing here so it may or may >>>> not >>>> work. It is also not clear if we need both a master and a node or >>>> just >>>> a master. >>>> >>>> >>>> -- >>>> Stephen J Smoogen. >>> >>> >>> >>> ___ >>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org >>> To unsubscribe send an email to >>> infrastructure-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org >> ___ >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org >> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > > > > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: FBR: Set up docs.teamsilverblue.org
+1 On 08/29/2018 01:06 AM, Patrick Uiterwijk wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi all, > > So, teamsilverblue pointed their DNS to us without informing us, can I get > +1s to add a redirect to docs.fp.o? > > Patrick > > > commit b0f37902db5d46b9aac5af8ebaa92639e9d43f8f > Author: Patrick Uiterwijk > Date: Tue Aug 28 23:03:28 2018 + > > Add docs.teamsilverblue.org and redirect to docs.fp.o/silverblue > > Signed-off-by: Patrick Uiterwijk > > diff --git a/playbooks/include/proxies-redirects.yml > b/playbooks/include/proxies-redirects.yml > index 91c167b..21b1583 100644 > - --- a/playbooks/include/proxies-redirects.yml > +++ b/playbooks/include/proxies-redirects.yml > @@ -762,3 +762,12 @@ > website: cloud.fedoraproject.org > path: /fedora-atomic-latest.x86_64.qcow2 > target: > https://download.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Atomic-22-20150521.x86_64.qcow2 > + > + # Team Silverblue > + - role: httpd/redirect > +shortname: docsteamsilverblue > +website: docs.teamsilverblue.org > +path: / > +target: https://docs.fedoraproject.org/en-US/fedora-silverblue/ > +tags: > +- docs.teamsilverblue.org > diff --git a/playbooks/include/proxies-websites.yml > b/playbooks/include/proxies-websites.yml > index 25ca1e4..8013c53 100644 > - --- a/playbooks/include/proxies-websites.yml > +++ b/playbooks/include/proxies-websites.yml > @@ -418,6 +418,14 @@ > - whatcanidoforfedora.org > >- role: httpd/website > +site_name: docs.teamsilverblue.org > +ssl: true > +sslonly: true > +certbot: true > +tags: > +- docs.teamsilverblue.org > + > + - role: httpd/website > site_name: fedoramagazine.org > server_aliases: [www.fedoramagazine.org stg.fedoramagazine.org] > cert_name: fedoramagazine.org > > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJbhdVoAAoJEIZXmA2atR5QZTUP/RkmcVpQ4a0wbu3rFe/PC5P/ > egb/tttT0KP0S3TXwUsNkLxaaZK/Une/l1rZU9a+8Y8TOw86THKWMlEp+15l+R9c > /+yShpSdJm6C+/fKlG+ajYOtq0pnrDVwyCEiTEz0CVXaXxoMToc/VXgtid7ORO0t > XRA6YWCjxs/eN5BkQmlcap0E5Oq2peGvuD3faxNNj8L1eoEDADTAy4AtvRTxOXay > PiXWg1bNTauIOEqXv57XZ51snFnf6qjqeok8uxKDKmpjp3ZOOYxvubdMRW8bJ+vh > MARovgRnUlAc6paeVdNrNi/FCfstT7W9Ht6Ep5zAZofFuEYZ4yLYbM16RAQQSmp7 > p8m0zqRVXVtMnzRtzyq+V140bqZOJHgA4kyzuFW07IKLmaAGwqKswX0YXKCnyx7G > yTY57Q/P/NtcOQeeTDzBH63/Idi/ba2Ysq0zRRQ40E+ItYEeOGCuS+B5SWN+PEhf > qDo7Rxdv0SFI6H2vK8ePuTT41/I+MIq6QuKWxC4cC5oBAphyKn9oeNtH0FyvY+Sc > WV36yBQJWl2dHtTBslcTL+MdhZbRIDApZH5iPsLTMHRMXtksMI/ZVVRHQh4T7iuK > AmwQbaPH+Y9y/SPW4/9c+Fcya81vhDXxqtoYVwJtpEG9pA8f7L2dx2WWpewOSv1W > +rCW/b1S6CRZNxVLxt7x > =R99I > -END PGP SIGNATURE- > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: libravatar in Fedora OpenShift
Hi Michal, On 08/01/2018 08:07 AM, Michal Novotny wrote: > Hello, > > I would like to ask if anyone is willing to sponsor running libravatar ( > https://git.linux-kernel.at/oliver/ivatar) in Fedora OpenShift per > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/requestforresources.html. > I think we could use the automatic deployment options that OpenShift offers > (Git update -> OpenShift pod update) to our advantage. OpenShift is also > the platform where the current development instance runs > http://ivatar-ivatar.1d35.starter-us-east-1.openshiftapps.com/. If I remember correctly I read somewhere that libravatar is not being decommissioned after all. Is this RFR still relevant then? If yes then I can probably sponsor it. -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/R4KH4QSJDOWATORSFTNBBYNUKETA5SVR/
Staging Koji sync
Tomorrow (Friday August 17) around 16:00 UTC I would like to start sync staging Koji with production to fix issues like [1]. Does anyone have any objections? [1] https://pagure.io/fedora-infrastructure/issue/7136 -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/I3XL4REL2ERIXTIHEPH7ULMB3H37DFMH/
Re: [PATCH] mbs: remove gcc/gcc-c++ from buildroot
Thanks, I've pushed it and ran MBS playbook.
On 07/10/2018 11:51 AM, ignatenkobr...@fedoraproject.org wrote:
> From: Igor Gnatenko
>
> References: https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> Signed-off-by: Igor Gnatenko
> ---
> .../files/default-modules.production/platform-f29.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
> a/roles/mbs/common/files/default-modules.production/platform-f29.yaml
> b/roles/mbs/common/files/default-modules.production/platform-f29.yaml
> index f3455313a..fabc655ef 100644
> --- a/roles/mbs/common/files/default-modules.production/platform-f29.yaml
> +++ b/roles/mbs/common/files/default-modules.production/platform-f29.yaml
> @@ -6,15 +6,15 @@ data:
>profiles:
> buildroot:
>rpms: [bash, bzip2, coreutils, cpio, diffutils, fedora-release,
> findutils, gawk,
> -gcc, gcc-c++, grep, gzip, info, make, patch, redhat-rpm-config,
> rpm-build,
> -sed, shadow-utils, tar, unzip, util-linux, which, xz]
> +grep, gzip, info, make, patch, redhat-rpm-config, rpm-build, sed,
> shadow-utils,
> +tar, unzip, util-linux, which, xz]
> srpm-buildroot:
>rpms: [bash, fedora-release, fedpkg-minimal, gnupg2,
> redhat-rpm-config, rpm-build,
> shadow-utils]
>stream: f29
>summary: Fedora 29 traditional base
>context: 0000
> - version: 4
> + version: 5
>xmd:
> mbs:
>buildrequires: {}
>
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/VIWMKJFM5JM42ROVMDBLDDL7ZHKZRXMP/
Re: IRC oncall
On 05/16/2018 07:23 PM, Kevin Fenzi wrote: >> If I recall, alerts are pretty easily accessible. You can poke around on >> Nagios if there are issues. Obviously if everything is down/red, it's not a >> good time to ask for help with your ssh access. > > Indeed. Yep. Nagios is pretty available to all. > > I can try and make sure I note exactly what I am doing to clear an > alert... sometimes I am bad about saying "fixing that" or "poking that" > without saying what exactly is going on. That's a good idea, and I noticed you already started doing this, thanks Kevin. To expand a bit on this, I logged/explained in more detail [1] what I did when working on one random issue. Since it was in staging, I could take some time to copy relevant commands and write down my thought process. Apprentices, if comments like this are useful, please let me know. [1] https://pagure.io/fedora-infrastructure/issue/6918#comment-512552 -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: [PATCH] Add version 1.2.0 of Fedora Bootstrap
On 05/06/2018 09:54 PM, Kevin Fenzi wrote: > On 05/02/2018 03:30 AM, Ryan Lerch wrote: >> This patch adds version 1.2.0 of fedora bootstrap into apps.fp.o/global for >> use in Fedora apps. >> >> This version of Fedora bootstrap uses the stable 4.0.0 release of Bootstrap. > > Applied. :) And I've just ran proxies playbook to have it deployed in production. -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR - Fixing OSBS build
+1
On 04/27/2018 02:02 PM, Clement Verna wrote:
> Currently OSBS builds are failing because of the kerberos
> configuration not been up-to-date.
>
> I would like to add the following to the osbs-playbook, this will make
> sure that the buildroot container is rebuild using the latest
> krb5.conf file.
>
> +1 ?
>
> diff --git a/files/osbs/buildroot-Dockerfile-production.j2
> b/files/osbs/buildroot-Dockerfile-production.j2
> index 70b556380..3ac044d32 100644
> --- a/files/osbs/buildroot-Dockerfile-production.j2
> +++ b/files/osbs/buildroot-Dockerfile-production.j2
> @@ -2,7 +2,8 @@ FROM registry.fedoraproject.org/fedora
> ADD ./infra-tags.repo /etc/yum.repos.d/infra-tags.repo
> RUN dnf -y install --refresh dnf-plugins-core && dnf -y install
> docker git python-setuptools e2fsprogs koji python-backports-lzma
> osbs-client python-osbs-client gssproxy fedpkg python-docker-squash
> atomic-reactor python-atomic-reactor* go-md2man
> RUN dnf -y install --refresh python2-productmd python3-productmd
> libmodulemd python2-gobject python3-gobject python2-modulemd
> python3-modulemd python2-pdc-client python3-pdc-client
> -RUN sed -i 's|.*default_ccache_name.*| default_ccache_name =
> DIR:/tmp/ccache_%{uid}|g' /etc/krb5.conf
> +ADD ./krb5.conf /etc
> +RUN printf '[libdefaults]\n default_ccache_name =
> DIR:/tmp/ccache_%{uid}' >/etc/krb5.conf.d/ccache.conf
> ADD ./krb5.osbs_{{osbs_url}}.keytab /etc/
> ADD ./ca.crt /etc/pki/ca-trust/source/anchors/osbs.ca.crt
> RUN update-ca-trust
> diff --git a/playbooks/groups/osbs-cluster.yml
> b/playbooks/groups/osbs-cluster.yml
> index 77d9a941c..4c09307ae 100644
> --- a/playbooks/groups/osbs-cluster.yml
> +++ b/playbooks/groups/osbs-cluster.yml
> @@ -795,6 +795,14 @@
>notify:
> - buildroot container
>
> +- name: Upload krb5.conf for buildroot container
> + template:
> +src: "{{ ansible }}/roles/base/templates/krb5.conf.j2"
> +dest: "/etc/osbs/buildroot/krb5.conf"
> +mode: 0644
> + notify:
> +- buildroot container
> +
> - name: Upload internal CA for buildroot
>copy:
> src: "{{private}}/files/osbs/{{env}}/osbs-internal.pem"
> _______
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Freeze Break Request: more new sync changes
+1
On 04/27/2018 04:17 AM, Kevin Fenzi wrote:
> Forgot the Everything dir in the last one:
>
>> diff --git a/roles/bodhi2/backend/files/new-updates-sync
>> b/roles/bodhi2/backend/files/new-updates-sync
>> index 21600c7..fba2a3d 100755
>> --- a/roles/bodhi2/backend/files/new-updates-sync
>> +++ b/roles/bodhi2/backend/files/new-updates-sync
>> @@ -33,9 +33,9 @@ RELEASES = {'f28': {'topic': 'fedora',
>> {'ref': 'fedora/28/x86_64/workstation',
>> 'dest': ATOMICDEST}],
>> 'to': [{'arches': ['x86_64', 'armhfp', 'aarch64',
>> 'source'],
>> -'dest': os.path.join(FEDORADEST, '28')},
>> +'dest': os.path.join(FEDORADEST, '28',
>> 'Everything')},
>> {'arches': ['i386', 'ppc64', 'ppc64le',
>> 's390x'],
>> -'dest': os.path.join(FEDORAALTDEST, '28')}
>> +'dest': os.path.join(FEDORAALTDEST, '28',
>> 'Everything')}
>>]},
>>'updates-testing': {
>> 'from': 'f28-updates-testing',
>
> +1s?
>
> kevin
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR MBS: Fix traceback when reusing components from module build with different buildrequires.
+1
On 04/20/2018 08:36 AM, Jan Kaluža wrote:
> Hi,
>
> this is FBR to fix MBS traceback which prevents builds of modules in
> situation when new build-require is added to a module Foo. Currently, MBS
> tries to check what was the commit hash ("ref") of such buildrequired module
> in previous build of Foo, but it fails with KeyError, because the previous
> Foo module build did not build-required this newly added build-required
> module.
>
> Full traceback is here:
>
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/site-packages/module_build_service/scheduler/consumer.py",
> line 240, in process_message
> further_work = handler(conf, session, msg) or []
> File
> "/usr/lib/python2.7/site-packages/module_build_service/scheduler/handlers/modules.py",
> line 292, in wait
> if attempt_to_reuse_all_components(builder, session, build):
> File
> "/usr/lib/python2.7/site-packages/module_build_service/utils/reuse.py", line
> 140, in attempt_to_reuse_all_components
> previous_module_build = _get_reusable_module(session, module)
> File
> "/usr/lib/python2.7/site-packages/module_build_service/utils/reuse.py", line
> 123, in _get_reusable_module
> ref2 = old_xmd['mbs']['buildrequires'][br_module_name].get('ref')
> KeyError: 'platform'
>
> Fixed patch [1] addresses this by catching the KeyError in this code block.
> It has been tested on staging and I verified it fixes this issue.
>
> [1]
> https://src.fedoraproject.org/rpms/module-build-service/c/9d3a4923631efca2f9e7e3baf6b1bf15294d66fd?branch=epel7
>
> Regards,
> Jan Kaluza
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: [PATCH] change FAW redirects to point to new unified repo
On 03/07/2018 09:38 PM, Dusty Mabe wrote: > --- > roles/download/files/httpd/dl.fedoraproject.org/rewrite.conf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/roles/download/files/httpd/dl.fedoraproject.org/rewrite.conf > b/roles/download/files/httpd/dl.fedoraproject.org/rewrite.conf > index 02611de6a..cd5be3372 100644 > --- a/roles/download/files/httpd/dl.fedoraproject.org/rewrite.conf > +++ b/roles/download/files/httpd/dl.fedoraproject.org/rewrite.conf > @@ -7,6 +7,6 @@ RewriteRule ^/$ /pub [R=302,L] > > RedirectMatch 302 ^/pub/fedora/linux/atomic/(.*$) > https://kojipkgs.fedoraproject.org/atomic/$1 > RedirectMatch 302 ^/pub/fedora/linux/atomic > https://kojipkgs.fedoraproject.org/atomic/ > -Redirect 302 "/ostree/27" > "https://kojipkgs.fedoraproject.org/atomic/workstation; > -Redirect 302 "/pub/ostree/27" > "https://kojipkgs.fedoraproject.org/atomic/workstation; > +Redirect 302 "/ostree/27" "https://kojipkgs.fedoraproject.org/atomic/repo; > +Redirect 302 "/pub/ostree/27" > "https://kojipkgs.fedoraproject.org/atomic/repo; +1 -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: congrats to Mikolaj Izdebski
On 02/06/2018 09:04 PM, Kevin Fenzi wrote: > I'm happy to announce that We have approved Mikolaj into the > sysadmin-main group. > > This is the core group of trusted folks that high level access to most > things. He's done great work maintaining koschei, helping us with > jenkins and java things and koji. > > Congrats and use your powers for good! Thank you. I appreciate the trust I've been given and I'll try to be a valuable contributor. -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On 04/25/2017 08:16 PM, Ralph Bean wrote: > On Tue, Apr 25, 2017 at 07:59:46PM +0200, Mikolaj Izdebski wrote: >> On 04/25/2017 07:48 PM, Ralph Bean wrote: >>> On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote: >>>> On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote: >>>>> - Store koshei integration flag >>>>> - store this in a yaml/toml file in the dist-git repo >>>>> - let the consumers >>>>> - do an http request to retrieve the file >>>>> - listen to fedmsg to catch changes to this file (and update a local >>>>> cache based on this) >>>> >>>> Do you mean separate yaml/toml file per package/collection, stored in >>>> dist-git branch, right next to spec file? >>> >>> Yeah. We would introduce some yaml/toml file alongside the spec file >>> in git, in branch. >>> >>> We figured it could be done one of a few different ways: >>> >>> - Consumers could only consider the 'master' branch. Whatever is in >>> rawhide is true for the package across the other branches. >>> - Consumers could consider each branch independently. This could let >>> koschei have new fine-grained on/off values for different releases. >>> Not sure if that's something we actually want, though. >> >> One problem I can see with this approach is that only commiters of >> Pagure repo could change the file, while currently any member of >> packager FAS group can change Koschei flag for any package. But that >> could work if provenpackager policy explicitly allowed changing this >> file directly, without filing bugs and waiting for maintainer response. > > True. Also, allowing pull-requests over dist-git with pagure would > help smooth the process. Even if a drive-by packager couldn't set the > flag on their own, they can *almost* set the flag on their own. You are very optimistic about maintainer responsivnes :) My experience shows that there are lots of packages without active maintainers, which are kept alive only by provenpackagers. Koschei is especially useful for this kind of packages as it allows others (usually SIGs or maintainers of dependant packages) to monitor and keep such de-facto-orphaned packages buildable, which prevents their removal from distro. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote: > - Store koshei integration flag > - store this in a yaml/toml file in the dist-git repo > - let the consumers > - do an http request to retrieve the file > - listen to fedmsg to catch changes to this file (and update a local > cache based on this) Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Future of Koschei staging
Hello, So far we've been using staging Koschei for two different things: pre-production deployment testing and to aid development by testing new upstream features and bugfixes (by deploying snapshots). After recent introduction of replication to PostgreSQL databases, we can no longer run some of database migrations without sysadmin-main assistance. Moreover, staning-sync playbook is broken as it worked by dropping and re-creating koschei database. (Note that Koschei *must* be synced after Koji sync, or it will be broken.) I can see two alternative solutions to this problem: Option 1: Switch to "dev-stg-prod" model that some other apps are using. By that I mean creating a separate development environment in cloud, with separate database (and possibly, even separate Koji). Staging would be used only for pre-production deployment testing. Dev instance could be created on-demand, only when actually needed, and terminated afterwards. Option 2: Use separate db for Koschei staging (possibly on one of existing Koschei hosts) without replication enabled. What should be the preferred course of action? -- Mikolaj Izdebski IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: koschei-backend reinstall as Fedora 25
On 11/28/2016 11:19 PM, Kevin Fenzi wrote: > On Mon, 28 Nov 2016 09:59:18 +0100 > Mikolaj Izdebski <mizde...@redhat.com> wrote: > >> Hello, >> >> I would like to reinstall koschei-backend as Fedora 25 (currently it's >> deployed on Fedora 24). This should hopefully fix Nagios warnings >> about high swap usage. >> >> Could someone help me with the following two tasks? >> >> >> 1. Create kickstart kvm-fedora-25-koschei as a copy of kvm-fedora-24, >> with updated repos and doubled size of swap partition? >> >> For security reasons I'm not attaching updated kickstart, >> but here's a "sed" patch instead: >> >> sed -e s/24/25/g -e s/2048/4096/ kvm-fedora-24 >>> kvm-fedora-25-koschei >> >> Alternatively, like Kevin suggested, a generic kvm-fedora-25 could be >> created with 4 GB of swap. > > Yeah, that seems fine to me. I have done this now. ;) Thanks. >> >> 2. Terminate koschei-backend01.stg VM on virthost11 so that I can >> recreate it with Ansible? > > I can do this when you are around to redeploy? Patrick already did this for me. I'm trying to reinstall it right now. Assuming staging reinstall is successful, I will attempt to follow up with production reinstall during today's outage window. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Cert penning, Certs and related
On 10/13/2016 09:34 PM, Kevin Fenzi wrote: >>> * If we are not completely retiring the koji CA, are we replacing >>> it? >> If not retired it has to be replaced, could be certs from freeipa >> that auto renew with certmonger, which i suspect users would like >> better than entering their kerberos password once a day. > > well, we can adjust the kerberos settings. If they can renew for a week > would that be sufficent? Couldn't users simply generate keytab for themselves? Koji client supports keytabs directly (via setting in koji.conf or --keytab param), for other services it should be possible to run "kinit -k" (which can even be ran from startup stripts, cron etc.) -- Mikolaj Izdebski IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
koschei-backend reinstall as Fedora 25
Hello, I would like to reinstall koschei-backend as Fedora 25 (currently it's deployed on Fedora 24). This should hopefully fix Nagios warnings about high swap usage. Could someone help me with the following two tasks? 1. Create kickstart kvm-fedora-25-koschei as a copy of kvm-fedora-24, with updated repos and doubled size of swap partition? For security reasons I'm not attaching updated kickstart, but here's a "sed" patch instead: sed -e s/24/25/g -e s/2048/4096/ kvm-fedora-24 >kvm-fedora-25-koschei Alternatively, like Kevin suggested, a generic kvm-fedora-25 could be created with 4 GB of swap. 2. Terminate koschei-backend01.stg VM on virthost11 so that I can recreate it with Ansible? Thanks, -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Memory on koschei-backend01.phx2
On 11/16/2016 04:17 PM, Kevin Fenzi wrote: > On Wed, 16 Nov 2016 14:17:46 +0100 > Mikolaj Izdebski <mizde...@redhat.com> wrote: > >> Michael Simacek pointed out that koschei-backend01.phx2 has 20 GB of >> physical memory, while Ansible inventory vars specify only 4 GB. >> >> Does anyone know where this difference comes from? Did anyone increase >> VM settings without committing them to Ansible git repo? If so, what >> was the reason? > > It might have been me... bumping the memory up to see if it helped it > with memory usage. ;( But usually when I make those changes, I also > make them in ansible, and I don't recall making this one, so perhaps it > was someone else. ;( That won't help much with swap usage by itself. We are limiting RSS for systemd services, any virtual memory beyond limit (currently 3 GB) is swapped to disk. So it ends up with swap usage above 80 %, but mostly free physical memory - below 25 %. > Anyhow, the way we setup hosts in ansible they have the memory they are > set for in vars, and also we set max_memory to 5* that value. ie, this > host was set for 4GB memory, so max was 20GB and it was dynamically > increased to that. Right, now I remember seeing this. > Shall I decrease it back to 4GB? (That may need a reboot). Not needed right now. I'll be reinstalling it as Fedora 25 after GA. When reinstalling I would like to add more swap (4 GB instead of 2 GB; that would require a custom kickstart, IIUC) and set max_mem_size to 4 GB. Any reason not to do this? Thanks, -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Memory on koschei-backend01.phx2
Michael Simacek pointed out that koschei-backend01.phx2 has 20 GB of physical memory, while Ansible inventory vars specify only 4 GB. Does anyone know where this difference comes from? Did anyone increase VM settings without committing them to Ansible git repo? If so, what was the reason? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: How to use fresh module on mock build
First, wrong list - this question should go to devel@ On 07/26/2016 12:04 PM, Jun Aruga wrote: > Today I tried to build rubygem-uglifier package depending on rubygem-execjs. > > On scratch build (Koji), new version is used. > https://kojipkgs.fedoraproject.org//work/tasks/1471/15021471/root.log > rubygem-execjs.noarch 2.7.0-1.fc25 > > However on mock build, old version still is used. Try mock --enablerepo local ... -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Planned Outage: fedorainfracloud.org - 2016-07-22 02:00 UTC
On 07/22/2016 10:17 AM, Vít Ondruch wrote: > If it had been planned, why it was announced just like 3h in advance? :/ I think that there is a difference between "planned" and "scheduled" outage. "Planned outages are interruptions prearranged on relatively short notice. Scheduled outages are routine interruptions planned well in advance such as those scheduled for routine maintenance or inspection of equipment." (quote from [1], but I think it is relevant for computer systems too.) [1] https://www.energyvortex.com/energydictionary/planned_outage__unplanned_outage__scheduled_outage.html -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Kickstart for Fedora 24 KVM guest
WHich kickstart file should I use for installing a Fedora 24 KVM guest? I would like to reinstall koschei-backend as Fedora 24 (for now just staging). Currently it is running on Fedora 23 and it's using kvm-fedora-23 kickstart [1]. There is no generic kvm-fedora-24, only openqa and taskotron variants. [1] http://10.5.126.23/repo/rhel/ks/kvm-fedora-23 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Planned Outage: Koschei update - 2016-05-12 15:00 UTC
Planned Outage: Koschei update - 2016-05-12 15:00 UTC There will be an outage starting at 2016-05-12 15:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2016-05-12 15:00 UTC' Reason for outage: Koschei will be updated to newer upstream version and reinstalled on new machines. Affected Services: Koschei - continuous integration system Services not listed are not affected by this outage. Contact Information: mizdebsk, msimacek Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5287 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: February status update for Fedora Infrastructure Apprentices
On 02/02/2016 12:36 AM, Kevin Fenzi wrote: > 0. Whats your fedora account system login? mizdebsk > 1. Have you logged in and used your fi-apprentice membership to look at > our machines/setup in the last month? Do you plan to? Yes, I did and I do. > 2. Has it helped you decide any area you wish to focus on or contribute > to more? No. > 3. Have you looked at or been able to work on any of the fi-apprentice > 'easyfix' tickets? > https://fedorahosted.org/fedora-infrastructure/report/14 Not in the past month. > 4. Do you still wish to be a member of the group? If not (for whatever > reason) could you provide any hints to help others down the road? Yes, I do. > 5. Is there any help or communication or ideas you have that would help > you do any of the above? No. > 6. What do you find to be the hardest part of getting involved? > Finding things to work on? Getting attention from others to help you? > Finding tickets in your interest area? Getting access to relevant systems. > 7. Have you been able to make any weekly irc meetings? Do you find them > helpful or interesting? Not in the past month. > 8. Have you logged into our Gobby instance and read/seen/added to our > meeting agenda? https://fedoraproject.org/wiki/Gobby Recently no. > 9. What will you spend leap day on this year? (2016-02-29) Work, just like any other ordinary day. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: December status update for Fedora Infrastructure Apprentices
Sorry for late reply, but I was on vacation. On 12/03/2015 09:03 PM, Kevin Fenzi wrote: > 0. Whats your fedora account system login? mizdebsk > 1. Have you logged in and used your fi-apprentice membership to look at > our machines/setup in the last month? Do you plan to? Yes, I have. > 2. Has it helped you decide any area you wish to focus on or contribute > to more? No. > 3. Have you looked at or been able to work on any of the fi-apprentice > 'easyfix' tickets? > https://fedorahosted.org/fedora-infrastructure/report/14 No, I didn't have time to do that. > 4. Do you still wish to be a member of the group? If not (for whatever > reason) could you provide any hints to help others down the road? Yes, I do. > 5. Is there any help or communication or ideas you have that would help > you do any of the above? No. > 6. What do you find to be the hardest part of getting involved? > Finding things to work on? Getting attention from others to help you? > Finding tickets in your interest area? Getting access to relevant systems (and finding time :) > 7. Have you been able to make any weekly irc meetings? Do you find them > helpful or interesting? Yes, and yes. > 8. Have you logged into our Gobby instance and read/seen/added to our > meeting agenda? https://fedoraproject.org/wiki/Gobby Not in the past month - I didn't have anything to add to agenda. > 9. Did you know that we are going to be doing a 'technical debt > cleanup' week on 2016-01-06 to 2016-01-09? See: > https://fedoraproject.org/wiki/Infrastructure/Debt > and come join us. Yes, I do - It was discussed on Flock in Rochester. -- Mikolaj Izdebski ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: November status update for Fedora Infrastructure Apprentices
On 11/04/2015 09:37 PM, Kevin Fenzi wrote: > 0. Whats your fedora account system login? mizdebsk > 1. Have you logged in and used your fi-apprentice membership to look at > our machines/setup in the last month? Do you plan to? Yes I have and I do plan to. > 2. Has it helped you decide any area you wish to focus on or contribute > to more? No, it has not. > 3. Have you looked at or been able to work on any of the fi-apprentice > 'easyfix' tickets? > https://fedorahosted.org/fedora-infrastructure/report/14 Not recently. > 4. Do you still wish to be a member of the group? If not (for whatever > reason) could you provide any hints to help others down the road? Yes, I do. > 5. Is there any help or communication or ideas you have that would help > you do any of the above? No. > 6. What do you find to be the hardest part of getting involved? > Finding things to work on? Getting attention from others to help you? > Finding tickets in your interest area? Getting access > > 7. Have you been able to make any weekly irc meetings? Do you find them > helpful or interesting? Yes, I attend most of the meetings and read IRC logs if I can't attend. They are helpful. > 8. Have you logged into our Gobby instance and read/seen/added to our > meeting agenda? https://fedoraproject.org/wiki/Gobby Not in the past month, but I have logged in there before. > 9. Did you know that we are having an apprentice work day on November > 18th? Will you be able to stop by and talk with us then and get more > involved? Yes, but I was hoping for more challenging tasks than updating docs or adding CSI vars :) Maybe some easyfix tickets -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/infrastructure@lists.fedoraproject.org
Re: [PATCH] koji directory cleanup: shorten the time we keep things
On 10/26/2015 10:13 AM, Vít Ondruch wrote: > Dne 23.10.2015 v 23:18 den...@ausil.us napsal(a): >> keep koschei builds for 1 day > > This is really short period. If the build fails Friday evening, it is > already long time lost Monday morning when I would like to check what > went wrong Definitely agreed. So short Koschei log life time very negatively affects Koschei users. Logs should be kept much longer than one day (at least 1 week IMHO). Note that Koschei users care mostly just about logs. You can remove RPMs as soon as you want, or even not store them at all, which I proposed this as a Koji enhancement long time ago: https://fedorahosted.org/koji/ticket/284 AFAIK this is a problem with lack of i-nodes on NetApp. Has anyone considered increasing available i-node instead of this patch? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/infrastructure@lists.fedoraproject.org
Re: [release] fedmsg: 0.16.2
On 10/08/2015 04:28 PM, Ralph Bean wrote: > > 0.16.2 > -- > > This release fixes a couple of errors that periodically get raised from calls > to `fedmsg.tail_messages(...)`. > > Pull Requests > > - (@ralphbean) #354, Try three times to get the CRL. > https://github.com/fedora-infra/fedmsg/pull/354 > - (@ralphbean) #356, Stop yielding None values from fedmsg.tail_messages. > https://github.com/fedora-infra/fedmsg/pull/356 Thanks. Could you add fixed packages to infra repo? One of the above bug breaks Koschei in production and I would like to fix that ASAP by upgrading to fedmsg 0.16.2. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/infrastructure@lists.fedoraproject.org
Re: October status update for Fedora Infrastructure Apprentices
On 10/01/2015 06:56 PM, Kevin Fenzi wrote: > 0. Whats your fedora account system login? mizdebsk > 1. Have you logged in and used your fi-apprentice membership to look at > our machines/setup in the last month? Do you plan to? Yes, I have and I do plan to keep doing that. > 2. Has it helped you decide any area you wish to focus on or contribute > to more? No. > 3. Have you looked at or been able to work on any of the fi-apprentice > 'easyfix' tickets? > https://fedorahosted.org/fedora-infrastructure/report/14 No, not in the past month. > 4. Do you still wish to be a member of the group? If not (for whatever > reason) could you provide any hints to help others down the road? Yes, I do. > 5. Is there any help or communication or ideas you have that would help > you do any of the above? No. > 6. What do you find to be the hardest part of getting involved? > Finding things to work on? Getting attention from others to help you? > Finding tickets in your interest area? Getting access to relevant systems. > 7. Have you been able to make any weekly irc meetings? Do you find them > helpful or interesting? Yes, I have. They are interesting and helpful. > 8. Have you logged into our Gobby instance and read/seen/added to our > meeting agenda? https://fedoraproject.org/wiki/Gobby Yes, I added my own announcements and agenda items to Gobby several times. > 9. If you could have the power to become invisible OR the power to read > minds, which would you choose? Neither :) -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org
Re: [release] pkgdb2: 1.28
On 09/02/2015 09:37 AM, Pierre-Yves Chibon wrote: > Good morning everyone, > > I just cut a new pkgdb2 release: 1.28 > > Here is its changelog: > * Wed Sep 02 2015 Pierre-Yves Chibon <pin...@pingoured.fr> - 1.28-1 > - Update to 1.28 > - Add koschei integration > > As you can see small changelog but nice feature added :) > > This is currently running in stg: > https://admin.stg.fedoraproject.org/pkgdb/package/python-pymilter/ Thanks. Koschei-side feature is deployed to staging too and is testable. Koschei listens to pkgdb's fedmsg, so it should see changes to tracking flag immediately. It is no longer possible to add packages through Koschei's web UI - this must be done through pkgdb now. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org
Re: September status update for Fedora Infrastructure Apprentices
On 09/01/2015 05:39 PM, Kevin Fenzi wrote: > 0. Whats your fedora account system login? mizdebsk > 1. Have you logged in and used your fi-apprentice membership to look at > our machines/setup in the last month? Do you plan to? Yes. > 2. Has it helped you decide any area you wish to focus on or contribute > to more? No. > 3. Have you looked at or been able to work on any of the fi-apprentice > 'easyfix' tickets? > https://fedorahosted.org/fedora-infrastructure/report/14 Yes. > 4. Do you still wish to be a member of the group? If not (for whatever > reason) could you provide any hints to help others down the road? Yes. > 5. Is there any help or communication or ideas you have that would help > you do any of the above? No. > 6. What do you find to be the hardest part of getting involved? > Finding things to work on? Getting attention from others to help you? > Finding tickets in your interest area? Getting access to relevant systems. > 7. Have you been able to make any weekly irc meetings? Do you find them > helpful or interesting? Yes. > 8. Have you logged into our Gobby instance and read/seen/added to our > meeting agenda? https://fedoraproject.org/wiki/Gobby Yes. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org
Re: Jenkins migration to new cloud
Jenkins migration took longer than expected, but it is mostly complete. The new instance is running at: http://jenkins.fedorainfracloud.org/, but the old domain (jenkins.cloud.fedoraproject.org) is also usable. I have removed old Jenkins config from ansible. The following cloud instances are still running, but they can be terminated now: - 209.132.184.153 (master, old cloud) - 209.132.184.165 (el6 slave, old cloud) - 209.132.184.137 (el7 slave, old cloud) - 209.132.184.59 (f22 slave, new cloud) Known significant differences from old Jenkins: 1) Any changes that were not it ansible are lost. I have seen several things that were not in ansible, but I didn't make any attempts to reverse-engineer them. Of course it is possible to re-add non-ansiblized features that were lost during migration. 2) The following plugins were installed on old instance, but are not installed on new Jenkins (I think they were not used by anything): - jenkins-bazaar-plugin - jenkins-chucknorris-plugin - jenkins-cvs-plugin - jenkins-instant-messaging-plugin - jenkins-ldap-plugin - jenkins-mercurial-plugin Known problems: 1) Login does not work when visiting Jenkins from old domain name (jenkins.cloud.fedoraproject.org). To login you need to use the new domain name. This will be fixed by adding redirect to new domain. 2) Python code coverage generation is not working for some reason. It is under investigation. This problem affects blockerbugs project. 3) Fedmsg sending and receiving is not working. I need help from sysadmin-main member with generating fedmsg certificate, running proxies playbook and possibly more things. During migration I had to apply 2 workarounds: 1) yumrepos.yml installs and enables EPEL only on RHEL, but not on CentOS. Workaround: I installed epel-release and enabled epel repo manually. I believe this should be fixed properly by installing EPEL also on CentOS hosts. 2) python-fedora depends on python-munge, which is not available in EPEL 6. Workaround: I've manually installed python-munge from dist-6E-epel-testing: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7687 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org
Re: Jenkins in new cloud - status update
On 07/30/2015 09:11 PM, Kevin Fenzi wrote: Deployment details: There are: 1 master and 3 slaves (workers) running in the new cloud. All instances are of type m1.small (1 CPU, 2 GB RAM, 20 GB disk). In the old cloud some of the builders were bigger, should we bump these up some when we move to production? I will check instances on the old cloud, now I should be able to access them. I wanted to avoid unnecessary resource consumption, given that this is only dev instance. Only members of sysadmin-jenkins group have admin access through web interface. Should sysadmin-main be added there too? We could, but I think all the sysadmin-main folks that are interested are already in sysadmin-jenkins and/or we could add them easily. Ok, I'll leave it as-is (sysadmin-jenkins only). Subversion plugin is currently disabled due to unresolved problem. Projects using subversion SCM (if any) won't work until this is fixed. Do we have any SVN projects in the old cloud? I don't know, but there is subversion plugin installed. I'm sure there is room for improvement - removing unneeded plugins and slave packages, but I didn't manage to do that yet, give the short deadline. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Jenkins in new cloud - status update
On 07/30/2015 07:46 PM, Joshua hoblitt wrote: On 07/30/2015 10:39 AM, Mikolaj Izdebski wrote: Jenknis runs as unprivileged user, so it can't listen on port 80 - it listens on port 8080. Old Jenkins was running httpd proxy, which forwarded incoming requests from port 80 to 8080. New Jenkins forwards ports using netfilter (aka iptables). Was there any other reason for running httpd proxy? At $day_job, I've been using nginx as a reverse proxy in front of the jenkins master to handle TLS termination and inject HTTP headers (HSTS, key pinning). In theory, it also allows us to show a help page instead of timeout / negative http status codes from jenkins during a restart or other problem. That's a good point. It may be worth to have similar setup for Fedora Jenkins. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Jenkins in new cloud - status update
Overall status: most of things are configured and working. New Jenkins should be ready for data migration from old instance. I've migrated two projects for now and they seem to be working. Deployment details: There are: 1 master and 3 slaves (workers) running in the new cloud. All instances are of type m1.small (1 CPU, 2 GB RAM, 20 GB disk). master: jenkins.fedorainfracloud.org (Fedora 22) slaves: jenkins-slave-el6.fedorainfracloud.org (Centos 6.6) jenkins-slave-el7.fedorainfracloud.org (RHEL 7.1) jenkins-slave-f22.fedorainfracloud.org (Fedora 22) Some notes or questions, in random order: Slaves have public IP assigned. It's not needed by Jenkins itself, but I think it is required to be able to manage them through ansible. Master is running official jenkins package from Fedora 22, with several core plugins also from Fedora. Plugins which were not available in Fedora are packaged in Copr repo and installed as RPMs too. Packages in Copr are just wrappers around upstream binaries - they are not built from source in Copr. Jenknis runs as unprivileged user, so it can't listen on port 80 - it listens on port 8080. Old Jenkins was running httpd proxy, which forwarded incoming requests from port 80 to 8080. New Jenkins forwards ports using netfilter (aka iptables). Was there any other reason for running httpd proxy? Only members of sysadmin-jenkins group have admin access through web interface. Should sysadmin-main be added there too? Subversion plugin is currently disabled due to unresolved problem. Projects using subversion SCM (if any) won't work until this is fixed. Slaves have the same set of extra packages installed as in the old cloud. Like in the old Jenkins instance, jenkins user is member of mock group, which opens possibility for arbitrary code execution on any of Jenkins hosts (on slaves as root, on master as jenkins user) for anyone with write access to any project. I'm not saying it's necessairly a problem, but I wanted to point it out clearly. Current Jenkins master doesn't have persistent storage, but I would like to add it when moving to production. Any questions or comments? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Installing fedora-packager on arm-packager hosts
On 07/14/2015 08:03 PM, Mikolaj Izdebski wrote: On 07/14/2015 07:06 PM, Kevin Fenzi wrote: You want to commit the changes to ansible? I'd be happy to run the playbooks. Sure, I'll commit it to ansible later this week if no one has any objections. Change pushed to ansible repo: http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=f11545e -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Installing fedora-packager on arm-packager hosts
On 07/14/2015 07:06 PM, Kevin Fenzi wrote: You want to commit the changes to ansible? I'd be happy to run the playbooks. Sure, I'll commit it to ansible later this week if no one has any objections. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Jenkins migration to the new cloud
Status update: Initial Jenkins master and slave instances are deployed in the new cloud, thanks to Kevin. Currently jenkins service is stopped to prevent abuse as security is not yet configured due to missing OpenID plugin. I've packaged jenkins-openid-plugin for Fedora. You can help by reviewing the package and its dependency: https://bugzilla.redhat.com/show_bug.cgi?id=1236224 https://bugzilla.redhat.com/show_bug.cgi?id=1236225 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Koschei - new Fedora infrastructure service
I'm glad to announce that as of yesterday Koschei production instance has been moved Fedora infrastructure and now it can be considered as officially-supported Fedora service. Koschei is a continuous integration service for Fedora packages. Koschei is aimed at helping Fedora developers by detecting problems as soon as they appear in rawhide - it tries to detect package FTBFS in rawhide by scratch-building them in Koji. More information can be found at Fedora Wiki [1]. Interested parties can be automatically notified when Koschei detects change in package FTBFS status. In order to subscribe to email or IRC notifications you can follow instructions at [2]. At the time of writing, Koschei monitors about 20 % of all Fedora packages, but anyone with FAS account can add packages they are interested in. See [3] for details how to add packages to Koschei. I would like to thank everybody who helped to make Koschei at Fedora infrastructure possible, especially Kevin Fenzi, who sponsored Koschei request for resources and assisted us with the migration. [1] https://fedoraproject.org/wiki/Koschei [2] https://fedoraproject.org/wiki/Koschei#Notifications [3] https://fedoraproject.org/wiki/Koschei#Adding_packages -- Mikolaj Izdebski ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Jenkins migration to the new cloud
As briefly discussed today during the meeting, I would like to evaluate the possibility to use our packaged Jenkins in Fedora infrastructure, instead of upstream binaries. (Jenkins is available[1] in Fedora 21 and later.) To get started with development of new Jenkins machines I would need someone to create 2 new cloud machines: master with Fedora 22 and with any OS (RHEL 6 would be my choice), each machine with at least 1 CPU, 2 GB RAM, public IP and root access for me (FAS: mizdebsk). From that I will try to come with my proof-of-concept of the new Jenkins. If people like it then old data can be migrated and it can become the new production instance. If not we can just scratch these machines and keep using upstream binaries. So if you don't mind I'd start working on this. Should I open a ticket for creating the new cloud instances? Some more technical notes: 1) It is possible to use third-party plugins with packaged Jenkins, which means that missing plugins can be installed as binary blobs until they are packaged in Fedora. 2) Jenkins RPMs must be installed only on master node. All slave nodes can connect to master and download Jenkins code from there. Slaves still need to have basic environment installed (such as Java, git, mock), but not Jenkins itself. This means that only the master node must be Fedora 21+, slaves can be anything (RHEL 6/7, older Fedoras). 3) Michal Srb is currently looking into packaging Jenkins as software collection for RHEL 6 and 7. Once (and if) done this could allow having RHEL 7 master, with the disadvantage of using unofficial RPMs from softwarecollections.org. This is just the beginning and we can evaluate having non-Fedora master later, if needed. [1] https://fedoraproject.org/wiki/Changes/Jenkins -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: June status update for Fedora Infrastructure Apprentices
On 06/01/2015 04:07 PM, Kevin Fenzi wrote: 0. Whats your fedora account system login? mizdebsk 1. Have you logged in and used your fi-apprentice membership to look at our machines/setup in the last month? Do you plan to? Yes, to both questions. 2. Has it helped you decide any area you wish to focus on or contribute to more? No. 3. Have you looked at or been able to work on any of the fi-apprentice 'easyfix' tickets? https://fedorahosted.org/fedora-infrastructure/report/14 I've looked in the past, but there is nothing for me to work on. 4. Do you still wish to be a member of the group? If not (for whatever reason) could you provide any hints to help others down the road? Yes, I do. 5. Is there any help or communication or ideas you have that would help you do any of the above? I can't think of anything. 6. What do you find to be the hardest part of getting involved? Finding things to work on? Getting attention from others to help you? Finding tickets in your interest area? Getting access to some systems. 7. Have you been able to make any weekly irc meetings? Do you find them helpful or interesting? I've been attending to the meetings, they are both useful and interesting. 8. Have you logged into our Gobby instance and read/seen/added to our meeting agenda? https://fedoraproject.org/wiki/Gobby Yes, I have. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: May status update for Fedora Infrastructure Apprentices
On 05/02/2015 07:44 PM, Kevin Fenzi wrote: 0. Whats your fedora account system login? mizdebsk 1. Have you logged in and used your fi-apprentice membership to look at our machines/setup in the last month? Do you plan to? Yes and yes. 2. Has it helped you decide any area you wish to focus on or contribute to more? No. 3. Have you looked at or been able to work on any of the fi-apprentice 'easyfix' tickets? https://fedorahosted.org/fedora-infrastructure/report/14 No. 4. Do you still wish to be a member of the group? If not (for whatever reason) could you provide any hints to help others down the road? Yes, I do. 5. Is there any help or communication or ideas you have that would help you do any of the above? I can't think of anything. 6. What do you find to be the hardest part of getting involved? Finding things to work on? Getting attention from others to help you? Finding tickets in your interest area? Getting access to affected machines or reproducing the problem locally. 7. Have you been able to make any weekly irc meetings? Do you find them helpful or interesting? Yes to both questions. 8. Have you logged into our Gobby instance and read/seen/added to our meeting agenda? https://fedoraproject.org/wiki/Gobby Yes, I have. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: April status update for Fedora Infrastructure Apprentices
On 04/06/2015 02:32 PM, Kevin Fenzi wrote: 0. Whats your fedora account system login? mizdebsk 1. Have you logged in and used your fi-apprentice membership to look at our machines/setup in the last month? Do you plan to? Yes, I have and I do plan to. 2. Has it helped you decide any area you wish to focus on or contribute to more? No, I already knew the area. 3. Have you looked at or been able to work on any of the fi-apprentice 'easyfix' tickets? https://fedorahosted.org/fedora-infrastructure/report/14 I checked them out, but there were none I would be able work on. 4. Do you still wish to be a member of the group? If not (for whatever reason) could you provide any hints to help others down the road? Yes, I do. 5. Is there any help or communication or ideas you have that would help you do any of the above? No, I can't think of any. 6. What do you find to be the hardest part of getting involved? Finding things to work on? Getting attention from others to help you? Finding tickets in your interest area? There is no easy way to develop and test needed changes. Servers are not easy to replicate locally and there is no way to have write access to Fedora-hosted servers, even stagging or development. 7. Have you been able to make any weekly irc meetings? Do you find them helpful or interesting? Yes, they are both helpful and interesting. 8. Have you logged into our Gobby instance and read/seen/added to our meeting agenda? https://fedoraproject.org/wiki/Gobby Yes I have. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Request to become apprentice
On 01/29/2015 11:32 PM, Kevin Fenzi wrote: On Thu, 29 Jan 2015 22:50:00 +0100 Mikolaj Izdebski mizde...@redhat.com wrote: I would like to become Fedora Infrastructure apprentice. Welcome. ;) [...] What are next steps I need to follow to become apprentice? I've added you to the group, and it should be live in 20-30min. See the apprentice wiki page for a link to the ssh sop to get logged in and look around. Thank you! -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Request to become apprentice
I would like to become Fedora Infrastructure apprentice. I am Mikolaj Izdebski - a Fedora developer, who primarily works in Java SIG on maintaining different Java build systems and libraries. You can find a bit more information about me on my user page [1] on the wiki. My primary interest in infrastructure area is improving infrastructure for Fedora developers, especially ones that work with large number of related or similar packages. This includes topics such as build systems, continuous integration and automated package testing. Some of short-term things I would like to do: * learn more about infra internals (how to use bastion to log into other machines, how Ansible playbooks work in Fedora, how backups are done, and much more) * work on completing Koschei playbook (currently it sets up only basic system, but a lot of other stuff has to be done manually) * migrate Koschei from Fedora 20 to RHEL 7 Long term goals: * make Koschei an official Fedora service (RFR is already filled) What are next steps I need to follow to become apprentice? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk [1] https://fedoraproject.org/wiki/User:Mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [RFR #4562] Koschei - continuous integration in Koji
On 10/16/2014 05:51 PM, Kevin Fenzi wrote: And deps are then checked when something updates in a group and the rest of the group rebuilt? or can you explain when a scratch build is fired? Strictly speaking scratch build is scheduled when all the following conditions are met: * package has the highest priority from all packages known to Koschei, * priority is above some threshold (configurable), * Koji load is below some threshold (configurable, 50 % ATM), * number of currently running Koji taks started by Koschei is below some threshold (also configurable, currently 50 concurrent tasks). Package priority depends on several fatcors (time since last rebuild, dependency changes, package state, package importance and more). For more information about priority see [1]. From higher-level perspective, with current settings package will be rebuilt when: * at least build-dependency changes, or * one week passes since last successful build or scratch build, or * someone (currently only admin) requests immediate rebuild. [1] https://fedoraproject.org/wiki/Koschei#Priority -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [RFR #4562] Koschei - continuous integration in Koji
- listens to fedmsg and updates database accordingly. It makes sense to have only one watcher. polling - periodically asks Koji about statuses of runnig scratch builds and package statuses (this is fallback mechanism necessary in case fedmsg message delivery fails). Only one polling service makes sense as this is only fallback methanism and can be ran every hour or even less often. resolver - resolves build dependencies of all packages when new repo is generated. Dep resolution is a CPU intensive task. Depending on number of packages tracked this may take up to a few hours of CPU time (estimate made for 100,000 pkgs, I'm thinking about future here). Resolver service can be configured to use multiple threads and it should scale linearly. reporter (WSGI webapp running in Apache httpd with mod_wsgi) - provides web UI for users. There can be muiltiple webapps runnig behing some HTTP balancer if needed. Database itself can be load balanced too (we are using PostgreSQL). To sum up, all components either don't need load balancing or can be load-balanced. * Are there any common sysadmin tasks we need to know about with the instance? Is there any special process to start/stop/reinstall it? Installing Koschei is done by installing RPM package from Fedora or EPEL repositories and coping a single config file. Managing all services (starting, stopping, viewing logs etc.) is done using standard system tools (systemctl, journalctl and so on). There is nothing special to be done besides standard sysadmin stuff (updating packages, viewing logs, backing up database and so on). * When there is koji maint, should we stop this service? How do we gracefully do that and start it again? In this case you can stop Koschei services that communicate with Koji (using systemctl stop koschei-servicename) and start them when maintenance is over. Web UI will remain functional during that time, but there will be no new build scheduled. Thats all I can think of right now. :) I hope this pretty long email answers your questions. [1] https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.koschei.package.state.change [2] https://bugzilla.redhat.com/show_bug.cgi?id=1130233 [3] https://fedorahosted.org/koji/ticket/284 [4] https://sochotni.fedorapeople.org/min_install/main.html -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [RFR #4562] Koschei - continuous integration in Koji
On 10/15/2014 10:10 PM, Ralph Bean wrote: On Wed, Oct 15, 2014 at 01:31:57PM -0600, Kevin Fenzi wrote: * How well does it keep up currently? I know you are careful not to overload koji, but I wonder if that means things like perl builds are often behind because there are so many of them? It would be great if there was a way to quantify and monitor this during runtime with both nagios and collectd. I must admit I'm not familliar with nagios or collectd, but we may look into this if that's needed. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
[RFR #4562] Koschei - continuous integration in Koji
Hello, I have just opened a Request for Resource ticket (#4562) for Koschei and I would like it to eventually become an official Fedora service. Please let me know what you think about my proposal. I'm happy to answer any questions and provide more information. [1] http://fedoraproject.org/wiki/Request_For_Resources -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
