Re: Freeze break request: koji update on builders

[Neal Gompa]

On Thu, Apr 18, 2024 at 8:15 PM 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



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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

[Neal Gompa]

On Mon, Apr 8, 2024 at 12:25 PM 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



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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: small koji update for builders

[Neal Gompa]

On Wed, Mar 20, 2024 at 4:16 PM Kevin Fenzi  wrote:
>
> I'd like to update koji on builders.
>
> This build (
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2423765 )
>
> has added:
> * A fix to make kiwi builds only use passed repos if there is one passed
> https://pagure.io/koji/pull-request/4061 ).
> I have tested this in staging and it does fix the bug we want it to fix:
> https://bugzilla.redhat.com/show_bug.cgi?id=2270397
> (basically if kiwi adds the buildroot repo from koji it gets unsigned
> rpms, we only want it to use the compose repo).
>
> * a small fix to add --debug to kiwi tasks so we can get much better
> compose output to debug problems.
>
> Also, I dropped some old patches around rpmdir issues debugging (but
> that shouldn't affect this freeze break because it only applies on
> builders, not hubs).
>
> So, can I get +1s to:
>
> apply this to koji builders
> restart kojid on them
>
> I might just do this and ask for forgiveness as we need to fire off rc
> 1.10 here in a short time. ;(
>

+1



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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 Snapshots without FedoraGroup tag

[Neal Gompa]

On Mon, Nov 27, 2023 at 12:14 PM Kevin Fenzi  wrote:
>
> On Thu, Nov 23, 2023 at 04:38:01PM +0100, Miroslav Suchý wrote:
> >
> > I had time to investigate it a bit:
>
> Thanks for digging into it.
>
> ...snip...
>
> >
> > Based on this founding I propose:
> >
> > 1) Delete **all** snapshots without FedoraGroup tag older than - let say -
> > 2021. This way we can actually review if there are some snapshots other than
> > leftovers form clean-amis that is worth preserving. But right now I am
> > unable to review manually anything. If the snapshot will be linked to live
> > AMI then AWS refuse to delete it and I will ignore such errors. If there
> > will be no objection I will top post this as separate headsup email.
>
> Sounds pretty reasonable to me.
>
> > 2) Open ticket that owners of fedimg should fix the tooling to delete the 
> > snapshots
> >
> > 3) Open tickets that owners of fedimg should delete cleanup AMIs with 
> > Deprecation time lower than todays date.
>
> "Owner of fedimg" is... us I guess? but as far as I know, no one is
> doing anything with it.
>
> The plan was that the cloud-sig was going to look at a new, better tool
> to manage uploading. I am not sure what the status of that is.
>

David Duncan (who I've CC'd to this) has been working on writing a new
ansible-based uploader supporting all our cloud targets. He can
provide an update on that.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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

[Neal Gompa]

On Wed, Oct 4, 2023 at 11:52 AM 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 from me.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Migration from registry.fp.o to quay.io

[Neal Gompa]

On Thu, Sep 7, 2023 at 10:15 AM Michal Konecny  wrote:
>
> So I contacted William Dettelback from quay.io Team about the feedback I got 
> here.
>
> This is the e-mail I sent:
> ```
> 1) Mock switched to "--use-bootstrap-image" (podman pulling images
> from various registries by default) and we had no single issue reported
> against the Fedora's registry, but CentOS (on quay.io) gives us random
> "pull" failures:
>
> https://github.com/rpm-software-management/mock/issues/1191
>
> Are you aware of this issue?
>
> 2) Quay.io is moving into console.redhat.com[2], which makes it even less
> fun since RH accounts for the console require giving a lot more
> information.
>
> Do we need to be Red Hat customers to access that? Could it be possible to
> allow Fedora Account System login?
>
> 3) There is a rate limiting enabled for pulling on quay.io [3]. Could it be 
> possible to
> remove that if some Fedora services start hitting that?
> ```
>
> And here is the response I got:
> ```
> Thanks for reaching out- we'd certainly like to support your migration. 
> Fedora makes perfect sense as a tenant on quay.io. Let me try to answer your 
> questions:
>
> 1) Not aware of this issue- I don't believe anyone has raised a support 
> ticket with us on it.
> Wasn't clear to me from the GH issue if you had a stable reproducer. If you 
> do,
> please feel free to raise a bug report at 
> https://issues.redhat.com/projects/PROJQUAY
> and we can take a look.
>
> 2) Our long term plan is to move all authenticated web UI access to 
> console.redhat.com
> but we will keep our quay.io web UI available for unauthenticated access
> (e.g. google search results linking to public images). So only users who need 
> authenticated
> access to your namespace(s)- for example to administer a Team, etc.. would 
> need to sign up
> for a Red Hat Account. Robot account / docker CLI access will still work 
> directly and not require RH SSO- so your automation can still push images, 
> etc..
>
> We have no plans to integrate the Fedora Account System login- but open to 
> discuss what that
> could look like (esp. if it supports OIDC).
>
> 3) We can disable the rate limiting on your namespace(s)- it's usually not a 
> problem, we do this
> for other Red Hat teams (e.g. Openshift). I would be interested to understand 
> more of your
> expected traffic loads for push/pull so we can plan accordingly on our side.
> ```
>
> 1) Corresponds with what Pavel wrote. I sent it before I noticed the response 
> from Pavel.
>
> 2) As FAS is supporting OIDC, we can start negotiating that. Or it would be 
> just mandatory for maintainers of quay.io namespaces to have RedHat account 
> (not that different from managing AWS now).
>

AWS supports being accessed via OIDC SSO, so it's possible to (for
example) tie Fedora's AWS account to FAS. I would really like to see
FAS supported by Red Hat SSO across the board, especially since now
CentOS contributors are forced to deal with Red Hat's Jira instance
with the completion of the RHEL-in-JIRA (RIJ) project.

> 3) That is really great to hear. Do we have any traffic statistics for 
> registry.fp.o in that regard?
>

Can we have an alias for registry.fp.o that goes to our quay namespace
too? Breaking the world is not fun, and if Quay doesn't work out, we
should be able to painlessly switch to something else.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Migration from registry.fp.o to quay.io

[Neal Gompa]

On Mon, Sep 4, 2023 at 12:47 PM Pavel Raiskup  wrote:
>
> On pondělí 4. září 2023 15:35:41 CEST Michal Konecny wrote:
> > Hi everyone,
> >
> > I finished investigation for migration from registry.fp.o to quay.io. It
> > is available in ARC investigation document [0]. The investigation ticket
> > [1] is on fedora-infra tracker.
>
> JFYI, Mock switched to "--use-bootstrap-image" (podman pulling images
> from various registries by default) and we had no single issue reported
> against the Fedora's registry, but CentOS (on quay.io) gives us random
> "pull" failures:
>
> https://github.com/rpm-software-management/mock/issues/1191
>
> So the stability might not be as ideal as with the current registry.
>
> Pavel
>
> > Looking forward for any feedback.
> >

I'm not super-enthused about this from a few perspectives:

1. Core artifacts should be able to be produced, hosted, and consumed
from Fedora infrastructure.
2. Quay ultimately does not need to care about Fedora as a stakeholder
3. Quay.io is moving into console.redhat.com[a], which makes it even less
fun since RH accounts for the console require giving a lot more
information.

[a]: https://issues.redhat.com/browse/PROJQUAY-5434



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: clean up on aisle pagure.io

[Neal Gompa]

On Wed, Apr 26, 2023 at 6:26 PM Ryan Lerch  wrote:
>
>
>
> On Wed, 26 Apr 2023 at 07:17, Kevin Fenzi  wrote:
>>
>> Hey folks.
>>
>> So, a few weeks back I noticed some spam projects on pagure.io.
>> So, I cleaned up about 165 of them and deactivated 165 spam users.
>>
>> Now, I see there's another pile of them. :(
>>
>> So, I started to look at cleaning things up again, but I think we need a
>> better solution that doesn't involve admins manually cleaning things up.
>> ;( Additionally, the clean up is not really very scripted and takes a
>> long time to do.
>>
>> So, thoughts on a longer term solution? I can think of a few:
>>
>> 1. only allow fedora 'contributors' to make new projects. (ie, people in
>> at least one non cla/non base ipa group
>> Pros:
>> - Would very likely cut off the spam or at least cut it way down.
>> - Might be easy to implement? (not sure tho!)
>> Cons:
>> - Would block legit people who aren't fedora contributors.
>
>
> This is my top pick!
>
> Had a quick look at the pagure code, and this looks like we will have to add 
> some additional logic for this to work (not necessarily difficult, but it’s 
> not just a config change)
>
> Afaict, there is no logic to restrict creating new repos (other than turning 
> it off completely). Additionally. The logic that restricts FPCA is done at 
> the login phase. So unless we want to restrict login to FPCA+1 (which I’m not 
> suggesting) it will take a bigger (but not that bad) of a fix to get working.

I'm happy to review contributions for this. The CI finally works
again, so if the tests fail in a PR, at least it's actionable. :)





--
真実はいつも一つ！/ Always, there's only one truth!
___
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 and /boot | /boot/efi

[Neal Gompa]

On Mon, Jan 30, 2023 at 10:05 PM Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> I've been working on migrating things to rhel9 of late.
> I reinstalled a staging virthost or two and found that while rhel8 would
> allow /boot and /boot/efi to be on raid, rhel9 does not all this at all.
>
> So, what do people do for this?
>
> 1. Just put /boot | /boot/efi on a primary partition on one disk and
> hope that disk doesn't die.
>
> 2. Put them on one disk, but have duplicate partitions on the other raid
> disks and some script that copies the 'primary' copies to the backups
> when kernels are changed.
>
> 3. Something else more clever?
>
> Whats best practice here? If 2 is the answer, does anyone have already
> scripts to do this and tie into dnf for kernel updates?
>
> I'd like to get this sorted out before moving any more bare metal hosts
> over to rhel9 if possible.
>

For my boxes, I've stopped having RAIDed OS disks a long time ago, so
option 2 wasn't really a concern for me. That said, it might make
sense to develop a trivial DNF plugin that automatically updates
secondary partitions on every transaction.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: State of Flask-OIDC

[Neal Gompa]

On Mon, Dec 5, 2022 at 12:48 PM Frantisek Zatloukal  wrote:
>
> \o/,
>
> I'd like to ask if there is anybody familiar with the state of flask-oidc? 
> It's been long-time broken with the latest itsdangerous, which was recently 
> bumped in Rawhide, which broke all the applications using flask-oidc from 
> Fedora repositories ( https://bugzilla.redhat.com/show_bug.cgi?id=2150955 ).
>
> There is an upstream PR against flask-oidc changing itsdangerous to pyJWT: 
> https://github.com/puiterwijk/flask-oidc/pull/144 (which, according to my 
> previous testing, makes the trouble go away). Can somebody take a look at it, 
> and merge/release a new fixed version? I can handle pyJWT packaging in Fedora 
> if this is the way forward.
>
> On a similar note, is the flask-oidc library the way to connect to FAS login 
> for python applications? I had an impression that apps should migrate to this 
> from plain openid (and I am planning to handle the transition of remaining 
> Fedora QA apps). It seems abandoned upstream, so should the devs of 
> python/flask apps use some other lib/way?
>
> Thanks a lot upfront!
>

There was an attempt to do something about this:
https://github.com/fedora-infra/flask-oidc

But it also seemingly died.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Drop getfedora.org/cloud redirect

[Neal Gompa]

On Tue, Nov 1, 2022 at 2:27 PM darknao  wrote:
>
> Hi everyone,
>
> As part of F37 release, we are restoring Fedora Cloud as an official
> edition on getfedora.org [1].
> There is an old redirect to https://alt.fedoraproject.org/en/cloud/ that
> will prevent the new page on getfedora to show up.
> We need to get rid of it before the release. See PR [2].
>
> Any +1s?
>
> [1]: https://fedoraproject.org/wiki/Changes/RestoreCloudEdition
> [2]: https://pagure.io/fedora-infra/ansible/pull-request/1240
>

+1



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 *.apps.ocp.fedoraproject.org cert

[Neal Gompa]

On Fri, Oct 14, 2022 at 1:03 PM Kevin Fenzi  wrote:
>
> It's renewed and checked into ansible-private.
>
> Can I get some +1's to push out the new cert to proxies?
>

+1



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Wed, Sep 28, 2022 at 8:35 PM Kevin Fenzi  wrote:
>
> On Tue, Sep 27, 2022 at 04:04:41PM +0200, Neal Gompa wrote:
> > On Tue, Sep 27, 2022 at 3:20 PM Neal Gompa  wrote:
> > >
> > > On Tue, Sep 27, 2022 at 3:01 PM 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?'
>
> Sure, we can.
>
> But at this point I think we have already gotten rid of most of the
> things we really don't need. So, someone will need to make a compelling
> argument for dropping things (at least to me).
>
> > > > mailman01 is one where maybe not having it on fedmsg wouldn't be earth 
> > > > shattering
> > > > but it also has the bigger problem of all its libraries being FTBFS in 
> > > > Fedora and
> > > > being retired from there. At which point we go with 'do we need to run 
> > > > mailing lists?'
>
> Well, until we figure out how to otherwise handle the use cases that
> mailing lists handle now?
>
> For example: all the -sig groups in pagure have mailing lists that get
> all the bugs send to it. We would need to find another way to get bug
> content to those groups (and still keep it private).
> scm-commits is still important IMHO, because its a external record of
> changes. If someone messed with git history, that might be the only
> record of real changes.
> devel/test/a few other lists are still active. They would have to move
> to discourse or otherwise have something.
>
> So, needs a concrete plan. I am not at all in favor of 'turn it off'
> without moving all the needs.
>
> > >
> > > The mailman stack is FTBFS on Fedora right now because of a single
> > > library (python-aiosmtpd) not working properly because of changes in
> > > the SSL module in Python 3.10. The whole stack can branch into RHEL 9
> > > just fine.
> >
> > And apparently that issue was fixed. Branching Mailman in EPEL9 is
>
> So, does that mean mailman3/hyperkitty/postorius can be fixed to not
> fail to build in Fedora now? That might be a bit less effort than them
> being retired and having to unretire them to fix them.
>

Yes, it should be possible. I'm not sure where in the chain it's FTBFS
right now since all the logs were reaped, but since the core
dependency that was breaking is not broken anymore, we can fix this.

> > waiting on people adding infra-sig and epel-packagers-sig to
> > dependencies of the stack.
> >
> > See: https://bugzilla.redhat.com/show_bug.cgi?id=2030061
>
> Yeah, django has been a holdup, but I think it just needs someone to
> say 'I will maintain this in epel9'.
>

Michel Salim was willing to do that, but some of Django's dependencies
are stuck waiting for ownership to be fixed so they can be branched.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Tue, Sep 27, 2022 at 3:20 PM Neal Gompa  wrote:
>
> On Tue, Sep 27, 2022 at 3:01 PM 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?'
> >
> > mailman01 is one where maybe not having it on fedmsg wouldn't be earth 
> > shattering but it also has the bigger problem of all its libraries being 
> > FTBFS in Fedora and being retired from there. At which point we go with 'do 
> > we need to run mailing lists?'
> >
>
> The mailman stack is FTBFS on Fedora right now because of a single
> library (python-aiosmtpd) not working properly because of changes in
> the SSL module in Python 3.10. The whole stack can branch into RHEL 9
> just fine.
>

And apparently that issue was fixed. Branching Mailman in EPEL9 is
waiting on people adding infra-sig and epel-packagers-sig to
dependencies of the stack.

See: https://bugzilla.redhat.com/show_bug.cgi?id=2030061



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Tue, Sep 27, 2022 at 3:01 PM 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?'
>
> mailman01 is one where maybe not having it on fedmsg wouldn't be earth 
> shattering but it also has the bigger problem of all its libraries being 
> FTBFS in Fedora and being retired from there. At which point we go with 'do 
> we need to run mailing lists?'
>

The mailman stack is FTBFS on Fedora right now because of a single
library (python-aiosmtpd) not working properly because of changes in
the SSL module in Python 3.10. The whole stack can branch into RHEL 9
just fine.

>>
>> busgateway - needs fedmsg, only in epel7
>> fedimg - needs fedmsg. will be replaced by some other solution
>> github2fedmsg - needs fedmsg, only in epel7
>> mailman01 - needs fedmsg
>> nuancer - needs fedmsg
>> osbs - needs new container build system
>> pdc - needs to be retired
>>
>> Finally, some I am not sure about and would like input:
>>
>> mbs - is this ready for rhel9? Should we move to Fedora instead?
>> odcs - how about this?
>>
>> So, as far as help goes, getting mirrormanager2 and pagure all in epel9 
>> would be great...
>> coming up with a fedmsg-irc replacement, and getting limnoria in epel9 seem 
>> to be the best ways right now.
>> I can start on the easier reinstalls.
>

Getting Pagure and MM2 branched into EPEL 9 shouldn't be too bad,
hopefully. I did it the last go around for EPEL 8 with not too much
effort.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: I made a new Fedora Apps page, do you want it?

[Neal Gompa]

On Wed, Sep 7, 2022 at 8:23 PM Jakub Kadlcik  wrote:
>
> Hello,
>
> I am reimplementing the current https://apps.fedoraproject.org
> page. It is not finished yet, but I wanted to share a demo with you:
> https://fedora-apps.netlify.app
>
> The upstream is here: https://github.com/frostyx/fedora-apps/
>
> Do you have any interest to eventually switch to this implementation
> and sunset the original one?
>
> PS: Please don't judge me too harshly for the code quality, I am
> learning the language. I will refactor once the basic features are
> done (I know everybody is saying that :D)
>

This is really neat! Thank you for doing this!



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: openshift applications best practices

[Neal Gompa]

On Fri, Jun 17, 2022 at 4:56 PM Kevin Fenzi  wrote:
>
> So, when moving openshift apps this week, I really came to the
> conclusion we should look at writing up some guidelines for openshift
> apps. Perhaps it could have 'MUST' items and 'SHOULD' items and
> 'SUGGESTION' items.
>
> I know I am coming at this from the operations side of things, so please
> do share other viewpoints, but let me mention a few issues I see:
>
> It's very difficult to tell what an application is running on:
> - We should probibly forbid 'X:latest' because what the application is
>   running depends on when it was last built/deployed. (unless: see
>   below)
> - A number of apps use images elsewhere (quay.io, etc). We have very
>   little way to tell whats in those or how they are made or if anyone is
>   still making them.
>
> We have a few apps that rebuild/deploy on git changes, which is fine,
> but doesn't do anything to keep their container env up to date/secure.
>
> We have a number of apps that tigger on imagestream changes, but as far
> as I can tell thats only changes in their image ('bodhi-base') not the
> base image that it was built from ('fedora:36'). I'd like to see us
> track base images and build/deploy when one changes. If we do that then
> :latest might be ok to use, since we know automation took care of
> updating it for us.
>
> There's a number of applications using ubi (rhel's base image), which I
> think might be worth recommending, especially if we start build/deploy
> on base image changes. Likely Fedora base images will change more
> quickly.
>

Fedora's images churning more often is a good thing, not a bad thing.
And frankly, I would not recommend RHEL UBI for a few reasons:

1. It's hard to get things fixed in a timely fashion
2. The content set is too reduced from RHEL
3. We already control the Fedora content, so we should use those

Dogfooding is important, as is self-sufficiency. Inability to do both
makes it much more difficult for others to reuse our stuff.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: on rpms

[Neal Gompa]

On Mon, May 30, 2022 at 11:20 PM Miroslav Suchý  wrote:
>
> Dne 23. 05. 22 v 20:57 Kevin Fenzi napsal(a):
> > However, now a days we have a number of new apps that are deployed in
> > openshift and aren't using rpms, but pip or s2i or other things.
>
> Regarding pip applications - we have pyp2rpm and pyp2spec which can convert 
> to rpm easily. And we have
>
>   https://copr.fedorainfracloud.org/coprs/g/copr/PyPI/
>
> with about 70k packages.
>

The bigger problem is that those applications are *not* able to easily
be deployed outside of Fedora infrastructure. One consequence of
OpenShift based deployments is that it's become almost too easy to
assume nobody else would ever want to run that code. Noggin and Bodhi
both have had a number of code changes in the past couple of years
that have made it increasingly difficult to use outside of Fedora
deployments in their default code state. I've given up on Bodhi, but
I'm still trying to get Noggin into good shape.

I've been able to evaluate those issues by packaging them as RPMs,
because RPM packaging forces a total decoupling of development,
deployment, and configuration. None of that is true with our container
based deployments. They're not discoverable, and if you can find them,
they're not independently useful.

Because of this, it becomes hard for community growth around these projects.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: FBR: Add nb to PAGURE_ADMIN_USERS

[Neal Gompa]

On Wed, Apr 27, 2022 at 5:11 PM Nick Bebout  wrote:
>
> I was working on a ticket mattdm filed about some spammers in Pagure.  I'd 
> like to add myself to PAGURE_ADMIN_USERS and run the Pagure playbook.
>
> PR here: https://pagure.io/fedora-infra/ansible/pull-request/1048
>

+1 here

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fedora 36 Beta Freeze now over

[Neal Gompa]

On Wed, Mar 30, 2022 at 7:49 AM Neal Gompa  wrote:
>
> On Wed, Mar 30, 2022 at 7:18 AM Mark O'Brien  wrote:
> >
> > Hi All,
> >
> > With the successful release of Fedora 36 beta yesterday we are now out of
> > freeze.
> >
> > Our next planned freeze is 2022-10-04 for Fedora 36 Final Release.
> > THIS IS NEXT TUESDAY!
>
> I don't think you meant October 4, which also happens to be a Tuesday. :)
>
> Do you mean April 10? (i.e. 2022-04-10)
>

And I should check dates, because the Final Freeze is actually April 5! :D



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fedora 36 Beta Freeze now over

[Neal Gompa]

On Wed, Mar 30, 2022 at 7:18 AM Mark O'Brien  wrote:
>
> Hi All,
>
> With the successful release of Fedora 36 beta yesterday we are now out of
> freeze.
>
> Our next planned freeze is 2022-10-04 for Fedora 36 Final Release.
> THIS IS NEXT TUESDAY!

I don't think you meant October 4, which also happens to be a Tuesday. :)

Do you mean April 10? (i.e. 2022-04-10)




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Building VM images for Copr builders

[Neal Gompa]

On Wed, Feb 23, 2022 at 12:19 PM Pavel Raiskup  wrote:
>
> Hello infra!
>
> Currently, in Copr team we are periodically preparing those kinds of images 
> for
> our VM builders:
>
> - x86_64 AMI image for AWS
> - aarch64 AMI
> - x86_64 image for hypervisors
> - ppc64le qcow2 image (uploaded to Power9 OpenStack and to our Power8 
> hypervisors)
> - s390x qcow2 (built in IBM Cloud)
> - internally we build also x86_64 images for OpenStack
>
> The way we do this now is pretty complicated:
>
> - we start with the officially provided Fedora images (AMI/QCOW2)
> - we modify and update them using ansible scripts and/or libguestfs
> - then the images are uploaded, and tested in our development stack
> - and if everything is OK, then these images are used in production
>
> Some more info https://docs.pagure.org/copr.copr/how_to_upgrade_builders.html
>
> This is a tedious and repetitive list of tasks, and I'm sure we
> should/could automatize some parts.  At least it would be awesome if we
> could try to trigger the build(s) for all the images by "a single button",
> somehow, somewhere...  So I am here to ask you how you would do this.
>
> - I thought the answer is Image Builder, but there's a missing support for
>   Fedora ppc64le and s390x targets for now (rhbz#2040685).
>
> - livemedia-creator, seems to be a bit related to Image Builder but I was told
>   some time ago that AMI support is experimental, the docs say
>   "At this time I have not tested the image with EC2. Feedback would be
>   welcome."
>
> - There's a Packer software (packer.io) used by testing farm folks (the 
> tooling
>   is not available in Fedora yet).
>
> - Koji is able to build some images using Kickstarts.  This one looks like
>   low-hanging fruit.  Existing and working solution, we could built on top of
>   of the maintained fedora-kickstarts files that we "use" anyway (through the
>   pre-built official images).  But I'm not sure if our team could be allowed 
> to
>   use Koji like this, and provide additional *ks files?
>
> Are there any other possibilities?  Opinions?
>

The kiwi image builder would be another option. The Fedora Cloud and
CentOS Hyperscale teams are exploring using it for images, and we've
been collaborating with the Koji folks on kiwi support. Also, at work
I'm doing stuff with kiwi for our cloud images, and I'd be happy to
help teach y'all how to use kiwi for building images for all of your
platforms.

It's packaged in Fedora and EPEL, so it's easy to get and use.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Tue, Feb 1, 2022 at 12:16 PM Aurelien Bompard
 wrote:
>
> Hey folks!
>
> A long email to give you some context, please bear with me :-)
>
> A while back, Bodhi's integration tests stopped working on the "pip"
> release (basically the latest python packages from PyPI). Since the
> integration tests were flaky at that time, they were disabled on the
> "pip" release. Now that the flakiness has been fixed (for now ;-) )
> I've revisited why they still fail. It led me to open a bodhi ticket
>  that explains the
> situation: basically Pyramid is switching the session serializer from
> pickle to JSON, because pickle is pretty insecure. However, one of our
> dependencies, python-openid, stores an object instance in the session,
> and that can't be serialized to JSON. A ticket has been opened on
> python-openid about that in *2011*, and the last comment in 2014
> states that the library is pretty much unmaintained.
>
> I think it's the final nail in Bodhi's OpenID auth coffin, we've
> wanted to switch to OIDC (OpenID Connect) for a long while but haven't
> got around to it yet. Now I don't think we can delay it much longer,
> as the newer versions will find their way in Fedora releases and
> things will stop working without horrible ad-hoc patches.
>
> I've started to convert Bodhi to OIDC, using the authlib library. The
> server part isn't so hard (there isn't a ready-made integration layer
> for Pyramid as there is for Flask and Django, but it's fine, it's not
> a big layer). The client however is going to be pretty different after
> the conversion. To log in, users won't be able to pass the login and
> password as they do now. When an authenticated operation is requested,
> the command-line client will open a browser window to ask the user to
> login on id.fp.o, as for web apps. After a successful login the page
> will say "You can now close this page and go back to bodhi". I know it
> looks weird to have a command-line tool open a graphical tool, but
> it's actually the recommended way to do things securely.
>

