Re: Freeze break request: koji update on builders
On Thu, 2024-04-18 at 17:14 -0700, Kevin Fenzi wrote: > In the run up to f40 final we were using a koji with a patch to _not_ > enable the builroot repo when making containers via kiwi plugin. > This was to fix the fact that pulling from the buildroot repo pulls > unsigned rpms, making all the rpms installed in the container unsigned. > > Foolishly, I pulled a newer/expansion of that patch from upstream in in > the last round of updates, but something in it's defaults/logic causes > it to not disable the buildroot repo, and again containers have unsigned > rpms. ;( > > So, what I would like to do is go back to the previous patch we had that > just has the 'only enable buildroot when no repos are passed' patch. > > Ideally we would do this today so the last f40 nightly would be right. > If not tho, we could land it anytime and then the nightly container > builds would be fixed. > > Can I get +1s for this plan? +1 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Freeze break request: update koji package on builders
On Mon, 2024-04-08 at 09:25 -0700, Kevin Fenzi wrote: > When I did the updates before final freeze, I missed updating the > builders with the latest koji package from the f39-infra tag. > > At the time for some reason I thought it didn't matter, because the > patches were all hub related, but turns out thats not the case. > > 2 of the patches affect builders: > > * One adding --debug to kiwi builds so we can see whats going on. > > * One changing it so kiwi build tasks don't use the koji buildroot for > packages. When they do this they get unsigned packages and it shows up > in the containers made with kiwi. > > So, I'd like to update all the builders to the latest f39-infra koji > package with these patches and restart kojid on them. > > +1s? +1 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Freeze break request: update pungi on compose hosts
On Wed, 2024-03-06 at 09:36 -0800, Kevin Fenzi wrote: > We need a newer pungi version that adds support for kiwi and has changes > for osbuild arm minimal. These are both things we are trying to land for > beta. > > There's a 4.6.2 release upstream that we need. > So, I'd like to build this for f39 (which our compose hosts are) and > update them. > > If something goes very wrong we should be able to just downgrade back to > the previous version. > > +1s? +1, I'm not super happy about landing these late, but that's what FESCo decided, so we should try it. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Freeze Break request: update kernel on buildhw-x86*
On Mon, 2024-03-04 at 17:52 -0800, Kevin Fenzi wrote: > Hey everyone. > > The koji builders are currently using 6.7.6-200.fc39, which is mostly > fine, but on i386 builds there's some kind of memory issue and (some) > builds run out of memory and fail. ;( > > See: https://pagure.io/fedora-infrastructure/issue/11775 > > I'd like to upgrade the buildhw-x86* builders to the latest 6.8.x > kernel. We tried this in staging and it let the build complete fine. > We only need to do those builders because those are the only ones in the > 'heavybuilder' channel that webkitgtk builds use, and the x86 ones are > the only ones that do i386 builds. ;) > > We could I suppose update all the buildvm-x86* also in case there are > other packages we don't know about that are affected, but then the > change is wider. > > So, +1s? Thoughts? +1. worst case it blows up everything, we reboot them back to 6.7, right? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Freeze Break request: update koji-flatpak on builders
On Wed, 2023-10-04 at 08:50 -0700, Kevin Fenzi wrote: > We tried to get everything working with the new flatpak building setup > before freeze, but at the last minute we ran into some issues between > bodhi and the metadata that flatpak builds store in koji. We got several > things sorted out yesterday before freeze, but there's still an issue > with the metadata we need to fix. > > See: > > https://pagure.io/fedora-infrastructure/issue/11557 > > So, I'd like to tag that build into f38-infra and update it on all the > builders and reload kojid. > > +1s? +1 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
On Thu, 2023-09-14 at 07:41 +0200, Tomas Hrcka wrote:
> Ok, now we are on the same page.
>
> On Wed, Sep 13, 2023 at 8:04 PM Adam Williamson
> wrote:
>
> > On Wed, 2023-09-13 at 16:49 +0200, Tomas Hrcka wrote:
> > > I thought this was exactly the JSON blob we will implement, If you look
> > at
> > > the model of PDC
> > >
> > https://product-definition-center.github.io/product-definition-center/_images/overview.svg
> > >
> > > Those endpoints are covered by relations Release, Compose, RPM through
> > some
> > > others.
> > > The PDC approach is more or less a normalized RDBMS model.
> > > This should be replaceable by a much simpler denormalized approach and
> > > create one entry for each compose with all the data in one place.
> >
> > That's missing the 'composes' endpoint use (#1 in my list below). Not
> > sure if that's your fault or mine, sorry if I left it out of a previous
> > list.
> >
> > Does your replacement plan cover the "previous_release" use case, where
> > we need a list of all the composes for each release in the order they
> > happened?
> >
> >
> Yes idea was to have the compose_id as a document root since it is unique
> for each compose.
> something like this:
>
> Fedora-Rawhide-20230913.n.0:{
> compose_related_metadata:[metadata0:metadata,metadata1:metadata]
> rpms:[nvr:other_rdata,nvr1:other_rdata1]
> images:{Fedora-Sway-Live-x86_64-Rawhide-20230913.n.0.iso:"some metadata"}
> }
Sure, that works. These dicts should just be straight dumps of the
metadata files from the composes - composeinfo.json, rpms.json and
images.json - e.g. the ones at
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20230913.n.0/compose/metadata/
. I'm pretty sure that's what they are in PDC already.
Note, I still don't think this covers my case #1 exactly: well, it
would probably make cid_to_label possible, but as described, I'm not
sure it would make label_to_cid possible. We can query PDC with a
release number and a label - a label is something like Beta-1.1 - and
it will return a single compose, from which we can read the compose ID.
If the proposal is essentially just a JSON dict whose keys are compose
IDs...well, I suppose technically we could grab the whole thing and do
some operations on it to find the compose with a given label, but it's
a bit more awkward than just querying. And if it's just a flat dict of
every compose ever, presumably it'll be paged, and finding the one you
want might take a while?
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: AWS gp2 -> gp3
On Wed, 2023-09-13 at 09:37 -0700, Kevin Fenzi wrote: > On Wed, Sep 13, 2023 at 11:17:41AM +0200, Miroslav Suchý wrote: > > Dne 05. 09. 23 v 17:11 Kevin Fenzi napsal(a): > > > So, I think it would be ok to just do anytime, but you can wait until > > > after freeze if you want to be extra careful. > > > > > > Freeze is over. I migrated all the remaining volumes. For the record, > > complete list is at the bottom of mail (and it is loong). > > It's actually not... we missed the early f39 beta release target, so we > are still in freeze at least another week. ;) Unfortunately the schedule has not been updated yet, I filed a ticket for this last week but I guess Aoife didn't get to it yet and I did not have access to the system that generates it. I have access now, so I'll try and update the schedule today. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
On Wed, 2023-09-13 at 16:49 +0200, Tomas Hrcka wrote: > I thought this was exactly the JSON blob we will implement, If you look at > the model of PDC > https://product-definition-center.github.io/product-definition-center/_images/overview.svg > > Those endpoints are covered by relations Release, Compose, RPM through some > others. > The PDC approach is more or less a normalized RDBMS model. > This should be replaceable by a much simpler denormalized approach and > create one entry for each compose with all the data in one place. That's missing the 'composes' endpoint use (#1 in my list below). Not sure if that's your fault or mine, sorry if I left it out of a previous list. Does your replacement plan cover the "previous_release" use case, where we need a list of all the composes for each release in the order they happened? Thanks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
pretty PDC version and rely on HTML scraping forever (sob). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
On Mon, 2023-09-04 at 16:51 +0200, Tomas Hrcka wrote: > > Current uses of PDC: > >1. > >Critical Path Package Tracking: Bodhi leverages PDC to track packages on >the critical path. > > /rest_api/v1/component-branches/: Specifically, Bodhi will handle the > critical-path flag. > > Bodhi's existing framework aligns well with releases and components. To > enhance this, we will create an auxiliary table that pairs this data with > additional metadata, > > predominantly focusing on the critical-path flag. Previously, we had to > query this information from PDC. > > It's essential to note that PDC is not the definitive source of truth for > critical-path packages. The Fedora Project Critical Path Package Wiki > indicates that the source of truth lies within the Fedora Comps repository. > > You can find specific information by searching for groups with the > "critical-path-*" prefix, as demonstrated here. > > While the data is accessible through DNF, generating it can be > time-consuming. PDC serves as a pre-computed cache. > > Previously, we followed this process to update it, but now we have > transitioned to using this method. > > The primary application of this information during the Fedora release cycle > is in Bodhi, where it is used to enforce stricter requirements on > critical-path package updates. For further details, please refer to this > link. This is all done already. I did it months ago: https://github.com/fedora-infra/bodhi/pull/4755 https://github.com/fedora-infra/bodhi/pull/4759 https://pagure.io/fedora-infra/ansible/pull-request/1294 https://pagure.io/fedora-infra/ansible/c/fea60aab95bd45960dbf4a0514c5df28a86090eb?branch=main https://pagure.io/fedora-infra/ansible/c/842db118e88b987dbb5ab98f4d17556aba0601d6?branch=main We no longer use PDC for critical path information and, indeed, we dropped the code for doing so from Bodhi last month: https://github.com/fedora-infra/bodhi/pull/5431 BTW, the email seems kind of weird. There are lots of places where it seems like it's referring to external information - "as demonstrated here", "Previously, we followed this process to update it, but now we have transitioned to using this method" - but it does not actually link to anything external, so I have no idea what the references are meant to be? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: congrats to another new sysadmin-mainer
On Wed, 2023-08-09 at 10:15 -0700, Kevin Fenzi wrote: > I'm happy to announce that We have approved a new member in our > sysadmin-main group: > > adamwill - Adam Williamson > > This is the core group of trusted folks that high level access to most > everything in fedora infrastructure. > > Adam has been around for a long time and has setup and run Fedora's > OpenQA instance. In addition he's done tons of work on bodhi, packages, > and too many other places to mention as well as testing everying and > making sure releases and rawhide are working. > > He has proved his dedication, trustworthiness, and ability. > > Congrats! > > Use your powers for good! :) Thanks kevin, and everyone! I'll try not to break too much stuff... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: This list and discussion.fedoraproject.org
On Tue, 2023-04-25 at 14:21 -0700, Kevin Fenzi wrote: > As some of you who follow the devel list may know, Matthew put forward > the idea of starting to move some discussion over to > discussion.fedoraproject.org (our hosted dicourse instance) instead of > the mailing list. > > For those of you who don't know: > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/Z2T5WKUTHNLS2SVCVAWNYYRIBK3NGF32/ > (and the long thread after it). > > Please do read that. I'll wait. > > ok. So, my question is: > > Should we look at moving to discussion.fedoraproject.org instead of this > list? We have a tag there already. > > I've personally setup discourse to email me things, so it actually ends > up being very similar to a list, with a few corner cases. I'm happy to > help anyone who has trouble with that setup. I could live with it fine. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-simplemediawiki
On Tue, 2023-04-25 at 08:06 +, Mattia Verga via devel wrote: > I'm going to orphan python-simplemediawiki. Upstream is long time dead > and the github repository was archived in 2018. > > It was used by Bodhi backend to fetch TestCases information from Fedora > Wiki, but Bodhi 7.1 switched to python-pymediawiki. I cannot find any > other use in fedora infrastructure. FWIW, if you want to de-duplicate effort a bit and are only maintaining python-pymediawiki for this purpose, I maintain python-mwclient: https://src.fedoraproject.org/rpms/python-mwclient because python-wikitcms depends on it. We use python-wikitcms for creating and submitting results to the validation event pages on the wiki, so I'm tied into maintaining it as long as we're using the wiki for results. So possibly we could have Bodhi move to *that*, and drop python-pymediawiki. I'm also now a maintainer of mwclient upstream, since the original maintainer went inactive and I got roped in to help out... Of course, if you're happy maintaining/using pymediawiki, there's no need to switch, just thought I'd mention the possibility. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: AWS gp2 -> gp3
On Tue, 2023-04-04 at 14:50 -0700, Kevin Fenzi wrote: > On Mon, Apr 03, 2023 at 07:12:47PM -, David Duncan wrote: > > Awesome news. We will add all of the flags once they are approved. There > > are three that we are focused on in the cloud instances: > > 1) gp2 volumes by default -> gp3 volumes by default > > I'm still unsure if that means we only do gp3 or what is the list of > ones we do after this change? > > > 2) IMDSv1 fallback -> IMDSv2 required. > > 3) classic bios boot -> uefi-preferred boot. > > Are Fedora-Cloud images all set for uefi? I can answer that - yes. We switched most openQA tests of the Cloud image to UEFI some time ago. See e.g. https://openqa.fedoraproject.org/tests/overview?distri=fedora=Rawhide=Fedora-Rawhide-20230406.n.0=1 , at the top, tests for Cloud_Base-qcow2-qcow2 , most of the tests are @uefi (we still run a couple on BIOS to make sure BIOS still works). I don't know if there are any additional complications with the process of getting them into AWS and booting them there, but the images themselves definitely boot fine on UEFI in VMs. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RHEL9 migration
On Wed, 2022-09-28 at 11:44 -0700, Kevin Fenzi wrote: > > > choice. We really ought to be able to sort out getting off PDC before > > RHEL 8 kicks the bucket. I'm kinda kicking the tires on a plan to move > > critpath handling into Bodhi at the moment, for one thing. > > Yeah, we should definitely git rid of pdc... just need to move > everything we use it for off. Might be good to sit down some folks and > write up a detailed plan so we can poke at it. ISTR there was already some effort to come up with a list of existing uses. At least I remember an email along those lines going out which I replied to with a detailed list of the things I'm involved in that use it. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RHEL9 migration
On Tue, 2022-09-27 at 09:00 -0400, Stephen Smoogen wrote: > On Mon, 26 Sept 2022 at 17:56, Kevin Fenzi wrote: > > > Here's my thoughts on rhel9 upgrades. > > > > We have 188 RHEL7 or RHEL8 instances (counting both vm's and bare > > hardware). > > > > > > Some will just not move anytime soon: > > > > > Is it possible to look at these as 'why does this need fedmsg?' 'what > happens if it doesn't have fedmsg', and 'do we need it?' FWIW, while I'm one of the holdouts on still needing PDC, I don't think anything I do with PDC relies on it publishing messages. Don't know if any other use cases of PDC do. I do think we need to sort out the key use cases of PDC before getting rid of it, but leaving it on RHEL 8 seems like it'd be a reasonable choice. We really ought to be able to sort out getting off PDC before RHEL 8 kicks the bucket. I'm kinda kicking the tires on a plan to move critpath handling into Bodhi at the moment, for one thing. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Debugging Datanommer performance issues
On Thu, 2022-08-11 at 10:18 +0200, Michal Konecny wrote: > Hi Aurelien, > > I think that the option 1 should work, the new messages in staging > should still show up in the datagrepper and I don't think anybody cares > about the messages that were already processed. I have done in the past. If it's absolutely necessary I guess it'd be OK, but I wouldn't jump right to it because 'nobody cares'. If the requirement is just to run DB queries, just cloning the DB somewhere seems like the obvious best option if we do have the space to do it. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FMN replacement: CI message schema tool
On Fri, 2022-07-08 at 09:22 +0200, Aurelien Bompard wrote: > > Hey, folks. Just a note on the FMN replacement plan - as part of > > that > > involves making sure important things have fedora-messaging message > > schemas, I thought I'd link to a thing I wrote a while back which > > may > > be handy: > > > > https://pagure.io/fedora-qa/python-ci_messages > > > Thanks Adam, I'll add it to my list of schema packages, and we can > start > using it right away, for example in datagrepper :-) > However, the page says that the tarballs are published on > https://pypi.org/project/ci-messages/ and they apparently haven't > been > uploaded yet. OK, this is fixed now, sorry for the trouble. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FMN replacement: CI message schema tool
On Fri, 2022-07-08 at 09:22 +0200, Aurelien Bompard wrote: > > Hey, folks. Just a note on the FMN replacement plan - as part of > > that > > involves making sure important things have fedora-messaging message > > schemas, I thought I'd link to a thing I wrote a while back which > > may > > be handy: > > > > https://pagure.io/fedora-qa/python-ci_messages > > > Thanks Adam, I'll add it to my list of schema packages, and we can > start > using it right away, for example in datagrepper :-) > However, the page says that the tarballs are published on > https://pypi.org/project/ci-messages/ and they apparently haven't > been > uploaded yet. Ah, yeah, it looks like I never actually got to the point of publishing it to pypi when I wrote it. I'm dealing with that now but it's become a bit of a yak shave - I am now, uh, trying to fix dill for Python 3.11 to try and make pylint's tests pass so I can try updating pylint to see if it fixes a bogus error pylint is throwing with Python 3.11. This is one hairy yak. Anyhow, yeah, I'm on it. :P -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FMN replacement: CI message schema tool
Hey, folks. Just a note on the FMN replacement plan - as part of that involves making sure important things have fedora-messaging message schemas, I thought I'd link to a thing I wrote a while back which may be handy: https://pagure.io/fedora-qa/python-ci_messages basically, there's already a schema for CI messages (ci.*), but it's a JSON schema: https://pagure.io/fedora-ci/messages python-ci_messages is a 'wrapper' that provides a fedora-messaging schema representation of the JSON schemas. I haven't tested it since I wrote it, but I think it should still more or less work. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bodhi's move to OIDC
On Tue, 2022-02-01 at 11:17 -0800, Kevin Fenzi wrote: > On Tue, Feb 01, 2022 at 06:15:59PM +0100, Aurelien Bompard wrote: > > Hey folks! > > > ...snip background... > > > > Weirdness aside, I'm wondering if this could hurt people who may run > > the bodhi client CLI on a headless server. The browser must be opened > > on the same host where the CLI is running. There could be a way around > > that but it would need a (minor, according to Patrick) addition to > > Ipsilon. (this workaround does not involve starting elinks instead) > > I think the workaround might be welcome here for these people who do hit > this case. Or documentation on how to run it on a workstation with a > local browser and move/copy the token to the headless place? > > > So, I have questions: > > - Do any of you run the bodhi CLI on a headless server instead of on > > their workstation? > > Yes. bodhi-backend01. ;) > ie, we need to make sure releng can auth to do pushes still and the > automated cron that does pushes still works. Isn't the 'workaround' for cases like this just to issue a non-expiring token? That's what we do for e.g. things in infra that need to edit the wiki... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Is anyone using greenwave 'decision update' fedora-messaging messages?
Hi folks! So, greenwave publishes these 'decision.update' messages: https://apps.fedoraproject.org/datagrepper/id?id=2022-04ed73bc-25ca-4dfc-9530-aa5635135f06_raw=true=extra-large Up until relatively recently, they were used by Bodhi to update gating status for updates. But I figured that was a bad design for various reasons, and changed Bodhi to do it differently[0]. I'm not aware of anything else that uses these messages, I think they're bad design, and I'd like to submit a greenwave PR to remove all the code that's used to produce them (it would substantially simplify greenwave). But before doing that, it seems a good idea to ask if anyone's aware of anything else that uses them. I believe Kevin told me no native fedora-messaging consumers seem to be subscribed to that topic, but it is possible something could be consuming them via the fedmsg bridge. Thanks folks! [0] https://github.com/fedora-infra/bodhi/pull/4230 -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Ticket notifications in IRC
On Tue, 2021-07-13 at 10:03 -0700, Kevin Fenzi wrote: > On Tue, Jul 13, 2021 at 08:30:29PM +1000, Ryan Lerch wrote: > > On Tue, Jul 13, 2021 at 8:23 PM Aurelien Bompard > > wrote: > > > > > > Hey folks! > > > > > > We currently have messages posted on the #fedora-apps and > > > #fedora-infrastructure IRC channels when there's a ticket change or a > > > pull-request change. I don't know about the infrastructure channel, but > > > it makes it difficult to have a development conversation in #fedora-apps, > > > the signal/noise ratio is just too low. > > > > > > Are you all happy with this setup? I would like to propose we move those > > > notifications to a different channel, such as #fedora-apps-activity (and > > > #fedora-infrastructure-activity). Otherwise I can go have my development > > > discussions in another channel, it's fine too. > > > > > > What do you think? > > > > Yes -- i agree with moving the notifications to a separate channel. > > > > I actually had a PR to change this already -- but just hadnt filed it > > yet. -- i have now: > > > > https://pagure.io/fedora-infra/ansible/pull-request/683 > > I guess we can do this... I just dispair for irc channel sprawl. > ;( > > Is any level of messages useful in #fedora-apps? > > Are there going to be any people who join a #fedora-apps-activity ? > > I mean, we could just also drop it entirely if people don't want it. > Or adjust it so only 'important' things go there. I do find the level of messages pretty overwhelming. Especially when we're getting stuff like "edited the priority fields of ticket blah" and "assigned ticket blah to blah". It does make it very difficult to see actual conversations in the backscroll. It does seem interesting that other groups don't do this and seem to function. We don't have all the QA-related trackers notifying #fedora- qa every time anyone touches a ticket, yet things still seem to work and the tickets aren't ignored... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Older Fedora use in infrastructure
On Mon, 2021-05-03 at 18:10 -0700, Kevin Fenzi wrote: > > We have a new bodhi release, we should build the rpms on F34 and move > these up: > > bodhi-backend01.iad2.fedoraproject.org > bodhi-backend01.stg.iad2.fedoraproject.org Just a reminder that when we do this, automatic update gating on openQA results will kick in. So we'll want to be on high alert for rampaging mobs of angry maintainers. And probably don't do it on a Friday evening. :D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ancient backups of the moinmoin wiki?
On Mon, 2020-11-16 at 11:01 -0800, Kevin Fenzi wrote: > On Mon, Nov 16, 2020 at 12:58:12PM -0500, Matthew Miller wrote: > > This is a long shot, I know. When we converted to MediaWiki from MoinMoin in > > 2008, pages were imported, but history was lost. I often like to go > > spelunking in the past, and it's often frustrating to hit this barrier. > > > > As I recall, MoinMoin stored everything in flat files, so it wouldn't even > > really need to be stood up again to get a look at the history. If someone > > happened to keep it, that is. Is there any chance we have a tarball snapshot > > of the wiki circa 2008? > > yes. :) Dennis located a copy we still have. > > Let me contact you out of list with a download link. ;) Oooh! Can I have it too? It might help me extend the Wikitcms History back even further... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Possible outdated Jenkins jobs
On Mon, 2020-11-02 at 11:30 -0300, Leonardo Rossetti wrote: > https://jenkins-fedora-infra.apps.ci.centos.org/job/pungi-modularity/ This looks to be associated with https://pagure.io/pungi-modularity , which hasn't been touched for four years. Seems pretty likely it can go. The maintainer is now a release manager at SUSE, according to Github...:) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Possible outdated Jenkins jobs
On Wed, 2020-11-04 at 17:26 +0100, Pierre-Yves Chibon wrote: > > https://jenkins-fedora-infra.apps.ci.centos.org/job/tunir/ > > I think this one has been archived, I'm not 100% anymore right now > though. This is my belief too. It was the runner for autocloud, and we decommissioned autocloud. openQA runs the tests autocloud used to run, but it doesn't use tunir and it doesn't need the tunir git repo or this CI job. Could check in with Kushal for confirmation, but I'm pretty sure it could go. (Looking at the git repo, it seems the CI was changed to Travis at some point anyway - see https://github.com/kushaldas/tunir/pull/62 for e.g.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Possible outdated Jenkins jobs
On Mon, 2020-11-02 at 11:30 -0300, Leonardo Rossetti wrote: > Hello all, > > We would like to "migrate" the current jenkins instance to a new centos-ci > infrastructure but there are several jobs that will need to be migrated as > well - the process would be to provision a new openshift cluster + a > Jenkins instance and migrate those jobs from the current instance to the > new one. > > Some jobs were never used while others had a few runs but haven't been used > since 2018, so I would like to get some feedback on how many of those could > be skipped/ignored. > > *Jobs that were never used/triggered:* > > https://jenkins-fedora-infra.apps.ci.centos.org/job/autocloudreporter-pagure-pr/ This one's mine. You can probably kill it, because I am moving my projects over to Software Factory's zuul, and also the project itself doesn't really need to exist any more as autocloud is dead. > https://jenkins-fedora-infra.apps.ci.centos.org/job/relvalconsumer-pagure-pr/ Also mine. You can kill it if you like, I'll move the CI to zuul when I get the time. > https://jenkins-fedora-infra.apps.ci.centos.org/job/resultsdb_conventions/ Ditto. Note these two *were* run, though - just before the move to CentOS CI :) They were last run on jenkins.fedorainfracloud.org in 2017. My code is so great and flawless it doesn't get many PRs. ;) > https://jenkins-fedora-infra.apps.ci.centos.org/job/blockerbugs/ blockerbugs CI has been moved to Zuul, so I'm pretty sure this can be dropped: https://pagure.io/fedora-qa/blockerbugs/c/ce6f9e37b8fd983489ee44d916997db8d02300d8?branch=develop CCing Frantisek for confirmation. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Mirrorlist bad entry for ftp.icm.edu.pl resulting 404
On Tue, 2020-10-27 at 14:11 +0100, Rafal Maszkowski wrote: > On Tue, Oct 27, 2020 at 10:20:08AM +0100, Adrian Reber wrote: > > On Tue, Oct 27, 2020 at 06:29:27AM -, Mariusz Brzezik wrote: > > > Dear community, recently i we faced a errors during machines creation > > > phase due to bad entry for ftp.icm.edu.pl within EPEL mirrorlist. Checked > > > for CentOS 7 and 8. > > > Centos 7 entry giving 404 error: > > > https://ftp.icm.edu.pl/pub/Linux/fedora/linux/epel/7/x86_64/ > > > Working link for CentOS7: > > > https://ftp.icm.edu.pl/pub/Linux/dist/fedora-epel/7/x86_64/ > > > Centos8 entry giving 404 error: > > > http://ftp.icm.edu.pl/pub/Linux/fedora/linux/epel/8/Everything/x86_64/ > > > Working link for CentOS8: > > > https://ftp.icm.edu.pl/pub/Linux/dist/fedora-epel/8/Everything/x86_64/ > > > Who should i contact with to issue those mirrorlist errors? > > > Thank You in advance for You help! > > Thanks for letting us know. The best place to report mirror problems is > > probably: https://pagure.io/fedora-infrastructure/issues > > I had a look at that mirror and it seems it changed URLs and I just > > updated our mirror entry to use the new URLs. > > It takes about one hour until the changes are live so it should soon > > point to the correct URLs. > > I prepare to use quick-fedora-mirror finally. It looks to me that with > that type of mirroring I can mirror only all subdirectories of > fedora/linux, including core and extra which I did not mirror until now > but I can no longer keep epel there. There are options for excluding things from the sync, including a regex-based exclude - you can set FILTEREXP='someregex' in the config file and any files matching the regex are excluded. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: What is our technical debt?
On Thu, 2020-06-25 at 21:59 +0200, Pierre-Yves Chibon wrote: > On Thu, Jun 25, 2020 at 03:51:42PM -0400, Neal Gompa wrote: > > On Thu, Jun 25, 2020 at 3:27 PM Pierre-Yves Chibon > > wrote: > > > > > > Good Morning Everyone, > > > > > > Just like every team we have technical debt in our work. > > > I would like your help to try to define what it is for us. > > > > > > So far, I've come up with the following: > > > - python3 support/migration > > > - fedora-messaging > > > - fedora-messaging schema > > > - documentation > > > - (unit-)tests > > > - OpenID Connect > > > > > > What else would we want in there? > > > > > > > These are all good things, especially the documentation one. I'd like > > to zero in on a particular aspect of documentation, though: getting to > > hack on it. A lot of our projects are surprisingly difficult to get up > > and running for someone to play with and hack on, and this is > > increasingly true as we adopt OpenShift-style deployments. One way we > > solved this in Pagure is by providing some quick start processes in > > the documentation and a fully working Vagrant based process to boot up > > and have a working environment to hack on the code. > > > > I'm not necessarily going to specify it needs to be Vagrant for > > everything, but I think this is something we should have for all of > > our projects, so that people *can* easily get going to use and > > contribute. > > I've recently had quite some pain with vagrant (just today, I've tried several > time to start my bodhi vagrant box and lost my morning w/o success). > > I guess it may be nice to see if there is something else out there that we > could > leverage. > If we could adopt one and try to get have it on most of our apps this may be a > nice goal for us to work towards. The thing is, even if vagrant *itself* is shonky as hell (I agree), if you vagrant-ify a project, there is at least a recipe I can relatively easily follow in a manually setup VM or mock root or whatever I like. The fact that the recipe is designed for vagrant is almost incidental, the key thing is that there's an 'official' "here's how to set up a dev env from scratch" recipe. Of course, it needs to be kept up to date and working... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Staging
On Mon, 2020-06-15 at 15:53 -0700, Kevin Fenzi wrote: > * Has staging been helpful to you? It's been useful to me a few times. For instance it was definitely useful when doing the initial fedmsg enablement for openQA and then for the port from fedmsg to fedora-messaging: we did both of those in staging first. Even though the 'staging' instance of openQA *itself* wasn't a real staging thing, it *did* publish to the staging fedmsg/fedora-messaging buses, so we could shake out the wrinkles in that without affecting prod, then deploy prod once we had it working. > * Is there anything we could do to make it better? This may be pretty niche, but I do wish the staging wiki contents were synced more often. Of course the sync process wipes out changes made directly on the staging wiki so there's a bit of a balance, but maybe auto-syncing every day or every few days would be good... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Datacenter move days 3 and 4
On Thu, 2020-06-11 at 21:09 -0700, Kevin Fenzi wrote: > * openqa. Right now it doesn't have any arm or power workers, but we > have some almost ready to go there that we should have in place next > week. quick clarification on this: up till now, we've always had aarch64 and ppc64 tests running only on the staging instance, prod has always been only x86_64. I've been sort of planning to move at least aarch64 to production for a while now, but I've been a bit reluctant because we still seem to hit a lot of flakes there (and the extremely long- standing https://bugzilla.redhat.com/show_bug.cgi?id=1689037 is still a big problem in aarch64 tests, and I still can't get any headway on getting that fixed). Right now it seems we won't have a staging instance (we may rename the second instance to 'test' or something, by the by, because 'staging' is a bad name for it as it's not really like other 'staging' things in infra) for a bit because we're running on a fairly minimal set of hardware in the new DC for now. So upshot is I'm kinda still unsure about how to proceed with that part of things. I'll talk to Kevin and Smooge tomorrow about exactly when we're likely to get a) the second server instance and b) the other worker hosts, and try to come up with a plan. so for now we just have the new prod instance operational and it's only running x86_64 tests (on a single worker host for now). it's working more or less fully, but right at this minute quite a lot of tests are failing due to a 'russian roulette' sort of problem (there are four possible IPs that mirrors.fedoraproject.org can resolve to from inside the new DC, and it seems that from the new worker host, two of them work and two of them don't). thanks to nirik and smooge for all their hard work, and sorry for the spurious test failures, I'll try to get that sorted ASAP. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Updating fedocal to work with Python 3
On Tue, 2020-06-02 at 19:38 +, Jonathan Trossbach wrote: > Hi everyone! > > My name is Jon Trossbach and I am a first time contributor to the > Fedora project. My first goal is to get fedocal working with Python > 3. > > I am currently trying to use this set of Ansible playbooks ( > https://pagure.io/fedora-infra/ansible) to deploy fedocal in a CentOS > 7 virtual machine using VirtualBox and Vagrant but I can't get the > playbook to finish without running into some errors. So I guess my > first question is: am I using these Ansible playbooks for their > intended purpose in trying to set up an individual development > environment for fedocal? Probably not. Those ansible plays are intended for the Fedora infrastructure environment specifically. Some people try to bear in mind 'generic' use of the playbooks when working there, but you can't rely on it. It may be best to treat the playbooks as a useful guide rather than literally trying to run them outside of the infra environment. The plays are also intended to set up real production instances, not development environments. > Or should I just follow the README in its github repository ( > https://github.com/fedora-infra/fedocal)? I've attempted both ways of > setting up a development environment and can't seem to get either to > work. What problem did you have with this approach? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The future of loopabull
On Thu, 2020-05-28 at 08:30 -0400, Neal Gompa wrote: > On Thu, May 28, 2020 at 8:19 AM Pierre-Yves Chibon > wrote: > > Good Morning Everyone, > > > > I know this question has already been raised a few times, but I think we > > should > > raise it once more: what do we see as future for loopabull? > > > > It is currently triggered on 4 topics (3 from prod and 1 from stg) to do > > basically > > three actions: > > - Flag commit successfully built in koji, in other words it adds these flags > > to dist-git: > > > > https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce > > - Flag when the Fedora CI start testing a PR > > - Flag when the Fedora CI finished testing a PR (and thus reports Pass/Fail) > > > > Wait, wait, wait, what?! These aren't things natively supported by the > software we use (Koji and Zuul)? It seems like the place to start here > would be to move this functionality to the right places. A koji plugin > and an extension for the Zuul pagure driver to do those things would > make a ton more sense here... Why, though? I quite like the design of small consumer components to do specific jobs in response to messages. Lots of the bits I maintain work that way. Why is it necessarily better for Koji to grow the ability to change stuff in dist-git than to have a little go-between to do the job? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [FBR] Retire in bugzilla package retired in Fedora
On Wed, 2020-04-22 at 20:14 +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > I believe this is not frozen but in doubt I'm still asking it :) > > I would like to deploy a new build of distgit-bugzilla-sync (running in > openshift) to include this pull-request: > https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/48 > which basically blocks in bugzilla packages that are retired in Fedora. > > This fixes https://pagure.io/fedora-infrastructure/issue/7639 > > Thoughts? Does it account for branches? i.e. it should only retire things in Bugzilla if they're retired on *all* current branches, it shouldn't e.g. retire a package that's not retired on F30. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Backlog prioritization
On Thu, 2020-04-16 at 13:33 -0700, Kevin Fenzi wrote: > > > * Mirror the ansible git repo on pagure.io > > I'd like to set up a mirror on pagure.io that would pull from batcave01. > > It > > would mean that PR can't really be merged in this mirror (unless we're > > fast > > enough to pull from the mirror and push to the main repo right after the > > merge, > > but there is a risk of a race-condition where the commit(s) just merged > > are > > overridden by a push to the main repo). > > It would expose a more up to date ansible repo to the public and we > > should be > > able to wget the patch of the PRs, git am to apply them and git push to > > the > > main repo. > > I think we should just bite the bullet and move the repo to pagure if we > can get a nice way to sync it back to batcave01 for actually running > playbooks there. > > I know I have been holdinng off on this related to the gitforge stuff, > and it likely will mean that we have to move it again sometime, but so > what. I think it's worth it to have. + especially if we can then set up some CI that at least checks PRs are syntactically sound and stuff (should not be hard to at least set up a job that runs a YAML syntax checker over it). That would save ever so many brown-paper-bag commits...:P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Packit Pagure support (was: [RFC] Optionally using git repositories instead of the lookaside cache)
On Thu, 2020-04-09 at 12:54 -0400, James Cassell wrote: > On Thu, Apr 9, 2020, at 12:33 PM, Neal Gompa wrote: > > On Thu, Apr 9, 2020 at 11:41 AM Tomas Tomecek wrote: > > > On Thu, Apr 9, 2020 at 4:34 PM Jeremy Cline wrote: > > > > We actually are. I assume you're asking about why we're not using > > > > packit. We're not on GitHub so the service isn't (as far as I can tell) > > > > useful to us. There's huge piles of existing bash scripts and makefiles > > > > that achieve about what I think packit-the-cli would give us so it > > > > would be some amount of work with no obvious benefit to move at the > > > > moment. Generally speaking, though, I'm not against the idea. > > > > > > When we started packit, we played with the scripts and makefiles in > > > your kernel repo and I hope it's not too bold of me to say that it > > > shouldn't be that hard to integrate the two now. > > > > > > I'm assuming you're using pagure.io - at this point, we're not going > > > to integrate packit with pagure (for obvious reasons). What are your > > > future plans for the git forge? > > > > What the heck are you talking about? pagure.io is not going away > > anytime soon. And there will be other pagure instances that host > > source code that packit integration support would be useful for. > > > > Hell, I've already offered to help with the pagure.io service. > > > > The whole situation is bit unfortunate, as the announcement made it > seem like pagure.io is going away. I mean, I have my issues with the announcement, but this seems like an unfair criticism. The *first paragraph* ends with "We are opting for GitLab for our dist git and project hosting and will continue to run pagure.io with community assistance." Every other mention of pagure.io clearly communicates that it will continue to run for at least a year and the preference is to keep it running permanently with community maintenance. I don't know where you get the idea that it is going away from the announcement. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Weekly Backlog Refinement - Week Mar 30 2020
On Thu, 2020-04-02 at 11:08 +0200, Michal Konecny wrote: > > > #7880 email2fas not working in production (fedmsg/datanommer, > > fedmsg/irc) - https://pagure.io/fedora-infrastructure/issue/7880 > > Trouble : medium > > Gain : low > Not sure about this one, FAS will be replaced soon, > fedmsg_meta_fedora_infrastructure will go away with fedmsg. I think this > is not worth our time, but we should instead think about including this > into fedora messaging. Yeah, even if you replace the systems, the *feature* is still needed: whether the lookup happens in FAS or AAA, whether the thing doing the looking up is a fedmsg meta processor or a fedora-messaging schema, "what Fedora account is associated with this email address?" is a thing we need as long as we have messages from systems which give us email addresses and not Fedora accounts (*cough cough* Bugzilla). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Weekly Backlog Refinement - Week Mar 30 2020
On Wed, 2020-04-01 at 15:50 +0200, Clement Verna wrote: > Hi all, > > Let's look at 5 tickets and rate them using the following categories : > * low-trouble, medium-trouble, high-trouble > * low-gain, medium-gain, high-gain > > #7867 Remove all old releases from torrent - > https://pagure.io/fedora-infrastructure/issue/7867 > Trouble : ? > Gain : ? low-gain > #7880 email2fas not working in production (fedmsg/datanommer, fedmsg/irc) - > https://pagure.io/fedora-infrastructure/issue/7880 > Trouble : ? > Gain : ? So the issues I see here are: 1) we're spewing out lots of email addresses in a very easily- harvestable way (potentially if fixing this *properly* is hard, we could obfuscate the email addresses in at least the human-readable bits?) 2) anything like Badges which relies on these messages to associate an event with a FAS identity probably isn't working (so Badges associated with Bugzilla and possibly Pagure may not be working right) so probably medium-gain ? trouble I can't estimate because (as mentioned in ticket) I don't have access to the systems to find out why it doesn't work. > #7743 Template for OIDC secret requests - > https://pagure.io/fedora-infrastructure/issue/7743 > Trouble : ? > Gain : ? low-trouble low-gain (I'd say medium if there were *more* of these requests but I don't see that there are any since 11 months ago) > #7796 oc rsh does not work - > https://pagure.io/fedora-infrastructure/issue/7796 > Trouble : ? > Gain : ? > > #7973 Finding a replacement for epylog - > https://pagure.io/fedora-infrastructure/issue/7973 > Trouble : ? > Gain : ? high-trouble (per smooge's comment) medium-gain (since f29 is EOL and I'm guessing we'd like not to be on RHEL 7 if we can avoid it?) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Proposing keeping multiple versions of the same package in the updates repo
On Wed, 2020-03-25 at 10:09 +0100, Vít Ondruch wrote: > Dne 24. 03. 20 v 19:52 Adam Williamson napsal(a): > > On Tue, 2020-03-24 at 18:59 +0100, Vít Ondruch wrote: > > > Dne 24. 03. 20 v 16:30 Adam Williamson napsal(a): > > > > On Tue, 2020-03-24 at 10:03 +0100, Vít Ondruch wrote: > > > > > +1 > > > > > > > > > > I would love this for Rawhide. This would also allow `dnf downgrade` > > > > > to > > > > > work, which would be very useful when things go south. In stable > > > > > releases, you could in theory downgrade from version in `updates` > > > > > repository to version from `fedora` repository`, but that is not > > > > > possible in Rawhide :/ > > > > It's pretty easy to do this with the Koji CLI: > > > > > > > > koji download-build --arch=x86_64 --arch=noarch (NVR) > > > > dnf downgrade *.rpm > > > While this might sound useful, it is not that useful when your system is > > > borked and you want to get it up and running again. > > > > > > IOW this is strawman to the original request and my reasoning for the +1. > > In what situation could you do 'dnf downgrade' but not that? > > In a situation I don't have other computer to explore Koji, in a case > that for example Gnome was updated and it is not just about downgrading > one package due to dependencies. You don't need another computer to 'explore koji', you can do it all with the koji CLI. 'koji list-tag-history' to find previous builds of a given package, for e.g. Admittedly it's a bit clunkier than the web UI, but it's all there. 'koji help' lists all the commands... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Proposing keeping multiple versions of the same package in the updates repo
On Tue, 2020-03-24 at 18:59 +0100, Vít Ondruch wrote: > Dne 24. 03. 20 v 16:30 Adam Williamson napsal(a): > > On Tue, 2020-03-24 at 10:03 +0100, Vít Ondruch wrote: > > > +1 > > > > > > I would love this for Rawhide. This would also allow `dnf downgrade` to > > > work, which would be very useful when things go south. In stable > > > releases, you could in theory downgrade from version in `updates` > > > repository to version from `fedora` repository`, but that is not > > > possible in Rawhide :/ > > It's pretty easy to do this with the Koji CLI: > > > > koji download-build --arch=x86_64 --arch=noarch (NVR) > > dnf downgrade *.rpm > > While this might sound useful, it is not that useful when your system is > borked and you want to get it up and running again. > > IOW this is strawman to the original request and my reasoning for the +1. In what situation could you do 'dnf downgrade' but not that? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [PATCH] rabbitmq: adjust things to avoid messy partitions
On Thu, 2020-03-12 at 19:32 +, Kevin Fenzi wrote: > We have been having the cluster fall over for still unknown reasons, > but this patch should at least help prevent them: (if I get a vote) +1, makes sense to me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Weekly Backlog Refinement - Week Mar 09 2020
On Mon, 2020-03-09 at 17:00 +0100, Michal Konecny wrote: > > #7935 Nightlies (Rawhide and Branched) not imported to PDC - > > https://pagure.io/fedora-infrastructure/issue/7935 > This is too much trouble for low gain, we should direct our manpower to > FPDC instead. This seems like a false evaluation to me. Presumably when FPDC is done, it will be populated by transferring in data from PDC. Garbage (or non- existence) in, garbage (or non-existence) out - if a bunch of data that should be in PDC is missing, it is not going to magically turn up when FPDC is deployed. As noted in https://pagure.io/fedora-infrastructure/issue/7935#comment-631920 , the last two official stable Fedora releases were not imported to PDC. That's pretty important archival information we're missing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze break request: koji autovacuum_freeze_max_age
On Tue, 2020-03-03 at 13:33 -0800, Kevin Fenzi wrote: > And our lazyness and indecision pays off! Woohoo, the Adam Strategy wins again! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze break request: koji autovacuum_freeze_max_age
On Sun, 2020-03-01 at 11:26 -0800, Kevin Fenzi wrote: > Greetings. > > Last night koji alerted due to slowness. It was not backups or anything, > but rather the database hitting the limit I raised in commit c678f73b: > > -autovacuum_freeze_max_age = 2 # maximum XID age before forced > vacuum > +autovacuum_freeze_max_age = 3 # maximum XID age before forced > vacuum > > What this means is basicially: postgres records the xid (transaction id) > that can 'see' other transactions in the table rows. However, xid is a > 32 bit value, meaning there can only be about 2.1billion transactions > before it 'wraps around'. When it does so, all the 'old' XID's need to > be gone or it will confuse it. It removes the old xids by marking old > transactions as 'frozen' (so any other transaction should see them). > > So, this value tells the autovacuumer to start processing the table for > old xids and frezzing them, so by the time the wrap around happens > everything will be set. > > Unfortunately, it's doing this on the buildroot_listing table, which is: > public | buildroot_listing | table | koji | 219 GB | > > So, the i/o load is heavy and koji is slow to respond to real requests. > > There's (at least) tree things we could do: > > 1. Bump the autovacuum_freeze_max_age up to 600million. The 100million > bump I did in january gave us about 1.5 months, so if we do 600, we > might last until june, when we will be migrating to the new datacenter. > 600million is still a long way from 2.1 billion, so it should be fine. > At that point I hope to move db-koji01 to a rhel8 instance and much > newer postgresql. We could also run the vacuum duing downtime and let it > finish. > > 2. Just let it finish now. Things will be slow, I don't know for how > long. Users will complain and it will take longer for people to get > things done, but at the end we should be in better shape and there's > basically no action we need to take (other than handling complaints) > > 3. Schedule an outage and take the db offline and run the vacuum. This > might be quicker than letting the autovac finish, I am not sure. > > Thoughts? please +1 the freeze break of the option you thing is best, or > feel free to ask more info or suggest other options. I'm fine with 1 or 2, but think we should definitely *not* do 3 unless a) we know quite precisely how long it will take and b) that is substantially faster than the online autovac. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State of FMN (FedMSG Notifications) and Replacement
On Wed, 2020-02-26 at 08:26 +0100, Clement Verna wrote: > Hi all, > > FMN (https://apps.fedoraproject.org/notifications) is currently one of the > main blocking point for dropping fedmsg in favour of fedora-messaging. > FMN is quite important to the community and the composition of Fedora > because it gives emails and notifications on commits, composes, builds and > updates via email and other tools. > > However, the code base is written in Python 2.7 and not maintained anymore. > Currently the service has to run on a Fedora 28 system to continue running. > This causes multiple problems and concerns, and needs to be addressed > before the datacenter move in June. > > In order to start putting together a specification for a replacement, we > should try to look at the minimum requirements for a notification system. > For example the current system supports sending notifications to IRC, > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live > without IRC ? Do we need it to monitor everything it does currently or just > a subset of items that the community has found useful. > > Let's use this thread to brainstorm ideas on what we need. I'd note that a key feature of FMN is that it provides human-readable summaries of messages. For fedmsg this is achieved through the fedmsg metadata system, and the Fedora providers for it: https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/ for fedora-messaging, the intended way to do approximately the same thing is with message schemas: https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema as part of modernizing FMN and rewriting it on fedora-messaging, we might well need to get fedora-messaging schema coverage up to a similar level as we have fedmsg meta coverage. We may want to see if we can come up with an automated or semi-automated process for converting fedmsg meta providers to fedora-messaging schemas, even... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Deprecating Autocloud
On Thu, 2019-12-05 at 14:44 +0530, Sinny Kumari wrote: > Reviving this thread > > Recently Fedora 29 went EOL [1] and with that we also did final Fedora > Atomic Host release and its EOL announcement [2] . > I think we should be good with deprecating autocloud now unless we want to > keep using it for running tests on Fedora Cloud images. It's already done, Kevin turned it off several days ago. openQA is now running the autocloud tests on Cloud_Base qcow2 images, e.g. https://openqa.fedoraproject.org/tests/overview?distri=fedora=30=Fedora-Cloud-30-20191205.0=1 . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: F29 and older instances
On Thu, 2019-11-14 at 12:44 -0800, Adam Williamson wrote: > On Thu, 2019-11-14 at 10:34 -0800, Kevin Fenzi wrote: > > On Thu, Nov 14, 2019 at 08:13:52AM -0800, Adam Williamson wrote: > > > On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote: > > > > autocloud*: f27, but should die when f29 goes eol (it's only used to > > > > test atomic-host). > > > > > > No, it isn't. It also tests the regular cloud images: > > > > Sigh. :( > > > https://apps.fedoraproject.org/autocloud/jobs/ > > > > > > the tests with family 'Base' are tests of non-Atomic images. The > > > regular Cloud base images are still release-blocking until whenever we > > > decide to switch over to CoreOS. At some point this testing was meant > > > > Well, or decide to just make the Cloud base image not blocking. > > > > > to move to Taskotron, then there was some talking of moving it to > > > Fedora CI, but I don't know if anyone has actually done any work on > > > either of those things. AFAIK we have no other system currently for > > > doing automated testing on the Cloud base images. > > > > > > We could probably run the tests in openQA without too much trouble if > > > desired (though I can't guarantee it as I haven't looked into it in any > > > detail), but we should probably do *something* here. > > > > yeah, keeping autocloud is really not an option. > > It's running on a eol OS. > > > > We have no upstream developers anymore. > > > > It takes up 2 large hardware boxes we can't use for anything else that > > are idle most of the time. > > > > So, yes, we should come up with something here. ;( > > welp, if no-one else has a plan, I can take a look at migrating the > tests it runs into openQA maybe next week. (That might also mean we'd > pay more attention to the results - the autocloud tests haven't passed > on Rawhide for like two months, but I didn't know that until I looked > this morning...) Well that turned out to be not too hard! https://openqa.stg.fedoraproject.org/tests/674207 So I briefly looked at whether I wanted to take over autocloud but there's a lot of it, and it looks to me like ultimately all it really *does* is boot the image and then do this: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/autocloud/backend/files/fedora.txt where ## means "this shouldn't fail the overall test if it fails", @@ means "this is expected to fail" and POLL means "wait till the system reboots" (per https://github.com/kushaldas/tunir/blob/master/docs/usage.rst). So I just taught openQA to be able to boot Cloud_Base qcow2 images and do basically the same: https://openqa.stg.fedoraproject.org/tests/674207/modules/autocloud/steps/1/src I'll get this cleaned up in various ways and deployed to production over today and tomorrow. It doesn't replicate *all* of autocloud - most notably for now it'll only test the Cloud_Base qcow2 images, not the vagrant images which autocloud also tested - but I think that's good enough for now. I'm not sure if it makes more sense to try and make openQA mimic the fedmsgs that autocloud currently publishes and the resultsdb results it reports, or just find anything that uses either of those and make it work with the openQA messages and results instead, I'll look into that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: F29 and older instances
On Thu, 2019-11-14 at 10:34 -0800, Kevin Fenzi wrote: > On Thu, Nov 14, 2019 at 08:13:52AM -0800, Adam Williamson wrote: > > On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote: > > > autocloud*: f27, but should die when f29 goes eol (it's only used to > > > test atomic-host). > > > > No, it isn't. It also tests the regular cloud images: > > Sigh. :( > > https://apps.fedoraproject.org/autocloud/jobs/ > > > > the tests with family 'Base' are tests of non-Atomic images. The > > regular Cloud base images are still release-blocking until whenever we > > decide to switch over to CoreOS. At some point this testing was meant > > Well, or decide to just make the Cloud base image not blocking. > > > to move to Taskotron, then there was some talking of moving it to > > Fedora CI, but I don't know if anyone has actually done any work on > > either of those things. AFAIK we have no other system currently for > > doing automated testing on the Cloud base images. > > > > We could probably run the tests in openQA without too much trouble if > > desired (though I can't guarantee it as I haven't looked into it in any > > detail), but we should probably do *something* here. > > yeah, keeping autocloud is really not an option. > It's running on a eol OS. > > We have no upstream developers anymore. > > It takes up 2 large hardware boxes we can't use for anything else that > are idle most of the time. > > So, yes, we should come up with something here. ;( welp, if no-one else has a plan, I can take a look at migrating the tests it runs into openQA maybe next week. (That might also mean we'd pay more attention to the results - the autocloud tests haven't passed on Rawhide for like two months, but I didn't know that until I looked this morning...) I still don't know what automated testing CoreOS has in place either...that might be useful to know... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: F29 and older instances
On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote: > autocloud*: f27, but should die when f29 goes eol (it's only used to > test atomic-host). No, it isn't. It also tests the regular cloud images: https://apps.fedoraproject.org/autocloud/jobs/ the tests with family 'Base' are tests of non-Atomic images. The regular Cloud base images are still release-blocking until whenever we decide to switch over to CoreOS. At some point this testing was meant to move to Taskotron, then there was some talking of moving it to Fedora CI, but I don't know if anyone has actually done any work on either of those things. AFAIK we have no other system currently for doing automated testing on the Cloud base images. We could probably run the tests in openQA without too much trouble if desired (though I can't guarantee it as I haven't looked into it in any detail), but we should probably do *something* here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze break request: update comps for rename of 'dnf-yum' to 'yum'
On Tue, 2019-10-15 at 09:47 -0700, Kevin Fenzi wrote: > On Tue, Oct 15, 2019 at 08:14:58AM -0700, Adam Williamson wrote: > > On Mon, 2019-10-14 at 18:17 -0700, Kevin Fenzi wrote: > > > On Mon, Oct 14, 2019 at 02:45:49PM -0700, Adam Williamson wrote: > > > > Hey, folks. Requesting a freeze break for this PR (as it applies to > > > > comps-f31.xml.in): > > > > > > > > https://pagure.io/fedora-comps/pull-request/427 > > > > > > > > In F31 'dnf-yum' is no more and 'yum' obsoletes it, but this was not > > > > changed in comps. As a result, clean installs of F31 (and Rawhide) have > > > > no 'yum' command, as we clearly intend they should. > > > > > > > > This isn't likely to make any images go oversize as all the 'yum' > > > > package contains is a symlink linking /usr/bin/yum to /usr/bin/dnf-3 > > > > and a manpage; /usr/bin/dnf-3 is part of python3-dnf which would > > > > already be in all the images. > > > > > > I'm not sure if this is really an infrastructure thing to decide, but > > > for FWIW, +1. :) > > > > I thought I needed an FBR to poke comps at this point? I mean if > > comps is in it's own 'fedora-comps' repo controlled by releng and is > more 'data' than anything to infrastructure. > > > everyone wants some extra bureaucracy I can file a bug, propose it as > > FE, we can vote to accept the bug as an FE, then we can vote on an FBR > > to honor the FE...oh boy, I'm getting excited already! > > Yeah, I don't know if it's worth all that. > > How about we get the usual suspects to just vote in the PR? How about we just merge it and go to lunch? :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Freeze break request: update comps for rename of 'dnf-yum' to 'yum'
On Mon, 2019-10-14 at 18:17 -0700, Kevin Fenzi wrote: > On Mon, Oct 14, 2019 at 02:45:49PM -0700, Adam Williamson wrote: > > Hey, folks. Requesting a freeze break for this PR (as it applies to > > comps-f31.xml.in): > > > > https://pagure.io/fedora-comps/pull-request/427 > > > > In F31 'dnf-yum' is no more and 'yum' obsoletes it, but this was not > > changed in comps. As a result, clean installs of F31 (and Rawhide) have > > no 'yum' command, as we clearly intend they should. > > > > This isn't likely to make any images go oversize as all the 'yum' > > package contains is a symlink linking /usr/bin/yum to /usr/bin/dnf-3 > > and a manpage; /usr/bin/dnf-3 is part of python3-dnf which would > > already be in all the images. > > I'm not sure if this is really an infrastructure thing to decide, but > for FWIW, +1. :) I thought I needed an FBR to poke comps at this point? I mean if everyone wants some extra bureaucracy I can file a bug, propose it as FE, we can vote to accept the bug as an FE, then we can vote on an FBR to honor the FE...oh boy, I'm getting excited already! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Freeze break request: update comps for rename of 'dnf-yum' to 'yum'
Hey, folks. Requesting a freeze break for this PR (as it applies to comps-f31.xml.in): https://pagure.io/fedora-comps/pull-request/427 In F31 'dnf-yum' is no more and 'yum' obsoletes it, but this was not changed in comps. As a result, clean installs of F31 (and Rawhide) have no 'yum' command, as we clearly intend they should. This isn't likely to make any images go oversize as all the 'yum' package contains is a symlink linking /usr/bin/yum to /usr/bin/dnf-3 and a manpage; /usr/bin/dnf-3 is part of python3-dnf which would already be in all the images. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Fri, 2019-09-13 at 13:40 +0100, Ankur Sinha wrote: > On Fri, Sep 13, 2019 09:23:44 +0200, Clement Verna wrote: > > Yeah the packages app is really useful and used by many, this is the main > > reason it was not included in the application we are currently working on > > giving away / retiring. But to be honest I think the priority of the > > packages > > app is quite low. Following are some of the work we have in our Backlog : > > • Packager UX improvement. > > • FAS replacement. > > • PDC replacement. > > • OSBS support for aarch64. > > • End to End testing and monitoring for the flatpak build pipeline. > > • Package review process improvement. > > • Fedora Infra technical debt. > > Is there somewhere community members can read more on these tasks of the > CPE please? > > For the packages app---if it's in maintenance mode, I guess that's OK > for the time being until something breaks. > > There are two aspects of the packages app that aren't available on > src.fp.o that make it important for me: > > - bugz.fp.o/packagename -> but I expect this can be aliased to a direct > bugzilla query type URL? "Open bugs" on the packages app heads to > bugzilla already: > > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced=Fedora=Fedora+EPEL=python-rosinstall_generator_status=NEW_status=ASSIGNED_status=REOPENED The feature this doesn't get you is the handy 'open a new bug for this package' button. Which again can be replicated as a direct Bugzilla link, but...you need at least a thing to serve a page showing those two links :) > There are DDG bangs for bugzilla by the way but they don't search by > component (I'll suggest a new one soon): !rbugs, !rhbz > > - "Install this package" -> this is critical. I was wondering if there > was a way to allow users to "click to install", There is actually supposed to be a URI format that PackageKit-based package managers should handle, IIRC, but that was a 2014-vintage thing or something so no idea if it still works. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, 2019-09-12 at 02:32 -0400, Neal Gompa wrote: > On Thu, Sep 12, 2019 at 2:28 AM Clement Verna > wrote: > > > > > > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote: > > > Hello, > > > > > > I was looking for information on the future of the packages > > > application[1]. I didn't see it mentioned in the commblog post[2]. > > > > Currently the application is in a kind of maintenance mode (in reality I > > don't have much time to look at tickets). This application is really > > valuable and used a lot, but the big problem is the technology stack it is > > built on TurboGears2 and making an heavy use of Moksha > > (https://moksha.readthedocs.io/en/latest/), while TG2 is still active > > upstream, this is not the case with Moksha and some of the TG2 dependencies > > the application has. The effort to move away from these 2 framework is > > quite high and I don't think we currently have the cycles for it. > > > > My personal opinion is that we should really try to consolidate on src.fp.o > > and instead of investing time in porting packages to more recent > > technologies we should put that effort in adding the missing features to > > src.fp.o. > > > > If we lose the packages app, we'll lose the only way to search for > binary packages. src.fp.o only shows source package names, and most > people aren't going to know what those are. FWIW, a feature of the packages app I use *all the time* is bugz.fedoraproject.org/ . I can do everything I use that for in other ways, sure, but it's a fantastically helpful shortcut for finding and reporting bugs in . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Warning: bodhi, pyramid, cornice, python-fedora depending on orphaned packages
On Mon, 2019-08-26 at 11:08 -0700, Kevin Fenzi wrote: > On 8/20/19 9:31 AM, Kevin Fenzi wrote: > > On 8/17/19 2:25 AM, Miro Hrončok wrote: > > > This is just a heads up that there is a dependency chain of orphaned > > > packages that would lead to problems in bodhi when retired. They will be > > > retired in less than a month if nobody takes them. > > > > > > See https://churchyard.fedorapeople.org/orphans.txt > > > > > > (I wonder who takes care of bodhi when Randy is not available, ccing > > > Aurelien who made some commits recently.) > > > > > > > Yeah, everyone in infra-sig group takes care of these packages, but as > > you know this is all coming at a bad time for us, since we are swamped > > with other work items and this is all on top. ;( > > > > Anyhow, I hope later this week to go and try and sort this out. > > So, looking at our packaging state... > > moksha* is python2 only as far as I can see, and hasn't had a release > since 2013. We have a number of things that depend on this stack: > > bugzilla2fedmsg The new version I keep trying to get us to deploy to production doesn't need it any more, as it is ported to Python 3 and fedora-messaging. Only the old fedmsg version needs it. > fedmsg itself, I think? Yeah, fedmsg uses moksha. > badges Ralph kicked it out of tahrir last year: https://github.com/fedora-infra/tahrir/commit/b8bbfdf36a82ed4781939bd985e82c1231f488e8 so again we just need a new version deployed there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: A Friday with Infra
On Fri, 2019-08-09 at 13:08 -0700, Adam Williamson wrote: > On Fri, 2019-08-09 at 07:13 +, Christophe DUMONT wrote: > > Hello, > > > > Badges (Tahrir) looks fine ! > > I made a bit of a start on Badges today because hey it's Friday and I > didn't feel like doing anything else. This is my branch: > > https://github.com/AdamWill/tahrir/tree/py3 > > I also ran into something that needs fixing in tahrir-api before tahrir > will work at all with current sqlalchemy: > > https://github.com/fedora-infra/tahrir-api/pull/47 > > so you'll want that fix too. I'll see how far I can get with this > today. Welp, I got this far: https://github.com/fedora-infra/tahrir/pull/427 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: A Friday with Infra
On Fri, 2019-08-09 at 07:13 +, Christophe DUMONT wrote: > Hello, > > Badges (Tahrir) looks fine ! I made a bit of a start on Badges today because hey it's Friday and I didn't feel like doing anything else. This is my branch: https://github.com/AdamWill/tahrir/tree/py3 I also ran into something that needs fixing in tahrir-api before tahrir will work at all with current sqlalchemy: https://github.com/fedora-infra/tahrir-api/pull/47 so you'll want that fix too. I'll see how far I can get with this today. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: How to consume fedora-messaging?
On Thu, 2019-06-20 at 10:11 +0200, Pavel Raiskup wrote: > Hi Adam, or anyone, > > On Monday, June 10, 2019 6:06:42 PM CEST Adam Williamson wrote: > > If you're writing an AMQP consumer in Python, what you'll ultimately > > get for your consumer to process is a `message` object which is an > > instance of a fedora_messaging.api.Message() (or a subclass of it - a > > message schema class). > > I fail to see an example of this, I mean ... [1] says > > Message bodies are JSON objects, that adhere to a schema. Message schemas > live in their own Python package, so they can be installed on the producer > and on the consumer. > > do we have any such package so I (as a consumer) can install the package > with schema class, and use it to parse the message body? Yeah, Bodhi. Write a consumer that listens to Bodhi messages, then run it without python3-bodhi installed. When it gets a message, it'll just show up as an instance of Message(), and your system log will have a warning like this: Jun 20 14:44:40 openqa-stg01.qa.fedoraproject.org fedora- messaging[11082]: [WARNING fedora_messaging.message] The schema "bodhi.update.request.testing.v1" is not in the schema registry! Either install the package with its schema definition or define a schema. Falling back to the default schema... Now install python3-bodhi, run the consumer again, and this time the message should show up as an instance of the appropriate schema class. (I have not actually tested this as the consumers I'm writing don't need to use any of the schema methods really...but that's how it's supposed to work). > I have seen > the example of producing the message using the schema [2], but not > consuming - only the toy example which is not really using the schema > class. > > > This will have a `body` attribute which should be a dict of the message > > 'body' - the main meat of the message. > > ... I can use the "meat" to instantiate the message object manually, by > Message(body=body) perhaps, but I still have to first check the topic, > etc, I hoped there's something like: > > from MYAPP import MessageConsumer > from fedora_messaging.api import consume > ... > > class Consumer(MessageConsumer): > def consume(self, message): > """ message _is_ instance of the schema class """ > message.do_some_stuff() > if message.some_property: > do_something() > > consume(Consumer) Yeah, so long as the package that provides the schema class is installed, this actually should work. I guess whether you write your consumer to work with or without the schema class, or just have it blow up if the schema class is not installed, is kinda up to you. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: How to consume fedora-messaging?
g-migration-tools/issues/20 . I came across this while converting fedmsg consumers to fedora- messaging, and I wrote a little helper to deal with it: https://pagure.io/fedora-qa/fedora_openqa/blob/fedora-messaging/f/fedora_openqa/consumer.py#_36 Whenever you want the body of a message you just run it through that and it should give you the 'true' body. That also means you won't have to worry if the bridge gets changed to fix the bug, that function will still give the correct result. If you want to look at some real-world fedora-messaging consumers, that file contains three consumers for scheduling openQA jobs and reporting their results. Also see the reference config files (the '.toml' files) and the README, at top level of the fedora-messaging branch: https://pagure.io/fedora-qa/fedora_openqa/tree/fedora-messaging You can also look at Bodhi, which has also been converted to fedora- messaging: https://github.com/fedora-infra/bodhi/blob/fde8eefc016b55be76ec6a5298b8b400b5a91476/bodhi/server/consumers/__init__.py the config file for Bodhi is in infra ansible: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/base/templates/fedora-messaging.toml.j2 Oh, one more wrinkle I had fun with: if you want to use the 'public' credentials for the brokers, be aware that the amqp_url setting and [tls] block settings in the sample config files are correct, but the necessary certificate and key files for the staging broker are not included in the `fedora-messaging` package at present. If you look in /etc/fedora-messaging after installing it you'll see only the files for the production broker are there. If you want to listen to the staging broker, you have to grab the files from a git checkout (they're in the 'configs' dir) and copy them to /etc/fedora-messaging . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Deprecating Autocloud
On Thu, 2019-05-02 at 10:15 -0400, Dusty Mabe wrote: > > On 5/2/19 12:08 AM, Neal Gompa wrote: > > On Wed, May 1, 2019 at 10:48 PM Dusty Mabe wrote: > > > We plan to have testing at various stages of the CoreOS build and delivery > > > pipeline. We definitely plan to have FCOS taken care of using the existing > > > kola testing utility [1] that was in use previously for container linux. > > > > > > With that said, one thing that has previously been out of scope for kola > > > is > > > testing instances that aren't provisioned with ignition (i.e. they use > > > cloud-init > > > instead). Today the Fedora Cloud base images are not provisioned using > > > ignition so > > > we'll either need to consider adding ignition as an option there OR > > > consider running > > > automated tests against the Fedora Cloud base images in OpenQA (if that's > > > possible). > > > > > > > It's all possible with OpenQA, the tests just have to be written. :) > > I don't know a whole lot about OpenQA but I'm interested to know: > Is it easy to start a VM and attach metadata to it (i.e. support cloud-init)? I'd have to look into it, but it shouldn't be hard. Starting VMs is what it *does*, and if it can't support cloud-init already, I can add it. I'm on vacation till the 19th, will follow up on this later. It would be a good idea if the actual tests can be shared between test systems as much as possible. I know the tests Autocloud ran were basically just bash scripts - openQA could easily use those. What do the tests run in kola look like? There's also the question of whether we still want to ship/support the Cloud Base images. For now they are still release-blocking deliverables, but their status feels a little vague to me. It would be good to figure out for sure whether we still consider them important, if so why, and if so who is in charge of them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ 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: Deprecating Autocloud
On Mon, 2019-04-29 at 18:57 +0530, Sinny Kumari wrote: > On Mon, Apr 29, 2019 at 4:47 PM Kamil Paral wrote: > > > On Mon, Apr 29, 2019 at 11:39 AM Sinny Kumari wrote: > > > > > > > > On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi wrote: > > > > > > > Or could we move f29+ all to whatever is replacing it? (taskotron?) > > > > > > > > > > It will be nice but I am not aware of any other system in place which > > > would > > > replace checks performed by autocloud. > > > > > > (CC'ed tflink and kparal) > > > Does taskotron provides capability to perform tests on Fedora cloud > > > Images like booting images and other basic checks? > > > > > > > Theoretically it is possible using nested virt. However, Taskotron is > > going away as well. The replacement is Fedora CI: > > https://docs.fedoraproject.org/en-US/ci/ > > > > Thanks kamil! yeah, it doesn't make sense to move to Taskotron if it is > going to be deprecated as well. > > > > I recommend to ask in the CI list: > > https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/ > > > > It should be possible for them to provide the infrastructure you need. > > > > Hmm, I am not very sure if we should spend time investigating and setting > up alternative > to autocloud unless we have usecases for long run. Fedora Atomic Host Two > Week releases ends with F29 EOL. We could run these tests in openQA pretty easily, I think. The question is, I guess, whether they will still be of value for Fedora CoreOS. I guess to me the real job Autocloud is doing is this: "make sure the images we intend people to use to run Fedora instances in the cloud basically work and can do some simple tasks people tend to do with such images". If the Fedora CoreOS team already is covering this some other way, or intends to cover it some other way before Fedora CoreOS becomes a supported thing, then we probably don't need to preserve the Autocloud tests. If this is not in scope for the Fedora CoreOS team...we probably still need to do it somewhere else. So...has anyone asked the Fedora CoreOS team what the plans here are? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: interesting article on commit messages
On Sun, 2018-12-16 at 15:43 -0800, Kevin Fenzi wrote: > Saw a nice article on commit messages: > > https://juffalow.com/other/write-good-git-commit-message > > The one big easy thing I liked from it was: > > "A properly formed Git commit subject line should always be able to > complete the following sentence: if applied, this commit will subject line here>" > > I think this might be a good rule of thumb to apply to our commits, at > least in ansible repo. I'm as guilty as the next person on useless > commits, but I'm gonna try and do better. ;) if your commit message is shorter than 500 words and doesn't explain: 1) the entire history of the problem 2) the detailed nature of the fix 3) every other possible approach you considered 4) brexit you're just not trying hard enough. ...or...that might just be my philosophy. :P but yes, isolating a change of interest down to a single commit and then finding that commit message gives you absolutely no useful information at all about the *reason* for the change is one of the most annoying things I can think of. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
ansible: fedmsg-hub-3 support
hey folks! just wanted to pass along a note about this change I made to the infra scripts today: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=6c390c669ba88bc3eeb9a08ccc30373f5ee7df13 What I did was extend a bit of scaffolding that already exists to handle fedmsg deployment differently if the host is in a group with 'python34-fedmsg' in its name (the 'python34' there is a EL-ism, but I didn't want to change it) so it now also covers fedmsg-hub as well as fedmsg-base. Now, if a system is in a group with 'python34-fedmsg' in its name and the 'fedmsg/hub' role is run on that system, instead of enabling the 'fedmsg-hub' service, it'll enable the 'fedmsg-hub-3' service. The 'restart fedmsg-hub' handler is also tweaked so it conditionally restarts *both* 'fedmsg-hub.service' *and* 'fedmsg-hub-3.service' (this seemed like the easiest solution to the service restart problem; as we're using conditional-restart.sh, whichever isn't present will just be ignored). This should help with moving things from Python 2 fedmsg to Python 3 fedmsg. It should be relatively easy to extend to the other fedmsg roles too, if desired - I didn't do that as I didn't want to change too much, and fedmsg-hub is all I needed for the box I'm migrating. Please let me know if you have any comments, concerns or suggestions about this, thanks! I did ask around on IRC and it didn't seem like anyone had a better idea or plan for doing this, so I just went ahead... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Koji / epel-7 - What's going on?
On Tue, 2018-11-20 at 14:52 -0800, Kevin Fenzi wrote: > On 11/20/18 2:39 PM, Frantisek Zatloukal wrote: > > Hi, > > I am currently trying to build new resultsdb[0] into epel7-candidate. > > However, I am facing some (weird?) behavior around python-flask, > > > > I am able to do a successful build of resultsdb (depending on python-flask) > > in mock epel-7 and koji scratch epel-7 [1]. However, it is failing on > > not-available python-flask in koji to epel-7-candidate [2]. > > > > Am I overlooking something? > > > > Thanks very much! > > > > [0] https://src.fedoraproject.org/rpms/resultsdb/blob/epel7/f/resultsdb.spec > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=31025152 > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=31025187 > > flask was pulled into rhel-extras (for docker distribution I think) and > when it was, it was only published for x86_64. > > Your package is noarch, but flask is not. > > So, you happened to get a x86_64 builder with your scratch build, but > your real build got a ppc builder where flask is not available. ;( > > I think you should be able to pass "Exclusivearch: noarch x86_64" and > have it work. If not, you can just resubmit your build until you get a > x86_64 builder. There are several packages like this, I think. It's a real pain. Is there no better solution we can come up with? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Fedora and PDC, road forward
On Wed, 2018-06-13 at 17:06 -0700, Kevin Fenzi wrote: > On 06/13/2018 03:19 PM, Adam Williamson wrote: > > On Wed, 2018-06-13 at 12:03 -0700, Kevin Fenzi wrote: > > > On 06/12/2018 07:41 AM, Pierre-Yves Chibon wrote: > > > > Good Morning Everyone, > > > > > > > > So yesterday we held a meeting on #fedora-apps about the future of PDC > > > > in Fedora. > > > > We kept notes in etherpad at: http://etherpad.osuosl.org/pdc_fedora > > > > Here is the gist of it: > > > > > > > > What do we currently store in PDC: > > > > * modules data - the list of what modules have been built, what rpms > > > > are in them, > > > > and which ones are active or not. > > > > * Stream branches, branch ownership, retirement dates (EOL/SLE) > > > > * release/life-circle tracking > > > >* product and product versions (fedpkg gets active Fedora and EPEL > > > > releases > > > > from product versions endpont) > > > > > > As an aside did we ever get that 'in development' addition we wanted so > > > we could point everything still using pkgdb to pdc for release status? > > > > All the code got done but no-one has yet/ever put a process in place to > > actually populate Fedora's PDC with the appropriate data, so it's not > > there. Things (fedfind, gnome-software...) are still using the > > 'collections' JSON for now. > > Is that the last thing using pkgdb that we know of? > > It would be pretty sad to keep running pkgdb, and pdc and the new thing > all at the same time. :( It's the last thing *I* know of. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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/NZ3DGHONI7TFTX6AS6C2SPDHYRMW5WMB/
Re: Fedora and PDC, road forward
On Wed, 2018-06-13 at 17:04 -0700, Kevin Fenzi wrote: > On 06/13/2018 02:50 PM, Randy Barlow wrote: > > On 06/13/2018 03:03 PM, Kevin Fenzi wrote: > > > ok. Note that this data changes over time, and releng needs a script to > > > update it (or better a automatic updating of it). > > > > Yeah there is a Bodhi ticket about this and I noted that we will need to > > make sure we still work with releng's script if we make the change: > > > > https://github.com/fedora-infra/bodhi/issues/2433 > > Yeah, it sure would be nice if we could just have something run in cron > once a day or so and just update it. Releng has not been good about > running this script often. > > > > We might want to bring up the bigger topic of if we want to bother > > > keeping this. The only current use of it is some rules about going > > > stable in bodhi... are those actually useful? > > > > This sounds like a policy decision, so perhaps the question could be > > posed to FESCo or possibly the packaging committee. It does make some > > intuitive sense to me that we would treat certain packages more > > stringently than we do others, but I don't have data to say one way or > > the other whether the current policies are beneficial. I will say that I > > would feel uncomfortable changing the policy without the blessing of a > > governing body. > > Yes, this is definitely something for FESCo. > They made the update policy that uses it. > > I can take it to them, I just wanted to see if there was a general sense > that it was useful and we should keep it, or it was pointless and we > should drop it. Perhaps I'll post to devel about it to see what the > general feeling is. FWIW I certainly think we should keep it. If anything, with the few folks we currently have who seem to +1 almost any update two seconds after it lands, we might want to make the barrier a bit higher. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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/WGSF2SAKYJYBZ6VNBGRQQUY7WIBR2QY3/
Re: Fedora and PDC, road forward
On Wed, 2018-06-13 at 12:03 -0700, Kevin Fenzi wrote: > On 06/12/2018 07:41 AM, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > So yesterday we held a meeting on #fedora-apps about the future of PDC in > > Fedora. > > We kept notes in etherpad at: http://etherpad.osuosl.org/pdc_fedora > > Here is the gist of it: > > > > What do we currently store in PDC: > > * modules data - the list of what modules have been built, what rpms are in > > them, > > and which ones are active or not. > > * Stream branches, branch ownership, retirement dates (EOL/SLE) > > * release/life-circle tracking > >* product and product versions (fedpkg gets active Fedora and EPEL > > releases > > from product versions endpont) > > As an aside did we ever get that 'in development' addition we wanted so > we could point everything still using pkgdb to pdc for release status? All the code got done but no-one has yet/ever put a process in place to actually populate Fedora's PDC with the appropriate data, so it's not there. Things (fedfind, gnome-software...) are still using the 'collections' JSON for now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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/NYKFJDHXPP63HKWWUZCTT5ZCZERC5AXD/
Re: Bodhi stakeholders' meeting
On Thu, 2018-05-10 at 16:49 -0400, Randy Barlow wrote: > > Other > = > > Other thoughts? I didn't know / remember that it existed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Changes in hardware in December affecting QA servers
On Thu, 2017-11-02 at 12:41 -0400, Stephen John Smoogen wrote: > I realized I had only informally gone over some of the items which > will be changing in December when hardware is moved. However the date > is finally arriving so it needs to be laid out more formally :). > > In December, Infrastructure will be moving to new racks with better > power monitoring, networking, and other tools. One of the side goals > of this is that any old hardware which has been meant to be recycled > over the years is to be done so. Which brings us to a set of qa > systems which were listed to be replaced a couple of years ago. > > qa01, qa02, qa03, qa04, qa05, qa07, qa08 are all IBM systems which > have reached the end of the road and are planned not to be moved over > to the new racks. [They have been scheduled to be removed for 2-3 > years now but it has finally come to that date.] What processes are > currently running on these systems and what is needed to replace them? qa05 and qa07 are the 'small' worker hosts for openQA (prod and stg, respectively). Each hosts 4 of the total 14 x86_64 worker instances. So losing them will cut the capacity of each openQA instance by about 30%. What I'd need to replace them *most easily* is...another couple of hosts in infra (technically, 'able to mount the NFS shares from the openQA servers and connect back to the openQA servers via http and possibly websockets', I think) capable of running four or more x86_64 VMs simultaneously, basically. Up till now openQA worker hosts have always been dedicated to that task; there's no fundamental theoretical reason why openQA workers couldn't run on a box which also does some other stuff, though we'd have to check if there were any conflicts in requirements as to how the box has to be set up (check the ansible plays). openQA has some newer capabilities that are basically about making 'more remote' workers possible, but I have not investigated those yet. It *may* be possible to use those to run workers in some kind of cloud, but that'd involve much more research and configuration and probably debugging than just doing straight-up replacements in infra. Another possibility I guess is having a single more powerful box hosting workers for both prod and staging. Again I believe it may be possible to get openQA to do this but it's different from what we do now and I'd need to look into it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: [Release] pagure: 3.5
On Tue, 2017-09-05 at 12:21 +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > I just cut a new release of pagure: 3.6. > > Here is its corresponding changelog: > > * Tue Sep 05 2017 Pierre-Yves Chibon <pin...@pingoured.fr> - 3.7-1 S...is it 3.5 (as per subject), 3.6 (as per third line of text), or 3.7 (as per changelog)? :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
New list for ResultsDB users
Hi folks! So I've been floating an idea around recently to people who are currently using ResultsDB in some sense - either sending reports to it, or consuming reports from it - or plan to do so. The idea was to have a group where we can discuss (and hopefully co-ordinate) use of ResultsDB - a place to talk about result metadata conventions and so forth. It seemed to get a bit of traction, so I've created a new mailing list: resultsdb-users . If you're interested, please do subscribe, through the web interface: https://lists.fedoraproject.org/admin/lists/resultsdb-users.lists.fedoraproject.org/ or by sending a mail with 'subscribe' in the subject to: resultsdb-users-j...@lists.fedoraproject.org Please note: despite the list being a fedoraproject one, the intent is to co-ordinate with folks from CentOS, Red Hat and maybe even further afield as well; we're just using an fp.o list as it's a quick convenient way to get a nice mailman3/hyperkitty list without having to go set up a list server on taskotron.org or something. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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, 2017-02-15 at 16:58 -0500, Randy Barlow wrote: > Hello! > > I've made a release of Bodhi 2.4.0 upstream: > > https://github.com/fedora-infra/bodhi/releases/tag/2.4.0 > > What guidance would this group give about deploying it tomorrow > (Thursday) vs. waiting until next Monday? New releases are traditionally deployed direct to production at 5:30pm on Friday, just before you leave for a long vacation with no internet access. Everyone knows this! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Freeze break request: refine the filterlist stuff (make it an imagelist using productmd)
On Mon, 2016-11-21 at 21:05 -0700, Kevin Fenzi wrote: > On Mon, 21 Nov 2016 19:46:27 -0800 > Adam Williamson <adamw...@fedoraproject.org> wrote: > > > The main problem here is the 'archive' filterlist is still pretty big, > > over 20MiB. I don't want to push the fedfind changes out to the public > > until it's smaller. With this change the imagelist files are all tiny, > > under 250KiB. pr #26 is an alternative to this which just extends the > > exclusion list of the previous approach, but nirik says he prefers > > this approach. > > +1, but I would want to wait until things calm down later tomorrow or > wed morning to apply. Don't want to do anything to mess up the release > morning. ;) For sure. I've tweaked the PR (#27) slightly to make create-filelist keep working if productmd isn't available - tibbs requested this as he wants it to be generically useful, not Fedora/EL-ish. Please see the PR for the revised version. If this FBR is approved I'll commit it with the revised create-filelist. Functionally it's the same, for our case. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Freeze break request: refine the filterlist stuff (make it an imagelist using productmd)
The main problem here is the 'archive' filterlist is still pretty big,
over 20MiB. I don't want to push the fedfind changes out to the public
until it's smaller. With this change the imagelist files are all tiny,
under 250KiB. pr #26 is an alternative to this which just extends the
exclusion list of the previous approach, but nirik says he prefers
this approach.
From 5b7169688a1732f49ff0bb6320fa34e641b363de Mon Sep 17 00:00:00 2001
From: Adam Williamson <awill...@redhat.com>
Date: Mon, 21 Nov 2016 19:36:49 -0800
Subject: [PATCH] turn 'filterlist' into 'imagelist', using productmd
This adopts https://pagure.io/quick-fedora-mirror/pull-request/27
and adapts to it, so we get `imagelist` files rather than
`filterlist` files (see recent commits for this). The rationale
is more fully explained in that PR (and in PR #26 also) - on
further inspection it turns out that we have to filter out an
awful lot of extensions to create small filterlists for all
three modules, and I'm worried that other file extensions may
appear in the future and cause the filterlists to suddenly get
bigger again. Instead, we have create-filelist use the productmd
constant that defines valid image formats, and only include files
that match those formats in the list. The downside of this
approach is we have to ensure productmd on all the systems that
run `create-filelist` is kept up to date if the list of valid
image formats changes.
---
files/scripts/create-filelist | 15 ---
files/scripts/update-fullfiletimelist | 26 +-
playbooks/groups/secondary.yml| 1 +
roles/bodhi2/backend/tasks/main.yml | 1 +
roles/releng/tasks/main.yml | 1 +
5 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/files/scripts/create-filelist b/files/scripts/create-filelist
index e485efb..0beaced 100755
--- a/files/scripts/create-filelist
+++ b/files/scripts/create-filelist
@@ -12,6 +12,7 @@ import argparse
import hashlib
import os
import sys
+from productmd.images import SUPPORTED_IMAGE_FORMATS
from scandir import scandir
@@ -58,8 +59,8 @@ def parseopts():
null = open(os.devnull, 'w')
p = argparse.ArgumentParser(
description='Generate a list of files and times, suitable for
consumption by quick-fedora-mirror, '
-'and a much smaller list with packages, Device Tree boot
files, HTML files, pictures '
-'and directories filtered out, for consumption by
fedfind.')
+'and a much smaller list of only files that match one of
the productmd supported '
+'image types, for use by fedfind.')
p.add_argument('-c', '--checksum', action='store_true',
help='Include checksums of all repomd.xml files in the file
list.')
p.add_argument('-C', '--checksum-file', action='append',
dest='checksum_files',
@@ -75,8 +76,8 @@ def parseopts():
help='Filename of the file list with times (default:
stdout).')
p.add_argument('-f', '--filelist', type=argparse.FileType('w'),
default=null,
help='Filename of the file list without times (default: no
plain file list is generated).')
-p.add_argument('-F', '--filterlist', type=argparse.FileType('w'),
default=null,
- help='Filename of the filtered file list for fedfind
(default: not generated).')
+p.add_argument('-i', '--imagelist', type=argparse.FileType('w'),
default=null,
+ help='Filename of the image file list for fedfind (default:
not generated).')
opts = p.parse_args()
@@ -112,9 +113,9 @@ def main():
# opts.filelist.write(entry.path + '\n')
print(entry.path, file=opts.filelist)
# write to filtered list if appropriate
-skips = ('.rpm', '.drpm', '.dtb', '.html', '.png', '.jpg')
-if not any(entry.path.endswith(skip) for skip in skips) and not
(entry.is_dir()):
-print(entry.path, file=opts.filterlist)
+imgs = ['.{0}'.format(form) for form in SUPPORTED_IMAGE_FORMATS]
+if any(entry.path.endswith(img) for img in imgs):
+print(entry.path, file=opts.imagelist)
if entry.name in opts.checksum_files:
checksums[entry.path[2:]] = True
info = entry.stat(follow_symlinks=False)
diff --git a/files/scripts/update-fullfiletimelist
b/files/scripts/update-fullfiletimelist
index f6c225a..c0439da 100755
--- a/files/scripts/update-fullfiletimelist
+++ b/files/scripts/update-fullfiletimelist
@@ -25,7 +25,7 @@ CREATE=/usr/local/bin/create-filelist
# context.
FILELIST=fullfilelist
TIMELIST='fullfiletimelist-$mod'
-FILTERLIST='filterlist-$mod'
+IMAGELIST='imagelist-$mod'
usage () {
echo
@@ -108,12 +108,12 @@ cd $tmpd
for mod in $MODS; do
currentfl=$TOPD/$mod/${FILELIST/'$mod'/$mod}
currenttl=$TOPD/$mod/${TIMELIST/'$mod'/$mod}
-currentsl=$TOPD/$mod/${FILTERLIST/'$mod'/$mod}
+currentil=$TOP
Re: freeze break request: filtered file lists
On Fri, 2016-11-18 at 19:05 -0700, Kevin Fenzi wrote: > +1 here. I can push it/test it tomorrow if you like. > > kevin That'd be great! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
freeze break request: filtered file lists
This commit should give us new 'filterlist' files alongside the
'fullfilelist' and 'fullfiletimelist' files in the /fedora , /archive
and /alt folders on the mirrors. The contents of this file are the same
as 'fullfilelist', but with all directories, packages (.rpm or .drpm
files) and device tree boot files (.dtb files) removed. This gives a
massively smaller list which, right now, will be useful for fedfind (it
can parse these lists instead of rsync scraping) and may possibly be
useful for other things in future, I guess.
It would be nice to have this now as this all came out of the work
around improving generation of the mediawriter 'available images' JSON
file: we want to use fedfind to generate that, but the rsync scraping is
pretty heavy for something that'll run quite frequently. This should
improve things quite a bit (especially as I've written fedfind to cache
the files and only re-download them if the Last-Modified header
changes). I have the fedfind changes all written and tested (I tested
against the fullfilelist files).
From 3f61df2f2879c23a7e44271527facce99bc92286 Mon Sep 17 00:00:00 2001
From: Adam Williamson <awill...@redhat.com>
Date: Fri, 18 Nov 2016 16:34:38 -0800
Subject: [PATCH] Generate filtered file lists for fedfind to use
This adds `filterlist` files alongside the `fullfilelist` and
`fullfiletimelist` files. These are much, much shorter lists
which skip the entries for packages, ARM device tree boot files
and directories. They are intended for consumption by fedfind,
so it can stop using rync scraping to discover the image files
it looks for. To enable this, we update to a newer version of
`create-filelist` from upstream `quick-fedora-mirror` and make
`update-fullfiletimelist` create the filterlist files as well.
We also delete a couple of old copies of `create-filelist`;
nirik made the two roles that use it share a common copy a few
months back, but missed deleting the copy each role had in its
`files` directory.
---
files/scripts/create-filelist | 10 -
files/scripts/update-fullfiletimelist | 19 ++--
roles/bodhi2/backend/files/create-filelist | 36
--
roles/releng/files/create-filelist | 36
--
4 files changed, 26 insertions(+), 75 deletions(-)
delete mode 100644 roles/bodhi2/backend/files/create-filelist
delete mode 100644 roles/releng/files/create-filelist
diff --git a/files/scripts/create-filelist b/files/scripts/create-filelist
index eeba9d0..8fc3367 100755
--- a/files/scripts/create-filelist
+++ b/files/scripts/create-filelist
@@ -57,7 +57,9 @@ def recursedir(path='.', skip=[], alwaysskip=['.~tmp~']):
def parseopts():
null = open(os.devnull, 'w')
p = argparse.ArgumentParser(
-description='Generate a list of files and times, suitable for
consumption by quick-fedora-mirror.')
+description='Generate a list of files and times, suitable for
consumption by quick-fedora-mirror, '
+'and a much smaller list with packages, Device Tree
boot files, HTML files and '
+'directories filtered out, for consumption by
fedfind.')
p.add_argument('-c', '--checksum', action='store_true',
help='Include checksums of all repomd.xml files in
the file list.')
p.add_argument('-C', '--checksum-file', action='append',
dest='checksum_files',
@@ -73,6 +75,8 @@ def parseopts():
help='Filename of the file list with times
(default: stdout).')
p.add_argument('-f', '--filelist', type=argparse.FileType('w'),
default=null,
help='Filename of the file list without times
(default: no plain file list is generated).')
+p.add_argument('-F', '--filterlist', type=argparse.FileType('w'),
default=null,
+ help='Filename of the filtered file list for fedfind
(default: not generated).')
opts = p.parse_args()
@@ -107,6 +111,10 @@ def main():
for entry in recursedir(skip=opts.skip_files):
# opts.filelist.write(entry.path + '\n')
print(entry.path, file=opts.filelist)
+# write to filtered list if appropriate
+skips = ('.rpm', '.drpm', '.dtb', '.html')
+if not any(entry.path.endswith(skip) for skip in skips) and not
(entry.is_dir()):
+print(entry.path, file=opts.filterlist)
if entry.name in opts.checksum_files:
checksums[entry.path[2:]] = True
info = entry.stat(follow_symlinks=False)
diff --git a/files/scripts/update-fullfiletimelist
b/files/scripts/update-fullfiletimelist
index 016ca8e..e70fadc 100755
--- a/files/scripts/update-fullfiletimelist
+++ b/files/scripts/update-fullfiletimelist
@@ -25,6 +25,7 @@ CREATE=/usr/local/bin/create-filelist
# context.
FILELIST=fullfilelist
TIMELIST='fullfiletimelist-$mod'
+FILTERLIST=filterlist
usage () {
echo
@@ -107,12 +108,14 @@ cd $tmpd
for mod in $MODS; do
cur
Calendaring. Again.
Hey, folks. Just wanted to take another shot at one of my oldest windmills :) So, we talked about calendaring for a long time. Then we picked Zarafa. Then we kind of implemented it. Then no-one used it, and we took it out again: http://smoogespace.blogspot.com/2011/02/resetting-expectations-fedora.html That wasn't what you might call a 'success', I know. I think there's maybe a couple of reasons for that. One, I'm still not really sure why we'd pick Zarafa. It's explicitly designed to be a Microsoft Exchange replacement, and I don't think Fedora is a project with a lot of people who really need to use ActiveSync or Outlook, so...huh? It just doesn't seem like it was ever a great fit. By the Zarafa page on the wiki - https://fedoraproject.org/wiki/Zarafa - we couldn't even ship Z-Push because ActiveSync is patented, so apparently our only ever official calendaring system never had a working sync mechanism at all, and I don't think Zarafa's web interface is any great shakes. Two, there was never any particular driver towards using it. So, I think another try with a more appropriate calendaring system - if we can find one - and a 'seed' use of it might be a good idea. I've been using eGroupware, personally, for quite a while, and I think it's a good system. I'm not aware of any major barriers to including it in Fedora. It has internal copies of a few Pear modules, but that's pretty small beer and it should be trivial to use the system-wide copies or get an exception (some of them are extensively modified). It has a nice web UI and decent sync capabilities via CalDAV: I've used it synchronized with Evolution on two systems and never had major problems. It seems at least a better fit than Zarafa. Citadel would be another one to look at. As for a 'seed' use, I think an ideal fit here would be the release schedules. Currently, these are dumb HTML tables with ICS files living in the current release manager's personal fedoraproject space: http://rbergero.fedorapeople.org/schedules/f-16/ which sucks for any number of reasons, not least of which you need to know who the hell the release manager is at the moment in order to find the schedule. =) Using a proper calendaring system would seem to be a far better way to handle the release calendars, and would be a great kickstarter for a project calendaring system. Since the calendars are maintained by one person, we only need to get one person (hi, Robyn!) to buy in, in order to kick off this seed use. To restrict the liability issues mentioned in Smooge's blog post, we could not enable the email function of the system we choose (this is possible with both EGW and Citadel). We could also not have individual accounts for all Fedora project members, at least at first: we could have just a few individual accounts with commit access, mainly for the release manager to maintain the calendars, and then have a single read-only guest account which people could use to view the calendars and sync them read-only to their phones and desktop clients. It may even be possible to set things up so people can view and read-only sync without any authentication required. What do people think of this idea? If it seems like an approach that's simpler to maintain and more likely to produce actual useful results, that'd be great. I'm willing to work on packaging eGroupware and resolving the private-copies-of-pear-modules issue - I already maintain eGW for Mandriva, so it wouldn't be too much work to convert the spec to Fedora standards. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Calendaring. Again.
On Thu, 2011-07-28 at 16:32 -0600, Kevin Fenzi wrote: Well, here's where we are I think... 1. zarafa 7.0.0 just came out a bit ago. I think this might have the ability to disable all but the calendar mode and might provide a more useful sync function set. So, I was going to upgrade our zarafa to that version when I got a chance. Which does indeed still exist: https://admin.fedoraproject.org/zarafa/ I agree that it doesn't seem to match up with all our needs for calendaring, so it might not pass this and we retire it out. Sounds cool. I'll take a look. I think it might take a bit to get over my worry about Zarafa - it is, after all, explicitly designed to be an open core, cheaper Exchange replacement for Exchange shops. But then eGW is also open core-ish, although its open source version is stable, mature, and does what we need (and really a lot more than we need). 2. The insight folks have been looking at making a calendar module for insight that we could use. (drupal based): http://fedoraproject.org/wiki/Insight_use_cases_for_calendar So, that was looking like it might be an option. Interesting! I hadn't heard about that. Will look at it. I guess we should really move back a step here. We have: https://fedoraproject.org/wiki/Fedora_Calendar_Project Which we should really clean up and update to what we NEED and what we would LIKE to have and then see what actual thing meets those criteria and run with it. Sounds good. I think quite a bit of that is still accurate, but I don't think FAS authentication is really required (especially in the 'just a few people with write access' scenario I suggested), and I'd like to have sync made a 'must have', especially since so many people use phones these days. It needs to be sync rather than one-time import/export, because if we delay the release, we'd wind up with a mess unless the calendars are actually _synced_. I'd hate for us to implement too many more things before actually knowing what we want/need. Thoughts? Sounds good. I'll make a note on my todo to take a look at the zarafa instance when it's updated, check out that drupal module, and propose a revision to the 'requirements' list. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required.
On Mon, 2010-01-25 at 13:14 +0530, susmit shannigrahi wrote: As you are doing testing right now, would it help to have a instance here in fedora-infra so that we can figure out if it suites our needs? I think that would be nice, yeah. It would be good to have an egroupware instance up alongside the zarafa instance so people can try both and see which they prefer. What do you need from me? Fedorized packages for egroupware? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required.
On Fri, 2010-01-22 at 14:18 -0500, Brennan Ashton wrote: I have deployed this as well a few times thought its history and it has served me well each time. One thing to consider is how large of a service it is, I have never really had to bother with trimming all the extra features (mail, address book etc...) from it. It's fairly well modularized. See the Mandriva package list: egroupware-developer_tools egroupware-egw-pear egroupware-emailadmin egroupware-etemplate egroupware-felamimail egroupware-filemanager egroupware-gallery egroupware-icalsrv egroupware-importexport egroupware-infolog egroupware-manual egroupware-mydms egroupware-news_admin egroupware-notifications egroupware-phpbrain egroupware-phpsysinfo egroupware-polls egroupware-projectmanager egroupware-registration egroupware-sambaadmin egroupware-sitemgr egroupware-syncml egroupware-timesheet egroupware-tracker egroupware-wiki egroupware-workflow all you really need installed for it to work at a basic level is the main package, emailadmin (the setup process won't complete without it), etemplate and calendar. Well, calendar was listed as a dependency by the previous maintainer, who I'm assuming knew what he was doing. I can't personally confirm that the app doesn't work without it. You don't need even the webmail chunk, let alone any of the more esoteric bits. I did test it some more today. I have working three-way sync of my real calendar and contacts - egroupware / desktop / laptop. Evolution seems quite flaky at transferring large amounts of data all at once - especially, for instance, trying to dump 50 contacts direct from a Google calendar (accessed by CalDAV) into the egroupware calendar (also accessed by CalDAV) tends to make it fall over. But I suspect that's as much Evo as anything else, I don't think anyone's really stressed its CalDAV capabilities much, and I'm running Rawhide. Once I got the data in, in small enough lumps, it works fine. I can't seem to make my Windows Mobile phone sync with the egroupware server; it should be possible via the Funambol client for Windows Mobile, which does SyncML synchronization. egroupware supports SyncML, and this is the method upstream recommends for syncing with WM devices. I can set it up and it claims to run correctly, but no data ever appears on the phone. That's not really a big deal from the Fedora viewpoint, though, it's not one of our requirements for the project and I'd guess most Fedora people have Android phones or iPhones, not WM phones. I'll probably give it a few more tries over the weekend or next week and see if I can figure out what's wrong. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required.
On Wed, 2009-10-28 at 19:36 +0530, susmit shannigrahi wrote: Hi, Zarafa is up at Publictest16. Anyone want to test? Please refer to last three comments of https://fedorahosted.org/fedora-infrastructure/ticket/1197 As I posted to the ticket, I've come across another candidate which appears to meet the requirements and which I don't _think_ we've dismissed already - eGroupWare: http://www.egroupware.org/ it has a decent web interface, doesn't seem to be insane in any way, doesn't need Java (it's PHP), is fairly mature and actively developed, and has CalDAV support for the calendaring stuff. I'm probably going to deploy it on my own network for my own needs, will try to report back on how that goes. My servers run Mandriva, where it's packaged (though a very old version, I'm currently updating the packages). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
