Introducing Luiz Carvalho
Hi all, Just an FYI - I've moved off of the Factory 2 team inside Red Hat to take a different role in the internal devops organization there. Luiz Carvalho (lucarval in both FAS and irc) takes my place leading the Factory 2 team! He's a good point of contact for greenwave, MBS, ODCS and freshmaker along with giulia, jkaluza, and mprahl. Say hi in channel sometime. -Ralph p.s., I'll still be around to help out as I can. :) signature.asc Description: 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
Re: FBR - Upgrade MBS
On Fri, Sep 07, 2018 at 03:42:06PM -0400, Ralph Bean wrote: > I'd like to upgrade MBS on either Monday or Tuesday of next week to > module-build-service-2.6.0-1.el7 and libmodulemd-1.6.3-2.el7. > > - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0a7da7520d > - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ee8aeba3a6 > > There is no database migration. It has a few bugfixes and a few new features: > > - MBS can now block the building of a module stream, if its stream is > marked as EOL in PDC (requested by mboddu). > - There's also an important bugfix for sgallagh that allows building > modules that refer to refs of components not under their master > branch - this is related to the libmodulemd update. > > I haven't upgraded staging yet, but would start to do so next week. > > +1 to proceed? Or hold off until after freeze? > > -Ralph Actually, nevermind. I checked with sgallagh on irc and he says the bugfix in there isn't actually blocking anyone atm, so we'll just wait to do the upgrade until after freeze. Thanks all! signature.asc Description: 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
FBR - Upgrade MBS
I'd like to upgrade MBS on either Monday or Tuesday of next week to module-build-service-2.6.0-1.el7 and libmodulemd-1.6.3-2.el7. - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0a7da7520d - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ee8aeba3a6 There is no database migration. It has a few bugfixes and a few new features: - MBS can now block the building of a module stream, if its stream is marked as EOL in PDC (requested by mboddu). - There's also an important bugfix for sgallagh that allows building modules that refer to refs of components not under their master branch - this is related to the libmodulemd update. I haven't upgraded staging yet, but would start to do so next week. +1 to proceed? Or hold off until after freeze? -Ralph signature.asc Description: 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
Re: FBR: Greenwave config update for F29
LGTM. Easy to roll back if it is incorrect. +1 On Tue, Aug 28, 2018 at 10:05:08AM -0400, Mohan Boddu wrote: > diff --git a/roles/openshift-apps/greenwave/templates/configmap.yml > b/roles/openshift-apps/greenwave/templ > index dd297c4..694ca3c 100644 > --- a/roles/openshift-apps/greenwave/templates/configmap.yml > +++ b/roles/openshift-apps/greenwave/templates/configmap.yml > @@ -97,6 +97,7 @@ data: > --- !Policy > id: "taskotron_release_critical_tasks_for_testing" > product_versions: > + - fedora-29 >- fedora-28 >- fedora-27 >- fedora-26 > @@ -114,6 +115,7 @@ data: > --- !Policy > id: "taskotron_release_critical_tasks_for_stable" > product_versions: > + - fedora-29 >- fedora-28 >- fedora-27 >- fedora-26 > @@ -155,6 +157,7 @@ data: > # http://fedoraproject.org/wiki/CI > id: "atomic_ci_pipeline_results" > product_versions: > + - fedora-29 >- fedora-28 >- fedora-27 >- fedora-26 > @@ -174,6 +177,7 @@ data: > # http://fedoraproject.org/wiki/CI > id: "atomic_ci_pipeline_results_stable" > product_versions: > + - fedora-29 >- fedora-28 >- fedora-27 >- fedora-26 > ___ > 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 signature.asc Description: 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
Re: Fwd: Red Hat bugzilla upgrade coming -- test now!
Thanks! FYI, there's a ticket kicking around about it over here, too: https://pagure.io/fedora-infrastructure/issue/7028 On Mon, Jun 25, 2018 at 09:05:26PM -0400, Zach Villers wrote: > Acknowledged Sir! :) > > I'll add it on the meeting agenda this week. > > -- > Zach Villers > z...@mailup.net > > On Mon, Jun 25, 2018, at 9:25 AM, Ralph Bean wrote: > > FWIW, there's a change to the way messaging works with BZ5. > > > > - Messages are published to a different queue. Someone will need to > > update bugzilla2fedmsg to pull from the new right place. > > - The message format changes, but I think it may only be additive. > > Someone should verify that we don't need any further code changes. > > > > -Ralph > > > > - Forwarded message from Matthew Miller - > > > > Date: Thu, 21 Jun 2018 11:26:48 -0400 > > From: Matthew Miller > > To: devel-annou...@lists.fedoraproject.org > > Subject: Red Hat bugzilla upgrade coming -- test now! > > User-Agent: Mutt/1.5.21 (2010-09-15) > > Reply-To: de...@lists.fedoraproject.org > > > > Red Hat is planning on upgrading Bugzilla to BZ5 in September. There's > > a test instance running now at http://bugzilla5.redhat.com/ > > > > Since Fedora is a major user and stakeholder here, it'd be helpful if > > we make sure everything works for us. If you find any bugs, report at > > https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=5.0 > > > > -- > > Matthew Miller > > > > Fedora Project Leader > > ___ > > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > > To unsubscribe send an email to devel-announce- > > 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/devel-annou...@lists.fedoraproject.org/message/ZWVCDPB3CBEJJ5FQOGVFA2RAWWK3NOXK/ > > ___ > > devel mailing list -- de...@lists.fedoraproject.org > > To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org/message/ZWVCDPB3CBEJJ5FQOGVFA2RAWWK3NOXK/ > > > > - End forwarded message - > > ___ > > 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/Z7KK5AXOWPPANAX3EM5EHLDER3QDBYLT/ > > Email had 1 attachment: > > + signature.asc > > 1k (application/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/message/L66TLDGKLN36QKMV4IVWPYFYE6JIXIXP/ signature.asc Description: 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/message/Z6LJJOQO6LBI6MP44EXUWOA2WJDRDTIM/
Fwd: Red Hat bugzilla upgrade coming -- test now!
FWIW, there's a change to the way messaging works with BZ5. - Messages are published to a different queue. Someone will need to update bugzilla2fedmsg to pull from the new right place. - The message format changes, but I think it may only be additive. Someone should verify that we don't need any further code changes. -Ralph - Forwarded message from Matthew Miller - Date: Thu, 21 Jun 2018 11:26:48 -0400 From: Matthew Miller To: devel-annou...@lists.fedoraproject.org Subject: Red Hat bugzilla upgrade coming -- test now! User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: de...@lists.fedoraproject.org Red Hat is planning on upgrading Bugzilla to BZ5 in September. There's a test instance running now at http://bugzilla5.redhat.com/ Since Fedora is a major user and stakeholder here, it'd be helpful if we make sure everything works for us. If you find any bugs, report at https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=5.0 -- Matthew Miller Fedora Project Leader ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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/devel-annou...@lists.fedoraproject.org/message/ZWVCDPB3CBEJJ5FQOGVFA2RAWWK3NOXK/ ___ devel mailing list -- de...@lists.fedoraproject.org To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org/message/ZWVCDPB3CBEJJ5FQOGVFA2RAWWK3NOXK/ - End forwarded message - signature.asc Description: 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/message/Z7KK5AXOWPPANAX3EM5EHLDER3QDBYLT/
Re: Modularity WG + f2 + Infra
On Tue, May 15, 2018 at 05:01:56PM -0700, Kevin Fenzi wrote: > On 05/15/2018 08:08 AM, Randy Barlow wrote: > > Greetings! > > > > At the hackathon we did recently, we talked about the need for one of us > > to attend the Modularity WG meetings so we could be more aware of what > > work is coming our way before it's a surprise, and I volunteered to be > > that person. > > > > For $reasons, today was the first of the WG meetings I was able to > > attend. There were two items of interest: > > > > > > New service > > === > > > > I learned that Factory 2 is developing a new service called Ursa Major. > > I gathered that its mission is to make it so that RPMs that depend on > > modules can get those modules pulled into their buildroot. > > > > Ralph, is the above correct? If so, what time frame do you anticipate us > > needing to get this service deployed to infrastructure? It is kinda correct. We developed ursa-major specifically not-for-Fedora... and now that it exists, folks are asking if we can also use it in Fedora. I have nothing in my current plans (up through F29) to do anything with ursa-major in Fedora.. but, since people have started asking for it I guess we should talk about it. Can I explain it? First, some context on the name: rpms in a module are called "modular" rpms. RPMS not in a module are "bare". Sync "bare" is a homophone with "bear", and "ursine" means relating to or resembling bears, we jokingly call bare rpms "ursine" rpms.. So ursa-major does something with ursine rpms (bare, non-modular rpms). The problem is how to transition from our current mostly-bare-rpms-with-a-few-modules state to a future still-some-bare-rpms-but-with-many-more-modules state. There are some packages in Fedora that make sense to always be in the non-modular core. There are other packages in Fedora that make sense to modularize, of which we should provide multiple parallel versions. There is an intersection between these two groups that ursa-major tries to address: packages which should be modularized, but which are needed *in the buildroot for the non-modular core*. These are things like higher level language stacks which are used to build the docs or run the %check tests of lower level components -- all at build time. The flow: - ursa-major is a script that runs on message bus trigger. - It has a config that defines some set of module streams that should be tagged into the core buildroot. Releng maintains this config, as it affects the whole distro. - When ursa-major fires, it takes a new module (or a module that has passed testing, or which has gone stable) and adds its tag to the tag inheritance of the base build tag - say, the f30-build tag. - Then, when new ursine rpms are built in the traditional way, they have some subset of what would otherwise be modular rpms available. To say again, I have no plans to seek to deploy this atm, but people have started asking for it... so, maybe we need some solution to the problem. It could be this tool or some other tool -- perhaps as a part of Bodhi's workflow: as modules get promoted, a select releng-maintained subset could be tagged into the base tag. > > Meetings > > > > > > The modularity WG suggested that it was probably not that beneficial for > > me to attend their meetings as an infra liason, as they are not actually > > particularly familiar with the infrastructure side of things. They > > suggested instead that we interface with Factory 2. > > Makes sense. > > > A suggestion was made that perhaps we could have an agenda item on *our* > > meeting, perhaps once a month, where we invite modularity WG and factory > > 2 to talk with us about what is coming our way, or about issues that > > need dealing with. I thought this was a fine suggestion, so I wanted to > > ask you all what you thought about it? > > I think thats a fine idea, but do we know who we can contact to invite? > And will we remember? > > Thanks for going to the meeting and keeping us informed! I can come, and bring some others. :) If it is recurring, then a calendar thingie will help make us not forget. I'd say let's not rely only on my team (Factory2) as an intermediary between you guys and the modularity-wg. Let's invite them too. signature.asc Description: 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/message/JZMPGE2VMBHDO4D6SC4YTRSYNQYZOT63/
[release] pdc-updater: 0.9.2
A new release of pdc-updater is out, fixing a bug in the retirement handler. https://pagure.io/fedora-infrastructure/issue/6928 0.9.2 - Pull Requests - #86, Merge pull request #86 from fedora-infra/dont-overwrite https://github.com/fedora-infra/pdc-updater/pull/86 Commits - 65ebd4ad9 Don't overwrite `branch`. https://github.com/fedora-infra/pdc-updater/commit/65ebd4ad9 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Bodhi 3.7.0-0.0.beta deployed to stg
On Wed, May 09, 2018 at 12:12:50PM -0400, Randy Barlow wrote: > On 05/09/2018 12:07 PM, Randy Barlow wrote: > > Aaand it also doesn't work in production. I tested the Greenwave API > > just yesterday and it did return the data that Bodhi looks for. Today > > the exact same query omits the specific data that Bodhi looks for, which > > means that Bodhi does *not* tell users which tests are missing. > > https://pagure.io/greenwave/issue/169#comment-511247 We talked about this in IRC after the fact. Here, the difference was that a user waived the koji_build failure and so greenwave stopped returning it as an unsatisfied requirement. It was satisfied. The greenwave API didn't change on this one. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: no CI requirements for modules
Thanks! This is done now: https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0/policies I fixed two other little things while I was in there: - https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=01d70107fca595715931861e80a7e642f9df191b - https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=a0314660d8e09990b3c5f23dc419e83cdaf48358 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR: no CI requirements for modules
Discussed in #fedora-admin just now. Modules are configure to require some test cases that never actually get run for them. This patch should treat them instead like we do epel: no CI requirements. Any +1s? diff --git a/roles/openshift-apps/greenwave/templates/configmap.yml b/roles/openshift-apps/greenwave/templates/configmap.yml index 44eb013..c88bb9d 100644 --- a/roles/openshift-apps/greenwave/templates/configmap.yml +++ b/roles/openshift-apps/greenwave/templates/configmap.yml @@ -91,7 +91,6 @@ data: --- !Policy id: "taskotron_release_critical_tasks_for_testing" product_versions: - - fedora-28-modular - fedora-28 - fedora-27 - fedora-26 @@ -103,7 +102,6 @@ data: --- !Policy id: "taskotron_release_critical_tasks_for_stable" product_versions: - - fedora-28-modular - fedora-28 - fedora-27 - fedora-26 @@ -113,8 +111,9 @@ data: rules: - !PassingTestCaseRule {test_case_name: dist.rpmdeplint} --- !Policy -id: "no_requirements_for_epel_testing" +id: "no_requirements_testing" product_versions: + - fedora-28-modular - fedora-epel-7 - fedora-epel-6 decision_context: bodhi_update_push_testing @@ -122,8 +121,9 @@ data: relevance_value: koji_build rules: [] --- !Policy -id: "no_requirements_for_epel_stable" +id: "no_requirements_for_stable" product_versions: + - fedora-28-modular - fedora-epel-7 - fedora-epel-6 decision_context: bodhi_update_push_stable signature.asc Description: PGP signature ___ 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 here too. It's easy to revert by downgrading the rpm if it blows up. On Fri, Apr 20, 2018 at 11:42:33AM +0200, Mikolaj Izdebski wrote: > +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 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: enable gating on fedora-27's Atomic CI results
+1 here on either version of the patch. :) ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: any infra apprentices looking for a challenge?
On Sun, Feb 25, 2018 at 12:37:36PM -0500, Dusty Mabe wrote: > > > On 02/23/2018 01:38 PM, Pierre-Yves Chibon wrote: > > On Fri, Feb 23, 2018 at 05:14:38PM +, ajay vembu wrote: > >>Hi Dusty, > >>I will start working on it. I will let you know if I any queries. > > > > Thanks for looking into it, do know that I'm unsure myself how I would > > implement > > it and it will touch a number of systems (pagure, gitolite underneath...), > > it's > > not a small change. > > Yes. Thanks pingou. I should not have pitched this without mentioning it is > quite > a complex change and probably not beginner level. I should not have done that. I would totally use this if it existed. :) Redirects would be clutch, such that all the old URLs to old issues still ended up working for users who clicked them. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
MBS disk usage
Way back in May some of us were in Raleigh for a Hackathon: https://fedoraproject.org/wiki/CI_and_Infrastructure_Hackathon_2017 There, we talked about the MBS and wondered what kind of new storage requirements it would impose on koji. We all worried about it, but we didn't have numbers to figure out how worried we should be. --- Here, below, find a query that Mike McLean shared for the koji database. It very, very roughly shows rpm storage usage per-quarter in koji, with a couple caveats. - It only counts rpm sizes. It doesn't count logs, or signed copied, or isos, or anything like that. - It is also biased towards newer quarters. More recent quarters haven't had time yet for garbage collection to kick in, so while they are larger in magnitude, it needs to be taken in context, with salt, etc. Here's a run:: koji=# select date_trunc('quarter', completion_time) as bin, round(sum(size1)/1073741824, 3) as rpm_gb, round(sum(size2)/1073741824,3) as archive_gb, round(sum(size1+size2)/1073741824, 3) as total_gb from (select build.id, build.completion_time, coalesce((select sum(size) from rpminfo where build_id=build.id),0) as size1, coalesce((select sum(size) from archiveinfo where build_id=build.id),0) as size2 from build where build.state=1 and build.volume_id=0) as data group by date_trunc('quarter', completion_time) order by bin; bin | rpm_gb | archive_gb | total_gb +- 2007-04-01 00:00:00 | 254.416 | 0.000 | 254.416 2007-07-01 00:00:00 | 314.764 | 0.000 | 314.764 2007-10-01 00:00:00 | 317.851 | 0.000 | 317.851 2008-01-01 00:00:00 | 427.718 | 0.000 | 427.718 2008-04-01 00:00:00 | 393.187 | 0.000 | 393.187 2008-07-01 00:00:00 | 404.171 | 0.000 | 404.171 2008-10-01 00:00:00 | 392.340 | 0.000 | 392.340 2009-01-01 00:00:00 | 565.137 | 0.000 | 565.137 2009-04-01 00:00:00 | 349.749 | 0.000 | 349.749 2009-07-01 00:00:00 | 464.736 | 0.000 | 464.736 2009-10-01 00:00:00 | 324.401 | 0.000 | 324.401 2010-01-01 00:00:00 | 331.923 | 0.000 | 331.923 2010-04-01 00:00:00 | 304.823 | 0.000 | 304.823 2010-07-01 00:00:00 | 293.123 | 0.000 | 293.123 2010-10-01 00:00:00 | 262.374 | 0.000 | 262.374 2011-01-01 00:00:00 | 307.806 | 0.000 | 307.806 2011-04-01 00:00:00 | 243.162 | 0.000 | 243.162 2011-07-01 00:00:00 | 239.072 | 0.000 | 239.072 2011-10-01 00:00:00 | 287.522 | 0.000 | 287.522 2012-01-01 00:00:00 | 388.169 | 0.000 | 388.169 2012-04-01 00:00:00 | 347.497 | 0.000 | 347.497 2012-07-01 00:00:00 | 384.210 | 0.000 | 384.210 2012-10-01 00:00:00 | 369.828 | 0.000 | 369.828 2013-01-01 00:00:00 | 522.266 | 0.000 | 522.266 2013-04-01 00:00:00 | 451.709 | 0.000 | 451.709 2013-07-01 00:00:00 | 733.928 | 0.000 | 733.928 2013-10-01 00:00:00 | 551.316 | 0.000 | 551.316 2014-01-01 00:00:00 | 530.781 | 0.000 | 530.781 2014-04-01 00:00:00 | 747.820 | 0.000 | 747.820 2014-07-01 00:00:00 | 1008.080 | 0.000 | 1008.080 2014-10-01 00:00:00 | 665.198 | 0.000 | 665.198 2015-01-01 00:00:00 | 839.060 | 0.000 | 839.060 2015-04-01 00:00:00 | 931.210 | 0.000 | 931.210 2015-07-01 00:00:00 | 887.543 | 0.000 | 887.543 2015-10-01 00:00:00 | 700.465 | 0.000 | 700.465 2016-01-01 00:00:00 | 1189.887 | 152.489 | 1342.376 2016-04-01 00:00:00 | 983.871 | 43.799 | 1027.670 2016-07-01 00:00:00 | 983.195 | 99.737 | 1082.932 2016-10-01 00:00:00 | 1165.745 | 27.005 | 1192.749 2017-01-01 00:00:00 | 1681.824 | 149.185 | 1831.009 2017-04-01 00:00:00 | 1861.706 | 8.289 | 1869.995 2017-07-01 00:00:00 | 2610.738 | 132.464 | 2743.203 2017-10-01 00:00:00 | 2236.426 | 4195.877 | 6432.303 (43 rows) Interesting! Now, let's see the same query, but with the MBS builds *excluded* (the MBS user is userid 3819):: koji=# select date_trunc('quarter', completion_time) as bin, round(sum(size1)/1073741824, 3) as non_mbs_rpm_gb, round(sum(size2)/1073741824,3) as non_mbs_archive_gb, round(sum(size1+size2)/1073741824, 3) as non_mbs_total_gb from (select build.id, build.completion_time, coalesce((select sum(size) from rpminfo where build_id=build.id),0) as size1, coalesce((select sum(size) from archiveinfo where build_id=build.id),0) as size2 from build where build.state=1 and build.volume_id=0 and build.owner!=3819) as data group by date_trunc('quarter', completion_time) order by bin; bin | non_mbs_rpm_gb | non_mbs_archive_gb | non_mbs_total_gb +- 2007-04-01 00:00:00 | 254.416 | 0.000 | 254.416 2007-07-01 00:00:00 | 314.764 | 0.000 | 314.764 2007-10-01 00:00:00 | 317.851 | 0.000 | 317.851 2008-01-01 00:00:00 | 427.718 | 0.000 | 427.718 2008-04-01 00:00:00 | 393.187 | 0.000 | 393.187 2008-
Re: [PATCH] start running f27 atomic/cloud pungi runs
+1 here too. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: Modules and the package list
Thanks! Applied: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=fe795ff8de2615b58a84ef7d80a919a5dad26304 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR: Modules and the package list
Karsten Hopp reported an issue with the MBS that his module builds of modules/krb5 and modules/udisks2 failed, because the MBS failed to tag them into f27-modular-updates-candidate at the end of the build. The module names weren't in the pkg list. I've added them directly to get him going again, but the root is an issue in the pkg list sync script. Here's a patch that should make it work going forwards. Any +1'd for the following fix? (Tested by hand against the udisks2 and krb5 modules. I also checked that the patch doesn't accidentally add the krb5 package to the list for f27 proper, which would be wrong.) diff --git a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 b/roles/bodhi2/backend/templates/owner-sync-pagure.j2 index 6131b13..b3400bf 100755 --- a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 +++ b/roles/bodhi2/backend/templates/owner-sync-pagure.j2 @@ -401,9 +401,13 @@ if __name__ == '__main__': namespace = info['namespace'] pkgs = [] for pkg, branches in namespace_to_projects[namespace].items(): -# The tag and branch names are the same for "old-style" branches if info['branch'] in branches or tag == ('f' + RAWHIDE): +# The tag and branch names are the same for "old-style" branches pkgs.append(pkg) +elif namespace == 'modules': +# Add modules to f27-modular-updates even if their only branch is '2.4' +pkgs.append(pkg) + # This is a special project, not in dist-git, but which needs to be in # the package list. if namespace == 'rpms': signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
[release] pdc-updater: 0.6.3
Just a few small bugfixes to pdc-updater here. 0.6.3 - Pull Requests - (@ralphbean) #73, Ignore modules in the build state. https://github.com/fedora-infra/pdc-updater/pull/73 - (@hanzz) #74, Use different way to call PDC API to workaround 404 bug for valid modules in PDC. https://github.com/fedora-infra/pdc-updater/pull/74 Commits - 9604e3009 Ignore modules in the build state. https://github.com/fedora-infra/pdc-updater/commit/9604e3009 - 66a15a516 Use different way to call PDC API to workaround 404 bug for valid modules in PDC. https://github.com/fedora-infra/pdc-updater/commit/66a15a516 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: whatcanidoforfedora.org is back
Oh, I wonder how that worked before. Hm.. It looks like the old server from openshift would automatically redirect to /en/ if no language was specified. https://github.com/fedora-infra/asknot-ng/blob/develop/.openshift/diy/pythonserver.py ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
whatcanidoforfedora.org is back
http://whatcanidoforfedora.org is back (the dns change is still propagating). Patrick and I set up an ansibilized cronjob on sundries01 to build it and sync it out to the proxies, similar to how our other websites are built. Ricky's going to proceed with looking at how to auto-build it in os.fedoraproject.org, so the team can get more experience with deploying applications with different update flows there. -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Freshmaker RFR
Hey all, Just like in for the ODCS RFR[1], I'm sending out a ping here about the Freshmaker RFR: https://pagure.io/fedora-infrastructure/issue/6183#comment-471098 I tried to put a bunch of context about what it is and vaguely how it works in the proposed SOP: https://pagure.io/infra-docs/pull-request/70 If there are questions, concerns, or anything to take up - let us know, please. Cheers- -Ralph [1] - https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/POE3P3XJNPVYI7G3OVMSXFXV7KSOCPYH/#POE3P3XJNPVYI7G3OVMSXFXV7KSOCPYH signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Introduction Ken Dreyer
Welcome :) ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
ODCS RFR
Hey all, I had a chat with Patrick yesterday and walked through the various parts of the RFR process that my team has done a less than great job of following. I never built up a good habit of following the RFR process to the letter. Sorry for this. Will try to do a better job. Patrick put together a template for the RFR process in the infra-docs repo we can use to make it easier to not accidentally skip steps. Anyways, I filled out some info on ODCS and thought I'd send it along here. If there are any questions, we can try to answer them here or in the ticket. https://pagure.io/fedora-infrastructure/issue/6182#comment-471097 Current status is that it is setup in staging, but the prod nodes haven't been provisioned yet. Most all of the bits in staging look like they're working, except for the crucially missing read-only mount of /mnt/koji. This is something I didn't think to ask for earlier on, but, anyways it's in the ticket above. Thanks for your time. Questions welcome! -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: 🎶if you liked it then you should've put a lock on it...🎶
Applied here: http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=aab2ea4590853acb8f631f4fae293e03df50e6cb ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR - a timeout for the koji pkglist sync script
Applied: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=18b7ea4435e2a28b65fae2dc9161900d7e961a1e ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR - a timeout for the koji pkglist sync script
Mohan and Matt found yesterday that the koji pkglist sync script was hung (for two hours) waiting on a koji query. We looked today, and found that the default timeout for koji requests is 12 hours! (whee!) Here's a patch to that script that sets a timeout of 10 minutes which, based on a reading of the logs, is 9.9 more minutes than we need to make the requests in question. If this doesn't work, we can just `git revert` to back it out. Any +1s? diff --git a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 b/roles/bodhi2/backend/templates/owner-sync-pagure.j2 index 8046c32..314e2c2 100755 --- a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 +++ b/roles/bodhi2/backend/templates/owner-sync-pagure.j2 @@ -292,22 +292,27 @@ def get_pagure_project_branches(namespace, package=None, verbose=False): def set_koji_ownership(tag, packages, arches, verbose=False): -koji_options = get_options() +koji_login_options = get_options() +koji_options={ +'krb_rdns': False, +# About ten minutes. The default is 12 hours. +'timeout': 60 * 10, +} for arch in arches: if arch == 'primary': session = koji.ClientSession( 'https://koji{0}.fedoraproject.org/kojihub'.format(ENV_SUFFIX), -{'krb_rdns': False} +opts=koji_options, ) else: session = koji.ClientSession( 'https://{0}.koji.fedoraproject.org/kojihub'.format(arch), -{'krb_rdns': False} +opts=koji_options, ) try: -session.krb_login(koji_options['principal'], koji_options['keytab']) +session.krb_login(koji_login_options['principal'], koji_login_options['keytab']) except: import traceback traceback.print_exc() signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: 🎶if you liked it then you should've put a lock on it...🎶
> How long is it taking to do a sync? I'm not sure. Patrick noticed it in #fedora-noc. > And would it be better to schedule the cron job to be non-daily in that case? Possibly, yes. (Likely still good to also put a lock on it). ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR: 🎶if you liked it then you should've put a lock on it...🎶
... or even if you didn't like it, it still probably needs a lock. /usr/local/bin/pagure-sync-bugzilla.py takes more than 24 hours to run, and it doesn't have a lock wrapper on it. It needs one. diff --git a/roles/distgit/pagure/tasks/main.yml b/roles/distgit/pagure/tasks/main.yml index 8cdf0b3..9079f06 100644 --- a/roles/distgit/pagure/tasks/main.yml +++ b/roles/distgit/pagure/tasks/main.yml @@ -228,7 +228,7 @@ user: root minute: 0 hour: 18 -job: /usr/local/bin/pagure-sync-bugzilla.py +job: /usr/bin/lock-wrapper pagure-sync-bugzilla "/usr/local/bin/pagure-sync-bugzilla.py" cron_file: pagure-sync-bugzilla state: present when: env != 'staging' Anyone for it? Against it? signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: MBS upgrade
OK, this is all done and upgrade and tested as far as I can test it. My build of the `testmodule` module succeeded. https://mbs.fedoraproject.org/module-build-service/1/module-builds/953 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: MBS upgrade
> That is a major code change on a Friday. What is the DB upgrade parts > and if there are further changes/problems what is the backout plan? The db change is here: https://pagure.io/fm-orchestrator/pull-request/686#_1,18 Two new added columns. The MBS (like many of our other apps) uses `alembic` to manage db migrations. The plan to upgrade involves using this playbook, which will use `mbs-upgradedb` (a small wrapper around alembic). https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/manual/upgrade/mbs.yml#n102 If it fails, I'll back it out with `alembic downgrade -1`. If *that* fails, having the additional columns shouldn't hurt anything, so we can downgrade the software but keep the advanced schema until we figure out how to resolve that (likely manual sql statements, but it shouldn't come to that[1]). -Ralph [1] - He says on a Friday afternoon, he says. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR: MBS upgrade
Hi, I'd like to upgrade the MBS to: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1db0646bc6 In particular, the bit about "Wait for components to be tagged also in final tag before marking module as done. This should fix an issue for the F27 compose." is important. See https://pagure.io/fm-orchestrator/pull-request/686 There is a db upgrade (to the MBS db) in this update. I'll verify in staging first that I can upgrade/downgrade before touching prod. Anyone for a +1? -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Bodhi + Modules (not quite an FBR, just yet)
New news: the Server SIG decided to go with a traditional release for F27: https://meetbot.fedoraproject.org/fedora-meeting-1/2017-09-12/serversig.2017-09-12-20.00.html - They still want to do a non-blocking modular release on the side (kind of like boltron). - We will still want/need to have Bodhi ready to support updates to that release. - But the fire is now off to try and cram this in before Friday (phew!) Martin Curlej, Randy Barlow, and I will be looking to deploy it in the window between Beta and Final freezes. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Bodhi + Modules (not quite an FBR, just yet)
This came up in the FESCo meeting today. https://github.com/fedora-infra/bodhi/issues/1795 In my last discussions with Randy, we were planning on merging, releasing, and deploying the modular bodhi masher work after Beta freeze thawed - but FESCo would rather see proof of it before freeze is up. This is reasonable. We would've liked to have it before Beta, but contiguous PTO schedules + Flock made that not possible. Anyways, here we are. I volunteered to take on trying to rebase the modular masher patches from https://github.com/fedora-infra/bodhi/pull/1697 and cutting a hotfix release of Bodhi.. and to exercise it very carefully in staging. I want to try upgrading it and downgrading it, and making sure it won't interrupt the mainline mash if anything is wrong with it. I don't think I need an FBR for staging - this is more of a pre-emptive request. If all goes well with that staging upgrade/downgrade, is the infra group OK with upgrading also in prod before the freeze is up? It's not a super small change. What sort of checks would help raise confidence? What should I watch out for? Can you help add items to my TODO list in #1795? (Feel free to edit the ticket there and just add them.) Yours- -Ralph p.s., for the ultimate prod upgrade, I'll send a separate email asking for approval after I've crossed off items on the list. p.p.s., for the ultimate prod upgrade, I'll do it at night US+EU TZ which is when I expect usage will be slightly less. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
[release] pdc-updater: 0.6.0
A new pdc-updater release! There are a few bugfixes related to the MBS, but crucially there is a new handler for propagating retirement: When a `dead.package` file gets committed, the code here (on pdc-backend0*) will update the EOL of that branch in PDC, indicating retirement. 0.6.0 - Pull Requests - (@ralphbean) #57, srpm_nevra must not be set when arch is src. https://github.com/fedora-infra/pdc-updater/pull/57 - (@ralphbean) #62, Force creation of parent with type during initialization. https://github.com/fedora-infra/pdc-updater/pull/62 - (@ralphbean) #60, Populate the dist_git_branch value... https://github.com/fedora-infra/pdc-updater/pull/60 - (@ralphbean) #61, Also construct container tags from stable updates tags. https://github.com/fedora-infra/pdc-updater/pull/61 - (@mprahl) #63, Add a handler so that PDC branches are EOL'd when the branch is retired https://github.com/fedora-infra/pdc-updater/pull/63 - (@mprahl) #64, Add some missing doc strings to RetireComponentHandler https://github.com/fedora-infra/pdc-updater/pull/64 - (@ralphbean) #66, Some changes to the retirement handler... https://github.com/fedora-infra/pdc-updater/pull/66 Commits - 6118478b5 srpm_nevra must not be set when arch is src. https://github.com/fedora-infra/pdc-updater/commit/6118478b5 - 600b6175e Populate the dist_git_branch value... https://github.com/fedora-infra/pdc-updater/commit/600b6175e - 17edf56ad Also construct container tags from stable updates tags. https://github.com/fedora-infra/pdc-updater/commit/17edf56ad - 7a022d494 Force creation of parent with type during initialization. https://github.com/fedora-infra/pdc-updater/commit/7a022d494 - b7341977a Add a handler so that PDC branches are EOL'd when the branch is retired https://github.com/fedora-infra/pdc-updater/commit/b7341977a - 31f7caf33 Break retirement out into its own staticmethod. https://github.com/fedora-infra/pdc-updater/commit/31f7caf33 - e2eeec935 Write an init method. https://github.com/fedora-infra/pdc-updater/commit/e2eeec935 - e132ab502 Add Docstrings to RetireComponentHandler https://github.com/fedora-infra/pdc-updater/commit/e132ab502 - e2d52896c Add the audit function to the RetireComponentHandler handler https://github.com/fedora-infra/pdc-updater/commit/e2d52896c - bcb112faa Add some missing doc strings to RetireComponentHandler https://github.com/fedora-infra/pdc-updater/commit/bcb112faa - 3a2cef32e Make these two work functions re-try-able. https://github.com/fedora-infra/pdc-updater/commit/3a2cef32e - fe8af401d Check pagure instead of cgit. https://github.com/fedora-infra/pdc-updater/commit/fe8af401d - e1b0542b4 Fix those mocks. https://github.com/fedora-infra/pdc-updater/commit/e1b0542b4 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Duplicates in package owner alias cronjob?
Introducing some retry stuff to be more resilient when pagure blips: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=b084a7762f00f110f2b73158a66b577ec01a9cfd ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Duplicates in package owner alias cronjob?
Fixed in https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=24141e596b989de79c04111291aab09effe49580 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Duplicates in package owner alias cronjob?
I'm confused about something. Can any postfix experts help debug? On Friday I put a new package-owner-alias cronjob in place on bastion (that Matt Prahl wrote). It generates the package owner list from pagure over dist-git instead of generating it from pkgdb. https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=eb241f903dcd6d7d3529539739508f6dc1b00982 Kevin saw that the hourly cronjob is spitting out some errors from the postfix command. However, when I inspect the file, I don't find any duplicates: $ cat /etc/postfix/package-owner | awk ' { print $1 } ' | uniq -d Anybody know what's wrong with that file/output? -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: [PATCH] F26 final 0-day release actions
LGTM. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Fedora 26 Final Freeze now in effect
On Wed, Jun 28, 2017 at 08:20:29AM -0600, Kevin Fenzi wrote: > On 06/28/2017 02:57 AM, Pierre-Yves Chibon wrote: > > > I did not realize this before, but this will impact the decommissioning of > > pkgdb. > > The idea was to deploy pagure on dist-git on July 5th and deprecate pkgdb on > > July 10th. > > > > So could/should we postpone this to say, deploy pagure on dist-git on the > > 10th? > > and deprecate pkgdb on the 17th? > > (The pagure part worries me less since it's a new service which should have > > minimal impact on the existing one). > > The issue is then, what do we do is release slips? > > > > Pierre > > > > > > PS: on a personal note, I'm not sure how much I'll be around on the 5th > > afternoon, 6th and 7th, so postponing to the 10th is actually appealing to > > me. > > Well, the folks with the short timeline/constraints are the factory 2.0 > folks, so lets see what they say here. ;) > > I'm fine with doing it later, but this may impact more milestones they > have. I agree the pagure part might be less impactfull since it should > hopefully not affect f26 efforts. The pkgdb drop could affect f26 (say a > blocker couldn't be built or the like), so it might be better to do that > when f26 is already go. > > kevin Some of our early project deadlines are deadlines because they block further work on other infrastructure tools. Those make me anxious, because if one slips, then *everything* slips. Luckily, the ArbitraryBranching Change is not one of those. We set an early deadline for ourselves so that we could provide maximum time during the F27 development cycle for packagers and "modulers" (module maintainers?) to use and acclimate to new branch-related tooling. Taking that into account, slipping the pkgdb change by a week is not a big deal from my PoV. Thanks for the heads up! -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: Add CSS handling to Taskotron artifacts serving
On Fri, Jun 02, 2017 at 10:06:56AM -0600, Tim Flink wrote: > The modularity-testing-framework tests use avocado to output nice HTML > reports but due to the way that we store and serve the artifacts, the > css doesn't load properly. An example (that should work post-fix) is: > > https://taskotron.fedoraproject.org/artifacts/all/dedb65bc-4793-11e7-a421-5254008e42f6/task_output/avocado-result/html/results.html > > I've fixed this in dev and stg already. I'd like to apply the fix to > prod. I'd be removing the if statements from this commit. > > https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/roles/taskotron/taskotron-master/templates/artifacts.conf.j2?id=5fb1ed978b83240b97f011d9160d6df2cffa29ac > > +1s? > > Tim +1 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR: Add deprecation banner to pkgdb in prod
Thanks, this is done now: https://admin.fedoraproject.org/pkgdb signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR: Add deprecation banner to pkgdb in prod
This just got approved in FESCo today. I'd like to manually apply this patch to the pkgdb web nodes in prod: https://github.com/fedora-infra/pkgdb2/pull/415 It's a template and css change that adds a banner informing packagers of the pending plans for: https://fedoraproject.org/wiki/Changes/ArbitraryBranching Can I get two +1s to apply it? -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
waiverdb in os.fedoraproject.org (prod)?
Cheers on os.stg.fedoraproject.org! I'd love to have waiverdb[1] be the first app on os.fedoraproject.org once it is ready. Do you guys have any estimates of when we could start messing with that in both stg and prod? (Maybe we could help you work out kinks if we can try deploying to os.stg.fp.o even before os.fp.o is ready?) I put a due date in my project planning of "June 30th" for when waiverdb would be available in a production env. It's not "make or break" if we don't hit that date, but if os.fp.o won't be available for many months, maybe we should go ahead with VM-based ansible deployment in the meantime. Yours- -Ralph [1] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/WaiverDB signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Service account for automated rebuilds?
On Wed, May 03, 2017 at 02:35:20PM -0400, Ralph Bean wrote: > Hey all, > > For the automated rebuilds work[1][2], we're going to need a service > account with rights to do various things (only in staging for now). > For container rebuilds, it will need to be able to request new OSBS > builds via koji. For module rebuilds, it will need to be able to > commit to dist-git (only for the modules/ namespace). It therefore > would need to be in the provenpackager group or have some other > special treatment. > > Kevin pointed out that the only thing we have like that now is the > releng account.. but it almost surely doesn't make sense to re-use > that account here. We should have some separation. > > Any thoughts? > > -Ralph > > p.s., As for names, the auto-rebuild system is called "freshmaker", so > calling the account itself "freshmaker" makes sense to me. > > [1] - https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker > [2] - > https://fedorapeople.org/groups/factory2/sprint-029/qwan-freshmaker-rebuild-modules-when-rpm-spec-updated.mp4 FYI, this got discussed today at the meeting and came up with an alternative approach: https://meetbot.fedoraproject.org/fedora-meeting/2017-05-04/infrastructure.2017-05-04-17.59.html We're going to talk about it more next week at the hackathon before doing anything more on it. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Service account for automated rebuilds?
CC'ing the rel-eng list for visibility. On Wed, May 03, 2017 at 02:35:20PM -0400, Ralph Bean wrote: > Hey all, > > For the automated rebuilds work[1][2], we're going to need a service > account with rights to do various things (only in staging for now). > For container rebuilds, it will need to be able to request new OSBS > builds via koji. For module rebuilds, it will need to be able to > commit to dist-git (only for the modules/ namespace). It therefore > would need to be in the provenpackager group or have some other > special treatment. > > Kevin pointed out that the only thing we have like that now is the > releng account.. but it almost surely doesn't make sense to re-use > that account here. We should have some separation. > > Any thoughts? > > -Ralph > > p.s., As for names, the auto-rebuild system is called "freshmaker", so > calling the account itself "freshmaker" makes sense to me. > > [1] - https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker > [2] - > https://fedorapeople.org/groups/factory2/sprint-029/qwan-freshmaker-rebuild-modules-when-rpm-spec-updated.mp4 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Service account for automated rebuilds?
Hey all, For the automated rebuilds work[1][2], we're going to need a service account with rights to do various things (only in staging for now). For container rebuilds, it will need to be able to request new OSBS builds via koji. For module rebuilds, it will need to be able to commit to dist-git (only for the modules/ namespace). It therefore would need to be in the provenpackager group or have some other special treatment. Kevin pointed out that the only thing we have like that now is the releng account.. but it almost surely doesn't make sense to re-use that account here. We should have some separation. Any thoughts? -Ralph p.s., As for names, the auto-rebuild system is called "freshmaker", so calling the account itself "freshmaker" makes sense to me. [1] - https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker [2] - https://fedorapeople.org/groups/factory2/sprint-029/qwan-freshmaker-rebuild-modules-when-rpm-spec-updated.mp4 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On Tue, Apr 25, 2017 at 01:36:50PM -0600, Kevin Fenzi wrote: > On 04/25/2017 08:23 AM, Pierre-Yves Chibon wrote: > ...snip... > > Now going through each of the requirements listed above > > - Store point of contact for a package (default assignee on bugzilla) > > - we could use the first committer, alphabetically > > - we could use the 'owner', but we need pagure to be able to "give" a > > repo which it currently cannot. > > - in order to "orphan" a package, we need this. > > - we could list the default assignee in the yaml file in dist-git > > - Not ideal since less "self-service" > > One possibility I'll toss out... change POC to > packagename-ow...@fedoraproject.org and have it go to the alias. This > has the advantages of: > > * Never need to update bugzilla after the package is made. > * People perhaps stop thinking of packages as "theirs" a bit more. > > But also disadvantages of people liking to see a name they can point to > about the package or know who is cc'ed on the bug. I like this idea a lot. > > - Store new package requests > > - matt prahl is already cooking up a way to do this using a > > https://pagure.io/repo-requests/issues/ queue and some scripts. > > - https://pagure.io/fedrepo_req/pull-request/1 > > - !!! we have problems using pagure ticket queue here (api tokens, need > > commit or really admin access...) > > - other options: > > - bugzilla > > no no, please not again. ;) > > > - custom made queue > > - fpaste! > > Ha. > > > - patch pagure to do what we need. > > -> Add the possibility to select a project in > >https://pagure.io/settings/token/new and allow there the > >issue_create, issue_update and issue_comment ACLs > > -> Add the possibility to set the duration of the token (with > >an upper limit: 365 days?) (per token with a default in the > >config file?) > > -> pingou will handle this > > Note that I think we still want an admin to ack new package requests. Agreed! Last time I talked with dgilmore about it, he pointed out that all kinds of oddball trademark issues only get caught at the cvsadmin level. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On Tue, Apr 25, 2017 at 02:31:19PM -0400, Randy Barlow wrote: > On Tue, 2017-04-25 at 16:23 +0200, Pierre-Yves Chibon wrote: > > - Store point of contact for a package (default assignee on bugzilla) > > - we could use the first committer, alphabetically > > - we could use the 'owner', but we need pagure to be able to "give" > > a > > repo which it currently cannot. > > - in order to "orphan" a package, we need this. > > - we could list the default assignee in the yaml file in dist-git > > - Not ideal since less "self-service" > > I'd probably advocate for modifying pagure to allow "giving" repos. > That sounds like a good feature anyway. Using the first committer would > prevent the ability to change PoC's of a package. Agreed. mprahl will be scoping out "giving ownership" in pagure shortly. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On Tue, Apr 25, 2017 at 07:56:06PM +0200, Michael Šimáček wrote: > > > On 2017-04-25 19:48, 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. > > > > Koschei flag in pkgdb was implemented because people thought it's more > natural to have all the package settings in one place (pkgdb). But koschei > can keep track of it's packages by itself (it has a view for adding > packages, it's just not visible when pkgdb integration is on). So if pkgdb > goes away, it can return to old behavior of keeping the koschei flag in > koschei itself. This works! No objection from me. Note, we still have to solve the same problem for the-new-hotness settings, which doesn't have a UI such as koschei's. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
[release] pdc-updater: 0.5.5
New release includes a fix to support the module build service. The koji tag names we were constructing were too long. 0.5.5 - Pull Requests - #53, Merge pull request #53 from hanzz/module-hash https://github.com/fedora-infra/pdc-updater/pull/53 Commits - b0f14d1f8 Use hash instead of variant_uid for koji_tag, otherwise we hit the 50 characters limit for koji_tag used by Koji. https://github.com/fedora-infra/pdc-updater/commit/b0f14d1f8 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: WhatCanIDoForFedora Hosting Server
On Tue, Apr 04, 2017 at 09:57:15AM -0600, InvalidPath wrote: > On Tue, Apr 4, 2017 at 9:27 AM, Stephen John Smoogen > wrote: > > > This was a project that Ralph Bean started to try and get an idea of > > what it could be. It seems to be running on an amazon cloud compute > > node. I don't know anything beyond that so I cc'd Ralph if he has time > > to help you. > > > > 217.181.172.54.in-addr.arpa domain name pointer > > ec2-54-172-181-217.compute-1.amazonaws.com. > > > > On 4 April 2017 at 11:17, InvalidPath wrote: > > > Tossing this question out there for tomorrow.. Anyone know when > > > I can look, or determine what server hosts WhatCanIDoForFedora? > > > Not looking for the easy way out, but a hint would be grand. > > Interesting.. thanks Smooge. I'll wait for ralphs input. It is hosted in Openshift Online. https://github.com/fedora-infra/asknot-ng/tree/develop/.openshift :) signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: FBR, check_modulemd check for taskotron!
On Fri, Mar 24, 2017 at 01:01:16PM -0600, Kevin Fenzi wrote: > +1 here > > kevin Thanks! All done and running. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR, check_modulemd check for taskotron!
Hey all, I'm seeking a FBR to enable a new taskotron check in production. It's not urgent (nothing will be blocked without it). It would just be nice to have. Tim Flink says in channel that "it's not a risky or major change". Backing it out would involve reverting that conditional in trigger_rules.yml and re-running the playbook to disable it. Anyone +1 on this? diff --git a/inventory/group_vars/taskotron-prod b/inventory/group_vars/taskotron-prod index 284d069..d75b0e3 100644 --- a/inventory/group_vars/taskotron-prod +++ b/inventory/group_vars/taskotron-prod @@ -24,6 +24,7 @@ grokmirror_repos: - { name: fedoraqa/abicheck, url: 'https://pagure.io/task-abicheck.git'} - { name: fedoraqa/rpmgrill, url: 'https://bitbucket.org/fedoraqa/task-rpmgrill.git'} - { name: fedoraqa/python-versions, url: 'https://github.com/fedora-python/task-python-versions'} + - { name: fedoraqa/check_modulemd, url: 'https://github.com/fedora-modularity/check_modulemd'} grokmirror_user: grokmirror grokmirror_default_branch: master diff --git a/roles/taskotron/taskotron-trigger/templates/trigger_rules.yml.j2 b/roles/taskotron/taskotron-trigger/templates/trigger_rules.yml.j2 index 8994e9a..f939c1d 100644 --- a/roles/taskotron/taskotron-trigger/templates/trigger_rules.yml.j2 +++ b/roles/taskotron/taskotron-trigger/templates/trigger_rules.yml.j2 @@ -33,11 +33,10 @@ do: - {tasks: [upgradepath]} {% endif %} -{% if deployment_type in ['dev', 'stg'] %} + - when: {message_type: DistGitCommit, namespace: modules} do: - {tasks: [check_modulemd]} -{% endif %} {% if deployment_type in ['dev'] %} - when: signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
FBR: PDC update
Hi all, I'd like to update: - PDC to python-pdc-1.2.0-8.git.30.gacf661f (f25-infra) on pdc-web0* - pdc-updater to pdc-updater-0.5.4-1 (epel7-infra) on pdc-backend0* There are two changes that come with this: - First, there is a new field in the productmd information produced by pungi which PDC doesn't know about. This is causing the import of some composes to break regularly: https://github.com/fedora-infra/pdc-updater/pull/49/files - Second, there is a bugfix to avoid a race condition in the MBS that relies on a new field added in PDC. The original issue is filed here: https://pagure.io/fm-orchestrator/issue/407 It produced this patch to the MBS: https://pagure.io/fm-orchestrator/pull-request/431 Which in turn depends on two patches to PDC and pdc-updater, which are the subject of this FBR: - https://github.com/fedora-modularity/product-definition-center/pull/11 - https://github.com/fedora-infra/pdc-updater/pull/52 Deploying this involves adding a field to the PDC schema with an automated database migration. If I can get two +1s from sysadmin-main, I'll run it in staging first and if anything goes haywire, I'll put the brakes on it until after the freeze is up. -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Bodhi 2.4.0 released upstream
On Wed, Feb 15, 2017 at 10:11:14PM -0500, Randy Barlow wrote: > On Wed, 2017-02-15 at 16:58 -0500, Randy Barlow wrote: > > https://github.com/fedora-infra/bodhi/releases/tag/2.4.0 > > I've been unable to build Bodhi in Rawhide, due to a packaging bug with > python-dogpile-cache: > > https://bugzilla.redhat.com/show_bug.cgi?id=1422716 > > That package can only be committed to by Ralph or the infra-sig. I'm > willing to fix it myself, but I'm not in the infra-sig. I applied for > membership in the infra-sig group if anyone would like to sponsor me. I > also applied for commit access on the package, which is lesser access > and is all I really need at this time, if someone wants to mark that > approved. If not, could one of you fix that bug for me? Rights granted to you on dogpile*! signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Bugzilla upgrade sometime in March, maybe.
FYI, there's an upgrade to Bugzilla 5 in the works. There's no exact date yet, but it looks like March is the current target. It occurs to me that we'll be in F26 Alpha freeze then, so it may be good to try and figure out what adjustments need to be made before then. This was brought to my attention by this issue: https://github.com/fedora-infra/bugzilla2fedmsg/issues/9 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Dreams and Plans and Ideas for 2017
On Wed, Jan 04, 2017 at 10:51:08AM -0700, Kevin Fenzi wrote: > Greetings and happy new year to everyone. > > I'd like to divide this email up into 2 parts: > > Firstly, what all do we want to get done in the next 2 months? > The end of Feb is the end of the Red Hat Fiscal year and many of us > have goals tied to that timeframe. :) > > For myself: > > * Finish migrating things off fedorahosted so we can retire it at the > end of Feb. I need to make a survey of how many things are left, etc. > > * Get mirrorlist containers all deployed and running (With a bunch of > help from Patrick). We have it working in staging, just need to get > things setup to build using OSBS and deploy in production. This > should allow us to avoid outages even more from mirrorlists service. > > * Get database replication setup finished in stg and hopefully setup in > production. We still need to sort out how to get db schema upgrades > fully working for people, but otherwise hopefully this should allow > us much less scheduled outages. I am waiting on BDR 2.0 to be > released (with postgresql 9.6 support, so this might slip out some). > > * Get s390 merged into the main/primary koji. This is waiting on > firewall/networking changes. > > What things are others trying to get done? I know there was a plan for > fas3, I know Ricky is working on modernpaste replacing sticky-notes, > what else is on the short term timeline? > > Secondly, there's the rest of the year. It's not too early to dream > about what we want to try and get done in the coming year. :) > > For myself: > > * I'd like to try and move askbot to current upstream code. This likely > will require us to try and move it to python3 and django1.8. I am > pretty sure this will require some python savvy coding action. :) > > * I'd love to try and do a FAD sometime this coming year if we can > identify something that we could tackle and solve/complete over a few > days. > > * I'd like to do some more apprentice work days to get apprentices more > involved. We should try and brainstorm some things we could do on > such work days. > > * I'm sure to think of more things as time goes on. ;) > > What does everyone else have on their radar? Just FYI, we talked about it briefly in the infra meeting on Thursday: https://meetbot.fedoraproject.org/teams/infrastructure/infrastructure.2017-01-05-18.00.html .. but we're going to have a number of Modularity and "Factory 2.0" tasks to take up in the F27 timeframe. Pierre and I (and anyone else who's around) are going to take it up in the hallway track at Devconf to see if we can list the things that need to be done. Some ideas off the top include: - Adjusting pkgdb to allow for flexible per-component branching. - Adjusting bodhi to allow containers and modules to pass through the karma/update system. - Tooling on top of bugzilla to automatically triage bug reports into the right module/component combination. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
[release] fedmsg: 0.18.1
This release primarily contains Patricks' bugfix, found this morning. 0.18.1 -- Pull Requests - (@ralphbean) #390, Drop old testcases against old python-six. https://github.com/fedora-infra/fedmsg/pull/390 - (@puiterwijk) #393, Only check for stomp messages after we decoded any ZMQMessage https://github.com/fedora-infra/fedmsg/pull/393 Commits - 9fc0e1e61 Drop old testcases against old python-six. https://github.com/fedora-infra/fedmsg/commit/9fc0e1e61 - 922c6f390 Only check for stomp messages after we decoded any ZMQMessage https://github.com/fedora-infra/fedmsg/commit/922c6f390 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
[release] fedmsg: 0.18.0
Hi all, I've cut a new release of fedmsg upstream and will be packaging it for Fedora and EPEL. There's nothing in this release that needs to be rolled out in the infra environment imminently. This email is just to let you know that the release if available for when we next do mass updates. 0.18.0 -- Pull Requests - (@ralphbean) #374, Cascade IRC connections. https://github.com/fedora-infra/fedmsg/pull/374 - (@ralphbean) #375, Kill the status page... https://github.com/fedora-infra/fedmsg/pull/375 - (@ncoghlan) #377, Make intro less Fedora specific https://github.com/fedora-infra/fedmsg/pull/377 - (@ralphbean) #380, Get fedmsg-hub working on STOMP. https://github.com/fedora-infra/fedmsg/pull/380 - (@jeremycline)#382, Turn testing Python 2.6 in Travis on https://github.com/fedora-infra/fedmsg/pull/382 - (@jeremycline)#381, Raise the resource limit on open files for fedmsg-hub https://github.com/fedora-infra/fedmsg/pull/381 - (@mprahl) #388, Return earlier when validate_signatures is turned off https://github.com/fedora-infra/fedmsg/pull/388 - (@ralphbean) #387, Document turning off validation for other busses. https://github.com/fedora-infra/fedmsg/pull/387 - (@asdil12)#386, Add SSL support to irc bot https://github.com/fedora-infra/fedmsg/pull/386 - (@tvieira)#385, Updating dependencies on documentation https://github.com/fedora-infra/fedmsg/pull/385 Commits - 55d4ecdd5 Cascade IRC connections. https://github.com/fedora-infra/fedmsg/commit/55d4ecdd5 - ce5a19b25 Add some logging. https://github.com/fedora-infra/fedmsg/commit/ce5a19b25 - 917ad58fc Make sure we don't do this forever... https://github.com/fedora-infra/fedmsg/commit/917ad58fc - b9ab4ffb6 Wait 5 seconds instead of 1. https://github.com/fedora-infra/fedmsg/commit/b9ab4ffb6 - e02633917 Kill the status page... it is old and hard to maintain. https://github.com/fedora-infra/fedmsg/commit/e02633917 - fb5190e24 Make intro less Fedora specific (#1) https://github.com/fedora-infra/fedmsg/commit/fb5190e24 - 10c0398a5 Add missing space https://github.com/fedora-infra/fedmsg/commit/10c0398a5 - d8b41ef35 Local and hosted test unification https://github.com/fedora-infra/fedmsg/commit/d8b41ef35 - 11a812feb Drop the support for Python 2.6 https://github.com/fedora-infra/fedmsg/commit/11a812feb - 37c5d2f8e Add support for Python 3.5 https://github.com/fedora-infra/fedmsg/commit/37c5d2f8e - f9d3bd74c Allow configuration for fedmsg-hub to listen to STOMP or AMQP instead of just zmq. https://github.com/fedora-infra/fedmsg/commit/f9d3bd74c - 8e5e9d1b6 fedmsg.core modifications for STOMP/AMQP hand-off. https://github.com/fedora-infra/fedmsg/commit/8e5e9d1b6 - 3714777cc Some config comments about STOMP usage. https://github.com/fedora-infra/fedmsg/commit/3714777cc - 7888c538e Massage STOMP messages into a more compatible format. https://github.com/fedora-infra/fedmsg/commit/7888c538e - 2f8b4024f Let the ircbot handle weird topics (like from STOMP). https://github.com/fedora-infra/fedmsg/commit/2f8b4024f - fa24f8c77 Add doc on enabling STOMP support. https://github.com/fedora-infra/fedmsg/commit/fa24f8c77 - 3c593e266 Be more precise in this comment. https://github.com/fedora-infra/fedmsg/commit/3c593e266 - 5df1e4831 Copy this docstring to the actual docs. https://github.com/fedora-infra/fedmsg/commit/5df1e4831 - 91594886c Use something more clear than .isalpha. https://github.com/fedora-infra/fedmsg/commit/91594886c - fdee6e458 Turn testing Python 2.6 in Travis on https://github.com/fedora-infra/fedmsg/commit/fdee6e458 - 439383ab7 Revert "Drop the support for Python 2.6" https://github.com/fedora-infra/fedmsg/commit/439383ab7 - bd452112f Update pip before starting the Travis tests https://github.com/fedora-infra/fedmsg/commit/bd452112f - 3651cfcdf Raise the resource limit on open files for fedmsg-hub https://github.com/fedora-infra/fedmsg/commit/3651cfcdf - 004a2fc9c Updating dependencies on documentation https://github.com/fedora-infra/fedmsg/commit/004a2fc9c - 8072a84e4 Fixing typo on library name https://github.com/fedora-infra/fedmsg/commit/8072a84e4 - 7cbc517a9 Add SSL support to ircbot https://github.com/fedora-infra/fedmsg/commit/7cbc517a9 - 69e382716 Document turning off validation for other busses. https://github.com/fedora-infra/fedmsg/commit/69e382716 - 0e1189c6a Return earlier when validate_signatures is turned off https://github.com/fedora-infra/fedmsg/commit/0e1189c6a ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Triage of fedmsg issues
On Wed, Nov 09, 2016 at 12:46:48PM +0100, Pierre-Yves Chibon wrote: > On Tue, Nov 08, 2016 at 08:25:45PM -0500, Ralph Bean wrote: > > On Tue, Nov 08, 2016 at 04:04:38PM +0100, Pierre-Yves Chibon wrote: > > > On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote: > > > > This is likely also https://pagure.io/fedora-infrastructure/issue/4022 > > > > Perhaps I should close that one UPSTREAM? > > > > (I have no idea if it still needs fixing) > > > > > > Nah that's bug in our git hook that is in ansible. > > > > > > There are two ways to go about it: > > > - Announce git branch that are removed > > > - Don't > > > (on pagure I took the second approach). > > > > > > If we want to take the first approach, we'll need to adjust > > > fedmsg_meta_fedora_infra for a new topic. > > > > > > I can take this one, any preferred solution? > > > > I don't have a preference on which route you take, Pierre. > > > > But, this brings up a separate, new issue: we did a good thing and a > > bad thing. > > > > The good thing is that when Mike Bonnet wrote the dist-git message > > hook for Red Hat's dist-git, we did our best to copy the message > > format published by the Fedora hook. The goal here is that we can now > > write message consumers that respond to either Fedora dist-git > > messages or RH dist-git messages.. and they'll just work (fingers > > crossed). We can share more infrastructure code! > > Cool :) > > > The bad thing is that we copied the code for the dist-git hook and > > rewrote it to use the internal message bus tech (my bad). So now, if > > you add a new message type (deleting a branch) we won't inherit that > > automatically over on the RH side. We'll have to keep updating our > > hook every time you update yours. Worse, you may introduce a change > > that we never notice, and then we'll be weirdly out of sync. > > Is there a way/possibility to correct this now? Not an easy way that I can see. The pygit2 code is mostly the same, but there's a not-small amount of proton[1] boilerplate to get the message out the door. > Thanks for the info, I'll try to keep it in mind and to ping you when we > change > this hook. Thanks :) [1] - http://qpid.apache.org/proton/ signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Triage of fedmsg issues
On Tue, Nov 08, 2016 at 04:04:38PM +0100, Pierre-Yves Chibon wrote: > On Thu, Nov 03, 2016 at 09:18:43AM -0600, Kevin Fenzi wrote: > > This is likely also https://pagure.io/fedora-infrastructure/issue/4022 > > Perhaps I should close that one UPSTREAM? > > (I have no idea if it still needs fixing) > > Nah that's bug in our git hook that is in ansible. > > There are two ways to go about it: > - Announce git branch that are removed > - Don't > (on pagure I took the second approach). > > If we want to take the first approach, we'll need to adjust > fedmsg_meta_fedora_infra for a new topic. > > I can take this one, any preferred solution? I don't have a preference on which route you take, Pierre. But, this brings up a separate, new issue: we did a good thing and a bad thing. The good thing is that when Mike Bonnet wrote the dist-git message hook for Red Hat's dist-git, we did our best to copy the message format published by the Fedora hook. The goal here is that we can now write message consumers that respond to either Fedora dist-git messages or RH dist-git messages.. and they'll just work (fingers crossed). We can share more infrastructure code! The bad thing is that we copied the code for the dist-git hook and rewrote it to use the internal message bus tech (my bad). So now, if you add a new message type (deleting a branch) we won't inherit that automatically over on the RH side. We'll have to keep updating our hook every time you update yours. Worse, you may introduce a change that we never notice, and then we'll be weirdly out of sync. Obviously, neither of us is obligated to stay in sync with the other, but it would be nice to share common message formats. Towards that end, I figured I should just let you all know what we're doing. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: [PATCH] update owner-sync-pkgdb to support the docker namespace
+1 here signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: PROPOSAL: employ a variant of upstream dist-git package into FedoraInfra
On Tue, Nov 01, 2016 at 12:13:50PM -0500, Dennis Gilmore wrote: > On martes, 1 de noviembre de 2016 12:51:28 PM CDT Chenxiong Qi wrote: > > On Mon, 2016-10-31 at 11:20 -0500, Dennis Gilmore wrote: > > > On jueves, 13 de octubre de 2016 2:35:59 PM CDT Pierre-Yves Chibon > > > > > > wrote: > > > > On Thu, Oct 13, 2016 at 02:04:04PM +0200, Michal Novotny wrote: > > > > >Hey, > > > > > > > > > >I'd like to propose employment of an upstream dist-git package > > > > > for > > > > >deploying pkgs machines. This is the package I have in mind: > > > > >https://github.com/release-engineering/dist-git. This package > > > > > contains > > > > >scripts and selinux policy for dist-git files. > > > > > > > > I am not sure we're using this, I believe all our work is in the > > > > ansible > > > > repo, afaik there is no dist-git repo/rpm. > > > > > > Correct, the github repo is not actually used anywhere. it was an > > > attempt to > > > make a upstream around dist-git, > > > > Where to report issues for the dist-git Fedora uses? > > Fedora infrastructure or release engineering Some links: - https://pagure.io/fedora-infrastructure/issues - https://pagure.io/releng/issues signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: bodhi-2.3.0-0.1.beta is deployed to staging
On Thu, Oct 20, 2016 at 03:13:35PM -0400, Randy Barlow wrote: > On Thu, 2016-10-20 at 10:07 +0530, Trishna Guha wrote: > > It would be nice if you could link to a guide on how to test Bodhi on > > staging so that I can jump in :). > > Unfortunately I don't think such a guide has been written. I mostly > just play around with the UI a bit myself. However, it is a good > suggestion to create such a guide. Would you like to file an issue with > Bodhi upstream so we remember to create a guide like this later? Once upon a time, we tried heading down a path of automating staging tests of the apps and we wrote 'rube': https://github.com/fedora-infra/rube/blob/develop/rube.fedora/README.rst#running The very few tests it has in test_bodhi2.py pass against the new staging deployment. :) It may be useful to expand its test suite. There is a Jenkins job running it (and failing on other apps) with some frequency: http://jenkins.fedorainfracloud.org/job/fedora-rube/ signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
[release] pdc-updater: 0.3.0
Hey all, A new release of pdc-updater is out. There are a few bug fixes in place. PR#15 adds wholly new functionality to start modelling our dependency chain in PDC. For more information see https://fedoraproject.org/wiki/User:Ralph/Drafts/Infrastructure/Factory2/ModellingDeps I'll be deploying this to staging (hopefully) later to today to see how it behaves. Cheers! - Ralph 0.3.0 - Pull Requests - (@ralphbean) #7, Apply with_ridiculous_timeout to the _import_compose method. https://github.com/fedora-infra/pdc-updater/pull/7 - (@ralphbean) #8, Pretend like kojipkgs has what we expect. https://github.com/fedora-infra/pdc-updater/pull/8 - (@ralphbean) #12, Not all composes have RPMS. https://github.com/fedora-infra/pdc-updater/pull/12 - (@nphilipp) #13, use PDCClient.get_paged() https://github.com/fedora-infra/pdc-updater/pull/13 - (@ralphbean) #15, Introducing new handlers to maintain an rpm dep chain. https://github.com/fedora-infra/pdc-updater/pull/15 Commits - fa305cd52 Demote this log statement. https://github.com/fedora-infra/pdc-updater/commit/fa305cd52 - 608d70814 Sleeping beauty. https://github.com/fedora-infra/pdc-updater/commit/608d70814 - 8afdbc121 Forgotten import. https://github.com/fedora-infra/pdc-updater/commit/8afdbc121 - 258c606f9 Check to make sure a compose is really really done before considering it. https://github.com/fedora-infra/pdc-updater/commit/258c606f9 - ac130f8b7 First stab at a diagram. https://github.com/fedora-infra/pdc-updater/commit/ac130f8b7 - a2be25f57 build diagram. https://github.com/fedora-infra/pdc-updater/commit/a2be25f57 - d9c51edb5 Klaxon. https://github.com/fedora-infra/pdc-updater/commit/d9c51edb5 - 23e9fb360 s/fedorainfracloud/fedoraproject/g https://github.com/fedora-infra/pdc-updater/commit/23e9fb360 - 52325526a We don't need the --insecure option anymore. https://github.com/fedora-infra/pdc-updater/commit/52325526a - 271810f5b libyaml-devel makes the tests 10x faster. https://github.com/fedora-infra/pdc-updater/commit/271810f5b - 956c2b0b5 atomic: Remove a duplicate component-groups query https://github.com/fedora-infra/pdc-updater/commit/956c2b0b5 - 19eca57a6 Allow in both FINISHED and FINISHED_INCOMPLETE composes. https://github.com/fedora-infra/pdc-updater/commit/19eca57a6 - fe906113f 0.2.4 https://github.com/fedora-infra/pdc-updater/commit/fe906113f - 9792b18b0 Merge branch 'master' into develop https://github.com/fedora-infra/pdc-updater/commit/9792b18b0 - f98249fd7 specbump https://github.com/fedora-infra/pdc-updater/commit/f98249fd7 - 23ef90842 pdc-client will be in the buildroot someday soon... https://github.com/fedora-infra/pdc-updater/commit/23ef90842 - 9a1c26b93 Disable tests for now until we get pdc-client in the buildroot. https://github.com/fedora-infra/pdc-updater/commit/9a1c26b93 - 9348dd98b Note to self. https://github.com/fedora-infra/pdc-updater/commit/9348dd98b - f2903804e More info in this error message, please. https://github.com/fedora-infra/pdc-updater/commit/f2903804e - 84bced32c Error check on this request. https://github.com/fedora-infra/pdc-updater/commit/84bced32c - a60cbd6ae Better error message this way.. https://github.com/fedora-infra/pdc-updater/commit/a60cbd6ae - 497fb0fcb Actually, this is not our problem. This is the atomic devs problem. https://github.com/fedora-infra/pdc-updater/commit/497fb0fcb - 73e6cdf18 Move the with_ridiculous_timeout decorator to the utils module. https://github.com/fedora-infra/pdc-updater/commit/73e6cdf18 - a91688d45 Apply with_ridiculous_timeout to the _import_compose method. https://github.com/fedora-infra/pdc-updater/commit/a91688d45 - eddba65ba Pretend like kojipkgs has what we expect. https://github.com/fedora-infra/pdc-updater/commit/eddba65ba - c438a39ba This was backwards. https://github.com/fedora-infra/pdc-updater/commit/c438a39ba - 0e63cf430 Some fixes for the failing test suite (sloppy threebean..) https://github.com/fedora-infra/pdc-updater/commit/0e63cf430 - c89994892 Not all composes have RPMS. https://github.com/fedora-infra/pdc-updater/commit/c89994892 - c15ee8852 use PDCClient.get_paged() https://github.com/fedora-infra/pdc-updater/commit/c15ee8852 - 5864fca6f Tests for new rpm depchain handlers. https://github.com/fedora-infra/pdc-updater/commit/5864fca6f - 3334d7a62 New depchain handlers for RPM. https://github.com/fedora-infra/pdc-updater/commit/3334d7a62 - 885aadae6 Update our utilities to support the new rpm depchain handlers. https://github.com/fedora-infra/pdc-updater/commit/885aadae6 - 8caec5d18 Fix config paths. https://github.com/fedora-infra/pdc-updater/commit/8caec5d18 - 2546dfc55 Link to the wiki page. https://github.com/fedora-infra/pdc-updater/commit/2546dfc55 - 675decc11 Encapsulate this PDC query, and fix a bug. https://github.com/fedora-infra/pdc-updater/commit/675decc11 - 2992a392e Prune the graph when deps disappear in koji. https
Re: Freeze break request: Add diversity-bot to ircbot.py
On Fri, Sep 02, 2016 at 02:53:45PM -0600, Kevin Fenzi wrote: > On Fri, 02 Sep 2016 16:01:23 +0100 > Clement Verna wrote: > > Sorry if I bring confusion, but I though that the freeze was over. I > > believe Kevin sent an email about this earlier this week. > > We are not in freeze. ;) > > We left it on wed, the day after the alpha release went out. Sorry about that. I wasn't paying attention and ended up spreading misinformation. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break request: Add diversity-bot to ircbot.py
On Thu, Sep 01, 2016 at 11:14:57PM -0400, Justin W. Flory wrote: > Hi all, > > This is my first time submitting a patch to a repo or during a freeze > break - if I missed a step or did something wrong, feel free to correct > me. :) I didn't see a SOP in infra-docs so I just followed the format of > past freeze break requests. > > This is a quick patch to add a new bot to ircbot.py for the > #fedora-diversity team. I copied the commopswatch bot and made slight > modifications. But I would appreciate it were reviewed for accuracy in > case I missed something. > > Patch is below and also attached to the email. > > > > From 1b182e380e10d978c4daa7f01d859916d5675b78 Mon Sep 17 00:00:00 2001 > From: "Justin W. Flory" > Date: Thu, 1 Sep 2016 23:07:04 -0400 > Subject: [PATCH] Add #fedora-diversity to ircbot.py for notifications > related > to diversity > > --- > roles/fedmsg/irc/templates/ircbot.py | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/roles/fedmsg/irc/templates/ircbot.py > b/roles/fedmsg/irc/templates/ircbot.py > index 2bb4c03..3f3931b 100644 > --- a/roles/fedmsg/irc/templates/ircbot.py > +++ b/roles/fedmsg/irc/templates/ircbot.py > @@ -363,6 +363,27 @@ config = dict( > body=['^((?!(modularity|Modularity)).)*$'], > ), > ), > + > +# And #fedora-diversity wanted in too > +dict( > +network='chat.freenode.net', > +port=6667, > +make_pretty=True, > +make_terse=True, > + > +{% if env == 'staging' %} > +nickname='diversity-bot-s', > +{% else %} > +nickname='diversity-bot', > +{% endif %} > +channel='fedora-diversity', > +filters=dict( > +topic=[ > + > '(planet|meetbot\.meeting\.item\.help|meetbot\.meeting|fedocal\.meeting\.new|fedocal\.meeting\.update|fedocal\.meeting\.delete|fedocal\.calendar|fas\.group\.member\.sponsor|pagure\.project\.new|askbot\.post\.flag_offensive)', > +], > +body=['^((?!diversity).)*$'], > +), > +), > ], > > ### Possible colors are ### > -- > 2.7.4 My reading of this (the way the patch is written) is: "Messages forwarded to #fedora-diversity *may not* include planet messages, or meetbot.meeting messages, or fedocal messages, or fas group sponsorship messages. They must also include the term 'diversity'." I think you probably wanted the opposite with respect to topic. You *only* want planet, meetbot, fedocal, and fas messages.. right? If that's the case, you need the "negative lookahead" wrapped around your topic expression. -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break request: Add diversity-bot to ircbot.py
On Fri, Sep 02, 2016 at 10:41:37PM +1000, Will Thames wrote: > > On 2 Sep 2016, at 18:38, Justin W. Flory wrote: > > > Hi Will, > > > > On 09/02/2016 03:15 AM, Will Thames wrote: > >> I hope the below code review is ok. I have a lot of experience with > >> Ansible, but not much experience with Fedora code reviews. I'm just > >> reviewing what I can see from the patch - if anyone can point me at > >> where I can actually see the repo, that would be helpful. > >> > > > > You can find the source code for the file I'm patching here: > > > > > > https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/fedmsg/irc/templates/ircbot.py > > > >> > >> This looks like there could be a for loop in the template, rather than > >> pretty much hardcoding the bot specification for each list. > >> > >> The code pattern {% if env == "staging" %} is a bit of a red flag > >> (mostly because it leads to problems later where you add a new non-prod > >> env). Really you should be using group variables. So you might have a > >> default bot_suffix of "", and then the staging group (or whichever group > >> is responsible for setting env to staging) would have a bot_suffix of "-s" > >> > >> Will > >> > > > > Not sure if this is an issue with my patch or the file as a whole. Let > > me know if this clarifies the patch. > > I’d consider tidying up the file to just: > > config = dict( > irc=[ > {% for bot in chatbots %} > dict( > network=‘{{ bot.network|default(“chat.freenode.net”) }}', > port={{ bot.port|default(6667) }}, > make_pretty={{ bot.pretty|default(True)|bool }}, > make_terse={{ bot.terse|default(True)|bool }}, > > nickname=‘{{ bot.nickname[env] if env in bot.nickname else > bot.nickname[‘default’] }}', > > channel=‘{{ bot_channel }}', > > filters=dict( > topic=[ {{ filters.topic|join(‘,’) }} ], > body=[ {{ filters.body|join(,) }} ], > ), > ), > {% endfor %} > ] > ) > > And then just have vars/main.yml define the bots. > > chatbots: > - nickname: > default: fedmsg-apps > staging: fedmsg-apps-s > channel: fedora-apps > etc +100 to the concept from Will here. Will, just by way of explanation, we're currently in an infrastructure freeze for the Fedora release cycle, which means that we want to minimize changes to the infra. Justin sent this to the list because (by policy) we require two +1s from members of the sysadmin-main group before changes can be applied during freeze. We want any changes to be as simple as possible (so we can be sure it won't explode the world) and easily revertable. Your suggestions are great.. but let's wait until after the freeze is up to refactor that stuff. :) signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Breaking distgit-stg
On Tue, Jul 19, 2016 at 06:12:35PM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > As part of his Google Summer of Code Vivek Anand has been working on adjusting > pagure so that it would fit our needs to run it on the top of distgit. > > All the changes have been merged now and our cloud instance is looking quite > good: http://209.132.184.205/ Cool. :) > So I would like to hereby request the permission to break distgit in stg by > dropping cgit and replacing http://pkgs.stg.fedoraproject.org/ by pagure, > or maybe more http://pkgs.fedoraproject.org/pagure/ by pagure so that it > doesn't > block accessing the other endpoints available at pkgs.fp.o. The modularity working group is currently using pkgs.stg.fp.o as part of our tooling (we have some module definitions stored there). We can probably work around it temporarily if it is broken, but we were hoping to demo our tools at Flock in conjunction with some pieces of staging infra. How long do you expect it will be broken? Oh, also, I know the OSBS infrastructure that maxamillion has been setting up has been using stg dist-git's other namespaces.. and that's under active work too I think. Does the new pagure work support namespaces for modules/foo, docker/foo, and rpms/foo? -Ralph signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: [release] fmn.consumer: 1.0.0
On Fri, Jul 15, 2016 at 04:58:48PM +0200, Pierre-Yves Chibon wrote: > - (@pypingou) #76, Redesign the architecture of fmn.consumer > https://github.com/fedora-infra/fmn.consumer/pull/76 This is great. Thanks Pierre :) signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: zodbot upgraded
On Mon, Jun 27, 2016 at 04:27:59PM -0600, Kevin Fenzi wrote: > I've completed the upgrade of zodbot to limnoria. https://github.com/ProgVal/Limnoria Awesome! Thanks Kevin. :) signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Systems (and ideas) for Modularity
I see that someone reorganized the demo videos on our fedorapeople space. They're in this dir now: https://fedorapeople.org/groups/modularity/sprint-5-demo/ ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Systems (and ideas) for Modularity
Hey all, The Modularity Working Group[1] is doing the "sprint" thing to organize work. We just completed a sprint, and have some demo videos up. The full list will be on youtube[2] later today, but we stage them on fedorapeople.org[3]. I wanted to point out a wiki page where we've been trying to write up ideas about what we'll need to change in infra/apps[4]. I've got a video in the demo set that just talks over that page and the diagrams there [5]. Some prototype code is being kicked around for various pieces of all that stuff, but before we get too far along down any particular route, I wanted to get it in front of this group. I'll be around in IRC if you want to talk about it and of course we can discuss it on list here. I can try to make it to the infra IRC meeting next week too if that would be a helpful venue. (If you hate all of it.. that's ok. Let's talk and figure out a plan we all like.) Yours- -Ralph [1] https://fedoraproject.org/wiki/Modularity_Working_Group [2] https://www.youtube.com/playlist?list=PLcwHJG45BmAMQM2nRKSWKuBFWdFVLLMJd [3] https://fedorapeople.org/groups/modularity/ [4] https://fedoraproject.org/wiki/Modularization/Infra [5] https://fedorapeople.org/groups/modularity/sprint5demo-threebean.ogv signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
[release] fedmsg_meta_fedora_infrastructure: 0.17.4
0.17.4 -- Pull Requests - (@ralphbean) #375, Return the package associated with a bz update. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/375 - (@AdamWill) #376, openQA: revise meta processor for pending new message format https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/376 - (@ralphbean) #378, Handle some namespaced scm things. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/378 - (@ralphbean) #381, Fix up the test suite. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/381 Commits - 7dc58687d Return the package associated with a bz update. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/7dc58687d - 8b6f5bdae openQA: revise meta processor for pending new message format https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/8b6f5bdae - 9d8c44d75 Handle some namespaced scm things. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/9d8c44d75 - ab39be0de Also allow rpms-checks. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/ab39be0de - 8beb2d316 Make the order here independent of the hash seed. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/8beb2d316 - 2d71a8526 Explicit unicode here. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/2d71a8526 - ea01d17a7 Update tox.ini to run the tests on things we know we need (six-1.3 is gone from old rhel now). https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/ea01d17a7 - 52468da55 Make py3 happy (cannot sum over type dict_keys). https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/commit/52468da55 ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze Break request: sync up fedmsg rules
On Wed, Apr 20, 2016 at 09:54:53AM -0600, Kevin Fenzi wrote: > Greetings. > > I'd like to run: > > time ansible-playbook /srv/web/infra/ansible/master.yml -t > fedmsgdconfig,fedmsgmonitor > > ie, the fedmsgdconfig and fedmsgmonitor tags over all hosts. > > The reason is that we added a new fedmsg cert for the not yet active > ppc-hub. So, this shouldn't change much at all, but it will make the > daily ansible check-diff report much more readable and apparent when > something is changed. > > +1s? +1 here! signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: [release] anitya: 0.9.1
On Tue, Apr 19, 2016 at 03:03:58PM +0200, Pierre-Yves Chibon wrote: > It should cut the list of failed update of ~200 projects :) Nice! :) signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: PS1 configuration
On Thu, Apr 07, 2016 at 10:28:54AM -0600, Kevin Fenzi wrote: > On Wed, 6 Apr 2016 17:39:27 -0400 > Zach Villers wrote: > > > Hello infra, > > > > First apologies for blowing up your inbox with ansible commits. > > > > Second - if you have a chance, please log into these machines before > > thursday's meeting and look at your prompt. You should see a red > > "[PROD]" before your normal prompt on the production machine and a > > regular color "[STG]" on the stage machine. If you dont, would you > > kindly let me know what shell you are using and what terminal > > emulator? > > > > badges-backend01.phx2.fp.o > > > > and > > > > badges-backend01.stg.fp.o > > Yeah, it's working here. I am not sure I like the red for PROD. > > I guess its an indicator to be carefull, but we are anyhow, and red > seems overkill. Perhaps yellow would be better? and blue or green for > stg? That sounds good to me too. Nice work! signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
[release] the-new-hotness: 0.7.3
0.7.3 - Pull Requests - (@phracek)#108, Fixes #107: Detect if file exists or is not empty https://github.com/fedora-infra/the-new-hotness/pull/108 - (@ralphbean) #109, Correct another instance of mis-used six.iteritems(). https://github.com/fedora-infra/the-new-hotness/pull/109 - (@phracek)#111, Fixes #110: This does not really fix the problem. Log about attaching is https://github.com/fedora-infra/the-new-hotness/pull/111 - (@ralphbean) #112, This dict expects a 4-tuple everywhere else in the code. https://github.com/fedora-infra/the-new-hotness/pull/112 - (@phracek)#114, Fix #113 Text in bugzilla has to be clear. https://github.com/fedora-infra/the-new-hotness/pull/114 - (@ralphbean) #115, Handle OSError from 'rm'. https://github.com/fedora-infra/the-new-hotness/pull/115 - (@phracek)#118, Check if dir exists before deleting https://github.com/fedora-infra/the-new-hotness/pull/118 - (@ralphbean) #120, Check if rawhide_version == upstream_version first. https://github.com/fedora-infra/the-new-hotness/pull/120 Commits - 71d7b2151 Fixes #107: Detect if file exists or is not empty https://github.com/fedora-infra/the-new-hotness/commit/71d7b2151 - 1a88414ea Correct another instance of mis-used six.iteritems(). https://github.com/fedora-infra/the-new-hotness/commit/1a88414ea - a99c1fbda Fixes #110: This does not really fix the problem. Log about attaching is valid only in case really attach. https://github.com/fedora-infra/the-new-hotness/commit/a99c1fbda - c6459c2cc This dict expects a 4-tuple everywhere else in the code. https://github.com/fedora-infra/the-new-hotness/commit/c6459c2cc - d7e91ba3f Fix #113 Text in bugzilla has to be clear. https://github.com/fedora-infra/the-new-hotness/commit/d7e91ba3f - 38ee2caf6 Update text once again with feedback from @pnemade. https://github.com/fedora-infra/the-new-hotness/commit/38ee2caf6 - 83f524842 Handle OSError from 'rm'. https://github.com/fedora-infra/the-new-hotness/commit/83f524842 - 77e30b3a9 Check if dir exists instead. https://github.com/fedora-infra/the-new-hotness/commit/77e30b3a9 - 53cbda5df Check if dir exists before deleting https://github.com/fedora-infra/the-new-hotness/commit/53cbda5df - 48bcd0048 Check if rawhide_version == upstream_version first. https://github.com/fedora-infra/the-new-hotness/commit/48bcd0048 - 3a2b1b834 .. but do also publish in this case. https://github.com/fedora-infra/the-new-hotness/commit/3a2b1b834 ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Bugzilla+fedmsg, 2016-03-29
On Tue, Mar 29, 2016 at 02:17:33PM -0400, Ralph Bean wrote: > The fedora-packages webapp currently doesn't cache bugzilla > information because it needs a fedmsg event to invalidate the cache -- > but now we have one! A patch for this is here now: https://github.com/fedora-infra/fedora-packages/pull/232 See this post for background information on how that thing works: http://threebean.org/blog/history-of-fedora-packages/ signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Bugzilla+fedmsg, 2016-03-29
On Thu, Mar 24, 2016 at 10:33:16AM -0400, Ralph Bean wrote: > There's a Bugzilla outage scheduled for 00:00 2016-03-29 UTC. > > If everything goes to plan, bugzilla should start transmitting > messages about changes to bug tickets shortly after this outage is > complete. We have a mediator service running and ready that should > receive those and rebroadcast them to our fedmsg bus. > > Please keep party streamers and confetti on standby. This is all in place and working now. As a point for discussion (maybe we can take it up in the Thursday meeting or here on list): now that we have the data stream, what would we like to do with it? I know in the past we wanted it for awarding badges in badges.fp.o. It will be useful for preparing metrics for presentations at Flock, etc.. The fedora-packages webapp currently doesn't cache bugzilla information because it needs a fedmsg event to invalidate the cache -- but now we have one! Same goes for fedora-hubs in the future. What else can we come up with? signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: buildvmhosts and buildvms reboot for multipath iscsi
On Thu, Mar 24, 2016 at 08:05:29AM -0600, Kevin Fenzi wrote: > Greetings. > > It seems that somehow our buildvmhost-10/11/12 machines are not > currently properly multipathed to the iscsi on the netapp. > > Normally, multipath means there's a number of ways to reach the iscsi > lun and the machine will use whichever one. With only one path (as it > is now), all our iscsi connections will die next week when there's a > netapp storage outage. > > So, I would like to in turn take out buildvm's from koji, let them > finish building and reboot the buildvmhost to get multipath back on > track. I tried restarting the service, but that didn't do any good, > it's in a weird state (likely from iscsi issues a number of weeks > back). > > Since we have signed off on Alpha, the buildvm's aren't critical to > it's release. > > +1s? +1 here. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Bugzilla+fedmsg, 2016-03-29
There's a Bugzilla outage scheduled for 00:00 2016-03-29 UTC. If everything goes to plan, bugzilla should start transmitting messages about changes to bug tickets shortly after this outage is complete. We have a mediator service running and ready that should receive those and rebroadcast them to our fedmsg bus. Please keep party streamers and confetti on standby. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break request: Update Autocloud for latest pungi/koji fedmsg updates
On Wed, Mar 23, 2016 at 11:11:49PM +0530, Kushal Das wrote: > Hi all, > > I am applying for a freeze break request for Autocloud project. We need > to be able to get koji build state changes from fedmsg so that we can > test F24, and rawhide Cloud/Atomic builds. The following [1] hotfix patch is > made for the same based on the similar change in fedimg. > > [1] > https://github.com/kushaldas/autocloud/commit/6d0a1ea6268f052e258458d1ad09b1cd16d9b9cf +1 here. (Although take a look at the inline comments all throughout that consumer code. It mentions 'uploading', but autocloud doesn't do any uploading. fedimg does though.. copy/paste holdovers? Let's fix those so they don't confuse future developers.) signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: pkgs git config
On Mon, Mar 21, 2016 at 09:31:57AM -0600, Kevin Fenzi wrote: > Sadly, while this change fixes new fedpkg/pyrpkg, it breaks old fedpkg. > > I have reverted it for now and Ralph and Pingou are looking for a > better solution. It was fun. We read the C code for git-daemon and ultimately resolved it as a problem with our selinux policy. We fixed that and re-rolled out Kevin's original change. Should be all working in prod now. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: pkgs git config
On Sun, Mar 20, 2016 at 04:38:40PM -0600, Kevin Fenzi wrote: > Greetings. > > It seems there is a fedpkg/pyrpgk update that depends on using the > namespaced (/rpms/) git checkouts. > > I'd like to apply the following to pkgs02: > > diff --git a/inventory/group_vars/pkgs b/inventory/group_vars/pkgs > index 2ebef26..fa29449 100644 > --- a/inventory/group_vars/pkgs > +++ b/inventory/group_vars/pkgs > @@ -18,7 +18,7 @@ git_group: packager > git_port: 9418 > git_server: /usr/libexec/git-core/git-daemon > git_server_args: --export-all --syslog --inetd --verbose > -git_basepath: /srv/git/repositories/rpms > +git_basepath: /srv/git/repositories > git_daemon_user: nobody > > clamscan_mailto: ad...@fedoraproject.org > > and then make sure we are using the systemd git socket instead of > xinetd (which we seem to be for some reason currently). > > This should allow namespaced git checkouts and fix: > > https://fedorahosted.org/fedora-infrastructure/ticket/5178 > and > https://fedorahosted.org/fedora-infrastructure/ticket/5059 > > I also have already made this change in stg a while back and it works > fine there. +1 here signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Freeze Break Request: Turn on fedmsg for PDC
We currently use a fedmsg-driven daemon to update PDC about stuff that gets composed by pungi. This patch turns on a new layer that lets PDC publish its own messages when it gets updated (the software comes with fedmsg as one of four different message-publication methods it can use, which is cool!) adamw wants to use these new messages to drive the validation event creation project. The iptables rules and the fedmsg.d/ endpoints and the certs were all set up when I first stood up PDC.. this patch just turns on the plugin, and adds the one topic PDC produces to our fedmsg policy. I'll have to do a master.yml playbook run of the 'fedmsgdconfig' tag, which will touch all hosts.. but I expect this will be "fine". Can I get two +1's to push this out? diff --git a/inventory/group_vars/pdc-web b/inventory/group_vars/pdc-web index f07deb7..59073da 100644 --- a/inventory/group_vars/pdc-web +++ b/inventory/group_vars/pdc-web @@ -29,6 +29,5 @@ fedmsg_certs: - service: pdc owner: root group: apache - # We don't have notifications from PDC yet, but when we do, add them here. - #can_send: - #- pdc.somethingorother + can_send: + - pdc.compose diff --git a/inventory/group_vars/pdc-web-stg b/inventory/group_vars/pdc-web-stg index 1c55f07..a7e45f9 100644 --- a/inventory/group_vars/pdc-web-stg +++ b/inventory/group_vars/pdc-web-stg @@ -29,6 +29,5 @@ fedmsg_certs: - service: pdc owner: root group: apache - # We don't have notifications from PDC yet, but when we do, add them here. - #can_send: - #- pdc.somethingorother + can_send: + - pdc.compose diff --git a/roles/pdc/frontend/templates/settings_local.py b/roles/pdc/frontend/templates/settings_local.py index 2d021a5..256260c 100644 --- a/roles/pdc/frontend/templates/settings_local.py +++ b/roles/pdc/frontend/templates/settings_local.py @@ -10,6 +10,11 @@ # settings, please remember to update your settings_local.py # when the items you extended got updated in settings.py. +# Turn on the fedmsg publishing plugin. +MESSAGE_BUS = { +'MLP': 'fedmsg', # MLP: Messaging Library Package +} + REST_FRAMEWORK = { 'DEFAULT_AUTHENTICATION_CLASSES': ( 'pdc.apps.auth.authentication.TokenAuthenticationWithChangeSet', signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze Break Request: Turn on fedmsg for PDC
This has been applied and is being pushed out. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: db01 tuning
On Tue, Mar 15, 2016 at 09:21:52AM -0600, Kevin Fenzi wrote: > Greetings. > > I was going to wait until after freeze to mess with the other > postgresql hosts, but then mattdm pointed out this morning that > hyperkitty is really slow currently. I'm not sure this will help, but > it really make db-koji01 a great deal happier and it should be pretty > easy to revert if needed. > > So, I'd like to make the same changes that made db-koji01 happy to > db01: +1! signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: do not redirect staging websites
On Mon, Mar 14, 2016 at 12:22:29PM +0100, Robert Mayr wrote: > Ok this is for staging websites, but it's a change in ansible and we change > some pre_tasks, so I ask for +1s to be sure. > > Staging websites should not redirect prerelease pages, but show them > normally (while production must still redirect them to the main page). We > are just before readiness and should at least test them out. > I'd comment out the rules for staging as in the diff below, if we need to > drop also the config files on the proxies, I attach a diff also for > playbooks/groups/proxies.yml. > Thanks. +1 to the idea. However, I think I found a bug: > diff --git a/playbooks/groups/proxies.yml b/playbooks/groups/proxies.yml > index 90d5001..1b46198 100644 > --- a/playbooks/groups/proxies.yml > +++ b/playbooks/groups/proxies.yml > @@ -74,17 +74,33 @@ ># When we have a prerelease we also need to drop the ># config files. > > - - name: Remove prerelease-to-final-spins > -file: > path=/etc/httpd/conf.d/spins.fedoraproject.org/prerelease-to-final-spins.conf > state=absent > + - name: Remove prerelease-to-final-spins-1 > +file: > path=/etc/httpd/conf.d/spins.fedoraproject.org/prerelease-to-final-spins-1.conf > state=absent > +when: env == 'staging' Look in /etc/httpd/conf.d/blah.fp.o/ on the proxy01.stg node and see that the file name you're trying to remove here has the role name appended to it. So, it's not prerelease-to-final-spins.conf but instead is: prerelease-to-final-spins-redirectmatch.conf Longer term, it is kind of annoying that when we comment out one of those roles, we have to go back and add pre_tasks to clean up. Perhaps we should add a state=absent argument to the role itself so that it knows how to clean itself up. (Let's save that until after freeze.) signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Technical debt fighting week, round #2
On Wed, Mar 09, 2016 at 11:23:01AM -0500, Ralph Bean wrote: > On Tue, Mar 08, 2016 at 11:26:49AM -0500, Ralph Bean wrote: > > On Tue, Mar 08, 2016 at 05:21:20PM +0100, Pierre-Yves Chibon wrote: > > > To keep people motivated and involved, we will do a short (<15minutes) > > > daily-meetup on #fedora-admin at 16:00 UTC. > > > Feel free to join there as well, it will be a good place to sync up work > > > done > > > and work remaining. > > > > Here are the logs from today's first meeting: > > > > https://meetbot.fedoraproject.org/fedora-admin/2016-03-08/infra_tech_debt_week.2016-03-08-16.02.log.html > > Here are the logs from the meeting on day 2: > > https://meetbot.fedoraproject.org/fedora-admin/2016-03-09/infra_tech_debt_week.2016-03-09-16.03.log.html We didn't have a meeting yesterday, but here are the logs from day 4: https://meetbot.fedoraproject.org/fedora-admin/2016-03-11/infra_tech_debt_week.2016-03-11-16.04.html signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze Break Request: Let openqa01.qa publish to the fedmsg bus
On Thu, Mar 10, 2016 at 04:56:15PM -0500, Ralph Bean wrote: > We want openqa01 to publish to the fedmsg bus (adamw's project) for some > integrations that releng/qa are working on for the release. > > The patch below does two things: > > - It whitelists the ip for openqa01 on the inbound fedmsg relay. We need this > since openqa01 is in the qa net, so it has to jump through hoops to > get to our bus. > - It adds conditionals to the fedmsg/base role so that the > ansible configuration we lay out on disk has all the right bits for > an external host like openqa01. This has been applied and pushed out. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Freeze Break Request: Let openqa01.qa publish to the fedmsg bus
We want openqa01 to publish to the fedmsg bus (adamw's project) for some integrations that releng/qa are working on for the release. The patch below does two things: - It whitelists the ip for openqa01 on the inbound fedmsg relay. We need this since openqa01 is in the qa net, so it has to jump through hoops to get to our bus. - It adds conditionals to the fedmsg/base role so that the ansible configuration we lay out on disk has all the right bits for an external host like openqa01. Can I get two +1s for this? diff --git a/inventory/group_vars/proxies b/inventory/group_vars/proxies index 53a291b..3122f29 100644 --- a/inventory/group_vars/proxies +++ b/inventory/group_vars/proxies @@ -63,6 +63,8 @@ custom_rules: [ # Allow resultsdb talk to the inbound fedmsg relay. '-A INPUT -p tcp -m tcp --dport 9941 -s 10.5.124.207 -j ACCEPT', +# Allow openqa01 to talk to the inbound fedmsg relay. +'-A INPUT -p tcp -m tcp --dport 9941 -s 10.5.131.71 -j ACCEPT', ] fas_client_groups: sysadmin-noc,fi-apprentice diff --git a/roles/fedmsg/base/tasks/main.yml b/roles/fedmsg/base/tasks/main.yml index c4bbe63..16d751d 100644 --- a/roles/fedmsg/base/tasks/main.yml +++ b/roles/fedmsg/base/tasks/main.yml @@ -119,7 +119,7 @@ - relay.py - logging.py - base.py - when: "'persistent-cloud' not in group_names" + when: "'persistent-cloud' not in group_names and 'qa-isolated' not in group_names" tags: - config - fedmsgdconfig @@ -152,7 +152,7 @@ - restart fedmsg-irc - restart fedmsg-relay -- name: setup basic /etc/fedmsg.d/ contents for cloud hosts +- name: setup basic /etc/fedmsg.d/ contents for firewalled/external hosts template: > src="{{ item }}.j2" dest="/etc/fedmsg.d/{{ item }}" @@ -165,7 +165,7 @@ - relay.py - logging.py - base.py - when: "'persistent-cloud' in group_names" + when: "'persistent-cloud' in group_names or 'qa-isolated' in group_names" tags: - config - fedmsgdconfig diff --git a/roles/fedmsg/base/templates/relay.py.j2 b/roles/fedmsg/base/templates/relay.py.j2 index 7973329..82cd0f9 100644 --- a/roles/fedmsg/base/templates/relay.py.j2 +++ b/roles/fedmsg/base/templates/relay.py.j2 @@ -24,7 +24,7 @@ config = dict( # It is also used by the mediawiki php plugin which, due to the oddities of # php, can't maintain a single passive-bind endpoint of it's own. relay_inbound=[ -{% if 'persistent-cloud' in group_names or 'jenkins-master' in group_names %} +{% if 'persistent-cloud' in group_names or 'jenkins-master' in group_names or 'qa-isolated' in group_names %} # Stuff from the cloud has to go through our external proxy first.. #"tcp://hub.fedoraproject.org:9941", signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: [PATCH] Fix `invalid signature!` to pagure's messages
On Wed, Mar 09, 2016 at 05:29:29PM -0500, Patrick Uiterwijk wrote: > > - Original Message - > > Pagure can send message with the topic: pagure.request.assigned.added but > > this > > is currently not allowed so we get an `invalid signature` error. > > > > Could I get a couple of +1s to push this in stg and prod? > > > > Thanks, > > > > Pierre-Yves Chibon (1): > > Allow pagure to send pagure.request.assigned.added messages > > > > +1 +1 Note that this will require a run of master.yml with -t fedmsgdconfig and then a run of restart-fedmsg-services.yml to pick up the change. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: build production websites from pagure
On Wed, Mar 09, 2016 at 10:08:58PM +0100, Robert Mayr wrote: > Recently the websites repository switched from fedorahosted to pagure and > we want to build websites now from there also for production. > Actually the websites in staging are built from pagure and we don't have > any issues so far. In order to sync out all the activity, as we are moving > more and more to Alpha, we want to switch as soon as possible. > The change is just a different checkout in our build script on sundries01. > Thank you. +1 here. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze break: restart httpd on proxies
On Wed, Mar 09, 2016 at 01:42:19PM -0700, Kevin Fenzi wrote: > I pushed some redirects out for the websites folks yesterday before > freeze, but they aren't working right. > > I'd like to restart httpd on all the proxies to pick up these current > changes. > > ie, > > ansible -a 'systemctl restart httpd' -f 1 proxies > > I have confirmed that all of them have a valid config via httpd -t, and > staging is working fine with these changes. > > In the event this causes an issue, we should fix it now anyhow, and > make sure we can restart httpd as we need closer to release. > > +1s? +1 here signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Technical debt fighting week, round #2
On Tue, Mar 08, 2016 at 11:26:49AM -0500, Ralph Bean wrote: > On Tue, Mar 08, 2016 at 05:21:20PM +0100, Pierre-Yves Chibon wrote: > > To keep people motivated and involved, we will do a short (<15minutes) > > daily-meetup on #fedora-admin at 16:00 UTC. > > Feel free to join there as well, it will be a good place to sync up work > > done > > and work remaining. > > Here are the logs from today's first meeting: > > https://meetbot.fedoraproject.org/fedora-admin/2016-03-08/infra_tech_debt_week.2016-03-08-16.02.log.html Here are the logs from the meeting on day 2: https://meetbot.fedoraproject.org/fedora-admin/2016-03-09/infra_tech_debt_week.2016-03-09-16.03.log.html signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
Re: Freeze Break Request: Forward pungi fedmsg messages to #fedora-releng
Thanks all! This has been applied. signature.asc Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org