It also doesn't work at all if you're doing work from a remote box or
in a headless system (like Vagrant or whatever). I've tried myself,
and I've failed to pull it off.

> 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'd like to see anything that makes this better. It would also help
for the eventual transition away from SSH for committing to Dist-Git,
as that's also blocked on the awkward workflow for HTTPS usage.

> So, I have questions:
> - Do any of you run the bodhi CLI on a headless server instead of on
> their workstation?
> - Do you use the --username and --password command-line switches of
> bodhi-client?
> - How far ahead should we warn users of this change? There's doc to update 
> too.
>

I do. There's also other external clients, like Fabio Valentini's
Rust-based ones. We should check with him on how we affect that.

> I don't think I can easily keep both stacks (OpenID and OIDC) working
> simultaneously, but in the interest of ease of migration I can try, if
> it's worth the non-negligible effort.
>
> I think I can get this work done in the context of the Bodhi
> initiative this quarter. If things don't explode too big.
>
> Comments? Opinions?
> Thanks for reading this far :-)
>

Thanks for looking into this!



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: automating SCM requests (again)

[Neal Gompa]

On Thu, Jan 6, 2022 at 10:08 AM Ken Dreyer  wrote:
>
> On Wed, Jan 5, 2022 at 3:14 PM Matthew Miller  
> wrote:
> >
> > Okay, this is making me _very_ sure that we should automate these:
> >
> > https://pagure.io/fedora-infrastructure/issue/10441
> >
> > That's because even though a human is spending time running the script,
> > there does not seem to be any opportunity for human intervention... this
> > happened: https://pagure.io/releng/fedora-scm-requests/issue/39869
>
> We give users a web form (Pagure) that invites human input, and then
> an automatic-but-human-sounding-response that gives the same response
> over and over, or eternal silence. There's no indication in the
> comment that this is not a human, or a clear link to the source code
> to improve anything about the situation.
>
> See my comment in
> https://pagure.io/releng/fedora-scm-requests/issue/19865 . I hit a
> despairing moment like you did. Interesting that you're able to
> re-open your ticket, because I don't think my account has permission
> to do that in this Pagure project.
>
> Imagine if this was as easy as GitHub or GitLab, where I just click a
> button to create a new repo, or I run "git push" to create a new
> branch.
>
> I miss the clarity and simplicity of Pkgdb.
>
> I've mentored a new Fedora contributor through this process a while
> ago, and this scm-admin part was the point at which they gave up.
>

I hate the scm-admin part. I hope we fix it... :(



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: [FBR] Update pagure to 5.13.3

[Neal Gompa]

On Mon, Nov 1, 2021 at 11:06 AM Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> This morning, I have cut a new release of pagure: 5.13.3 with the following
> changelog:
> - Warn users when a PR contains some characters
> - srcfpo theme: Change "Packages" link to new packages website (Brendan Early)
> - srcfpo theme: left-align the lines in description (Zbigniew 
> Jędrzejewski-Szmek)
> - fas user url updated for new accounts system (Mark O Brien)
> - Change fas link from admin.fp.o to accounts.fp.o (Lenka Segura)
> - Remove message about 60 day key length (Ken Dreyer)
> - Escape $ to fix Jenkins interpolation warning (#5178) (Anatoli Babenia)
> - Fix another invalid  width/height attribute (Anatoli Babenia)
> - Fix missing space before src in 

Re: Openshift 4 SOP PR review

[Neal Gompa]

On Thu, Sep 23, 2021 at 11:02 PM David Kirwan  wrote:
>
> > On the storage, are we ok if a node goes down? ie, does it spread it
> > over all the storage nodes/raid? Or is it just in one place and you are
> > dead if that node dies?
> For storage, we maintain 3 replicas for data, spread across 3 nodes. However, 
> not all nodes are equally resourced, we have 2 large nodes and 1 much 
> smaller, therefore, more replicas will be spread over these 2 larger nodes. 
> We can likely afford to lose one of the large physical nodes while still 
> maintaining data integrity.
>
> > Is there any way to backup volumes?
> There are ways to clone, extend, take snapshots etc of these volumes. We've 
> never done it, so it'll be a learning process for us all ;). We should sync 
> to get a better handle on the requirements for backups. In CentOS CI we've 
> set up backups to S3, we can certainly use some of that, eg: backup of etcd, 
> but may need further investigation to backup the volumes managed by OCS. Will 
> need to do some research here.
>
> > should we make a playbooks/manual/ocp.yml playbook for things like
> > - list of clusteradmins
> > - list of clustermoniting
> > - anything else we want to manage post install
> Sure yep, as we're finishing up soonish, I'd imagine the next few weeks we'll 
> all be back focused on the Infra/Releng tasks and will be focusing on tying 
> up any loose ends like this, and starting migration of apps.
>
> > Have we tried a upgrade of the clusters yet? Did everything go ok?
> > Do we need any docs on upgrades?
> Yes, we've already completed a number of upgrades, latest is to 4.8.11. We 
> have SOPs for upgrades which we can copy over from the CentOS CI infra, and 
> will make any updates required in the process.
>
>
> > Since the control plane are vm's I assume we need to drain them one at
> > a time to reboot the virthosts they are on?
> If we are rebooting a single vmhost/control plane VM at a time, yes that 
> should be good. If we are doing more than 1 at the same time, we should do a 
> full graceful cluster shutdown, and then a graceful cluster startup. We have 
> SOPs for this in CentOS CI also, we'll get those added here and any content 
> updates made.
>
> > * Should we now delete the kubeadmin user? In 3.x I know they advise to
> > do that after auth is setup.
> We can delete it, as we have system:admin available from the os-control01 
> node. Best practices might suggest we do. We can also give cluster-admin role 
> to all users in the sysadmin-main and sysadmin-openshift groups.
> I'm in two minds about deleting it, I was hoping to wait until we get a 
> solution that syncs IPA groups/users to Openshift. There is an official 
> supported solution for syncing LDAP (think that will work?).
>
> > * Right now the api is only internal. Is it worth getting a forward
> > setup to allow folks to use oc locally on their machines? It would
> > expose that api to the world, but of course it would still need auth.
> We'd love to expose it, but.. all interaction with the clusters upto this 
> point have also only been done via Ansible, so if it turns out we can't 
> expose the API like this we're ok with that. With minor changes to the 
> playbook we should be able to at least replicate the current 3.11 experience.
>
> >> That's what we decided to do for the CentOS CI ocp setup, and so CI
> >> tenants can use oc from their laptop/infra. As long as cert exposed for
> >> default ingress has it added in the SAN, it works fine :
> >>
> >> X509v3 Subject Alternative Name:
> >> DNS:*.apps.ocp.ci.centos.org, DNS:api.ocp.ci.centos.org,
> >> DNS:apps.ocp.ci.centos.org
>
> > Yeah, thats all fine, but to make it work for our setup, I would need to
> > get RHIT to nat in port 6443 to proxy01/10 from the internet. At least I
> > think thats the case. Openshift 3 could just use https, but alas, I fear
> > OCP4 needs that 6443 port.
> Yep think you're right on that.
>
>
> >Do we want to try and enable http/2 ingress?
> https://docs.openshift.com/container-platform/4.5/networking/ingress-operator.html#nw-http2-haproxy_configuring-ingress
> We can take a look and see if we can figure it out!
>
>
> > We will want to enable kubevirt/whatever it's called...
> We definitely want to make this available, but we will have to set quotas on 
> usage. We should enable on staging, but should we enable on production?
>
> On CentOS CI OCP4 cluster, we have Openshift Virtualization / kubevirt 
> installed, but I don't think anyone is actually using it. We have several 
> tenants which have elevated permissions, and are then accessing KVM directly 
> to bring up VMs on the Openshift nodes, this is something we want to avoid, 
> as we can't effectively set quotas on this type of usage.
>

I believe the Hyperscale SIG is using it. Or if they're not, it's
because they don't know it's there.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
infrastructure 

Re: Openshift 4 SOP PR review

[Neal Gompa]

On Wed, Sep 22, 2021 at 7:12 PM Kevin Fenzi  wrote:
>
> On Wed, Sep 22, 2021 at 01:03:52PM +0900, David Kirwan wrote:
> > Hi all,
> >
> > We have put a number of SOPs together, related to Openshift 4, installation
> > and configuration on Fedora Infra, we are hoping to get some feedback!
> >
> > If you get a minute please check the following:
> > https://pagure.io/infra-docs-fpo/pull-request/8
>
> Looks pretty nice to me. Thanks for the detailed docs. ;)
>
> I do have some other questions, might as well throw them here:
>
> * On the storage, are we ok if a node goes down? ie, does it spread it
> over all the storage nodes/raid? Or is it just in one place and you are
> dead if that node dies?
>
> * Is there any way to backup volumes?
>
> * should we make a playbooks/manual/ocp.yml playbook for things like
> - list of clusteradmins
> - list of clustermoniting
> - anything else we want to manage post install
>
> * Have we tried a upgrade of the clusters yet? Did everything go ok?
> Do we need any docs on upgrades?
>
> * Since the control plane are vm's I assume we need to drain them one at
> a time to reboot the virthosts they are on?
>
> * Should we now delete the kubeadmin user? In 3.x I know they advise to
> do that after auth is setup.
>

I'm not sure that's a good idea. I'm not even certain that was a good
idea in the OCP 3.x days, because eliminating the kubeadmin user means
you lose your failsafe login if all else fails.

> * Right now the api is only internal. Is it worth getting a forward
> setup to allow folks to use oc locally on their machines? It would
> expose that api to the world, but of course it would still need auth.
>
> * Do we want to try and enable http/2 ingress?
> https://docs.openshift.com/container-platform/4.5/networking/ingress-operator.html#nw-http2-haproxy_configuring-ingress
>

Maybe? I think if we want to have more HA-deployed services, it would
make sense to do so.

> * We will want to enable kubevirt/whatever it's called...
>

I think it's formally called OpenShift Virtualization, but yeah, it's KubeVirt.

> Thanks for the great docs. +1 on them.
>

These are awesome, indeed!




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: another ipsilon freeze break

[Neal Gompa]

On Mon, Sep 13, 2021 at 2:58 PM Kevin Fenzi  wrote:
>
> This time I just want +1s to run the ipsilon playbook.
>
> This will deploy the OIDC client data for the production ocp cluster we
> are working on bringing up. It shouldn't cause any problems and woud be
> easy to back out.
>
> +1s?

+1


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Freeze Break Request: more ipsilon/sssd debugging

[Neal Gompa]

On Mon, Sep 13, 2021 at 1:34 PM Kevin Fenzi  wrote:
>
> So, it turns out the additional debugging we setup in that sssd package
> on the ipsilon servers isn't sufficent to show what the problem is. ;(
>
> sssd developers would like us to crank up debugging to try and get logs
> of whats happening. Unfortunately, this will use a ton of disk space,
> which these vm's do not have much of. ;(
>
> I was going to ask to grow the disk on ipsilon02, but I think perhaps
> cleaner would be to create a NFS volume and mount it on /var/log/sssd/
> on ipsilon02. This way we don't need to actually take the machine down
> and it's really easy to back out.
>
> So, can I get +1s to:
>
> * make a NFS volume and mount it on /var/log/sssd on ipsilon02
> * adjust ipsilon02's sssd to enable crazy levels of debug.
> * restart sssd and wait for the next failure.
> * profit!
>
> +1s? other ideas?
>

+1 from me.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Freeze Break Request: debugging sssd on ipsilon

[Neal Gompa]

On Thu, Sep 9, 2021 at 3:28 PM Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> We have been having a sporadic issue for a while now where sssd on
> ipsilon01 and/or ipsilon02 goes into a error state and starts rejecting
> everyone's logins. ;( See https://fedorastatus.org and the ticket on
> this. It's really quite irritating.
>
> We have raised a ticket with sssd upstream and they need more
> information to find the bug. Toward that end, they have made a build of
> sssd that has debugging particular to this failure in it.
>
> So, I'd like to upgrade ipsilon01/02 to this debugging sssd build and
> wait for the problem to re-occur and get them the info they hopefully
> need to fix it.
>
> This build just has a small debugging patch on top of the existing
> fedora 34 build we are using now. We should be able to dnf distro-sync
> anytime to get back to the stock one.
>
> Can I get +1s to do this? :)
>

+1 from me.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: epel-next and MirrorManager

[Neal Gompa]

On Wed, Jun 2, 2021 at 9:17 AM Adrian Reber  wrote:
>
> Recently a bug was opened to add additional repositories to
> MirrorManager for epel-next. One of the problems with adding new
> repository definitions to MirrorManager is that the definitions are part
> of the code. For each new/changed repository a new release is needed.
>
> I was thinking about changing this for a long time. Have the repository
> definition in a configuration file.
>

Making this a configuration file would also make it easier to adopt in
other projects. For example, it's still bandied about for openSUSE.
The hardwired definitions in the codebase are a problem, though.

> During the last months I have been rewriting umdl in Rust after the
> first two MirrorManager tools rewritten in Rust proofed to be really
> reliable during the last 1.5 years.
>
> The new tool, scan-primary-mirror, is already used in RPM Fusion for a
> few weeks and now with the need to have epel-next repositories I
> replaced umdl only for EPEL also in Fedora.
>
> So far it seems to work correctly. The epel-next repositories have been
> detected and all other metalinks have also been updated correctly.
>
> Please let me know if something around EPEL metalinks is not working as
> expected.
>

Are these tools packaged in Fedora yet?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Fri, May 7, 2021 at 4:41 PM Adam Williamson
 wrote:
>
> 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

This is going to be awesome and terrible



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: informal video meeting for infrastructure contributors

[Neal Gompa]

On Wed, May 5, 2021 at 1:55 PM Kevin Fenzi  wrote:
>
> On Wed, May 05, 2021 at 08:30:30AM -0400, Eduard Lucena wrote:
> > What if we record this an we put it in the Fedora Project Channel on
> > YouTube?
>
> Well, I am not sure about that. We wanted to just have some casual
> conversation and no set topic. I personally don't mind a recording, but
> it might make some people nervous or unwilling to participate.
>
> I think perhaps we could look at doing some more formal videos that we
> could record / publish?
>
> Just my opinion... what does everyone else think?

I'm cool with an informal thing (no topic, no recording).


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: ssh git access to src.fedoraproject.org feedback

[Neal Gompa]

On Wed, Mar 3, 2021 at 6:12 PM Kevin Fenzi  wrote:
>
> On Wed, Mar 03, 2021 at 05:26:46PM -0500, Neal Gompa wrote:
> > On Wed, Mar 3, 2021, 5:13 PM Matthew Miller 
> > wrote:
> >
> > > On Wed, Mar 03, 2021 at 01:53:28PM -0800, Kevin Fenzi wrote:
> > > > 4) We could add some kind of GSSAPI/Kerberos support to pagure, so
> > > > people could use https and a kerberos ticket.
> > >
> > > What's amount of effort required for this option? Because other than "it
> > > might be a lot of work", it seems ideal, and would resolve a lot of other
> > > cases where it's an extra step to have to configure an access token for
> > > pagure. But "it might be a lot of work" is a pretty big con.
> > >
> > > If the answer is "yeah, it's a lot", I vote for whichever other option
> > > makes
> > > this a logical next step when there is time to do such work.
> > >
> >
> > I don't think it would be that hard anymore. Recently, Pagure changed to
> > proxy and handle Git via HTTPS, meaning that we can do whatever we want to
> > authenticate pulls and pushes.
>
> Except this doesn't work currently for src.fedoraproject.org pagure, as
> the OIDC tokens take over. :(
>

Yeah, we need to fix this somehow. But it shouldn't be too hard, I
think? We already have this setup for pagure.io...

> > Ideally, we'd support it as a full login backend, so that logins this way
> > would also generate accounts automatically.
>
> As long as those were pagure accounts, sure.
> We don't want real system accounts. :)
>

Of course! These would be Pagure accounts, not Linux system accounts.


> > We do have a ticket for GSSAPI for Git+HTTPS:
> > https://pagure.io/pagure/issue/4995
>
> Yeah, perhaps mod_auth_gssapi would be a short way to this.
>
> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: ssh git access to src.fedoraproject.org feedback

[Neal Gompa]

On Wed, Mar 3, 2021, 5:13 PM Matthew Miller 
wrote:

> On Wed, Mar 03, 2021 at 01:53:28PM -0800, Kevin Fenzi wrote:
> > 4) We could add some kind of GSSAPI/Kerberos support to pagure, so
> > people could use https and a kerberos ticket.
>
> What's amount of effort required for this option? Because other than "it
> might be a lot of work", it seems ideal, and would resolve a lot of other
> cases where it's an extra step to have to configure an access token for
> pagure. But "it might be a lot of work" is a pretty big con.
>
> If the answer is "yeah, it's a lot", I vote for whichever other option
> makes
> this a logical next step when there is time to do such work.
>

I don't think it would be that hard anymore. Recently, Pagure changed to
proxy and handle Git via HTTPS, meaning that we can do whatever we want to
authenticate pulls and pushes.

Ideally, we'd support it as a full login backend, so that logins this way
would also generate accounts automatically.

We do have a ticket for GSSAPI for Git+HTTPS:
https://pagure.io/pagure/issue/4995

>
___
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: Fedora packages site down

[Neal Gompa]

On Wed, Nov 25, 2020 at 1:30 PM Brendan Early  wrote:
>
> On 11/25/20 12:00 PM, Mattia Verga wrote:
> > I can't find anymore the links to the testing instances of the two apps.
> > Can anyone re-post them here?
>
> I don't have testing instances, but it will look similar to this.
>
> https://mymindstorm.fedorapeople.org/pkgs-demo/pkgs/numix-icon-theme-square/
>
> You may want to look at this thread for more background.
>
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/JLKMBMMGR6H6OSLW35ZXODPNAQP4OIEF/
>

My understanding is that the -static version cannot update at the same
cadence as the content synced out to the mirrors. To me, that's a
problem, because then the data is just too stale or wrong because it's
not fresh enough.

The behavior of the -ng version is preferable to me, since the content
will actually match what Fedora has continuously.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: pagure.fedoraproject.org

[Neal Gompa]

On Thu, Sep 24, 2020 at 3:10 PM Kevin Fenzi  wrote:
>
> Greetings.
>
> We have been wanting to upgrade pagure01 from rhel7 to rhel8 for a
> while. Additionally, the disk we have defined for it is getting too
> small, so we would need to add space.
>
> To deal with both issues, I have created a pagure02 rhel8 instance with
> a larger disk on the same virthost.
>
> I'd like to modify the sshd_config on pagure01 (temporarily) to allow
> agent forwarding. This will allow us to use the ansible agent on
> batcave01 to rsync data over ssh from pagure01 to pagure02. I intend to
> only have this active while copying.
>
> I plan to then copy:
>
> /srv
> /var/lib/pgsql
> /var/www/
>
> over and then pingou will take over and get things setup and running.
> We can then test things until beta freeze is over and then schedule a
> outage late next week to do the cut over.
>
> Can I get +1s for the sshd change and plan in general?
>

+1 to the whole thing.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: increase koji ram to 32 GB

[Neal Gompa]

On Mon, Sep 21, 2020 at 3:52 PM Stephen John Smoogen  wrote:
>
>
> Currently koji01 and koji02 are using 16 GB and need 32 GB . Bump each guest 
> in ansible and via virsh commands.
>

+1



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 state of staging

[Neal Gompa]

On Fri, Sep 18, 2020 at 3:32 PM Kevin Fenzi  wrote:
>
> greetings everyone.
>
> I thought I would send out an email about where we are with staging and
> get more input on some things related to that. :)
>
> Account system / noggin:
>
> I will let the noggin team report here. I know they have been working on
> deployment and fixing issues they hit. I don't think other things a
> blocking them. Please do chime in here noggin team!
>
> Buildsystem side:
>
> * koji hub is up
> * koji db is up, but the prod->stg sync script failed with a db error.
> Still need to debug what is wrong there. Likely the koji db schema
> changed and we need to adjust the sync script.
> * The x86_64 and s390x buildvm's are up.
> * The aarch64/armv7 and ppc64le builders are not yet up. I need to talk
> with smooge next week when he is back and we need to adjust vlans and
> such to get them online.
> * I haven't deployed the aarch64 osbs yet, but it should be doable.
>
> * I am currently doing a load of the db01 prod server db into db01.stg.
> This will then need adjustment for staging users/passwords on a app by
> app basis. This is a good time/place to change staging applications db
> passwords.
>
> Things I have not deployed and why:
>
> * basset - unclear if we are wanting this again to interface with noggin
> or not.
>
> * datagrepper/datanommer - We did not save any of the staging databases
> sadly, so we would need to start with a copy of prod, but since we plan
> to redo this application soon, I thought why not just wait until then
> and we can deploy the replacement in stg.
>
> * notifs - This is also going to get replaced, but also it would be
> difficult to deploy in stg since it's on a EOL fedora.
>
> * badges - do we want to deploy this in stg? Or was it going to move to
> openshift?
>
> * fedimg - we don't compose images in stg yet and we were going to
> replace this anyhow.
>
> * mailman - Also wanting to be redeployed, so figured there wasn't much
> point in deploying the old thing again now.
>
> So, basically everything is installed, we need to go and fix
> applications now that aren't working. Perhaps this could be a good use
> of a monitoring solution test. :)
>
> One thing that needs doing soon is getting sssd working correctly in
> staging, which will allow non root logins and sudo and hopefully groups
> (some of which are used in playbooks). I hope to look more into that
> next week.
>
> Thoughts? questions?
>

Thanks for getting this far along, Kevin! It's still on my plate to
fix the mailman3 stack and get everything into Fedora...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 koji to 1.22.1

[Neal Gompa]

On Wed, Sep 9, 2020 at 2:47 PM Kevin Fenzi  wrote:
>
> koji 1.22.1 just was released. It's a small bugfix only release:
> https://lists.fedorahosted.org/archives/list/koji-de...@lists.fedorahosted.org/thread/YU5CXXID6VMWMV6EBCFYIHPI5LMHTVHH/
>
> https://docs.pagure.org/koji/release_notes/release_notes_1.22.1/
>
> We already had a patched rpm with the btrfs subvolume and
> extra-boot-opts fixes. I want to update to this version to get
> the fix for time formatting for timezone values. This is the bug that
> prevents us from loading information about container builds (either on
> the web interface or via the cli). A number of people have noticed this
> bug. :(
>
> There's no schema update so we can downgrade if something happens.
>
> +1s?
>

+1 LGTM



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fix DKIM signing for aws and fedorahosted

[Neal Gompa]

On Wed, Sep 2, 2020 at 3:03 PM Stephen John Smoogen  wrote:
>
> diff --git a/roles/opendkim/files/SigningTable 
> b/roles/opendkim/files/SigningTable
> index 84cb8f78f..81cad91f3 100644
> --- a/roles/opendkim/files/SigningTable
> +++ b/roles/opendkim/files/SigningTable
> @@ -15,6 +15,10 @@
>  *@fedoraproject.org bastion-iad._domainkey.fedoraproject.org
>  *@lists.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
>  *@stg.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
> +*@aws.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
> +*@fedorahosted.org bastion-iad._domainkey.fedoraproject.org
> +*@lists.fedorahosted.org bastion-iad._domainkey.fedoraproject.org
> +pag...@pkgs.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
>  pag...@pagure.io bastion._domainkey.pagure.io
>
>  # NON-WILDCARD EXAMPLE
>

+1



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 (Fix 2factor on builders)

[Neal Gompa]

On Fri, Aug 28, 2020 at 4:29 PM Stephen John Smoogen  wrote:
>
>
> Currently the builders are trying to contact os-node boxes on port 8443 but 
> that is not where fas-all lives.
>
> diff --git a/roles/base/templates/iptables/iptables.kojibuilder 
> b/roles/base/templates/iptables/iptables.kojibuilder
> index a3819777c..805cf735f 100644
> --- a/roles/base/templates/iptables/iptables.kojibuilder
> +++ b/roles/base/templates/iptables/iptables.kojibuilder
> @@ -78,10 +78,12 @@
>  -A OUTPUT -p tcp -m tcp -d 10.3.163.76 --dport 443 -j ACCEPT
>  -A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 80 -j ACCEPT
>  -A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 443 -j ACCEPT
> -# for 2 facter auth
> --A OUTPUT -p tcp -m tcp -d 10.3.163.69 --dport 8443 -j ACCEPT
> --A OUTPUT -p tcp -m tcp -d 10.3.163.70 --dport 8443 -j ACCEPT
> --A OUTPUT -p tcp -m tcp -d 10.3.163.71 --dport 8443 -j ACCEPT
> +# for 2 facter auth (fas-all)
> +-A OUTPUT -p tcp -m tcp -d 10.3.163.74 --dport 8443 -j ACCEPT
> +-A OUTPUT -p tcp -m tcp -d 10.3.163.75 --dport 8443 -j ACCEPT
> +-A OUTPUT -p tcp -m tcp -d 10.3.163.76 --dport 8443 -j ACCEPT
> +-A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 8443 -j ACCEPT
> +
>
>  #nfs to vtap-fedora-nfs01.storage.phx2.redhat.com - a little to wide-open - 
> but
>  # kinda necessary
>

+1 from me.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 update for all builders

[Neal Gompa]

On Thu, Aug 27, 2020 at 2:37 PM kevin  wrote:
>
> The koji 1.22.0 update added handling for the '--extra-boot-args'
> kickstart option. UNfortunately, this support wasn't working right and
> causes all our images specifying such options to fail.
>
> The good news is that the fix is just a one-liner:
>
> -cmd.extend(['--extra-boot-args',
> -'--append=\"%s\"' % b_append])
> +cmd.extend(['--extra-boot-args', '\"%s\"' % b_append])
>
> I've built a new rpm with this patch applied and would like to do a
> freeze break to apply it to the 'builders' ansible group.
> (This applies to kojid).
>
> See:
> https://pagure.io/koji/pull-request/2452
> https://pagure.io/fedora-infrastructure/issue/9271
>
> +1s?
>

LGTM!

+1



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 state of the planet (the app)

[Neal Gompa]

On Mon, Jul 20, 2020 at 4:36 AM Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> Running a personal planet and having upgraded the box running it to a recent 
> OS
> (Fedora in this case), I have found out that the underlying application does 
> not
> support python3.
>
> To be precise, the main script says:
>   Requires Python 2.1, recommends 2.3.
>
> Needless to say, this doesn't work anymore with python3.
>
> So I went looking a bit around to see what is available.
> There is Venus which we run, which has this problem ^ and hasn't been touched 
> in
> 9 years:
> https://github.com/rubys/venus
>
> There are a few java-based, php-based, or ruby-based, with different level of
> activity (though to be fair, RSS and planets have been there for a while now, 
> so
> a working application likely does not need much maintenance anymore).
> However, nothing jumped at me as a clear successor for our setup.
>
> Do people have some experience with planet? Would you recommend us something?
>
>
> At this stage, it is very unclear to me if the best approach is to switch
> application (new stack, new UI to do, new configuration file to do/adjust...) 
> or
> port venus to python3 (potentially a 1 time effort but what about the long 
> term
> maintenance?).
>

I believe Stasiek (CC'd to this email) recently implemented a planet
replacement. I am unsure if he used Venus or something else, though.

Perhaps he can reply with information...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

[Neal Gompa]

On Mon, Jul 6, 2020 at 8:22 PM Ken Dreyer  wrote:
>
> On Wed, Jul 1, 2020 at 12:57 PM Stephen John Smoogen  wrote:
> >
> > On Wed, 1 Jul 2020 at 14:46, Miroslav Suchý  wrote:
> > >
> > > Dne 30. 06. 20 v 9:44 Pierre-Yves Chibon napsal(a):
> > > > What are you talking about here? The Fedora release process? The 
> > > > mass-branching
> > > > in dist-git?
> > >
> > > This. And creating new gpg keys, new mock configs, new tags in Koji, add 
> > > release to retrace.f.o, Copr, ... I have a
> > > dream where you just bump up number in - let say - PDC and everything 
> > > else will happen automagically. At right time.
> > >
> >
> > I think choosing the one tool which is so end of life to do it in.. is
> > a sign of why we can't do this. Every release some set of tools in
> > Fedora get added by some team who have been working on their own
> > schedules and their own API without any idea of any other teams
> > working on.
> > We then have to do a lot of integration and make it work
> > before the release deadline to make it work. Then usually after 1 or 2
> > releases that software team is no longer in existence and we have to
> > continue with it waiting for the promised replacement which will do
> > all those things you list above.. but instead get some other tool
> > which has to be shoved in.
>
> This is an excellent summary of the problem over the past couple of years.
>
> I think one of the problems with PDC was that so many teams had to
> adapt all their *giant* tools to it, and this integration effort was
> unsustainable when we have natural contributor turnover. Everything
> ended up tightly coupled together so that it was really difficult to
> remain agile as tools and business requirements (naturally) changed.
> Also we never drew the line and wrote a list of things that PDC was
> *not* going to do, so the Second Syndrome effect just kept growing
> until it collapsed.
>
> Instead of having everything having to talk to PDC to determine its
> configuration, I'm approaching this problem from the other end -
> making Ansible talk to all the services according to each service's
> API. Here are some things I like about this approach:
>
> 1. Ansible is really simple and well-documented.
>
> 2. It's easy to start small and get value incrementally.
>
> 3. The playbooks can (and do) change independently from the APIs. This
>kind of agility is essential because SOPs must be able to change over
>time.
>
> 4. If we haven't completely implemented something in Ansible yet, the
>service itself is not completely broken. The workaround does not
>require multiple teams of developers (like with PDC). The workaround
>is that the administrator simply does the thing they used to do
>manually (and file tickets for the missing RFEs in the Ansible modules)
>
> For the koji-ansible project, we're using it to configure some large
> products internally. Now we have to expand this concept to the rest of
> the pipeline (Bodhi, Pungi configuration, etc.)
>
> Clement started on https://github.com/cverna/bodhi-ansible but I think
> that's abandoned at this point. I do think this is the way to go,
> though. In some ways this is the point - it should be possible for
> these Ansible modules to be isolated so that when contributor turnover
> happens, the whole system does not fall apart.
>

This sort of worries me though: abusing Ansible to do this sort of
thing is not what it was made for. It also makes mentally modeling how
everything works so much harder because the sequencing (or execution
flow) of actions is non-obvious.

And Ansible's own APIs are horrifically unstable, to the point that
I've had *bar conversations* about how people have to pin to specific
Ansible releases because all the crap they build on top of it to bend
Ansible to their needs relies on the part of Ansible that's
deliberately *not* stable: the Python module extension interface.

We're potentially trading one kind of technical debt for one that's
arguably worse: debt we can't fix because we're eating our own tails.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

[Neal Gompa]

On Tue, Jun 30, 2020 at 2:22 AM Julen Landa Alustiza
 wrote:
>
>
>
> 20/6/26 11:32(e)an, David Kirwan igorleak idatzi zuen:
> > Hi all,
> >
> > If we are moving towards openshift/kubernetes backed services, we should
> > probably be sticking with containers rather than Vagrant. We can use CRC
> > [1] (Code Ready Containers) or minikube [2] for most local dev work.
>
> In my experience CRC is a pita for occasional contribution on different
> projects due to it's one month lifecycle. It's fine if you are using it
> daily but if you are using for just some few projects that only need
> some ocassional coding having to redeploy the minicluster every time is
> hard and time consuming.
>

I cannot run CRC on my laptop, full stop. I don't have enough RAM for it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

[Neal Gompa]

On Fri, Jun 26, 2020 at 6:15 AM Tomasz Torcz  wrote:
>
> On Fri, Jun 26, 2020 at 10:50:47AM +0100, Stephen Coady wrote:
> > On Fri, 26 Jun 2020 at 10:34, David Kirwan  wrote:
> > >
> > > Hi all,
> > >
> > > If we are moving towards openshift/kubernetes backed services, we should 
> > > probably be sticking with containers rather than Vagrant. We can use CRC 
> > > [1] (Code Ready Containers) or minikube [2] for most local dev work.
> > >
> >
> > The only problem with that is not everything runs in containers. For
> > example the new AAA service is backed by FreeIPA and that does not run
> > in a container.
>
>   It doesn't? What about https://github.com/freeipa/freeipa-container ?
>

My understanding is that it is an experimental implementation
currently. FreeIPA does not necessarily work very well broken up into
containers right now.

> > Everything will run in a virtual machine given that
> > enough care has been put into creating the VM. I don't think the same
> > can be said for containers.
>
>   I think in todays world we should develop for containers first.
> Especially when k8s abstracts many things and provides useful
> infrastructure for application.  A bit like systemd a decade ago, by
> providing useful APIs like socket-activation, watchdog, restarts,
> parallel invocations locks, applications do not have to care about
> re-implementing boring stuff over and over again.
>

The difference is that it's actually a huge pain for people to run
containers on Kubernetes. All these things you described can be done
with systemd units in regular RPMs. In fact, for the AAA solution, I
*already* did that so that we can reuse it for the Fedora and openSUSE
deployments[1].

While I think it'd be valuable to figure out the container workflow
for apps deployed in containers, let's not forget all that stuff in
our infrastructure requires OpenShift, and I don't know about most of
you, but I'm fresh out of OpenShift at home to be able to do this sort
of thing.

I have made something really simple that kind of works for OKD 3.x[2],
but no such equivalent exists for OKD 4.x, so that's been out of reach
for me for a while. Plain Kubernetes literally does not work. Aside
from plain Kubernetes being a pain to actually get working enough to
run applications, we actually use OpenShift features that do not exist
in Kubernetes.

So I would caution all of this by stating that at least for me as an
external no-name plain contributor, I'm more or less locked out of
contributing to apps that are deployed exclusively through OpenShift.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/fedora-aaa/
[2]: https://pagure.io/openshift-allinone-deployment-configuration

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

[Neal Gompa]

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.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Mon, Jun 15, 2020 at 6:54 PM Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> As you hopefully know, we took down our old staging env in phx2 as part
> of the datacenter move. Once machines from phx2 are shipped to iad2 and
> racked and installed and setup we can look at re-enabling our staging
> env.
>
> However, I'd like to ask everyone about how we want that to look.
>
> Some questions:
>
> * Before we had a staging openshift with staging applications in it.
> This is sort of not how openshift is designed to work. In the ideal
> openshift world you don't need staging, you just have enough tests and
> CI and gradual rollout of new versions so everything just works.
> Granted a staging openshift cluster is useful to ops folks to test
> upgrades and try out things, and it's useful for developers in our case
> to get all the parts setup right in ansible to deploy their application.
> So, what do you think? should we setup a staging cluster as before?
> Or shall we try and just use the one production cluster for staging and
> prod?
>


I think having a staging OpenShift would still be useful, because we
probably still have cases where we may want to test a mixture of
cluster and app changes together, and that'd be difficult to do in the
production OpenShift system.

> * Another question is openshift 4. Openshift 3.11 is supported until
> june of 2022, so we have some time, but do we want to or need to look at
> moving to openshift 4 for our clusters? One thing I hate about this is
> that you must have 3 master nodes, and the only machines we have are big
> powerfull virthost servers, so it's very wastefull of resources to
> deploy a openshift 4 cluster (with the machines we have currently
> anyhow).
>

You could make your OpenShift master nodes be able to schedule
workloads, so it's less wasteful. I think it'd make a ton of sense to
look at OpenShift/OKD 4 with this move. There *are* differences with
OpenShift 4, and we will likely have to do some significant
adaptations to our deployment code for it, but it would be worth it
for the simpler maintenance of the cluster.

> * In our old staging env we had a subset of things. Some of them we used
> the staging instances all the time, others we almost never did. I'm not
> sure we have the resources to deploy a 100% copy of our prod env, but
> assuming we did, where should we shoot for on the line? ie, between 100%
> duplicate of prod or nothing?
>
> * We came up with a pretty elaborate koji sync from prod->staging. There
> were lots of reasons we got to that, but I suppose if someone wants to
> propose another method of doing this we could revisit that.
>
> * Any other things we definitely want from a staging env?
>

I think that as long as we have a relatively close replica of our prod
infrastructure, it will be useful for being able to experiment with
improvements to our infra in a safe way.

> * Has staging been helpful to you?
>

Staging has been immensely helpful for the things I work with (Package
infra, Pagure, etc.), it's helped us with testing new releases, new
changes, etc. and catching bugs before we make releases. I hope we
continue to have it.

> * Is there anything we could do to make it better?
>

I don't particularly have a lot of access, which is kind of
frustrating. But that's a problem specific to me rather than something
wrong with staging infra env. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Thu, May 28, 2020 at 12:31 PM Adam Williamson
 wrote:
>
> 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?

If it's discoverable, I don't care. But I had no idea that Koji and
Zuul weren't responsible for those things.

As for loopabull, I don't particularly see a problem with keeping it.
There's nothing wrong with hobby-maintained software. After all, we're
a hobby-maintained distribution. :)




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

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...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 deal with dist-git repository of packages never imported

[Neal Gompa]

On Wed, May 27, 2020 at 1:11 PM Mattia Verga
 wrote:
>
> I've started to clean up the list of approved review-tickets which were
> never closed when I found https://bugzilla.redhat.com/show_bug.cgi?id=564412
>
> The package bwping was approved and a git repo created, but it always
> have been empty. It's currently orphaned both on Fedora and EPEL, but it
> was never retired. So, I think this is an anomaly of the auto retirement
> script.
>
> Apart from that, I'm wondering what's the best course of action to do
> with this package: should I self take and retire it, or it is best to
> completely delete the git repo since nothing has never been in it? Is it
> possible, and how?
>

I think in this circumstance, it would just make sense to delete the
repo and clear everything out.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

New ipsilon snapshot update submitted for F31+ (Fedora AAA stack)

[Neal Gompa]

Hey all,

I've submitted a new snapshot update of Ipsilon for Fedora 31+.

* Fedora 31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-42cc028b51
* Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a47230d384

This update is the result of fixes made while working with Stasiek
Michalski in the openSUSE Heroes team on setting up Ipsilon as
sso.opensuse.org.

As a refresher, for those who do not know, my intent is to release
version 3.0.0 as soon as I have the Python 3 based codebase fully
validated in both Fedora and openSUSE production environments.

The latest packaging being used for the AAA solution based accounts
system is available at my COPR:
https://copr.fedorainfracloud.org/coprs/ngompa/fedora-aaa/

In addition, the packaging source is maintained here:
https://pagure.io/fedora-aaa-copr-packaging

I have not yet submitted freeipa-fas or noggin packages into Fedora,
but once we go live with a production deployment, I will.

If you have any questions, feel free to ask!

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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] fix openshift

[Neal Gompa]

On Thu, Apr 23, 2020 at 8:35 AM Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> This morning as I was trying to build a new distgit-bugzilla-sync build in
> staging, I ran into the issue that the build never started.
> It seems it was related to openshift not being able to resolve correctly:
> registry.redhat.io.
>
> Once Clément pointed me to the right direction, I adjusted staging as follow:
> https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=e371f8b0ceef30639facb7ac7a70c27beb3e689c
> and I was able to do a new build.
>
> I would like to apply the same fix to production (ie:
> roles/hosts/files/os-hosts).
>
> Thoughts?
>

+1 from me. Seems small, simple, and reasonable to do.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mirror the ansible repo from pagure in the batcave

[Neal Gompa]

On Thu, Apr 23, 2020 at 5:47 AM Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> Kevin and I had a discussion on IRC the other day about mirroring the ansible
> repo.
> The options we considered are:
> - mirroring to pagure
> - mirroring from pagure
>   - using pagure's mirroring feature
>   - using a different approach
>
> - Mirroring to pagure
>   This meant, the canonical place for ansible remains in the batcave and 
> pagure
>   only periodically pulls from there to update itself (or a hook updates 
> pagure
>   on push).
>   This would work, but it basically make the pull-request workflow for 
> reviewers
>   a little more complex, as you would have to download the patch of the PR,
>   apply it (potentially adding the: Merging  so it marks the PR as merged)
>   and then push to the batcave.
>   If you merged via the UI in pagure, you would then have to pull from pagure
>   and then push to the batcave, with the risk of a race condition if someone 
> or
>   something updates pagure right after your merge and suddenly the commit(s) 
> of
>   the PR disapear (since the content in pagure would be overriden by what is
>   coming from the batcave).
>
>   So, not an ideal workflow.
>
> - Mirroring from pagure
>   This means, the canonical place for ansible is in pagure.io.
>   However, we need to still be able to run ansible when pagure.io goes down
>   (keeping in mind batcave and pagure.io are in two different data-center).
>   So we want to keep a mirror of the ansible repo in the batcave for 
> emergencies
>   and that repo should be as up to date as possible.
>
>   With this approach, all the work happens on pagure.io, the PR workflow is 
> the
>   usual, straight forward one and we have a mirror in the batcave that is 
> mostly
>   up to date.
>
>   - Using pagure's mirroring feature
>   Pagure can mirror in and out, out is done right after a push, however, 
> batcave
>   is not accessible from pagure.io, so we just can't use this.
>
>   - Using a different approach
>   We have two ways we could do this: a simple cron job, a message-based 
> service.
>
>   For a first step I went with a third approach: a small python service that
>   runs every 3 minutes (configurable): git fetch && git fsck (to ensure the 
> git
>   is in a correct state). It actually doesn't run every 3 minutes, it calls 
> git,
>   then wait for 3 minutes then calls git again and so on. So if git was ever 
> to
>   takes 4 minutes to run, there is no risk of the program stepping on its own
>   toes.
>
>
> I would like to propose that install and configure this for a test.
> I propose that we keep /git/ansible.git as is and just have a
> /git/mirrors/ansible.git which will be the mirror from pagure.
> We can migrate the hook from /git/ansible.git to /git/mirrors/ansible.git so
> /srv/web/infra/ansible (ie: the exploded tree) is coming from the mirror.
>
> I guess the lag time to get /git/mirrors updated will quickly be annoying (up 
> to
> 3 minutes between when the PR is merged and when the playbook is updated), so
> if we like the workflow we will likely want to switch pretty quickly to a
> message-based service and then we could keep the current cron-like service to
> run hourly and update /git/ansible.git which would then become some kind of
> backup.
>
>
> What do you think?
> FBR worthy? (ie: if F32 goes out next week, I think we can wait, if it doesn't
> do we want to try this sooner?)
>
> If we like the idea, I'll start looking into the fedora-messaging based
> consumer, using the approach from the current service, it should be pretty
> straight forward (I'll re-use the same project for it).
>
>
> Oh, and if you want to see the code of the current service:
> https://pagure.io/Fedora-Infra/mirror_from_pagure

I think this is FBR worthy. Heck, I think it's fine to do now. It's
really not that invasive, and it makes contributions to the ansible
repo a lot more straightforward. We don't _have_ to accept any PRs
without an FBR approval, but I think switching to the PR workflow now
will make life better.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Allow RHEL8 systems to know about code-ready

[Neal Gompa]

Okay then... +1 from me. :)

On Tue, Apr 21, 2020 at 11:10 AM Stephen John Smoogen  wrote:
>
> There were worries it might pull in things we do not want. I am going to let 
> that be dealt with outside of FBR season.
>
> On Tue, 21 Apr 2020 at 11:05, Neal Gompa  wrote:
>>
>> On Tue, Apr 21, 2020 at 11:03 AM Stephen John Smoogen  
>> wrote:
>> >
>> >
>> > diff --git a/files/common/rhel8.repo b/files/common/rhel8.repo
>> > index 162848d..9686500 100644
>> > --- a/files/common/rhel8.repo
>> > +++ b/files/common/rhel8.repo
>> > @@ -25,3 +25,10 @@ 
>> > baseurl=https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/rhel-
>> >  gpgkey = 
>> > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
>> >  enabled=1
>> >  gpgcheck=1
>> > +
>> > +[rhel8-CRB]
>> > +name = rhel8 CodeReadyBuilder $basearch
>> > +baseurl=https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/codeready-builder-for-rhel-8-$basearch-rpms/
>> > +gpgkey = 
>> > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
>> > +enabled=0
>> > +gpgcheck=1
>> >
>> > --
>>
>> Generally +1, but why not just enable it? We're going to need it
>> basically everywhere...
>>
>>
>>
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>> ___
>> 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
>
>
>
> --
> Stephen J Smoogen.
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Allow RHEL8 systems to know about code-ready

[Neal Gompa]

On Tue, Apr 21, 2020 at 11:03 AM Stephen John Smoogen  wrote:
>
>
> diff --git a/files/common/rhel8.repo b/files/common/rhel8.repo
> index 162848d..9686500 100644
> --- a/files/common/rhel8.repo
> +++ b/files/common/rhel8.repo
> @@ -25,3 +25,10 @@ 
> baseurl=https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/rhel-
>  gpgkey = 
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
>  enabled=1
>  gpgcheck=1
> +
> +[rhel8-CRB]
> +name = rhel8 CodeReadyBuilder $basearch
> +baseurl=https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/codeready-builder-for-rhel-8-$basearch-rpms/
> +gpgkey = 
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
> +enabled=0
> +gpgcheck=1
>
> --

Generally +1, but why not just enable it? We're going to need it
basically everywhere...




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Thu, Apr 16, 2020 at 7:03 PM Adam Williamson
 wrote:
>
> 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

And pagure.io isn't going anywhere, so it's not going to be a problem
to have it there anyway. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Thu, Apr 16, 2020 at 11:04 AM Clement Verna  wrote:
>
> * Mirror the ansible git repo on [4]pagure.io
> Trouble: Low
> Gain: Low
>
> Since that would not allow PRs I think the gain is quite low, but it also 
> seems like not much trouble to do it.
>

We could upgrade the Gain to High if we configured the repo to push
mirror back to the old location and just changed the canonical source
to pagure.io.

> * Migrate [6]stg.pagure.io and [7]src.stg.fedoraproject.org to RHEL8.
> Trouble: Low
> Gain: Medium
>
> I think that would be rather low trouble (destroying the current instances 
> and rebuilding on RHEL8) but that would give us an opportunity to test that 
> before the move and then maybe give us the confidence to reinstall dist-git 
> on RHEL8 in the new data centre.
>

I'd personally like to see if everything works. :)




--
真実はいつも一つ！/ Always, there's only one truth!
___
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)

[Neal Gompa]

On Mon, Apr 13, 2020 at 1:55 AM Tomas Tomecek  wrote:
>
> On Thu, Apr 9, 2020 at 6:34 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.
>
> Neal, I understand you are frustrated after I read some of your
> responses in other threads. I'd appreciate if you didn't use such
> strong language when reaching out to me.
>
> My point with the sentence was that we'd be busy adding GitLab
> integration into packit in coming months, tightening our capacity. I
> also didn't say anything about pagure.io going away. I was just
> interested in the details.
>
> Actually, pagure support is being added to packit these days (starting
> here [1]). So far no one was pushing us hard to add native pagure.io
> integration hence it's not present. To this day we've received a bunch
> of requests to support GitLab [2] (you're on the thread as well) and
> that's it.
>
> If you have a strong case for having packit working with pagure.io
> (doing RPM builds for PRs mainly), please open an issue [3] so we can
> track this request. Once [1] is merged, it shouldn't be that difficult
> to do such a thing (I expect that pagure.io and git.centos.org use the
> same fedmsg payloads though).
>
>
> [1] https://github.com/packit-service/packit-service/pull/515
> [2] https://github.com/packit-service/packit-service/issues/249
> [3] https://github.com/packit-service/packit-service/issues/new
>

Issue filed: https://github.com/packit-service/packit-service/issues/556

I didn't realize nobody had filed an issue for it. I assumed it had
already been done as part of getting parity for a Fedora service for
projects hosted on Fedora infrastructure.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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)

[Neal Gompa]

On Thu, Apr 9, 2020 at 12:55 PM 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. SSSD project just yesterday switched to Github from 
> Pagure.
>
> I hope to see Pagure continue doing great things, and I appreciate your 
> involvement.
>

That's disappointing. On the flip side, the ironthree project (Rust
clients and libraries for Fedora infrastructure) moved from GitHub to
Pagure last week: https://pagure.io/projects/ironthree/%2A

I'm not moving Ipsilon to GitHub either.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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

Packit Pagure support (was: [RFC] Optionally using git repositories instead of the lookaside cache)

[Neal Gompa]

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.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: [RFC] Optionally using git repositories instead of the lookaside cache

[Neal Gompa]

On Wed, Apr 8, 2020 at 7:17 PM clime  wrote:
>
> On Thu, 9 Apr 2020 at 01:08, Neal Gompa  wrote:
> >
> > On Wed, Apr 8, 2020 at 6:55 PM clime  wrote:
> > >
> > > On Thu, 9 Apr 2020 at 00:48, Neal Gompa  wrote:
> > > >
> > > > On Wed, Apr 8, 2020 at 4:27 PM Jeremy Cline  wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > The Fedora kernel is moving to maintaining the package in a source
> > > > > (sometimes people refer to it as an "exploded") tree. Basically just a
> > > > > fork of upstream. This makes a lot of packager tasks easier, but has
> > > > > introduced a minor issue with respect to the lookaside cache.
> > > > >
> > > > > Right now, it's configured to create a tarball from the git tree and
> > > > > upload it to the lookaside cache for each build. We build the rawhide
> > > > > kernel every weekday (give or take) and the xz compressed source
> > > > > tarball is ~110MB. This works out to about 28GB per year for Rawhide
> > > > > alone (if this is a drop in the bucket and no one cares please let me
> > > > > know and we'll just do this). The old approach uploaded a release
> > > > > tarball and then incremental tarballs on top of that.
> > > > >
> > > > > If, however, Fedora allowed packagers to optionally generate tarballs
> > > > > from a git repository we could just push the linux git repository. The
> > > > > entire repository with history going back 15 years is under 4GB total,
> > > > > which is pretty good when compared to ~419GB which is the space
> > > > > required for the equivalent time using the lookaside cache.
> > > > >
> > > > > What would need to change:
> > > > >
> > > > > * Fedora offers a git repository to push source trees to.
> > > > >
> > > > > * A new file in the dist-git repository could be added if the packager
> > > > >   wishes called "source-repos". In it, it contains a git url and 
> > > > > commit
> > > > >   identifier. For example, an entry might look like:
> > > > > "
> > > > > https://src.fedoraproject.org/sources/kernel.git v5.6"
> > > > >   where v5.6 is a tag in the repository. We can restrict it so the git
> > > > >   repository must be hosted by Fedora so we keep all the sources
> > > > >   forever.
> > > > >
> > > > > * fedpkg and fedpkg-minimal would need to be updated to pull the
> > > > >   source tree if the "source-repos" file is found and run
> > > > >   "git archive". Fortunately this work is actually already done since
> > > > >   Red Hat's version of fedpkg already supports this.
> > > > >
> > > > > I'm happy do to all the work for fedpkg/fedpkg-minimal to make this
> > > > > possible because the other option is to add a bunch of hacks to the
> > > > > kernel tooling to spit out a bunch of incremental tarballs to reduce
> > > > > what we have to upload.
> > > > >
> > > > > I assume this is something that will need to go through the packaging
> > > > > SIG, but from an infra side of things are there any thoughts/concerns?
> > > > >
> > > >
> > > > At least with this _specific_ proposal, I don't see too many issues.
> > > > Adding a "sources" namespace to Pagure and setting up a workflow for
> > > > that isn't a horrible idea.
> > > >
> > > > I still feel like my general concerns in original proposal from two
> > > > years ago[1] haven't been sufficiently addressed. But, given that you
> > > > seem to have a specific idea in mind here, my questions about this for
> > > > the kernel (and others that would opt into this workflow):
> > > >
> > > > * Are you okay with imposing the same restrictions we have on rpms/*,
> > > > modules/*, flatpaks/*, and containers/* for sources/*? That is, no
> > > > rewriting history, no branch deletion, no tag deletion, etc.
> > > > * Are you okay with blocking the usage of submodules, Git LFS,
> > > > Git-Annex, or any other mechanism that allows bypassing our
> > > > protections or cannot be replicated from an upstream repo locally?
> > >
> > > I would just like 

Re: [RFC] Optionally using git repositories instead of the lookaside cache

[Neal Gompa]

On Wed, Apr 8, 2020 at 6:55 PM clime  wrote:
>
> On Thu, 9 Apr 2020 at 00:48, Neal Gompa  wrote:
> >
> > On Wed, Apr 8, 2020 at 4:27 PM Jeremy Cline  wrote:
> > >
> > > Hi folks,
> > >
> > > The Fedora kernel is moving to maintaining the package in a source
> > > (sometimes people refer to it as an "exploded") tree. Basically just a
> > > fork of upstream. This makes a lot of packager tasks easier, but has
> > > introduced a minor issue with respect to the lookaside cache.
> > >
> > > Right now, it's configured to create a tarball from the git tree and
> > > upload it to the lookaside cache for each build. We build the rawhide
> > > kernel every weekday (give or take) and the xz compressed source
> > > tarball is ~110MB. This works out to about 28GB per year for Rawhide
> > > alone (if this is a drop in the bucket and no one cares please let me
> > > know and we'll just do this). The old approach uploaded a release
> > > tarball and then incremental tarballs on top of that.
> > >
> > > If, however, Fedora allowed packagers to optionally generate tarballs
> > > from a git repository we could just push the linux git repository. The
> > > entire repository with history going back 15 years is under 4GB total,
> > > which is pretty good when compared to ~419GB which is the space
> > > required for the equivalent time using the lookaside cache.
> > >
> > > What would need to change:
> > >
> > > * Fedora offers a git repository to push source trees to.
> > >
> > > * A new file in the dist-git repository could be added if the packager
> > >   wishes called "source-repos". In it, it contains a git url and commit
> > >   identifier. For example, an entry might look like:
> > > "
> > > https://src.fedoraproject.org/sources/kernel.git v5.6"
> > >   where v5.6 is a tag in the repository. We can restrict it so the git
> > >   repository must be hosted by Fedora so we keep all the sources
> > >   forever.
> > >
> > > * fedpkg and fedpkg-minimal would need to be updated to pull the
> > >   source tree if the "source-repos" file is found and run
> > >   "git archive". Fortunately this work is actually already done since
> > >   Red Hat's version of fedpkg already supports this.
> > >
> > > I'm happy do to all the work for fedpkg/fedpkg-minimal to make this
> > > possible because the other option is to add a bunch of hacks to the
> > > kernel tooling to spit out a bunch of incremental tarballs to reduce
> > > what we have to upload.
> > >
> > > I assume this is something that will need to go through the packaging
> > > SIG, but from an infra side of things are there any thoughts/concerns?
> > >
> >
> > At least with this _specific_ proposal, I don't see too many issues.
> > Adding a "sources" namespace to Pagure and setting up a workflow for
> > that isn't a horrible idea.
> >
> > I still feel like my general concerns in original proposal from two
> > years ago[1] haven't been sufficiently addressed. But, given that you
> > seem to have a specific idea in mind here, my questions about this for
> > the kernel (and others that would opt into this workflow):
> >
> > * Are you okay with imposing the same restrictions we have on rpms/*,
> > modules/*, flatpaks/*, and containers/* for sources/*? That is, no
> > rewriting history, no branch deletion, no tag deletion, etc.
> > * Are you okay with blocking the usage of submodules, Git LFS,
> > Git-Annex, or any other mechanism that allows bypassing our
> > protections or cannot be replicated from an upstream repo locally?
>
> I would just like to note that this point is not precise. Usage of git
> submodules (and other technologies) is completely alright if they
> still point to src.fp.o. Is there a source for the point so that I can
> open a PR to fix it?
>

Making foreign repositories do that isn't straightforward. You would
have to edit the repositories and change all the submodules, download
and reimport all the LFS/Annex objects, etc. And that all tampers with
the repository itself in ways that break the concept of having
pristine trees mirrored to build from.

(Source: have done no less than two major SCM migrations and had to
deal with all of these problems)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: [RFC] Optionally using git repositories instead of the lookaside cache

[Neal Gompa]

On Wed, Apr 8, 2020 at 4:27 PM Jeremy Cline  wrote:
>
> Hi folks,
>
> The Fedora kernel is moving to maintaining the package in a source
> (sometimes people refer to it as an "exploded") tree. Basically just a
> fork of upstream. This makes a lot of packager tasks easier, but has
> introduced a minor issue with respect to the lookaside cache.
>
> Right now, it's configured to create a tarball from the git tree and
> upload it to the lookaside cache for each build. We build the rawhide
> kernel every weekday (give or take) and the xz compressed source
> tarball is ~110MB. This works out to about 28GB per year for Rawhide
> alone (if this is a drop in the bucket and no one cares please let me
> know and we'll just do this). The old approach uploaded a release
> tarball and then incremental tarballs on top of that.
>
> If, however, Fedora allowed packagers to optionally generate tarballs
> from a git repository we could just push the linux git repository. The
> entire repository with history going back 15 years is under 4GB total,
> which is pretty good when compared to ~419GB which is the space
> required for the equivalent time using the lookaside cache.
>
> What would need to change:
>
> * Fedora offers a git repository to push source trees to.
>
> * A new file in the dist-git repository could be added if the packager
>   wishes called "source-repos". In it, it contains a git url and commit
>   identifier. For example, an entry might look like:
> "
> https://src.fedoraproject.org/sources/kernel.git v5.6"
>   where v5.6 is a tag in the repository. We can restrict it so the git
>   repository must be hosted by Fedora so we keep all the sources
>   forever.
>
> * fedpkg and fedpkg-minimal would need to be updated to pull the
>   source tree if the "source-repos" file is found and run
>   "git archive". Fortunately this work is actually already done since
>   Red Hat's version of fedpkg already supports this.
>
> I'm happy do to all the work for fedpkg/fedpkg-minimal to make this
> possible because the other option is to add a bunch of hacks to the
> kernel tooling to spit out a bunch of incremental tarballs to reduce
> what we have to upload.
>
> I assume this is something that will need to go through the packaging
> SIG, but from an infra side of things are there any thoughts/concerns?
>

At least with this _specific_ proposal, I don't see too many issues.
Adding a "sources" namespace to Pagure and setting up a workflow for
that isn't a horrible idea.

I still feel like my general concerns in original proposal from two
years ago[1] haven't been sufficiently addressed. But, given that you
seem to have a specific idea in mind here, my questions about this for
the kernel (and others that would opt into this workflow):

* Are you okay with imposing the same restrictions we have on rpms/*,
modules/*, flatpaks/*, and containers/* for sources/*? That is, no
rewriting history, no branch deletion, no tag deletion, etc.
* Are you okay with blocking the usage of submodules, Git LFS,
Git-Annex, or any other mechanism that allows bypassing our
protections or cannot be replicated from an upstream repo locally?



[1]: https://pagure.io/releng/issue/7498




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Hello world!

[Neal Gompa]

On Tue, Apr 7, 2020 at 11:42 AM David Kirwan  wrote:
>
> Hello all,
>
> My name is David Kirwan, I'm originally from Kilkenny, Ireland, now living in 
> Waterford, Ireland. I've recently transferred to the CPE team at Red Hat, 
> where I'll likely be working on CentOS and Fedora infrastructure in a devops 
> capacity. I also hope to get involved in some of the packaging work for the 
> Ruby/ML SIGs, although that might be in my spare time!
>

Welcome! Don't mind the dust, it's a bit unsettled, but it's fine. :)

Looking forward to working with you. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 Git forge decision (was CPE Weekly: 2020-03-28)

[Neal Gompa]

On Mon, Mar 30, 2020 at 8:13 AM Nicolas Mailhot via devel
 wrote:
>
> Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit :
> >
> > > As a General User
> > > I want to access repos fully over https
> > > For environments where SSH is blocked
> >
> > I would be really curious if the Red Hat Infrastructure Security guys
> > have changed their opinion on this after four years of blocking the
> > development of this feature in Pagure. The two major reasons we don't
> > have this in Pagure are:
>
> Neal,
>
> Security is the usual excuse not to implement stuff. That does not work
> when competing with others that did their homework. As you noted
> yourself ssh accesss is not blameless either.
>
> Gitlab and Github work in https mode. Pagure does not. End of story.
>
> Expecting others to hole their security with corkscrew because of the
> ssh holy cow was never going to impress any third party.
>

You don't have to tell me, I already know. It was intentionally not
implemented. And even with all that, we *do* have HTTPS through SSO on
src.fp.o. We just don't have it on pagure.io. Don't expect it to be
available with the move to GitLab. GitLab admins have a toggle they
can use to disable HTTPS pushing for policy reasons, and I will
strongly bet on it being flipped so that HTTPS pushing will not be
available in our GitLab.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

The Git forge decision (was CPE Weekly: 2020-03-28)

[Neal Gompa]

On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney  wrote:
>
> ### Other Updates
>
>  GitForge Decision
> * After evaluating over 300 user stories from multiple stakeholders we
> have aligned on a decision for the Gitforge that CPE will operate for
> the coming years. We are opting for Gitlab for our dist git and
> project hosting and will continue to run pagure.io with community
> assistance.
> * Check out our GitForge decision on the Fedora Community blog
> https://communityblog.fedoraproject.org/
> * And at the CentOS blog page
> https://blog.centos.org/2020/03/git-forge-decision/
> * Keep an eye out for mails in the coming months to the devel lists as
> we plan transitions and next steps with GitLab
> * We would like to express our sincere thank you to all who
> contributed requirements to us!
>
>

I'm going to start with the delivery of this decision sucked. If I
hadn't been alerted to look for this by other folks due to my advocacy
and community building work around Pagure, I would *not* have known
that the decision had been made. This is in contrast to the *big deal*
that was made about starting this "decision process". I don't know if
there were folks counting on nobody noticing this or not, but this is
not a good way to deliver effectively a major decision like this. I
also absolutely *refuse* to deal with the fact that this thread was
split into three mailing lists. All three are connected to this
thread, and I will take responses from all of them and follow them
accordingly.

Enough about that, let's talk about the actual decision.

So, you're going with GitLab. It's interesting to note that the
particulars about going to GitLab are not even figured out. It is
curious that "SAAS" is mentioned very prominently. That made me a bit
more curious, so I looked at the "final" feature requirements.
Needless to say, I was extremely disappointed.

To put it bluntly, there are *zero* free and open source solutions
that satisfy your needs. From this, I understood why you said GitLab
and SaaS. You want GitLab Ultimate, the proprietary solution that
includes several extra features on top to satisfy the following
requirements (quoted from your blog post):

> * There is a need for CentOS Stream to integrate with a kernel workflow that 
> is an automated bot driven merging solution (merge trains). This allows for 
> richer CI capabilities and minimizes the need for human interaction
> * Gitlab allows for project planning capability which could make multiple 
> trackers such as Taiga redundant, allowing for the planning and tracking to 
> reside within the repo. It would enrich the current ticket based solution 
> that Pagure has evolved into for some groups

These two requirements *alone* automatically force us to GitLab
Enterprise Ultimate Edition, as there is no other solution available
that satisfies those requirements in one product. Merge trains *is* a
feature of Pagure when combined with Zuul, but GitLab's project
planning features do not exist in *any* FOSS product, including GitLab
CE (or GitLab Core as they call it now).

There are mentions of other work that CPE team wants to do to better
improve Fedora. Okay, sure. I even agree with some of them. And the
time bomb that is FAS is definitely worth the attention (note that I
am somewhat involved in the development of the Fedora AAA solution and
am also working on trying to develop a community around it so it
doesn't implode like virtually every other project under the Fedora
umbrella, more on *that* a bit later).

However, nobody has given me or anyone else in the Pagure community
(which yes, is more than Pierre-Yves, thank you very much!) any
concrete details of deficiencies they'd see that is not satisfiable by
the community within a year before now. I've spent a little over a day
analyzing the user stories and thinking about the gaps between Pagure
and what the community wants, and I want to give some perspective here
for some of these. I'm happy to accept refutations and other details
to further enhance the color of these stories, of course.

> 5
> As a RH Developer
> I need the ability to privately comment on a PR
> so that confidential information does not leak outside Red Hat

Ignoring the mountainous levels of terrible problems that such a
feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I
were literally discussing this with a Mageian who was interested in
this feature for Pagure weeks ago. We had identified the feature as
not difficult to implement but also simultaneously nobody really
*wanted it now*. It surprises me that this is something that should be
considered an important feature to preserve. It's actually a very
*rare* feature, and does not exist in any forge today, presumably
because it's actually a horrifically bad idea and antithetical to open
development. GitLab itself lacks this feature, in all variants.

> 16
> As a general user
> I want to be able to create a bot/service account
> That integrates with the 

Re: Pagure for EL8 (EPEL8)

[Neal Gompa]

On Sat, Mar 21, 2020 at 3:42 AM Neal Gompa  wrote:
>
> On Sat, Feb 22, 2020 at 11:50 PM Neal Gompa  wrote:
> >
> > On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa  wrote:
> > >
> > > On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi  wrote:
> > > >
> > > > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > > > > I've done an early build locally to determine what's needed to make
> > > > > this possible. The following report from DNF indicates the missing
> > > > > packages that need to be added to EPEL 8 before I can introduce Pagure
> > > > > into EPEL8:
> > > > >
> > > > >  Problem 1: conflicting requests
> > > > >   - nothing provides python3-jenkins needed by 
> > > > > pagure-ci-5.8-1.el8.noarch
> > > > >  Problem 2: conflicting requests
> > > > >   - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(binaryornot) needed by
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(celery) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(flask-wtf) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(redis) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(straight.plugin) needed by
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(wtforms) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
> > > > > pagure-5.8-1.el8.noarch
> > > > >  Problem 3: conflicting requests
> > > > >   - nothing provides python3-trololio needed by 
> > > > > pagure-ev-5.8-1.el8.noarch
> > > > >
> > > > > One of the reasons I'd like to have this done sooner rather than later
> > > > > is so that we can drop Python 2 support from Pagure with version 6.0.
> > > > > I think it's quite reasonable to say that version 6.0 isn't going to
> > > > > happen until we can get our Pagure servers running on EL8 using Python
> > > > > 3.
> > > > >
> > > > > So now, I need some help making this happen. I already own trololio,
> > > > > and I'm going to make that available in EPEL 8 ASAP. Can anyone help
> > > > > with some of the other dependencies here?
> > > >
> > > > Can you give a list with maintainers? I'm not sure off hand how many of
> > > > those are maintained by me/infra-sig, but any I can I would be happy to
> > > > add in. There's a few that are in testing I think already...
> > > >
> > >
> > > Sure, here's a list so far (package: maintainer):
> > >
> > > * gitolite3: limb
> > > * python-jenkins: cottsay
> > > * python-binaryornot: pingou
> > > * python-celery: bowlofeggs
> > > * python-flask-wtf: pingou
> > > * python-redis: kevin
> > > * python-straight-plugin: pingou
> > > * python-wtforms: kumarpraveen
> > > * python-pygit2: pwalter
> > > * python-trololio: ngompa
> > >
> > > I've already got trololio going:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd
> > >
> >
> > So an update on this...
> >
> > We're now only missing two dependencies:
> >
> > * python-celery: abompard
> > * python-pygit2: pwalter
> >
> > The rest of them are now in EPEL 8.
> >
>
> We're now only missing python-pygit2, as celery just landed in EPEL 8.
>

And now it's all done, with Pagure 5.9.0 landing in EPEL 8:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a504acc25e

Thanks to everyone who helped make this happen!


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Pagure for EL8 (EPEL8)

[Neal Gompa]

On Sat, Feb 22, 2020 at 11:50 PM Neal Gompa  wrote:
>
> On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa  wrote:
> >
> > On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi  wrote:
> > >
> > > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > > > I've done an early build locally to determine what's needed to make
> > > > this possible. The following report from DNF indicates the missing
> > > > packages that need to be added to EPEL 8 before I can introduce Pagure
> > > > into EPEL8:
> > > >
> > > >  Problem 1: conflicting requests
> > > >   - nothing provides python3-jenkins needed by 
> > > > pagure-ci-5.8-1.el8.noarch
> > > >  Problem 2: conflicting requests
> > > >   - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(binaryornot) needed by
> > > > pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(celery) needed by 
> > > > pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(flask-wtf) needed by 
> > > > pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(redis) needed by 
> > > > pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(straight.plugin) needed by
> > > > pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(wtforms) needed by 
> > > > pagure-5.8-1.el8.noarch
> > > >   - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
> > > > pagure-5.8-1.el8.noarch
> > > >  Problem 3: conflicting requests
> > > >   - nothing provides python3-trololio needed by 
> > > > pagure-ev-5.8-1.el8.noarch
> > > >
> > > > One of the reasons I'd like to have this done sooner rather than later
> > > > is so that we can drop Python 2 support from Pagure with version 6.0.
> > > > I think it's quite reasonable to say that version 6.0 isn't going to
> > > > happen until we can get our Pagure servers running on EL8 using Python
> > > > 3.
> > > >
> > > > So now, I need some help making this happen. I already own trololio,
> > > > and I'm going to make that available in EPEL 8 ASAP. Can anyone help
> > > > with some of the other dependencies here?
> > >
> > > Can you give a list with maintainers? I'm not sure off hand how many of
> > > those are maintained by me/infra-sig, but any I can I would be happy to
> > > add in. There's a few that are in testing I think already...
> > >
> >
> > Sure, here's a list so far (package: maintainer):
> >
> > * gitolite3: limb
> > * python-jenkins: cottsay
> > * python-binaryornot: pingou
> > * python-celery: bowlofeggs
> > * python-flask-wtf: pingou
> > * python-redis: kevin
> > * python-straight-plugin: pingou
> > * python-wtforms: kumarpraveen
> > * python-pygit2: pwalter
> > * python-trololio: ngompa
> >
> > I've already got trololio going:
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd
> >
>
> So an update on this...
>
> We're now only missing two dependencies:
>
> * python-celery: abompard
> * python-pygit2: pwalter
>
> The rest of them are now in EPEL 8.
>

We're now only missing python-pygit2, as celery just landed in EPEL 8.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Mon, Mar 9, 2020 at 3:58 PM Kevin Fenzi  wrote:
>
> On Mon, Mar 09, 2020 at 02:47:47PM +0100, Clement Verna wrote:
> > Hi all,
>
> Hi!
>
> > This is the first email with trying to better prioritize our backlog of
> > ticket ( https://pagure.io/fedora-infrastructure/issues ).
>
> Thanks for doing this!
>
> > So 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
> >
> > #8455 Move mailman to newer release of Fedora or CentOS -
> > https://pagure.io/fedora-infrastructure/issue/8455
> Trouble : High.
> Gain : medium
>
> I think this is kind of stalled, because it needs for us to have a
> mailman3 rpm that works in fedora/epel8. Right now in Fedora it's FTBFS
> and it's being worked on. Also, there's other parts like hyperkitty, etc
> that aren't packaged yet. So, I wonder if this might be better as an
> initative? since we need packaging, then deployment/testing then
> migration and finally hand off to production.

It seems that Duck (cc'd to this mail) has updated packaging for the
stack, but we need to get mailman3 working again in Fedora and then
branch that into EPEL 8. I've also been slowly churning through
building hyperkitty and postorious packages based on the latest
releases as opposed to our old release, but that's all blocked on
mailman3 right now.

It'd be great to get some help with getting some of the new
dependencies packaged in Fedora, too.

> > Let's also use this thread to ask questions and clarifications if needed.
> > Also if you have any ideas or feedback on how to improve that process I am
> > happy to hear about it :-).
>
> I think it's a great thing to start in on. ;)
>

It's a good start for sure. I'd also like to point out that we're
close on getting pagure in EPEL 8, I'm waiting on pygit2[1] and
celery[2] to show up in EPEL 8 now. If anyone can get in touch with
either Pete Walter or Matthias Runge to help make this happen, that'd
be very helpful.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1803544
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1804511


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Pagure for EL8 (EPEL8)

[Neal Gompa]

On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa  wrote:
>
> On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi  wrote:
> >
> > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > > I've done an early build locally to determine what's needed to make
> > > this possible. The following report from DNF indicates the missing
> > > packages that need to be added to EPEL 8 before I can introduce Pagure
> > > into EPEL8:
> > >
> > >  Problem 1: conflicting requests
> > >   - nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch
> > >  Problem 2: conflicting requests
> > >   - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(binaryornot) needed by
> > > pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(celery) needed by 
> > > pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(flask-wtf) needed by 
> > > pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(redis) needed by 
> > > pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(straight.plugin) needed by
> > > pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(wtforms) needed by 
> > > pagure-5.8-1.el8.noarch
> > >   - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
> > > pagure-5.8-1.el8.noarch
> > >  Problem 3: conflicting requests
> > >   - nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch
> > >
> > > One of the reasons I'd like to have this done sooner rather than later
> > > is so that we can drop Python 2 support from Pagure with version 6.0.
> > > I think it's quite reasonable to say that version 6.0 isn't going to
> > > happen until we can get our Pagure servers running on EL8 using Python
> > > 3.
> > >
> > > So now, I need some help making this happen. I already own trololio,
> > > and I'm going to make that available in EPEL 8 ASAP. Can anyone help
> > > with some of the other dependencies here?
> >
> > Can you give a list with maintainers? I'm not sure off hand how many of
> > those are maintained by me/infra-sig, but any I can I would be happy to
> > add in. There's a few that are in testing I think already...
> >
>
> Sure, here's a list so far (package: maintainer):
>
> * gitolite3: limb
> * python-jenkins: cottsay
> * python-binaryornot: pingou
> * python-celery: bowlofeggs
> * python-flask-wtf: pingou
> * python-redis: kevin
> * python-straight-plugin: pingou
> * python-wtforms: kumarpraveen
> * python-pygit2: pwalter
> * python-trololio: ngompa
>
> I've already got trololio going:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd
>

So an update on this...

We're now only missing two dependencies:

* python-celery: abompard
* python-pygit2: pwalter

The rest of them are now in EPEL 8.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: CPE Weekly: 2020-02-14

[Neal Gompa]

On Wed, Feb 19, 2020 at 10:29 AM Till Maas  wrote:
>
> On Fri, Feb 14, 2020 at 05:56:26PM +, Aoife Moloney wrote:
>
> > ### AAA Replacement
>
> IMHO this section should be labeled "AAA - Replacement for Fedora
> Account System (FAS)" or is this not called AAA but securitas?
>
>
> > This project is replacing our old existing fas (fedora account system)
> > with a new freeipa based system.
> > * Check out our blog on the teams progress to date!
>
> It would be great if you could add the link to the blog (post?) here.
>
> > * You can also see our jira board for tickets we are working on
>
> Also a link to the Jira board would be great.
>

The JIRA board isn't terribly helpful, since only RHers can see it.

> > * And we have an IRC channel - #fedora-AAA
> > * We are currently working on the FreeIPA API integration and the
> > folks at FreeIPA have been really helpful so far to work with
>

There's also some interest from the openSUSE community about using it
to replace their account system. There's some work to be done to make
it suitable on that front, though...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Turning off keys.fedoraproject.org

[Neal Gompa]

On Wed, Feb 5, 2020 at 11:57 AM Stephen John Smoogen  wrote:
>
>
> Fedora has been part of an GPG sks service[1] for a number of years running 
> off of keys.fedoraproject.org. Last year, there were a number of attacks made 
> on the service which due to its 'write-only' nature makes it impossible to 
> clean up [2] [3]. When the attacks came up, and it was clear it was not 
> easily fixable, we moved keys to a proxy only mode. However this mode has not 
> been too stable and caused other issues.
>
> Fedora Infrastructure has tried to figure out ways to run a service 
> replacement, but currently has not found one which we can with the resources 
> we have available. We plan to turn off and decommission 
> keys.fedoraproject.org on 2020-02-10.
>
> We currently recommend people to use https://keys.openpgp.org/ which offers 
> lookup capabilities.
>
> [1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
> [2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> [3] 
> https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/
>

We may want to replace it with a simple Web Key Directory server:
https://wiki.gnupg.org/WKD

That would make it easy to lookup keys based on @fedoraproject.org
email addresses, and since keys can be replaced in the directory, it
avoids the problems with SKS attacks.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: moving bugzilla overrides to dist-git

[Neal Gompa]

On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp  wrote:
>
> Hi,
>
> We are currently working on getting rid of the git repo at 
> fedora-scm-requests [1] which is nowadays only used to store the overrides of 
> the default assignee in bugzilla (for example to allow different default 
> assignee for Fedora and EPEL).
>
> I am working on porting this mechanism to dist-git itself (much like we did 
> for the anitya integration a few weeks ago).
>
>  We are thinking on providing a simple text field to submit FAS username or 
> email to override the default assignee, the big question is then, who should 
> be allowed to update this field ?
>
> Should the main admin be able to set someone else as assignee ?
>
> If there is already an override assignee, who should be allowed to change 
> that ?
>
> If there's no override assignee set, can everyone become it or is that up to 
> the main admin of the component to decide and set ?
>

I think in this case, it should be the main admin who can change this.
If we had per-branch ACLs, then I would also say that the admins of
the EPEL branches could change EPEL assignments too...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: CPE Weekly: 2019-11-29

[Neal Gompa]

On Fri, Nov 29, 2019 at 5:05 PM Aoife Moloney  wrote:
>
> Hi everyone,
>
>
> Welcome to the CPE team weekly project update mail!
>
>
>
> Background:
>
> The Community Platform Engineering group is the Red Hat team combining
> IT and release engineering from Fedora and CentOS. Our goal is to keep
> core servers and services running and maintained, build releases, and
> other strategic tasks that need more dedicated time than volunteers
> can give.
>
> For better communication, we will be giving weekly reports to the
> CentOS and Fedora communities about the general tasks and work being
> done.  Also for better communication between our groups we have
> created #redhat-cpe on Freenode IRC! Please feel free to catch us
> there, a mail has landed on both the CentOS and Fedora devel lists
> with context here.
>
>
> Note:
>
> This document is currently built from individual reports rolled into a
> google document which we edit and copy into a final document. We are
> aware that this causes problems with some email readers, and are
> working on a method to make this less problematic.
>
>
> High Level Project Updates:
>
>
>
>
> Fedora:
>
>
> Rawhide Gating:
> Bodhi was 5.1 released and is deployed in staging
> Robosignatory is broken in staging preventing testing much there
>
>

Speaking of robosignatory, what's the state of affairs for Sigul[0]?
At Flock, I was assured by Patrick that he'd release a new Python
3-compatible Sigul that works with GnuPG 2.1 or higher. We still don't
have that, so it's *still* not possible for people to sign packages
and repos with Koji deployments...

The last time I brought this up (at the top of the year[1]), I
proposed considering switching to obs-signd, since nothing has been
happening with Sigul. At that point, I was assured work was going on
here and also told that obs-signd is not capable of serving our needs.

So... now what?

[0]: https://pagure.io/sigul
[1]: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/CGDTZI5M7WOUZVDOWS44MSFMRYH276ND/


>
>
> Application Retirements
>
> Elections
> Elections being moved to Communishift really soon! Stay tuned!
>
> Fedocal
> Still no progress on kanban board last four weeks
> https://teams.fedoraproject.org/project/fedora-calendar/kanban
>
> Jlanda is still hitting permission error in communishift
> https://pagure.io/fedora-infrastructure/issue/8274
> Still working on running local instance
>

I'm confused how this is the first time we're seeing these issues. Do
we not have *any* apps in Communishift using PostgreSQL (or any
database for that matter) besides Fedocal?

> Nuancier
> Benson Muite is now working on OIDC authentication
> A PR will be created on Github to test if we can see the progress
> New PR from sebwoj - Porting to Fedora messaging is under review
>
> Pastebin
> Still on track for December 1 modernpaste shutdown
>
> GDPR and privacy centric conversations with respect to application
> handovers have resulted in…..more conversations needed - shock :)
>

Can we please have fpaste.org and paste.fedoraproject.org still work?

>
>
>
>
> CentOS:
> The team have been testing projects migration from repospanner to
> locally hosted git repositores on git.dev.centos.org and come back
> with a migration script/plan to unblock RCM
>

Does this mean that the whole magical future plan of having multiple
distros' branches in src.fp.o and git.c.o is dead?

> CentOS Stream
> Scoping meetings are still ongoing
>

What does this even mean!?

>
> Misc
>
> Bugzilla sync script has been resolved
> Email inviting to review its change has been sent
>
> New changes to src.fedoraproject.org deployed:
> Ability to set the anitya monitoring status directly in the UI
> Ability to adopt orphan (and not retired) packages directly in the UI
>

Yay!

> New changes to Pagure on the horizon:
> New API endpoint to enable/disable git hooks
> Ability to set dist-git in the default assignee overrides for bugzilla
>

Can somebody please consider looking into supporting per-branch ACLs
in Pagure Dist-Git? It's become a problem that I'm too nervous to hand
out EPEL branches to people because they can do bad things to the
Fedora branches I care about...

Also, question: is it supposed to be possible for people other than
the maintainer to request EPEL branches and force me to have them?
Somehow I wound up getting EPEL 8 branches for buildbot[2][3], and I
definitely did not ask for them. What's crap about this is that now
I'm stuck with Git branches I don't want in a configuration I didn't
ask for, with commits in there I definitely don't like. Thankfully,
there have been no builds, but it's still bad.

[2]: https://pagure.io/releng/fedora-scm-requests/issue/19857
[3]: https://pagure.io/releng/fedora-scm-requests/issue/19856

>
> EPEL 8 modularity
> Updates can now be created in bodhi staging!
> We are currently testing pushes/composes
> We are also testing epel8-playground-modules composes
>

Does anyone know how we're 

Re: status.fedoraproject.org

[Neal Gompa]

On Wed, Nov 27, 2019 at 3:06 AM Miroslav Suchý  wrote:
>
> Hi.
> For long time, I plan to do something about
>   https://status.fedoraproject.org/
>
> I think that manual updates of this page does not reflect the capabilities of 
> these century.
>
> My question is: do we want to go SasS way? I found
>   https://www.statusdashboard.com/pricing
> which would cost us $99 per month.
>
> Or we want to maintain it in-house?
> The code of this specific service is open-source
>   https://github.com/tomalessi/statusdashboard
> thou there are no commits for past few years.
> And there are some alternatives like:
>   https://github.com/statusdashboard/statusdashboard
>

Two actively maintained open source options are:

* Staytus: https://staytus.co/

* Cachet: https://cachethq.io/

Either could be customized and ran somewhere fairly easily...


--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Pagure for EL8 (EPEL8)

[Neal Gompa]

On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi  wrote:
>
> On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > I've done an early build locally to determine what's needed to make
> > this possible. The following report from DNF indicates the missing
> > packages that need to be added to EPEL 8 before I can introduce Pagure
> > into EPEL8:
> >
> >  Problem 1: conflicting requests
> >   - nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch
> >  Problem 2: conflicting requests
> >   - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(binaryornot) needed by
> > pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(flask-wtf) needed by 
> > pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(straight.plugin) needed by
> > pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(wtforms) needed by 
> > pagure-5.8-1.el8.noarch
> >   - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
> > pagure-5.8-1.el8.noarch
> >  Problem 3: conflicting requests
> >   - nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch
> >
> > One of the reasons I'd like to have this done sooner rather than later
> > is so that we can drop Python 2 support from Pagure with version 6.0.
> > I think it's quite reasonable to say that version 6.0 isn't going to
> > happen until we can get our Pagure servers running on EL8 using Python
> > 3.
> >
> > So now, I need some help making this happen. I already own trololio,
> > and I'm going to make that available in EPEL 8 ASAP. Can anyone help
> > with some of the other dependencies here?
>
> Can you give a list with maintainers? I'm not sure off hand how many of
> those are maintained by me/infra-sig, but any I can I would be happy to
> add in. There's a few that are in testing I think already...
>

Sure, here's a list so far (package: maintainer):

* gitolite3: limb
* python-jenkins: cottsay
* python-binaryornot: pingou
* python-celery: bowlofeggs
* python-flask-wtf: pingou
* python-redis: kevin
* python-straight-plugin: pingou
* python-wtforms: kumarpraveen
* python-pygit2: pwalter
* python-trololio: ngompa

I've already got trololio going:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Pagure for EL8 (EPEL8)

[Neal Gompa]

Hey all,

In the interest of helping to modernize the infrastructure Fedora runs
on, I'm working on introducing Pagure into EPEL8. This will hopefully
allow us to upgrade our Pagure instances to use RHEL 8 instead of RHEL
7, and notably, make the transition (mostly) complete for moving all
Python software Fedora runs to Python 3.

I've done an early build locally to determine what's needed to make
this possible. The following report from DNF indicates the missing
packages that need to be added to EPEL 8 before I can introduce Pagure
into EPEL8:

 Problem 1: conflicting requests
  - nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch
 Problem 2: conflicting requests
  - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(binaryornot) needed by
pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(flask-wtf) needed by pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(straight.plugin) needed by
pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(wtforms) needed by pagure-5.8-1.el8.noarch
  - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
pagure-5.8-1.el8.noarch
 Problem 3: conflicting requests
  - nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch

One of the reasons I'd like to have this done sooner rather than later
is so that we can drop Python 2 support from Pagure with version 6.0.
I think it's quite reasonable to say that version 6.0 isn't going to
happen until we can get our Pagure servers running on EL8 using Python
3.

So now, I need some help making this happen. I already own trololio,
and I'm going to make that available in EPEL 8 ASAP. Can anyone help
with some of the other dependencies here?

Thanks in advance,
Neal

--
真実はいつも一つ！/ Always, there's only one truth!
___
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 the purpose of my "...@fedoraproject.org" email address?

[Neal Gompa]

On Thu, Oct 31, 2019 at 10:27 AM Chris Rainey  wrote:
>
> Thanks for the clarification. I just received this "reject" notice when 
> sending a test msg. So, if I understand correctly, it is non-deliverable from 
> the outside world and can simply be used as the "From:" address in my MUA?
>

No, people are supposed to be able to send you mail with that address,
the Red Hat MTA would just auto-forward it to your email address.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 the purpose of my "...@fedoraproject.org" email address?

[Neal Gompa]

On Thu, Oct 31, 2019 at 10:19 AM Chris Rainey  wrote:
>
> I just noticed that my FAS account has an automatic(?) @fedoraproject.org 
> email address. Is there an "Inbox" for this or is it just an alias to my 
> "Primary" account address for privacy, etc.?
>

The latter. You can set up your email client to send with that
address, and mail received will be forwarded to your registered email
address.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 packages app has a short runway

[Neal Gompa]

On Fri, Oct 25, 2019 at 3:48 PM Clement Verna  wrote:
>
>
>
> On Fri, Oct 25, 2019, 21:42 Randy Barlow  wrote:
>>
>> On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
>> > It's not a bad feature to have in fedpkg, but it fundamentally does
>> > not help *other people* discover what we have in the distribution.
>>
>> Yeah I've discussed this a bit with some people, and I agree. Fedora
>> *users* might use the packages app to find out the same info that
>> packagers want to find out.
>>
>> However, I think that even though users and packagers are coming to
>> this app for the same purpose, only one of those purposes maps to the
>> CPE team's mission statement: the packager's. If you are a packager,
>> you *need* to know what versions are where at a glance, especially when
>> dealing with something high priority like a CVE.
>>
>> That's not to say that the end-user story isn't a valuable use case,
>> but our team is overburdened and we need to drop most of what we do
>> right now, and we have to be specific about what our purpose is. This
>> means dropping some valuable use cases.
>
>
> https://pkgs.org/ might be a good replacement for that. Does anybody have 
> used or is using this website ? Any feedback on it ?
>

Some of the searching is a little awkward. It does let you see stuff
across distributions, but a lot of Fedora-specific information isn't
present.

Unfortunately, improving pkgs.org is impossible as the author is hard
to get ahold of and the software is not FOSS.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 packages app has a short runway

[Neal Gompa]

On Fri, Oct 25, 2019 at 2:43 PM Randy Barlow
 wrote:
>
> On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote:
> > The packages app (https://apps.fedoraproject.org/packages/) was
> > originally running on RHEL6, I tried to move it to RHEL 7 but they
> > were some dependencies missing there so we decided to move it to
> > Fedora. I don't remember which dependencies were missing tho. One of
> > the pain point is that the frontend is rendered using moksha/tosca
> > widgets (http://toscawidgets.org/) and this is pretty much a dead
> > upstream project. Removing these dependencies is not going to be
> > trivial.
>
> OK. Given our extreme time constraints, I think it is likely that we
> will have to retire the Packages app.
>
> However, there is one feature in it that I personally believe does map
> to the CPE team's mission statement: the table of which versions of a
> package are in which versions of Fedora/EPEL.
>
> I think we should do *something* to continue to provide that particular
> feature to packagers. I have a proposal:
>
> What if we make a fedpkg subcommand that prints that table? I think it
> could get all the needed data by querying Koji.
>
> I suggest this instead of a webapp or service, because webapps and
> services increase the burden on the CPE team, and also because creating
> an entire application just to print a table is a lot of boilerplate.
>
> Adding it to fedpkg feels clean to me, because it seems like a sensible
> place for such a feature to exist, and because it *should* be simple
> and easy. Simple is good!
>
> I may be able to find the time to make this happen before April too.
>
> Thoughts?

It's not a bad feature to have in fedpkg, but it fundamentally does
not help *other people* discover what we have in the distribution. If
anything, the biggest problem with CLI tools over web apps is that
there's no intuitive way to discover anything. In my view, it does not
replace the purpose of the packages web app.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 packages app has a short runway

[Neal Gompa]

On Thu, Oct 24, 2019 at 2:13 PM Clement Verna  wrote:
>
>
>
> On Thu, 24 Oct 2019 at 18:07, Randy Barlow  
> wrote:
>>
>> Greetings!
>>
>> The packages app is running on Fedora 30, and its dependencies are not
>> available in Fedora 31+ as I understand it.
>>
>> This means it has about 7 months before we need to do something about
>> it, or shut it off.
>>
>> Do we know if it can run on RHEL 7?
>
>
> The packages app (https://apps.fedoraproject.org/packages/) was originally 
> running on RHEL6, I tried to move it to RHEL 7 but they were some 
> dependencies missing there so we decided to move it to Fedora. I don't 
> remember which dependencies were missing tho. One of the pain point is that 
> the frontend is rendered using moksha/tosca widgets 
> (http://toscawidgets.org/) and this is pretty much a dead upstream project. 
> Removing these dependencies is not going to be trivial.
>

There appears to be work starting on a brand new implementation:
https://github.com/xsuchy/fedora-packages-ng

This version looks like it'll be Python 3 compatible, though it is quite new.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: communishift reinstall

[Neal Gompa]

On Tue, Oct 22, 2019 at 5:38 PM Kevin Fenzi  wrote:
>
> Sorry for the delay here. The re-install took yesterday, last night and
> into today. ;( (Mostly due to hardware and os deployment issues).
>
> Anyhow, it's all re-installed and set back up, feel free to re-import
> your applications/projects and let us know if there's anything broken
> you spot.
>
> The version is now also 4.2...
>

The developer catalog is completely empty. Is that the normal?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: communishift reinstall

[Neal Gompa]

On Sat, Oct 19, 2019 at 7:51 PM Kevin Fenzi  wrote:
>
> On Sat, Oct 19, 2019 at 07:38:04PM -0400, Neal Gompa wrote:
> > On Sat, Oct 19, 2019 at 7:37 PM Kevin Fenzi  wrote:
> > >
> > > Greetings communishift group (and infrastructure list).
> > >
> > > I was working on the communishift cluster trying to fix it's failing to
> > > upgrade as well as some cert issues, and managed to munge up the cluster
> > > but good. ;( It's a tribute to the resillance of OpenShift that it's up
> > > and serving applications still. :)
> > >
> > > In any event, I think the easiest way to clean things up and get back to
> > > normal is for us to just reinstall it. With that in mind, I am planning
> > > to do so starting at 21UTC on 2019-10-21 (monday).
> > >
> > > If everyone could oc export any config or data they wish to save before
> > > then that would be great.
> > >
> > > Sorry for the trouble, but hopefully we will be back on track after
> > > that.
> > >
> >
> > Out of curiosity, is there some documentation somewhere of how this
> > process is being handled?
>
> Which process? The re-install?
>
> Basically just:
>
> https://docs.openshift.com/container-platform/4.2/installing/installing_bare_metal/installing-bare-metal.html
>
> Then after the install we run a few things (setup our idp, storage,
> certs and users).
>

I had figured that maybe there was some automation being used to
handle that installation process.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: repospanner and our Ansible repo

[Neal Gompa]

On Wed, Sep 18, 2019 at 9:58 AM Stephen John Smoogen  wrote:
>
> On Wed, 18 Sep 2019 at 09:44, Randy Barlow  
> wrote:
> >
> > On Tue, 2019-09-17 at 19:01 -0400, Neal Gompa wrote:
> > > Out of curiosity, do we know where the bottlenecks are in
> > > repoSpanner?
> > > In theory, the architecture of repoSpanner isn't supposed to be too
> > > different from gitaly, so I'm curious where we're falling down.
> >
> > I believe it needs a more efficient way to store the git objects. As I
> > understand it, it currently stores each one in its own file, resulting
> > in a large number of small files.
>
> So my "hot-take probably wrong" look at things seems to indicate that
> the reason it stores everything as a separate file is to make certain
> git actions faster. When you pack the files, searches, diffs and other
> checks become slower or memory intensive because you have to calculate
> new deltas and other things 'lost' in the packing.
>
> Looking at the gitaly documents, I think that is the reason they have
> multiple different types of in-memory caches at different layers. It
> allows for both faster accesses but probably blows up the size of what
> is needed for hardware. We have to be careful here because we don't
> have a hardware reserve to dive into for more memory/cpu.
>
> I think that for gitlab.org (versus running a local gitlab) they also
> use a lot of backend 'eventual' consistency caching. You push and it
> begins to spread that out through the multiple regions it is housed.
> The 'user' doesn't see this because the front end level just directs
> you to the known hot caches for that particular pull/push request..
> but if you somehow were hardcoded to a region you might not see the
> update/change for a while because it hasn't mirrored out completely.
> That also would speed up push/pull/changes greatly and not something
> we could 'duplicate'.
>

That definitely explains the performance consistency between
repoSpanner and gitaly for my local deployment. So it's most likely
related to how they simulate better performance as the backend catches
up.

That said, the most recent change to gitaly is that it now does hashed
storage of git objects and does "fast forking" using alternates
instead of storing as bare git repos and duplicating repos on disk.

None of that changes the initial push for a unique repo.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Fri, Sep 13, 2019 at 11:51 AM Adam Williamson
 wrote:
>
> 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 :)
>

I wonder if we can find some interest with other folks in other RPM
distros with the packages app... There isn't much about it that is
Fedora-specific. It doesn't even depend on Koji, which means people
who use other tooling could use it. So building up a group interested
could help with porting it to Python 3 and making it more configurable
for usage by other distros (if any such work is needed).

> >   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.

It was never implemented as far as I know. That said, I had been
recently talking to some folks at openSUSE about developing a new
protocol to replace 1-Click-Install (ymp) and some of the other custom
things being used. If this is something people want, it's something I
can prioritize advancing.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Thu, Sep 12, 2019 at 3:20 AM Clement Verna  wrote:
>
>
>
> On Thu, 12 Sep 2019 at 08:41, 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.
>
>
> Why can't we enhance src.fp.o to be able to search using binary packages ? 
> All the data the packages app is using the build the search index is coming 
> from mdapi (https://mdapi.fedoraproject.org/) so I don't see why we could not 
> build a similar index as part of src.fp.o and at the same time improve the 
> search experience there.
>

Because the search in src.fp.o is the Pagure git repo search. It's
searching for git repos. They just happen to be the same names as the
source packages. :)

I don't think it'd be appropriate to wire in mdapi into the search,
and it would probably lead to very confusing results.

>>
>>
>> That said, I'm already working on many different applications that CPE
>> is trying to offload as it is. I can't personally take on this one
>> too.
>
>
> Welcome to our world :-)
>>
>>
>> But perhaps this is worthy of some kind of internship or other student
>> program project?
>>
>> >>
>> >>
>> >> Is it OK for us to link to the packages application in documentation, or
>> >> should we just link to src.fp.o already (in the NeuroFedora
>> >> documentation[3]) for example?
>> >>
>> >> The one thing that makes us prefer the packages app is that it has the
>> >> install command listed there while src.fp.o does not. That makes the
>> >> packages app somewhat more appropriate for end-users than
>> >> src.fp.o---src.fp.o has links to all the other build pipelines
>> >
>> >
>> > That's sounds like something that could be easily solved. For example 
>> > having a simple README.md for each package with a Description, How to 
>> > install and How to report Bugs.
>> >
>>
>> It is strategically infeasible to use the README.md file in this way
>> for src.fp.o. If we want data showing up there, we need to adjust
>> src.fp.o itself to show that data.
>
>
> I lack the knowledge here, why would that be strategically infeasible ? due 
> to the volume of packages ?
>

It's not just the volume of packages, but also because the README.md
file is editable by committers. It can even be deleted by them. You
can't guarantee anything about the file.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

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.

That said, I'm already working on many different applications that CPE
is trying to offload as it is. I can't personally take on this one
too.

But perhaps this is worthy of some kind of internship or other student
program project?

>>
>>
>> Is it OK for us to link to the packages application in documentation, or
>> should we just link to src.fp.o already (in the NeuroFedora
>> documentation[3]) for example?
>>
>> The one thing that makes us prefer the packages app is that it has the
>> install command listed there while src.fp.o does not. That makes the
>> packages app somewhat more appropriate for end-users than
>> src.fp.o---src.fp.o has links to all the other build pipelines
>
>
> That's sounds like something that could be easily solved. For example having 
> a simple README.md for each package with a Description, How to install and 
> How to report Bugs.
>

It is strategically infeasible to use the README.md file in this way
for src.fp.o. If we want data showing up there, we need to adjust
src.fp.o itself to show that data.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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] Upgrade pagure in production

[Neal Gompa]

On Fri, Aug 30, 2019 at 10:58 AM Pierre-Yves Chibon  wrote:
>
> Good Morning,
>
> A bit before freeze started, we upgrade pagure to 5.7.4 on src.fp.o but forgot
> to do pagure.io
> Since then there has been 4 small bug fixes releases (most of which are 
> related
> to src.fp.o), changelog is at: https://docs.pagure.org/pagure/changelog.html
>
> I'd like to upgrade src.fp.o from 5.7.4 to 5.7.8 which will also make Tomas
> Tomecek's life easier on packit and upgrade pagure.io to the latest version.
>
> Down time for src.fp.o is as small as an apache restart, on pagure.io there 
> is a
> database migration to apply but it should be just a few minutes.
>
>
> Thoughts?

Seems fine to me.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: BYO Jenkins for Pagure CI?

[Neal Gompa]

On Tue, Jul 16, 2019 at 2:37 PM Justin W. Flory  wrote:
>
> Hi all,
>
> I was looking into Pagure CI with Jenkins, but it wasn't clear if there
> is a Fedora-provided Jenkins server or if someone needs to bring their
> own Jenkins build infrastructure for Pagure CI.
>
> If there is a Fedora-provided Jenkins, could someone point me towards
> documentation on requesting an account / getting started?
>

You can use either the Jenkins instance provided by the CentOS Project
(which requires talking to those guys for getting your stuff set up)
or you can bring your own Jenkins instance and tell your Pagure
project to point to it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Retire keys.fedoraproject.org?

[Neal Gompa]

On Fri, Jul 5, 2019 at 11:15 AM Pierre-Yves Chibon  wrote:
>
> On Tue, Jul 02, 2019 at 02:47:36PM -0700, Kevin Fenzi wrote:
> > Hey everyone,
> >
> > As some of you may have read:
> >
> > https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> > and
> > https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html
> >
> > or other media reports about vulnerabilities of the current gpg
> > keyserver software/network/policy.
> >
> > TLDR: Someone can (and has been) flooding sks keyservers with poisoned
> > certs. Users that download from sks keyservers may well find gpg just
> > stops working, hangs, or breaks in terrible ways. The SKS software is no
> > longer maintained and because the policy is 'never delete anything'
> > there's likely no way to mitigate the attacks.
> >
> > I've cc'ed nb here for his take on things, but as I read it, it might be
> > best to just retire the keys.fedoraproject.org service at least for now
> > to avoid breaking users or telling them we have a service they should
> > trust when they really... should not.
>
> Having read this, +1 to decommission this service. This is quite saddening
> though :(
>
> I'd to hear nb's opinion on this but I think we may want to announce our 
> intent
> and turn it off somewhat soon.
>

As someone who relies on keys.fedoraproject.org quite a lot, I'm sad
that we have to decommission it...

If we ever brought it back, we'd probably want to configure the server
to not be part of the SKS server ring...




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Wed, May 1, 2019 at 10:48 PM Dusty Mabe  wrote:
>
>
>
> On 5/1/19 10:20 PM, Adam Williamson wrote:
> > 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?
> > :)
>
> 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. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Mon, Apr 29, 2019 at 8:32 AM Pierre-Yves Chibon  wrote:
>
> On Mon, Apr 29, 2019 at 08:22:31AM -0400, Neal Gompa wrote:
> > On Mon, Apr 29, 2019 at 8:21 AM Pierre-Yves Chibon  
> > wrote:
> > >
> > > On Mon, Apr 29, 2019 at 08:10:59AM -0400, Neal Gompa wrote:
> > > > On Mon, Apr 29, 2019 at 7:51 AM Stephen John Smoogen  
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Mon, 29 Apr 2019 at 07:35, Neal Gompa  wrote:
> > > > >>
> > > > >> On Mon, Apr 29, 2019 at 7:21 AM Kamil Páral 
> > > > >>  wrote:
> > > > >> >
> > > > >> > > On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi 
> > > > >> > >  > > > >> > >
> > > > >> > >
> > > > >> > > 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?
> > > > >> >
> > > > >> > (My email to the list was rejected because I'm not subscribed, let 
> > > > >> > me try again from the web UI...)
> > > > >> >
> > > > >> > 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/
> > > > >> >
> > > > >>
> > > > >> But Fedora CI is broken and/or vaporware. How can we replace 
> > > > >> Taskotron
> > > > >> with that?
> > > > >>
> > > > >
> > > > > Honestly.. weren't we saying the same damn thing about taskotron 
> > > > > until Fedora CI became the latest thing to rail about. It was 
> > > > > constantly 'why do you spend time on this broken crap' and then it 
> > > > > becomes the 'oh why are you replacing my favorite thing in the 
> > > > > world'. I am pretty sure there are multiple thesis and doctorates on 
> > > > > the codependency that OpenSource developers exhibit..
> > > > >
> > > > >
> > > >
> > > > I actually don't remember this for Taskotron... I'm pretty sure that's
> > > > because most of us can't interact with it.
> > > >
> > > > The problem with Fedora CI is that it's documentation is useless and
> > > > attempts to use the system end in miserable failure.
> > >
> > > Sorry for asking, but could you point me to the tickets you've opened for 
> > > the
> > > issues you've seen/faced?
> >
> > I personally haven't opened any tickets because I can't figure out how
> > to use it. But I've heard from others (Fabio, Miro, etc.) that none of
> > it works, so I haven't bothered trying to dig into it anymore.
>
> Would be nice to rely on your own experience rather than hearsay :)
> I'm not saying Miro hasn't had problems, he has said so in a few occasions
> before with links to tickets he opened but I'm hearing a lot of people
> bad-mouthing CI while there aren't so many tickets on:
> https://pagure.io/fedora-ci/general/ considering how wide it is deployed and
> should impact the community.
> So I'm questioning if people are bad-mouthing because they've heard other 
> people
> doing it or because they have legitimate issues that have been reported and
> should be fixed.
>
> I'm very happy to help raise concerns/issues from the community about issues
> about the CI pipeline but I need to have hard-facts and tickets to be able to 
> do
> so, not hear-say.
>

My two problems right now:

1. I don't know how to actually use it (I'd like to for snapd, at least)
2. I really don't want to have to design an Ansible playbook for this
(that's overkill!).


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Mon, Apr 29, 2019 at 8:21 AM Pierre-Yves Chibon  wrote:
>
> On Mon, Apr 29, 2019 at 08:10:59AM -0400, Neal Gompa wrote:
> > On Mon, Apr 29, 2019 at 7:51 AM Stephen John Smoogen  
> > wrote:
> > >
> > >
> > >
> > > On Mon, 29 Apr 2019 at 07:35, Neal Gompa  wrote:
> > >>
> > >> On Mon, Apr 29, 2019 at 7:21 AM Kamil Páral  
> > >> wrote:
> > >> >
> > >> > > On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi  > >> > > wrote:
> > >> > >
> > >> > >
> > >> > > 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?
> > >> >
> > >> > (My email to the list was rejected because I'm not subscribed, let me 
> > >> > try again from the web UI...)
> > >> >
> > >> > 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/
> > >> >
> > >>
> > >> But Fedora CI is broken and/or vaporware. How can we replace Taskotron
> > >> with that?
> > >>
> > >
> > > Honestly.. weren't we saying the same damn thing about taskotron until 
> > > Fedora CI became the latest thing to rail about. It was constantly 'why 
> > > do you spend time on this broken crap' and then it becomes the 'oh why 
> > > are you replacing my favorite thing in the world'. I am pretty sure there 
> > > are multiple thesis and doctorates on the codependency that OpenSource 
> > > developers exhibit..
> > >
> > >
> >
> > I actually don't remember this for Taskotron... I'm pretty sure that's
> > because most of us can't interact with it.
> >
> > The problem with Fedora CI is that it's documentation is useless and
> > attempts to use the system end in miserable failure.
>
> Sorry for asking, but could you point me to the tickets you've opened for the
> issues you've seen/faced?
>

I personally haven't opened any tickets because I can't figure out how
to use it. But I've heard from others (Fabio, Miro, etc.) that none of
it works, so I haven't bothered trying to dig into it anymore.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Mon, Apr 29, 2019 at 7:51 AM Stephen John Smoogen  wrote:
>
>
>
> On Mon, 29 Apr 2019 at 07:35, Neal Gompa  wrote:
>>
>> On Mon, Apr 29, 2019 at 7:21 AM Kamil Páral  wrote:
>> >
>> > > On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi > > > wrote:
>> > >
>> > >
>> > > 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?
>> >
>> > (My email to the list was rejected because I'm not subscribed, let me try 
>> > again from the web UI...)
>> >
>> > 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/
>> >
>>
>> But Fedora CI is broken and/or vaporware. How can we replace Taskotron
>> with that?
>>
>
> Honestly.. weren't we saying the same damn thing about taskotron until Fedora 
> CI became the latest thing to rail about. It was constantly 'why do you spend 
> time on this broken crap' and then it becomes the 'oh why are you replacing 
> my favorite thing in the world'. I am pretty sure there are multiple thesis 
> and doctorates on the codependency that OpenSource developers exhibit..
>
>

I actually don't remember this for Taskotron... I'm pretty sure that's
because most of us can't interact with it.

The problem with Fedora CI is that it's documentation is useless and
attempts to use the system end in miserable failure.

What I'm annoyed about is the continual replacement of things with
stuff that works _less_ than before. I'm sure this has a lot to do
with "agile" and pushing "minimal viable products" as full
replacements, with the hope that it'd iteratively build up. That
doesn't seem to happen quickly enough for things to be useful, and
sometimes the effort going in falls off before it reaches parity with
what it replaced.

Replacing a Honda Civic with a Tata Nano just doesn't fly.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[Neal Gompa]

On Mon, Apr 29, 2019 at 7:21 AM Kamil Páral  wrote:
>
> > On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi  >
> >
> > 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?
>
> (My email to the list was rejected because I'm not subscribed, let me try 
> again from the web UI...)
>
> 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/
>

But Fedora CI is broken and/or vaporware. How can we replace Taskotron
with that?

Also, I don't relish the idea of writing Ansible playbooks for tests.
And I imagine most other folks don't. We don't need a Zuul-like system
for most package testing.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: What are we going to do about sigul?

[Neal Gompa]

On Tue, Jan 29, 2019 at 4:28 PM Kevin Fenzi  wrote:
>
> On 1/21/19 10:13 AM, Neal Gompa wrote:
> > Hey all,
> >
> > So, we've got a bit of a problem. The sigul package is not installable
> > in Fedora 29, and pygpgme is half-broken in Fedora 28 and was retired
> > during Fedora 29 development due to constant breakage.
> >
> > This means that sigul is in danger of being retired in Fedora.
> > Unfortunately, sigul is the only supported signer system for Koji at
> > the moment.
> >
> > What do we want to do here? It's well-known that sigul does not work
> > with GnuPG 2, though I vaguely recall that some work was done to try
> > to fix this.
> >
> > Do we want to port sigul to python3-gpg, switching Sigul to Python 3
> > and the official gpgme bindings so that it works with GnuPG 2?
>
> I would think this would be the way to go, but of course it's up to Patrick.
>

Is this in progress anywhere?

> >
> > Or do we want to adapt the bridge to work with obs-signd (which is
> > already used by Copr)?
>
> This is a non starter, obs-signd doesn't do everything that sigul does
> and we have a number of things that depend on sigul working the way it
> does.
>

Forgive me, but what does sigul do that signd cannot? I'm unaware of
any material differences between the two.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 1.17.0 and Python 3

[Neal Gompa]

On Mon, Mar 11, 2019 at 9:44 AM Peter Robinson  wrote:
>
> > I disabled autopushing precisely so that there's no accidental pushing
> > to stable updates. The worst thing that can happen is that we have to
> > unpush the update from testing. Seriously, that's really not the end
> > of the world.
> >
> > Nowhere did I say that releng needs to deploy this RIGHT NOW. Having
> > this in rawhide and F30 updates-testing makes it possible for the
> > dependency map for Python 2 to cleanup even more, allowing the Python
> > SIG to continue its work to clean out Python 2 subpackages in Fedora
> > 30/31.
>
> So if you've disabled/removed python2 support in Fedora 30 you've
> broken image building at least.
>

I double-checked this and you're sadly right. I've fixed this so
koji-builder is now using Python 2 again.

I thought I had validated all the dependencies for Koji we use in
infra to have been ported, but alas, imgfac hasn't been done yet.

Sorry all. I've learned my lesson. I'm not going to touch
infrastructure in Fedora directly again.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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