Re: Congrats to Nick Bebout

[Clement Verna]

On Mon, 5 Apr 2021 at 17:48, Kevin Fenzi  wrote:

> Greetings.
>
> I'm happy to announce that Nick Bebout(fas: nb, irc: nb)
> has been added to our sysadmin-main group.
>
> This is the core group of trusted folks that high level access to most
> everything in fedora infrastructure.
>
> Nick has been doing infrastructure tasks for various groups for many
> years in sysadmin-noc, sysadmin-web, and too many other groups to list.
>
> He's proved his dedication, trustworthiness, and ability.
>
> Congrats!
>

Congrats Nick :)


> Use your powers for good! :)
>
> 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
>
___
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

[Clement Verna]

On Wed, 25 Nov 2020 at 20:26, Brendan Early  wrote:

> On 11/25/20 12:34 PM, Neal Gompa wrote:
> > 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.
>
> How often do the mirrors sync? I have been meaning to change the sync
> script to only generate files for version differences, which should
> allow for running it every thirty minutes.
>

The previous solution was listening to this message
https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.mdapi.repo.update=2
to update the database. The message is sent if changes are detected in the
repos. That process is run by a cronjob every hour.

IMO that's acceptable, but curious to hear from others :-)


> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Fedora packages site down

[Clement Verna]

On Tue, 24 Nov 2020 at 23:02, Kevin Fenzi  wrote:

> On Tue, Nov 24, 2020 at 12:18:54PM +0100, Miroslav Suchý wrote:
> > Dne 18. 11. 20 v 2:11 Kevin Fenzi napsal(a):
> > > We are close to replacing this app with a new setup...
> > >
> > > see the 'packages app' thread in this very list. ;)
> >
> > Did we come to conclusion which app (out of these two) we are going to
> deploy?
>
> Well, I personally thought it would be better to go with the community
> maintained one. Less work for you/your team, more respectfull of the
> work they already put into this, and I know you and your team are busy.
> >
> > If that will be the fedora-packages-ng I will be happy to proceed and
> spin up VM in AWS and update playbooks. I just
> > need the green light :)
> > If that helps, I can promise that CPT (aka Copr) team will maintain it.
>
> Thats great, and if that was the only choice I would be very happy...
> however, we have another community maintained/created one. :(
>
> > On 11/24/20 5:18 AM, Miroslav Suchý wrote:
> > > Dne 18. 11. 20 v 2:11 Kevin Fenzi napsal(a):
> > > > We are close to replacing this app with a new setup...
> > > >
> > > > see the 'packages app' thread in this very list. ;)
> > > Did we come to conclusion which app (out of these two) we are going to
> deploy?
> >
> > Timothée and I submitted a solution in April. It would be great if
> > packages-static could be adopted.
> >
> > I have been consistently responding to all discussions on the mailing
> list.
> > I did respond to the thread back in September. Kevin said you were busy
> and
> > suggested -static and -ng be tested. I have submitted an RFR since then.
> I
> > have time to maintain packages-static and I am still looking for a
> favorable
> > decision.
> >
> >
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/SYM6OT4BGDOWF7EGOGG75YG5LOXB7XMF/#YD5TFWZHBITXZBA35KDELKDGXANCH5E6
> >
> > https://pagure.io/fedora-infrastructure/issue/9441
>
> Yeah, I have had no time to work on deploying this, but it should be
> pretty short work for any of the folks who have deployed apps in our
> openshift.
>
> I'd personally go with static, but perhaps thats just me.
>

Yeah I think we should give a chance to the static solution, which seems to
be the easier to maintain and run on the long term.


>
> I would love to hear from more feedback one way or another.
>
> Miroslav: what do you think? would you be ok if we went with static and
> in the event something didn't work there or we needed more functionality
> down the road we could move to ng then and in the mean time less work
> for you?
>
> Please chime in everyone. :)
>
> 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
>
___
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)

[Clement Verna]

+1

On Fri, Aug 28, 2020, 23:58 Neal Gompa  wrote:

> 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
>
___
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: Tech debt analysis tool

[Clement Verna]

On Thu, 16 Jul 2020 at 17:14, Michal Konecny  wrote:

> Hi James,
>
> I'm using the LGTM tool on Anitya and I'm pretty happy with it. It scans
> both javascript and python code.
>


We are also using LGTM on Bodhi and I am also pretty happy with it. It
currently runs on every PRs and add some comments about the new "code
smells" found in the PR, it is also possible to have a global view of the
project https://lgtm.com/projects/g/fedora-infra/bodhi/



>
> Didn't tried the other two.
>
> Michal
>
> On 16/07/2020 15:31, James Richardson wrote:
>
> Hi All,
>
> Vipul and I are looking into several different tools that will allow us to
> better analyze our tech debt with any new code that is merged into apps in
> http://github.com/fedora-infra.
>
> Currently, we have looked at the tools below, but we would love any and
> all input from the team and community on this.
>
> SonarCloud
> LGTM
> ShiftLeft
>
> Our goal is to find an open source tool that is easy to integrate as well
> as providing useful and timely feedback.
> So far, SonarCloud has proved to be the one that looks best, but again, we
> are very open to any and all suggestions, and at this early stage, a good
> conversation to arrive at the best solution.
>
> Regards,
>
> James
>
>
> --
>
> James Richardson
>
> Engineering Intern
>
> He | Him | His
>
> Red Hat Waterford 
>
> Communications House
>
> Cork Road, Waterford City
>
> jamri...@redhat.com 
> M: +353851970521 <+353877545162> IM: jamricha
> @redhatjobs    redhatjobs
>  @redhatjobs
> 
> 
>
> ___
> 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
>
>
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: What is our technical debt?

[Clement Verna]

On Tue, 7 Jul 2020 at 02:28, 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.


Yeah this was more of a proof of concept, but I think it would be
interesting to continue working on it. Being able to manage the bodhi
releases (create, update status, update tags, etc ..) in Ansible would be
quite cool. We also have an example of playbook that is using koji-ansible
[0], I only played with it in staging before the data center move but it
would be cool to actually use this playbook when we branch F33.


[0] -
https://pagure.io/fedora-infra/ansible/blob/master/f/playbooks/manual/releng/koji-release-tags.yml


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

> - Ken
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: What is our technical debt?

[Clement Verna]

On Thu, 25 Jun 2020 at 21:35, 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?
>

In my opinion the biggest struggle we have is too many code bases and we
don't have the time or interest to make sure that they are all in good
shape. I think that even if we were to spend the next 3 months just
focusing on paying back that debt (updating documentation, dependencies,
tests etc ) we would come back to our current situation in 1 year or so
because we just can't keep up.
In my opinion it would be really good to spend some time looking at all the
applications interactions and look at opportunities to reduce these
interactions and consolidate features in fewer applications. (this is
something that I started when looking at PDC and I still think that ideally
we should try to not replace PDC but enhance existing services to provide
the features we need.)
If anyone can draw a diagram of all the services we have and how they
interact with each other I would be super interested to see that and I
think that would be a great start to look at reducing our technical debt.


>
>
> Looking forward to your thoughts,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The future of loopabull

[Clement Verna]

On Mon, 1 Jun 2020 at 15:37, Pierre-Yves Chibon  wrote:

> On Fri, May 29, 2020 at 03:18:58PM +0200, Clement Verna wrote:
> >On Thu, 28 May 2020 at 14:27, Pierre-Yves Chibon <[1]
> pin...@pingoured.fr>
> >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:
> >
> >  [2]
> 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)
> >
> >  Upstream released yesterday a 0.0.7 release which brings supports
> for
> >  fedora-messaging (contributed by your servitor).
> >  Looking at the code, it should be python3 compatible, but it
> doesn't say
> >  specifically in the setup.py and I honestly don't remember if I've
> >  tested that
> >  or not.
> >  The package has been orphaned in Fedora for over 10 months and has
> thus
> >  been
> >  retired.
> >
> >  I've had a chat with upstream yesterday and they are still
> interested in
> >  the
> >  project but more as a pet project and their time is just like the
> rest
> >  of us,
> >  limited for pet projects these days.
> >  That being said the code base is really quite small and involves
> >  technologies
> >  we're already using in other places (python-pika, celery, rabbitmq,
> >  ansible...)
> >  so there isn't really anything new there.
> >
> >  One of its limitation currently is with secrets, how to pass/specify
> >  them.
> >  This is something we could circumvent via ansible-vault or so, but
> it
> >  needs a
> >  little investigation.
> >
> >  I basically see three ways forward with this:
> >  - We continue with loopabull and we need to check its python3
> support,
> >  how to
> >deal with secrets, if we can get it to run in openshift & so on.
> >  - We look for something else, similar. The requirements being:
> >- Run a task when seeing a message in our message bus
> >- Handle secrets
> >- Scalable up/down
> >- Runnable in openshift is a bonus
> >- Preferably in a language we can debug (python++, potentially
> rust)
> >  - We write something that fits our needs and requirements
> >
> >There is a PR[0] in fedora-messaging to add a 'run' callback that
> would
> >let you execute any command, I think that might be a nice solution
> and I
> >think it would meet most of the requirements.
> >
> >[0] - [3]https://github.com/fedora-infra/fedora-messaging/pull/163
>
> Isn't that the equivalent of having us write a custom fedora-messaging
> consumer
> for each task we want to automate?
>

Yes but without all the boilerplate needed for each consumer.


> In a way I like this, it's simple(r), really straight forward, constraint
> and
> self-contained. There is no risk that a previous task prevents a following
> one
> to be executed.
> On the other hand it also means that if we move to, say fed-messaging, in
> the
> future, we will have to convert more consumers.
>

> If that's a trade off we're willing to live with, then I'm ok with it as
> well.
>

I don't have a strong opinion here :-)


>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The future of loopabull

[Clement Verna]

On Thu, 28 May 2020 at 14:27, 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)
>
> Upstream released yesterday a 0.0.7 release which brings supports for
> fedora-messaging (contributed by your servitor).
> Looking at the code, it should be python3 compatible, but it doesn't say
> specifically in the setup.py and I honestly don't remember if I've tested
> that
> or not.
> The package has been orphaned in Fedora for over 10 months and has thus
> been
> retired.
>
> I've had a chat with upstream yesterday and they are still interested in
> the
> project but more as a pet project and their time is just like the rest of
> us,
> limited for pet projects these days.
> That being said the code base is really quite small and involves
> technologies
> we're already using in other places (python-pika, celery, rabbitmq,
> ansible...)
> so there isn't really anything new there.
>
> One of its limitation currently is with secrets, how to pass/specify them.
> This is something we could circumvent via ansible-vault or so, but it
> needs a
> little investigation.
>
> I basically see three ways forward with this:
> - We continue with loopabull and we need to check its python3 support, how
> to
>   deal with secrets, if we can get it to run in openshift & so on.
> - We look for something else, similar. The requirements being:
>   - Run a task when seeing a message in our message bus
>   - Handle secrets
>   - Scalable up/down
>   - Runnable in openshift is a bonus
>   - Preferably in a language we can debug (python++, potentially rust)
> - We write something that fits our needs and requirements
>

There is a PR[0] in fedora-messaging to add a 'run' callback that would let
you execute any command, I think that might be a nice solution and I think
it would meet most of the requirements.

[0] - https://github.com/fedora-infra/fedora-messaging/pull/163

>
>
> Would you know something that fits our requirements and that we could just
> run?
> If not, do you have a preferred way between options #1 and #3?
>
>
> Thanks for your thoughts,
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: IAD2 datacenter testing/application validation

[Clement Verna]

On Wed, 27 May 2020 at 11:57, Pierre-Yves Chibon 
wrote:

> On Wed, May 27, 2020 at 10:29:20AM +0200, Clement Verna wrote:
> >On Wed, 27 May 2020 at 09:42, Michal Konecny <[1]mkone...@redhat.com>
> >wrote:
> >
> >  I don't see the-new-hotness anywhere. Will it be deployed together
> with
> >  Anitya?
> >
> >I think these 2 apps were in the Minimal Viable Fedora infra so they
> will
> >be deployed but in the second phase when all the hardware is
> available in
> >IAD2.
>
> Were or were not (in the Minimal Viable Fedora)? :)
>

I guess "were not" but I can't be 100% sure about that :P

>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: IAD2 datacenter testing/application validation

[Clement Verna]

On Wed, 27 May 2020 at 09:42, Michal Konecny  wrote:

> I don't see the-new-hotness anywhere. Will it be deployed together with
> Anitya?
>

I think these 2 apps were in the Minimal Viable Fedora infra so they will
be deployed but in the second phase when all the hardware is available in
IAD2.


>
> Michal
>
> On 27/05/2020 00:22, Kevin Fenzi wrote:
>
> Greetings everyone.
>
> We now have most things deployed in our new datacenter (IAD2).
>
> Accordingly, I would like to get some testing and validation started.
>
> Please see the following document:
> https://hackmd.io/op6N_nIaR7aMzw9Ib-sDAQ
>
> Please feel free to ask questions here and add/check off services that
> appear to be running as expected. Application owners (people in
> sysadmin-whatever groups) should check that they have the expected level
> of access as before, that their playbooks run (idempotently!) and the
> logs and any interfaces show the application appears to be running fine.
>
> We have this week and next to get everything in good shape for migration
> week (20202-06-08) when we will moving everything out of phx2.
>
> Thanks for any help. :)
>
> 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
>
>
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-review is run on pull requests

[Clement Verna]

On Thu, 14 May 2020 at 19:52, Nils Philippsen  wrote:

> Hi everybody,
>
> since a couple of hours, ansible-review is run on changes submitted
> through pull requests in our Ansible repository on Pagure.
>
> This means: when someone submits a PR to the ansible repo or pushes
> changes into its source branch, a Zuul job is started which, when
> finished, reports whether or not ansible-review finds problems in
> changed playbooks/roles/... as a detailed comment (linking to test
> results) and as a flag in the side bar (see [1] as an example).
>
> Currently this is merely informational, i.e. if the Zuul job hasn't yet
> finished or fails, this won't stop reviewers from merging the change
> into the repository regardless. On the other hand, because we've set up
> ansible-review to just process the changes submitted in the PR, this
> takes relatively little time (think about 2 minutes from push to the
> report coming in), so it should come in early enough unless you're in a
> real rush. ;)
>
> I'd like to thank Pingou, who did the preliminary work and structure
> and especially Fabien Boucher who debugged the trouble we initially had
> with our deployed version of Zuul[2] and contributed a workaround[3,4].
>

This is really cool, thanks to everyone involved 


>
> Ciao,
> Nils
>
> [1]: https://pagure.io/fedora-infra/ansible/pull-request/62
> [2]: https://pagure.io/fedora-infra/ansible/pull-request/54
> [3]: https://pagure.io/fedora-infra/ansible/pull-request/60
> [4]: https://pagure.io/fedora-zuul-jobs/pull-request/60
> --
> Nils Philippsen"Those who would give up Essential Liberty to
> Software Engineer   purchase a little Temporary Safety, deserve neither
> Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
> PGP fingerprint:  D0C1 1576 CDA6 5B6E BBAE  95B2 7D53 7FCA E9F6 395D
> old:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Pre GA tasks

[Clement Verna]

+1 here from the updated diff

On Fri, 24 Apr 2020 at 20:33, Stephen John Smoogen  wrote:

>
> Reviewed updated diff. +1
>
>
> On Fri, 24 Apr 2020 at 12:41, Mohan Boddu  wrote:
>
>> Hi,
>>
>> On Fri, Apr 24, 2020 at 12:33 PM Kevin Fenzi  wrote:
>> >
>> > On Fri, Apr 24, 2020 at 12:26:06PM -0400, Mohan Boddu wrote:
>> > > Hi,
>> > >
>> > > The following changes are needed for pre ga tasks, please review them.
>> > >
>> > > Thanks.
>> >
>> > 2 things:
>> >
>> > I do not think we want to change pkgdb-gnome-software-collections.json
>> > today. If we do, gnome-software will start offering f32 updates to
>> > people before release.
>> >
>> > I don't think we want to set Frozen: False yet, thats the infra freeze,
>> > it's still on until next wed.
>>
>> Thanks Kevin, here's the updated diff.
>>
>> >
>> > Otherwise looks ok to me.
>> >
>> > 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
>> ___
>> 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
>
___
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: reboot ppc9-02

[Clement Verna]

On Sat, 25 Apr 2020 at 00:33, Kevin Fenzi  wrote:

> ppc9-02 is in a odd state. Guests are running ok, but the host itself is
> hanging any ansible runs against it. :( Usually this is a sign of some
> stuck hardware.
>
> I've disabled the builders on it and once builds finish on them I would
> like to update and reboot ppc9-02. Due to existing builds this may be
> later this weekend...
>
> +1s?
>

+1 from me


> 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
>
___
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 DNS to match closer zones

[Clement Verna]

On Sun, 26 Apr 2020 at 17:43, Stephen John Smoogen  wrote:

> Currently several countries are getting routed to proxies which are timing
> out for them. This should 'fix' some though I expect we will need to break
> this out further per continental region.
>
> diff --git a/roles/dns/files/named.conf b/roles/dns/files/named.conf
> index c8b95b9..135ec69 100644
> --- a/roles/dns/files/named.conf
> +++ b/roles/dns/files/named.conf
> @@ -610,7 +610,7 @@ view "RDU2" {
>
>  // The zones
>  view "NA" {
> -match-clients { US; CA; MX; };
> +match-clients { US; CA; MX; BM; GL; };
>  recursion no;
>  // no rate-limit on internal requests
>  rate-limit {
> @@ -636,9 +636,10 @@ view "NA" {
>  };
>
>
> -// This is not "EU" countries, I just wanted a short way to represent
> Europe.
> +// This should have been EME and during the next freeze break should be
> made as such.
>  view "EU" {
> -match-clients { AT; BE; BG; CY; CZ; DE; DK; EE; ES; FI; FR; GR;
> HU; IT; LT; LU; LV; MT; NL; PL; PT; RO; RU; SE; UA; GB; IE; IS; NO; };
> +   match-clients { AD; AL; AT; AX; BA; BE; BG; CH; CZ; DE; DK; EE;
> ES; FI; FO; FR; GB; GG; GI; GR; HR; HU; IE; IM; IS; IT; JE; LI; LT; LU; LV;
> MC; ME; MK; MT; NL; NO; PL; PT; RO; RS; RU; SE; SI; SJ; SK; SM; UA; VA; AE;
> AM; AZ; BH; CY; GE; IL; IQ; JO; KW; LB; OM; QA; SA; TR; YE; };
> +
>  recursion no;
>  zone "fedoraproject.org" {
>  type master;
> @@ -660,7 +661,7 @@ view "EU" {
>  };
>
>  view "APAC" {
> -match-clients { AE; AF; AM; AU; AZ; BD; BH; BN; BT; CC; CN; CX;
> CY; GE; HK; ID; IL; IN; IO; IQ; IR; JO; JP; KG; KH; KP; KR; KW; KZ; LA; LB;
> LK; MM; MN; MO; MV; MY; NP; NZ; OM; PH; PK; PS; QA; RU; SA; SG; SY; TH; TJ;
> TL; TM; TR; TW; UZ; VN; YE; };
> +match-clients { AF; BD; BN; BT; CN; HK; ID; IN; JP; KG; KH; KZ;
> LA; LK; MM; MN; MO; MV; MY; NP; PH; PK; SG; TH; TJ; TL; TM; UZ; VN; AS; AU;
> CC; CK; CX; FJ; FM; GU; HM; KI; MH; MP; NC; NF; NR; NU; NZ; PF; PG; PN; PW;
> SB; TK; TO; TV; UM; VU; WF; WS; }
>  recursion no;
>  zone "fedoraproject.org" {
>  type master;
>
>
+1


>
> --
> Stephen J Smoogen.
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

On Wed, 22 Apr 2020 at 11:18, Timothée Floure 
wrote:

> Hi,
>
> Took a bit more time than expected due to other and more local
> priorities on my side. The basic structure is there and usable, and
> indexing seemed work quite well before CommunityShift (hence yacy) went
> down.
>
> * Main page: https://fnux.ch/fedpkg/public_html/
> * Crawler entrypoint:
> https://fnux.ch/fedpkg/public_html/crawler-entrypoint.html
> * Package page:
> https://fnux.ch/fedpkg/public_html/pkgs/qutebrowser/
>
> Everything lives on https://pagure.io/fedora-packages-static, and
> contains the TODO-list (epel-8, flatpaks & containers, dependencies,
> etc.).  CommunityShift will be back earlier than I initially thought,
> and I hope to find some time to complete some of the TODO tasks by then.
>

This is cool, thanks for working on this. How long does it take for the
`make all` command to complete ? ( I am just curious compared to the
current solution :-) )


>
> Feedback, green light, whether it looks good enough to replace the
> current app, or anything you think relevant is welcome. The only
> dependencies are python3-requests and python3-jinja2 and there is no
> flying parts since it is a static website: we should not hit dead
> dependency issues ever again (or the package app will be the least of
> our problems!).
>

I think we should look at deploying this service once communishift is back
online. Also since the current application will go down during the data
center move switching to this service instead of bringing back up the old
code base seems to me like an interesting way forward.



>
> Have a nice day,
>
> --
> Timothée
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: OIDC testing

[Clement Verna]

On Thu, 23 Apr 2020 at 17:43, Pierre-Yves Chibon 
wrote:

> On Thu, Apr 23, 2020 at 05:59:10PM +0300, Benson Muite wrote:
> > Hi,
> >
> > Does one need to request anything other than client secrets through an
> infrastructure Pagure issue to be able to test application authentication
> with
> >
> > https://iddev.fedorainfracloud.org/
>
> For this instance you can self-register yourself, it is not even needed to
> request a client secret.
>

I wrote some small docs while working on fpdc-client on how to self
register against iddev.fp.o, see
https://fpdc-client.readthedocs.io/en/latest/userguide.html#authentication

Hope that helps


>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] fix openshift

[Clement Verna]

On Thu, 23 Apr 2020 at 14:43, 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?
>

It is a small change and without it builds are broken so +1 from me.


> Thanks,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] Retire in bugzilla package retired in Fedora

[Clement Verna]

On Wed, 22 Apr 2020 at 20:48, Kevin Fenzi  wrote:

> On Wed, Apr 22, 2020 at 08:14:08PM +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> >
> > I believe this is not frozen but in doubt I'm still asking it :)
> >
> > I would like to deploy a new build of distgit-bugzilla-sync (running in
> > openshift) to include this pull-request:
> > https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/48
> > which basically blocks in bugzilla packages that are retired in Fedora.
> >
> > This fixes https://pagure.io/fedora-infrastructure/issue/7639
> >
> > Thoughts?
>
> +1
>
> I assume you will run it a few times manually and confirm it's doing
> sane things? ;)
>
> If it messes up anything we need for release we can always manually
> change it back.
>

+1 from me too


>
> 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
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] docs-translation-update: change cron to run at 22 instead of 2. Fixes ticket 8847.

[Clement Verna]

On Thu, 23 Apr 2020 at 00:18, Kevin Fenzi  wrote:

> Per ticket 8847, moving this cron job to 10pm will let it run and finish
> before the larger
> and longer cron script runs to update the docs site. This will prevent
> overlap and get
> updates out a day sooner in some cases.
>
> Signed-off-by: Kevin Fenzi 
> ---
>  roles/fedora-docs/translation/files/cron-docs-translation-update | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/roles/fedora-docs/translation/files/cron-docs-translation-update
> b/roles/fedora-docs/translation/files/cron-docs-translation-update
> index bf91755..5a0627b 100644
> --- a/roles/fedora-docs/translation/files/cron-docs-translation-update
> +++ b/roles/fedora-docs/translation/files/cron-docs-translation-update
> @@ -1,2 +1,2 @@
>  MAILTO=jibecfed
> -0 2 * * * _update_docs_trans /usr/local/bin/lock-wrapper
> cron-docs-translation-update "/usr/local/bin/docs-translation-update"
> +0 22 * * * _update_docs_trans /usr/local/bin/lock-wrapper
> cron-docs-translation-update "/usr/local/bin/docs-translation-update"
> --
>

+1


> 1.8.3.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Ideas for more releng automation

[Clement Verna]

On Sun, 19 Apr 2020 at 20:24, Pierre-Yves Chibon 
wrote:
 snip


> >
> > Possibly, but it would mean it would need secrets to unlock the vault
> > and we don't use valut for anything else currently. ;(
>
> That almost applies to loopabull as well ;-)
> (Well we do use it, but not much)
>
> > I wonder how hard it would be to move loopabull into openshift... that
> > might also help the secrets thing by allowing it to keep things in
> > openshift secrets...
>
> I wonder if there is a benefit from using loopabull at that point, having a
> simple fedora-messaging consumer running in openshift would work just as
> well.
>

Yeah, also fedora-messaging makes it quite easy to setup the consumer and
there is not much boilerplate needed. So we could consolidate on 1 "bot"
consumer that listen to all the messages we are interested in and then
triggers different tasks.

I don't have a strong opinion, I was just thinking that maybe loopabull
would mean less maintenance on the longer term (ie focusing on witting the
tasks and tests for these tasks) but maybe the more we use it the more we
will have to touch loopabull upstream.


> > Is loopabull moved to fedora-messaging? Or still fedmsg?
>
> I have ported it to fedora-messaging, it only needed a couple of tweaks
> from the
> existing amqp plugin.
> I may still need a release. I know we talked about it with Adam on IRC not
> long
> ago, but looking at github it looks like there was no recent release made.
>

So the version deployed in the infra is still using fedmsg ?


>
> Pierre
> ___
> rel-eng mailing list -- rel-...@lists.fedoraproject.org
> To unsubscribe send an email to rel-eng-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/rel-...@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: add sysadmin-analysis to bastion

[Clement Verna]

On Tue, 21 Apr 2020 at 01:08, Kevin Fenzi  wrote:

> On Mon, Apr 20, 2020 at 06:50:40PM -0400, Stephen John Smoogen wrote:
> > The sysadmin-analysis group is used on data-analysis01 for people to log
> in
> > and work there. Because everyone in that group was in an existing group,
> I
> > forgot to add it to bastion. However a new person joined and they don't
> > have access.
> >
> > [smooge@batcave01 ansible (master)]$ git diff
> > diff --git a/inventory/group_vars/bastion b/inventory/group_vars/bastion
> > index 8e63d1a..160f1d1 100644
> > --- a/inventory/group_vars/bastion
> > +++ b/inventory/group_vars/bastion
> > @@ -23,7 +23,7 @@ custom_rules: [
> >
> >  # TODO - remove modularity-wg membership here once it is not longer
> needed:
> >  # https://fedorahosted.org/fedora-infrastructure/ticket/5363
> > -fas_client_groups:
> >
> sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs,sysadmin-odcs
> > +fas_client_groups: sysadmin-analysis,
> >
> sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs,sysadmin-odcs
>
> +1
>


+1


> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
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: Ideas for more releng automation

[Clement Verna]

On Fri, 17 Apr 2020 at 14:22, Leonardo Rossetti  wrote:

>
>
>
> On Fri, Apr 17, 2020 at 8:07 AM Clement Verna 
> wrote:
>
>> Hi all,
>>
>> I wanted to start a discussion and possibly some work around automating
>> the manual tasks involved in the release engineering work.
>>
>> In particular I have in mind the following tasks :
>>  - processing the unretire package tickets.
>>  - processing the requests for a new package or a new branch.
>>  - container base image release.
>>
>> Instead of looking at each of these individually I was thinking that it
>> might be interesting to look at having an automation framework or something
>> like a bot that could be flexible enough to add more tasks or process in
>> the future.
>>
>> To do that we have different possibilities, one could be to build a bot
>> that has a similar architecture than the compose-tracker (
>> https://pagure.io/releng/compose-tracker) ie a fedora-messaging consumer
>> processing messages.
>> Another option is to use loopabull (
>> https://github.com/maxamillion/loopabull) to trigger ansible playbook on
>> fedora-messaging messages.
>>
>> Both solutions are quite similar, but one (loopabull) provides already
>> the boilerplate to trigger a script or a function based on messages
>> received (a bit like AWS lambda or other serverless framework). We also
>> have already a few process automated that way (
>> https://pagure.io/Fedora-Infra/loopabull-tasks).
>> So I believe that using loopabull might be the best way forward, but I
>> would be interested to hear about other ideas :-)
>>
>
> I would lean to use loopabull because it already works in a "reactive way"
> with mq messages and we don't need to write a full application since we
> will be using ansible (which still can be "extended" developing modules for
> complex tasks) - the above script could become a couple of ansible modules
> to be used in a playbook with loopabull.
>
>
>>
>> Now if we look at the tasks to automate, I was thinking that we could
>> implement that automation in different phases :
>>
>> *un-retiring tickets*:
>>
>>- First step would be to run automatically the check-unretirement
>>script (
>>https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py)
>>and redirect its output into the ticket comments. That way people
>>processing the ticket have all the information available in the ticket.
>>- Second step would be to process automatically the tickets that do
>>not require a new bz review (retired less than 8 weeks ago)
>>- Finally see if we can process automatically all the tickets.
>>
>>
>> *creating new dist-git repo or branches:*
>>
>>- Idea here would be to run the fedscm-admin (
>>https://pagure.io/fedscm-admin) cli automatically when a new ticket
>>is created here (https://pagure.io/releng/fedora-scm-requests).
>>
>>
> I think it would also need to check for missed tickets from time to time,
> like every 5 minutes for example, in case it missed one for whatever reason.
>
>
>> *container base image release:*
>>
>>- Instead of building the image every night, we could rebuild the
>>image only when at least 1 package present in the base image has been
>>updated.
>>- Push the image weekly to the registry if a build happened during
>>that week.
>>
>>
> Is there any particular reason for using a weekly push schedule (assuming
> doing one on every build is way too much)?
>

So yeah that comes down to how update works for the Docker Hub official
images, this is done by PR and need someone from Docker to review and
approve the PR, so we can't really spam them with multiple PR per week. See
https://github.com/docker-library/official-images/issues/7529 for more info.
Also I think there is little point to push a new image every time there is
at least one package updated, doing it weekly allows to release the latest
image that might contain multiple updates. Longer term we could be smarter
and have a special case for security update.


>
>
>>
>>
>> Again here are some ideas, and I would very much appreciate feedback or
>> other ideas :-). Also if you think about another process that could be
>> automated that way please share it :-).
>>
>> Thanks
>> Clément
>>
>> ___
>> rel-eng mailing list -- rel-...@lists.fedoraproject.org
>> To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org
>> Fedora Code of 

Ideas for more releng automation

[Clement Verna]

Hi all,

I wanted to start a discussion and possibly some work around automating the
manual tasks involved in the release engineering work.

In particular I have in mind the following tasks :
 - processing the unretire package tickets.
 - processing the requests for a new package or a new branch.
 - container base image release.

Instead of looking at each of these individually I was thinking that it
might be interesting to look at having an automation framework or something
like a bot that could be flexible enough to add more tasks or process in
the future.

To do that we have different possibilities, one could be to build a bot
that has a similar architecture than the compose-tracker (
https://pagure.io/releng/compose-tracker) ie a fedora-messaging consumer
processing messages.
Another option is to use loopabull (https://github.com/maxamillion/loopabull)
to trigger ansible playbook on fedora-messaging messages.

Both solutions are quite similar, but one (loopabull) provides already the
boilerplate to trigger a script or a function based on messages received (a
bit like AWS lambda or other serverless framework). We also have already a
few process automated that way (
https://pagure.io/Fedora-Infra/loopabull-tasks).
So I believe that using loopabull might be the best way forward, but I
would be interested to hear about other ideas :-)

Now if we look at the tasks to automate, I was thinking that we could
implement that automation in different phases :

*un-retiring tickets*:

   - First step would be to run automatically the check-unretirement script
   (https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py)
   and redirect its output into the ticket comments. That way people
   processing the ticket have all the information available in the ticket.
   - Second step would be to process automatically the tickets that do not
   require a new bz review (retired less than 8 weeks ago)
   - Finally see if we can process automatically all the tickets.


*creating new dist-git repo or branches:*

   - Idea here would be to run the fedscm-admin (
   https://pagure.io/fedscm-admin) cli automatically when a new ticket is
   created here (https://pagure.io/releng/fedora-scm-requests).

*container base image release:*

   - Instead of building the image every night, we could rebuild the image
   only when at least 1 package present in the base image has been updated.
   - Push the image weekly to the registry if a build happened during that
   week.



Again here are some ideas, and I would very much appreciate feedback or
other ideas :-). Also if you think about another process that could be
automated that way please share it :-).

Thanks
Clément
___
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

[Clement Verna]

On Thu, 16 Apr 2020 at 22:43, Kevin Fenzi  wrote:

> On Thu, Apr 16, 2020 at 03:01:35PM +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> >
> > I have a few items in my backlog that I'd like to discuss priorities
> with you,
> > so here is the unsorted list, let me know how you would sort it :)
>
> Thanks for this pingou! :)
>
> Perhaps we should all try and do this at the beginning of the week or
> something. :)
>
> > * Finish bringing bugzilla overrides to dist-git
> >   means:
> > - Deploy pagure 5.9.x to src.fp.o
> > - Migrate the data from the scm-requests repo to dist-git
> > - Adjust the README of the scm-requests repo
> > - Close off the scm-requests repo to pull-requests
> > - Announce & profit/watch the world burn
> >   Blocked by the current freeze, unless a FBR is acceptable to upgrade
> pagure
> >   to 5.9.x (knowing that 5.9.x does not bring any DB changes).
>
> This is a good one.
> >
> > * Reworkd the packager sync from FAS to bugzilla
> >   Currently, there is a cron job that adds bugzilla privileges to people
> that
> >   are added to the packager group. That cron relies on a DB in FAS that
> tracks
> >   people being added or removed from this group. This isn't quite the
> 2020 way
> >   of doing things and this will not be portable to noggin (the next gen
> FAS).
> >   Python-bugzilla also recently (it's merged but not released) gained
> support
> >   for groups, so we can finally do something like: ask FAS for all the
> packagers
> >   and their email, list all the people in the corresponding group in
> bugzilla,
> >   do a diff and add/remove accordingly.
> >   fixes https://pagure.io/fedora-infrastructure/issue/8628
>
> This one I just had to manually fix 2 users. It's going to be an ongoing
> source of pain. ;(
>
> > * Finish retiring in bugzilla packages that are retired in Fedora (ie:
> close
> >   these components to new bugs in bugzilla).
> >   This was blocked on a change in bugzilla which has been deployed in
> the last
> >   release. So we should be able to proceed and adjust our
> bugzilla<->dist-git
> >   sync script to do this.
> >   fixes https://pagure.io/fedora-infrastructure/issue/7639
>
> This would be nice, but we have done without it for a long time, so more
> shouldn't hurt too much. :)
>
> >
> > * 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.
>
> Lets set aside a time and make this happen. :)
> I guess after freeze.
>
> > * Migrate stg.pagure.io and src.stg.fedoraproject.org to RHEL8.
> >   While we're in freeze, I figure this is a good time to do this. We
> could do
> >   pagure.io post-freeze and wait to do src.fp.o when it gets
> reinstalled in the
> >   new data-center.
>
> Yeah, good to do. I was going to ask you about this the other day.
> Perhaps I could reinstall stg pagure with rhel8 some day my night and
> you could take over your next morning with reloading the old data/etc?
>
> I agree it's a good time to do it.
>
> Perhaps monday night I could try and do it and you could work on it
> tuesday morning?
>

That could be also a good first issue for Mark to work on with pingou on it
since timezone will make that easier :-)

What do you think ?


>
> >
> > So here you go, let me know what you think :)
>
> My order:
>
> packager perms sync to bugzilla
> pagure to rhel8
> mirror ansible repo (after freeze)
> bugzilla overrides in pagure
> retired packages closed to bugs
>
> 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
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Meeting Agenda Item: Introduction Mark O'Brien

[Clement Verna]

On Thu, 16 Apr 2020 at 13:43, Mark O'Brien  wrote:

> Hello,
>
> May name is mark, I have just started as a software engineer at redhat, I
> have worked as a DevOps for 3 years previously and am familiar with tooling
> such as ansible and scripting languages such as python and bash.
>


Welcome Mark, looking forward to work with you :-)


>
> My irc handle: mjobrien
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Backlog prioritization

[Clement Verna]

On Thu, 16 Apr 2020 at 15:28, Pierre-Yves Chibon 
wrote:

> On Thu, Apr 16, 2020 at 03:16:29PM +0200, Clement Verna wrote:
> >Should we use the same prioritization category that we have for
> tickets ?
> >(low-gain, medium-gain, high-gain, low-trouble, medium-trouble,
> >high-trouble). That might give use a nice way to focus on 1 or 2
> things
> >:-)
> >Thoughts ?
>
> That or plain 1, 2, 3, 4 works for me :)
>

So here is my gain vs trouble thingy

* Finish bringing bugzilla overrides to dist-git
Trouble : Medium
Gain: High

There seems to be quite a few steps to be done, plus the need for an FBR so
medium troubles, but it would be obviously a high gain in terms of user
experience.

* Rework the packager sync from FAS to bugzilla
Trouble : Medium
Gain: Medium

I would put this as Medium in both Trouble and Gain since it looks like
what we currently have works but we have a better way of doing things now
:-).

* Finish retiring in bugzilla packages that are retired in Fedora
Trouble : Low
Gain: Low

Does not seems like this is much work to be done but I don't know how much
value we will get from it too.

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

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

just my 2cents :-)



> Some are easier to do than others, but there isn't any that is very high
> trouble
> I think.
>
>
> Pierre
>
> >On Thu, 16 Apr 2020 at 15:08, Pierre-Yves Chibon <[1]
> pin...@pingoured.fr>
> >wrote:
> >
> >  Good Morning Everyone,
> >
> >  I have a few items in my backlog that I'd like to discuss priorities
> >  with you,
> >  so here is the unsorted list, let me know how you would sort it :)
> >
> >  * Finish bringing bugzilla overrides to dist-git
> >means:
> >  - Deploy pagure 5.9.x to src.fp.o
> >  - Migrate the data from the scm-requests repo to dist-git
> >  - Adjust the README of the scm-requests repo
> >  - Close off the scm-requests repo to pull-requests
> >  - Announce & profit/watch the world burn
> >Blocked by the current freeze, unless a FBR is acceptable to
> upgrade
> >  pagure
> >to 5.9.x (knowing that 5.9.x does not bring any DB changes).
> >
> >  * Reworkd the packager sync from FAS to bugzilla
> >Currently, there is a cron job that adds bugzilla privileges to
> people
> >  that
> >are added to the packager group. That cron relies on a DB in FAS
> that
> >  tracks
> >people being added or removed from this group. This isn't quite
> the
> >  2020 way
> >of doing things and this will not be portable to noggin (the next
> gen
> >  FAS).
> >Python-bugzilla also recently (it's merged but not released)
> gained
> >  support
> >for groups, so we can finally do something like: ask FAS for all
> the
> >  packagers
> >and their email, list all the people in the corresponding group in
> >  bugzilla,
> >do a diff and add/remove accordingly.
> >fixes [2]https://pagure.io/fedora-infrastructure/issue/8628
> >
> >  * Finish retiring in bugzilla packages that are retired in Fedora
> (ie:
> >  close
> >these components to new bugs in bugzilla).
> >This was blocked on a change in bugzilla which has been deployed
> in
> >  the last
> >release. So we should be able to proceed and adjust our
> >  bugzilla<->dist-git
> >sync script to do this.
> >fixes [3]https://pagure.io/fedora-infrastructure/issue/7639
> >
> >  * Mirror the ansible git repo on [4]pagure.io
> >I'd like to set up a mirror on [5]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

Re: Backlog prioritization

[Clement Verna]

Should we use the same prioritization category that we have for tickets ?
(low-gain, medium-gain, high-gain, low-trouble, medium-trouble,
high-trouble). That might give use a nice way to focus on 1 or 2 things :-)

Thoughts ?

On Thu, 16 Apr 2020 at 15:08, Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> I have a few items in my backlog that I'd like to discuss priorities with
> you,
> so here is the unsorted list, let me know how you would sort it :)
>
> * Finish bringing bugzilla overrides to dist-git
>   means:
> - Deploy pagure 5.9.x to src.fp.o
> - Migrate the data from the scm-requests repo to dist-git
> - Adjust the README of the scm-requests repo
> - Close off the scm-requests repo to pull-requests
> - Announce & profit/watch the world burn
>   Blocked by the current freeze, unless a FBR is acceptable to upgrade
> pagure
>   to 5.9.x (knowing that 5.9.x does not bring any DB changes).
>
> * Reworkd the packager sync from FAS to bugzilla
>   Currently, there is a cron job that adds bugzilla privileges to people
> that
>   are added to the packager group. That cron relies on a DB in FAS that
> tracks
>   people being added or removed from this group. This isn't quite the 2020
> way
>   of doing things and this will not be portable to noggin (the next gen
> FAS).
>   Python-bugzilla also recently (it's merged but not released) gained
> support
>   for groups, so we can finally do something like: ask FAS for all the
> packagers
>   and their email, list all the people in the corresponding group in
> bugzilla,
>   do a diff and add/remove accordingly.
>   fixes https://pagure.io/fedora-infrastructure/issue/8628
>
> * Finish retiring in bugzilla packages that are retired in Fedora (ie:
> close
>   these components to new bugs in bugzilla).
>   This was blocked on a change in bugzilla which has been deployed in the
> last
>   release. So we should be able to proceed and adjust our
> bugzilla<->dist-git
>   sync script to do this.
>   fixes https://pagure.io/fedora-infrastructure/issue/7639
>
> * 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.
>
> * Migrate stg.pagure.io and src.stg.fedoraproject.org to RHEL8.
>   While we're in freeze, I figure this is a good time to do this. We could
> do
>   pagure.io post-freeze and wait to do src.fp.o when it gets reinstalled
> in the
>   new data-center.
>
> So here you go, let me know what you think :)
>
>
> Thanks,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: remove elections from inventory and run noc.yml playbook

[Clement Verna]

On Tue, 14 Apr 2020 at 22:03, Stephen John Smoogen  wrote:

>
>
> On Tue, 14 Apr 2020 at 15:49, Kevin Fenzi  wrote:
>
>> On Tue, Apr 14, 2020 at 03:08:25PM -0400, Stephen John Smoogen wrote:
>> > The following patch should do a minimal removal of the elections app
>> from
>> > ansible inventory so that a run of noc.yml will remove the systems from
>> > being monitored. Then we can turn off the elections systems.
>>
>> Wrong patch attached? Or something going on with my email client?
>>
>> It looks like pingou's kerneltest patch?
>>
>>
> Honestly.. you would think I knew how computers work by now . I have
> attached correct patch (I hope).
>

+1

>
>
>
>> kevin
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to
>> infrastructure-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>>
>
>
> --
> 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
>
___
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: ansible playbook to create koji tags

[Clement Verna]

On Tue, 14 Apr 2020 at 19:11, Kevin Fenzi  wrote:

> On Tue, Apr 14, 2020 at 04:20:22PM +0200, Clement Verna wrote:
> > Hi all,
> >
> > I have been playing a little bit around with the koji-ansible collection
> > and created a Proof of Concept playbook that creates the main tags for a
> > release in koji (staging).
> >
> > I have installed the collection on batcave01 running the following
> >
> > ```
> > ansible-galaxy collection install
> > ktdreyer.koji_ansible:0.0.0-git.274+c448a960
> > ```
>
> huh. Where did that install to?
>
> I would have hoped /usr/share/ansible/collections/ but it seems no?
>

The default is under /root/.ansible/collections/ansible_collections/ but
that can be configured in the ansible.cfg.


>
>
> > And the playbook is available under
> > playbooks/manual/releng/koji-release-tags.yml [0]. For now there is still
> > very much a lot of things hard coded, but that should give us a good idea
> > of what we can do with that collection.
>
> Cool! Yeah, we should be able to use the release variables I setup a
> while back, ie, f{{ FedoraRawhideNumber }} and such.
>
> It would be awesome to have all these in there and just change the
> variable and branching and run it and done.
>
> > Members of the sysadmin-main group can try the playbook by running
> >
> > ```
> > ansible-playbook
> > /srv/web/infra/ansible/playbooks/manual/releng/koji-release-tags.yml
> --check
> > ```
> >
> > For now it is executed on `composer.stg.phx2.fedoraproject.org` and it
> is
> > using this host keytab to authenticate with koji.
> >
> > I ll keep working on this and see if I can turn it in a role that could
> be
> > used to create all the tags for each release, in the mean time if you
> have
> > ideas or feedback please share them with me :-).
>
> There are so many tags and such, not sure how to organize it so they
> look clear, but I guess we can look at that down the road...
>

Yeah that's why I think a role or more might help here, also I am not sure
if things like the groups associated to tags are managed somewhere else, or
should they be described in the playbook/role too.


>
> Thanks for working on this!
>
> kevin
> ___
> rel-eng mailing list -- rel-...@lists.fedoraproject.org
> To unsubscribe send an email to rel-eng-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/rel-...@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Clement Verna]

On Tue, 14 Apr 2020 at 16:38, Pierre-Yves Chibon 
wrote:

> On Tue, Apr 14, 2020 at 04:03:59PM +0200, Clement Verna wrote:
> >On Tue, 14 Apr 2020 at 14:33, Pierre-Yves Chibon <[1]
> pin...@pingoured.fr>
> >wrote:
> >
> >  Good Morning,
> >
> >  While working on [2]
> https://pagure.io/fedora-infrastructure/issue/8035
> >  to help
> >  Kevin I ended up adding the following commit to the proxies and
> running
> >  the
> >  proxy playbook for it:
> >
> >  commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
> >  Author: Pierre-Yves Chibon <[3]pin...@pingoured.fr>
> >  Date:   Tue Apr 14 11:25:17 2020 +0200
> >
> >  proxies-website: Add kerneltest to the proxies
> >
> >  Signed-off-by: Pierre-Yves Chibon <[4]pin...@pingoured.fr>
> >
> >  diff --git a/playbooks/include/proxies-websites.yml
> >  b/playbooks/include/proxies-websites.yml
> >  index a18f7a3a3..5159ecdff 100644
> >  --- a/playbooks/include/proxies-websites.yml
> >  +++ b/playbooks/include/proxies-websites.yml
> >  @@ -996,6 +996,13 @@
> >   cert_name: "{{wildcard_cert_name}}"
> >   tags: calendar
> >
> >  +  - role: httpd/website
> >  +site_name: [5]kerneltest.fedoraproject.org
> >  +sslonly: true
> >  +server_aliases: [[6]kerneltest.stg.fedoraproject.org]
> >  +cert_name: "{{wildcard_cert_name}}"
> >  +tags: kerneltest
> >  +
> >   # fedorahosted is retired. We have the site here so we can
> redirect it.
> >
> > - role: httpd/website
> >
> >  I had totally forgot proxies were frozen, so my apologies for
> pushing
> >  this
> >  through and I'd like to ask for a post-fact FBR.
> >
> >  With this I got kerneltest mostly working expect that it doesn't
> send
> >  back the
> >  expected html page.
> >  Clément took a look at it and pointed me to the reverse proxy which
> >  haven't been
> >  configured for kerneltest.
> >  So I'd like to apply the following patch and run the corresponding
> >  playbook
> >
> >I think there is a copy/paste error, the commit below is the same as
> the
> >one above :-)
>
> Indeed, here is the correct one:
>
> commit ad1224c3f09d75f02362e721110a565676575e99 (HEAD -> master)
> Author: Pierre-Yves Chibon 
> Date:   Tue Apr 14 14:19:30 2020 +0200
>
> proxies: add kerneltest.fp.o reverse proxy so it points to openshift
>
> Signed-off-by: Pierre-Yves Chibon 
>
> diff --git a/playbooks/include/proxies-reverseproxy.yml
> b/playbooks/include/proxies-reverseproxy.yml
> index dd80b5e34..1bb5cf87a 100644
> --- a/playbooks/include/proxies-reverseproxy.yml
> +++ b/playbooks/include/proxies-reverseproxy.yml
> @@ -234,6 +234,15 @@
>  balancer_name: app-os
>  targettype: openshift
>  keephost: true
> +
> +  - role: httpd/reverseproxy
> +website: kerneltest.fedoraproject.org
> +destname: kerneltest
> +balancer_name: app-os
> +targettype: openshift
> +keephost: true
> +tags: kerneltest
> +header_scheme: true
>

I think this was from the previous block, so the block should be added
after that :)

>  when: env == "staging"
>
   - role: httpd/reverseproxy
>
>
one small thing to fix, but +1 from me.


>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

ansible playbook to create koji tags

[Clement Verna]

Hi all,

I have been playing a little bit around with the koji-ansible collection
and created a Proof of Concept playbook that creates the main tags for a
release in koji (staging).

I have installed the collection on batcave01 running the following

```
ansible-galaxy collection install
ktdreyer.koji_ansible:0.0.0-git.274+c448a960
```

And the playbook is available under
playbooks/manual/releng/koji-release-tags.yml [0]. For now there is still
very much a lot of things hard coded, but that should give us a good idea
of what we can do with that collection.

Members of the sysadmin-main group can try the playbook by running

```
ansible-playbook
/srv/web/infra/ansible/playbooks/manual/releng/koji-release-tags.yml --check
```

For now it is executed on `composer.stg.phx2.fedoraproject.org` and it is
using this host keytab to authenticate with koji.

I ll keep working on this and see if I can turn it in a role that could be
used to create all the tags for each release, in the mean time if you have
ideas or feedback please share them with me :-).

[0] -
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/manual/releng/koji-release-tags.yml
___
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] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Clement Verna]

On Tue, 14 Apr 2020 at 14:33, Pierre-Yves Chibon 
wrote:

> Good Morning,
>
> While working on https://pagure.io/fedora-infrastructure/issue/8035 to
> help
> Kevin I ended up adding the following commit to the proxies and running the
> proxy playbook for it:
>
> commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
> Author: Pierre-Yves Chibon 
> Date:   Tue Apr 14 11:25:17 2020 +0200
>
> proxies-website: Add kerneltest to the proxies
>
> Signed-off-by: Pierre-Yves Chibon 
>
> diff --git a/playbooks/include/proxies-websites.yml
> b/playbooks/include/proxies-websites.yml
> index a18f7a3a3..5159ecdff 100644
> --- a/playbooks/include/proxies-websites.yml
> +++ b/playbooks/include/proxies-websites.yml
> @@ -996,6 +996,13 @@
>  cert_name: "{{wildcard_cert_name}}"
>  tags: calendar
>
> +  - role: httpd/website
> +site_name: kerneltest.fedoraproject.org
> +sslonly: true
> +server_aliases: [kerneltest.stg.fedoraproject.org]
> +cert_name: "{{wildcard_cert_name}}"
> +tags: kerneltest
> +
>  # fedorahosted is retired. We have the site here so we can redirect it.
>
>- role: httpd/website
>
>
> I had totally forgot proxies were frozen, so my apologies for pushing this
> through and I'd like to ask for a post-fact FBR.
>
> With this I got kerneltest mostly working expect that it doesn't send back
> the
> expected html page.
> Clément took a look at it and pointed me to the reverse proxy which
> haven't been
> configured for kerneltest.
> So I'd like to apply the following patch and run the corresponding playbook
>

I think there is a copy/paste error, the commit below is the same as the
one above :-)

>
> commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
> Author: Pierre-Yves Chibon 
> Date:   Tue Apr 14 11:25:17 2020 +0200
>
> proxies-website: Add kerneltest to the proxies
>
> Signed-off-by: Pierre-Yves Chibon 
>
> diff --git a/playbooks/include/proxies-websites.yml
> b/playbooks/include/proxies-websites.yml
> index a18f7a3a3..5159ecdff 100644
> --- a/playbooks/include/proxies-websites.yml
> +++ b/playbooks/include/proxies-websites.yml
> @@ -996,6 +996,13 @@
>  cert_name: "{{wildcard_cert_name}}"
>  tags: calendar
>
> +  - role: httpd/website
> +site_name: kerneltest.fedoraproject.org
> +sslonly: true
> +server_aliases: [kerneltest.stg.fedoraproject.org]
> +cert_name: "{{wildcard_cert_name}}"
> +tags: kerneltest
> +
>  # fedorahosted is retired. We have the site here so we can redirect it.
>
>- role: httpd/website
>
> +1s?
>
>
> Thanks,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Big patch to dhcpd to move all mgmt interfaces to dhcp for move

[Clement Verna]

On Fri, 10 Apr 2020 at 23:33, Kevin Fenzi  wrote:

> On Fri, Apr 10, 2020 at 05:12:53PM -0400, Stephen John Smoogen wrote:
> > Kevin and I found all the mac addresses for the mgmt boxes and are
> putting
> > them onto dhcp so when they show up in new location.. they should come up
> > without trying to use 'dead' networks.
>
> There's a lot of whitespace changes too, but they seemed ok for the most
> part. Once we do move things we will need to also make sure we set all
> of them to use grub instead od pxelinux, but that does not need to be
> now.
>
> +1
>

Gave it a look and it looked sane to me :-)

+1


>
> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
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 Apr 06 2020

[Clement Verna]

On Wed, 8 Apr 2020 at 11:13, Michal Konecny  wrote:

> Went through the list and added my 2c to them.
>
> Michal
>
> On 07/04/2020 14:42, Clement Verna wrote:
>
> Hi all,
>
> Let's look at 5 tickets and rate them using the following categories :
> * low-trouble, medium-trouble, high-trouble
> * low-gain, medium-gain, high-gain
>
> #8729 Do we want to have a copy of translate.fp.o backups? -
> https://pagure.io/fedora-infrastructure/issue/8729
> Trouble : medium
> Gain : high
>
> This is something we should definitely do. With the BorgBackup support in
> Weblate I don't think it will be that much trouble to do it.
>
+1

>
> #8693 Please create `@copr-team` src.f.o group -
> https://pagure.io/fedora-infrastructure/issue/8693
> Trouble: medium
> Gain: high
>
>
> This is definitely something that will help COPR team to automate things
> and I think we should encourage automating things in Fedora. But looking at
> the discussion I'm not sure if this could be solved easily.
>
+1

>
> #8600 All maintainers should be removed from retired packages eventually.
> - https://pagure.io/fedora-infrastructure/issue/8600
> Trouble: medium
> Gain: low
>
> According to smooge's lasts comment this should be discussed with FESCO
> first. We should switch this to state "waiting for reply" or something
> similar. I propose to ping vondruch and if nothing happens just close it.
>

Yeah not sure what to do with this ticket :(

>
> #8481 Cannot subscribe to the ocaml-devel mailing list via hyperkitty, get
> a webserver error - https://pagure.io/fedora-infrastructure/issue/8481
> Trouble: medium
> Gain: low
>
> This looks like wrong redirection to postorius and indeed there is no
> ocaml-devel list in postorius. Shouldn't this be synchronized or is this
> list just gone and the hyperkitty has it for archivation?
>
+1 on this too

>
> #8370 Fedora CoreOS + multi-arch -
> https://pagure.io/fedora-infrastructure/issue/8370
> Trouble: medium
> Gain: medium
>
> If I'm not mistaken this is now waiting for the word from Fedora CoreOS
> team to say when they want the hardware. I think we should just ping the
> dustymabe on this. I will go with medium gain for this, because this will
> be helpful for CoreOS and OSBS as well.
>

I think this as the potential for a mini initiative and should probably be
sent in Aoife's way.

>
> Thanks all
>
> ___
> 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
>
>
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Weekly Backlog Refinement - Week Apr 06 2020

[Clement Verna]

Hi all,

Let's look at 5 tickets and rate them using the following categories :
* low-trouble, medium-trouble, high-trouble
* low-gain, medium-gain, high-gain

#8729 Do we want to have a copy of translate.fp.o backups? -
https://pagure.io/fedora-infrastructure/issue/8729
Trouble : ?
Gain : ?

#8693 Please create `@copr-team` src.f.o group -
https://pagure.io/fedora-infrastructure/issue/8693
Trouble: ?
Gain: ?

#8600 All maintainers should be removed from retired packages eventually. -
https://pagure.io/fedora-infrastructure/issue/8600
Trouble: ?
Gain: ?

#8481 Cannot subscribe to the ocaml-devel mailing list via hyperkitty, get
a webserver error - https://pagure.io/fedora-infrastructure/issue/8481
Trouble: ?
Gain: ?

#8370 Fedora CoreOS + multi-arch -
https://pagure.io/fedora-infrastructure/issue/8370
Trouble: ?
Gain: ?

Thanks all
___
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

[Clement Verna]

On Mon, 6 Apr 2020 at 08:58, Timothée Floure 
wrote:

> Hi,
>
> > How does the indexing works ?
>
> You point Yacy to a domain or list of URLs
> (https://fnux.fedorapeople.org/pkgs/ in this case), and it takes care of
> everything. There is also an advanced crawler panel in the UI allowing
> you to filter content (e.g. HTML classes) from pages, which would be
> useful if we do not want to index everything (e.g. dependencies).
>
> I am not familiar with the maths used by Yacy for indexing.
>

Me neither :D

>
> > And what would it take to add more info for each package ?
>
> I wrote a quick script (https://paste.gnugen.ch/raw/4JAC) fetching
> package metadata from PDC+mdapi for testing, but it is ways too slow to
> scale to the whole package set.
>

Cool, yeah the current indexing takes hours (I think around 4-5 hours)
there are more than 80 000s packages and sub-packages. I think we can run
this once a day so speed is not super super critical I would say.

>
> MDAPI will have to be replaced by local SQLite to increase performance.
> I think we could generate most of the content from the repositories'
> metadata (last N Fedora + EPEL) but I need to find where the SQL files
> lives. A privileged endpoint to dist-get to fetch the package ->
> maintainer mapping bypassing pagination would be convenient.
>

You can look at how mdapi grabs these sqllite files (
https://pagure.io/mdapi/blob/master/f/mdapi-get_repo_md). For the
maintainer mapping you should be able to find that here -->
https://src.fedoraproject.org/extras/


> We can use Yacy's JSON API to build a sexy fedora-branded search page
> but I think it's a late-stage optimization.
>

+1, would be interesting to see with msuchy if that can be easily
integrated with the work he was doing.


> --
> Timothée
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

On Fri, 3 Apr 2020 at 09:18, Timothée Floure 
wrote:

> * Yacy (there might be others to test) running on communityshift:
> http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org
> * It's indexed against the 20 first PDC packages:
> https://fnux.fedorapeople.org/pkgs/
>
> * Example looking for 'disk encryption':
> http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysearch.html?auth==text=false=disk+encryption+%2Fdate=10=0=ifexist=local=location%2Chosts%2Cauthors%2Cnamespace%2Ctopics%2Cfiletype%2Cprotocol%2Clanguage==0==5=-120=disk+encryption


Hi Timothée, the above link is asking for a username password, but I was
able to play around using the first url you provided. I think Yacy can be a
cool solution to offer a search service for packages, in particular using
the JSON api[0] so anyone could use this service and build some cool
application if they wanted too.

How does the indexing works ? And what would it take to add more info for
each package ?

[0] -
http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysearch.json?query=atomic

>
>
> Looks good so far. I'm curious how relevant/fast the search would be
> against 40K packages and ways more details.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

On Wed, 1 Apr 2020 at 23:20, Timothée Floure 
wrote:

> Hi,
>
> Jumping in since I saw this at the top of the web list archive. This
> service is very convenient and I think it would be fairly painful for
> the community to see it disappear. Since we do not have the capacity to
> develop + maintain new software, I wonder if the following 'low-tech'
> approach could work:
>
> * Generate a static page for each package.
> * Crawl/Index it with existing search solution such as Yacy [1]
>

I think it is an interesting idea, I don't know about Yacy but I think
doing a simple proof-of-concept with maybe a few packages could be
interesting.


>
> We could even extend this search thing to more Fedora websites if it
> performs well. I think it might be worth a proof-of-concept, which I can
> try to build if you're willing to allocate me some server/VM space for
> testing :-)
>

If you are happy with having something running in containers, you can ask
to get access to communishift [0] but mind that this will be offline for a
little while in the coming months because of the data centre move.
Otherwise I think we could get you instance on AWS probably. Either way if
you open an infra ticket [1] with what you need or want we can then look at
possible solutions :-).


[0] - https://fedoraproject.org/wiki/Infrastructure/Communishift
[1] - https://pagure.io/fedora-infrastructure

>
> [1] https://yacy.net/
>
> --
> Timothée
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

On Mon, 30 Mar 2020 at 14:00, Miroslav Suchý  wrote:

> Dne 28. 03. 20 v 1:09 Kevin Fenzi napsal(a):
> > Hey, any news on this? I guess the problem is as always time.
> >
> > How far along is it? Could we run a demo/dev version in communishift?
>
> Yes. Time :(
> I have this as huge debt. I will try to prepare something.
>
> But still I have "just" the page which shows the package detail. @clement
> how is the search code doing? I said you will
> migrate that part.
>

Yeah I did not have time to look at this, a while back I started
fedora-search [0] to look at using Postgresql full text search capabilities
but that seemed quite slow compared to what we have with Xapian. One
possible quick way forward would be to extract the code that does the
indexing and search from the current packages app and give it as simple
search endpoint. While I honestly don't think I will be able to lead that
effort, if anyone is interested in working on this I ll be more than happy
to help with getting started.


[0] - https://github.com/fedora-infra/fedora-search

>
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Bodhi 5.2.0 deployed in production.

[Clement Verna]

On Mon, 23 Mar 2020 at 15:33, Clement Verna 
wrote:

>
>
> On Mon, 23 Mar 2020 at 10:39, Igor Gnatenko <
> ignatenkobr...@fedoraproject.org> wrote:
>
>> Hello Clement,
>>
>> On Mon, Mar 23, 2020 at 10:30 AM Clement Verna 
>> wrote:
>> >
>> > Hi all,
>> >
>> > I have just deployed Bodhi 5.2.0 in production. This version should
>> improve the performance of updates creation since the expansive task of
>> tagging builds in koji has been moved to an async process using a celery
>> workers.
>> > Also this version will also allow the use of side-tags to all releases
>> (ie not limited to rawhide anymore).
>>
>> I'll test this ASAP.
>>
>
> Ok we seems to have a problem with tagging side-tag updates, I am working
> on a fix :-).
>

I have just deployed bodhi 5.2.1 to fix the issue, so creating updates from
side-tag should work again :-)


>
>
>> > For a more detail view of the changes you can consult the release notes
>> [0].
>> >
>> > I would like to thanks everyone that has contributed to this release
>> [1].
>> >
>> > Thanks
>> > Clément
>> >
>> > [0] - https://bodhi.fedoraproject.org/docs/user/release_notes.html
>> > [1] -
>> https://bodhi.fedoraproject.org/docs/user/release_notes.html#contributors
>> > ___
>> > devel mailing list -- de...@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org
>> ___
>> devel mailing list -- de...@lists.fedoraproject.org
>> To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org
>>
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Bodhi 5.2.0 deployed in production.

[Clement Verna]

On Mon, 23 Mar 2020 at 10:39, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Hello Clement,
>
> On Mon, Mar 23, 2020 at 10:30 AM Clement Verna 
> wrote:
> >
> > Hi all,
> >
> > I have just deployed Bodhi 5.2.0 in production. This version should
> improve the performance of updates creation since the expansive task of
> tagging builds in koji has been moved to an async process using a celery
> workers.
> > Also this version will also allow the use of side-tags to all releases
> (ie not limited to rawhide anymore).
>
> I'll test this ASAP.
>

Ok we seems to have a problem with tagging side-tag updates, I am working
on a fix :-).


> > For a more detail view of the changes you can consult the release notes
> [0].
> >
> > I would like to thanks everyone that has contributed to this release [1].
> >
> > Thanks
> > Clément
> >
> > [0] - https://bodhi.fedoraproject.org/docs/user/release_notes.html
> > [1] -
> https://bodhi.fedoraproject.org/docs/user/release_notes.html#contributors
> > ___
> > devel mailing list -- de...@lists.fedoraproject.org
> > To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Bodhi 5.2.0 deployed in production.

[Clement Verna]

Hi all,

I have just deployed Bodhi 5.2.0 in production. This version should improve
the performance of updates creation since the expansive task of tagging
builds in koji has been moved to an async process using a celery workers.
Also this version will also allow the use of side-tags to all releases (ie
not limited to rawhide anymore).

For a more detail view of the changes you can consult the release notes [0].

I would like to thanks everyone that has contributed to this release [1].

Thanks
Clément

[0] - https://bodhi.fedoraproject.org/docs/user/release_notes.html
[1] -
https://bodhi.fedoraproject.org/docs/user/release_notes.html#contributors
___
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

Weekly Backlog Refinement - Week Mar 16 2020

[Clement Verna]

Hi all,

Let's look at 5 tickets and rate them using the following categories :
* low-trouble, medium-trouble, high-trouble
* low-gain, medium-gain, high-gain

#6441 Monitoring the worker's queue of pagure -
https://pagure.io/fedora-infrastructure/issue/6441
Trouble : ?
Gain : ?

#6801 run hardlink on fedora-secondary -
https://pagure.io/fedora-infrastructure/issue/6801
Trouble : ?
Gain : ?

#7294 Add GDPR script for release-monitoring.org -
https://pagure.io/fedora-infrastructure/issue/7294
Trouble : ?
Gain : ?

 #7377 SSH keys length can prevent user from login in Fedora infrastructure
- https://pagure.io/fedora-infrastructure/issue/7377
Trouble : ?
Gain : ?

#7603 Problem with package-owner-aliases cron script on bastion servers -
https://pagure.io/fedora-infrastructure/issue/7603
Trouble : ?
Gain : ?

Let's use this thread to ask questions and clarifications if needed.

Thanks
Clément
___
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

[Clement Verna]

Thanks all for your inputs and comments, this was really useful .

I have tagged these issues based on the feedback received, you can see all
the issues with at least one of these tags using this link [0]

[0] -
https://pagure.io/fedora-infrastructure/issues?status=Open=high-trouble=low-gain=high-gain=medium-gain=medium-trouble=low-trouble=0_status=

On Mon, 9 Mar 2020 at 14:47, Clement Verna  wrote:

> Hi all,
>
> This is the first email with trying to better prioritize our backlog of
> ticket ( https://pagure.io/fedora-infrastructure/issues ).
>
> 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 : ?
> Gain : ?
>
> #8167 Adding topic authorization to our RabbitMQ instances -
> https://pagure.io/fedora-infrastructure/issue/8167
> Trouble : ?
> Gain : ?
>
> #8035 A few final ansible secrets for kerneltest -
> https://pagure.io/fedora-infrastructure/issue/8035
> Trouble : ?
> Gain : ?
>
> #7935 Nightlies (Rawhide and Branched) not imported to PDC -
> https://pagure.io/fedora-infrastructure/issue/7935
> Trouble : ?
> Gain : ?
>
> #7919 Fix fas fedmsg sending in openshift -
> https://pagure.io/fedora-infrastructure/issue/7919
> Trouble : ?
> Gain : ?
>
>
> 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 :-).
>
>
> Thanks
> Clément
>
___
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

[Clement Verna]

On Tue, 10 Mar 2020 at 02:45, Adam Williamson 
wrote:

> On Mon, 2020-03-09 at 17:00 +0100, Michal Konecny wrote:
> > > #7935 Nightlies (Rawhide and Branched) not imported to PDC -
> > > https://pagure.io/fedora-infrastructure/issue/7935
> > This is too much trouble for low gain, we should direct our manpower to
> > FPDC instead.
>
> This seems like a false evaluation to me. Presumably when FPDC is done,
> it will be populated by transferring in data from PDC. Garbage (or non-
> existence) in, garbage (or non-existence) out - if a bunch of data that
> should be in PDC is missing, it is not going to magically turn up when
> FPDC is deployed.
>

It is not clear yet how or when FPDC will be done (There is currently no
work happening on the replacement of PDC). The little work I did was to
look at the releng use cases and try to identify how we could use another
service to get the data we currently get from PDC which are mainly
information about component branches and state of releases. So we need to
also look at the other use cases of PDC and look at possible alternatives
that does not involved yet another application developed  by the Fedora
Community for example something like Kinto (https://github.com/Kinto/kinto)
might be a good fit.



> As noted in
> https://pagure.io/fedora-infrastructure/issue/7935#comment-631920 ,
> the last two official stable Fedora releases were not imported to PDC.
> That's pretty important archival information we're missing.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] rabbitmq: adjust things to avoid messy partitions

[Clement Verna]

+1

On Thu, 12 Mar 2020 at 20:40, Kevin Fenzi  wrote:

> We have been having the cluster fall over for still unknown reasons,
> but this patch should at least help prevent them:
>
> first we increase the net_ticktime parameter from it's default of 60 to
> 120.
> rabbitmq sends 4 'ticks' to other cluster members over this time and if 25%
> of them are lost it assumes that cluster member is down. All these vm's are
> on the same net and in the same datacenter, but perhaps heavy load
> from other vm's causes them to sometimes not get a tick in time?
> http://www.rabbitmq.com/nettick.html
>
> Also, set our partitioning strategy to autoheal. Currently if some cluster
> member gets booted out, it gets paused, and stops processing at all.
> With autoheal it will try and figure out a 'winning' partition and restart
> all the nodes that are not in that partition.
> https://www.rabbitmq.com/partitions.html
>
> Hopefully the first thing will make partitions less likely and the second
> will make them repair without causing massive pain to the cluster.
>
> Signed-off-by: Kevin Fenzi 
> ---
>  roles/rabbitmq_cluster/templates/rabbitmq.config | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/roles/rabbitmq_cluster/templates/rabbitmq.config
> b/roles/rabbitmq_cluster/templates/rabbitmq.config
> index 5c38dbd..82dd444 100644
> --- a/roles/rabbitmq_cluster/templates/rabbitmq.config
> +++ b/roles/rabbitmq_cluster/templates/rabbitmq.config
> @@ -21,7 +21,7 @@
>
> %% How to respond to cluster partitions.
> %% Documentation: https://www.rabbitmq.com/partitions.html
> -   {cluster_partition_handling, pause_minority},
> +   {cluster_partition_handling, autoheal},
>
> %% And some general config
> {log_levels, [{connection, none}]},
> @@ -29,9 +29,7 @@
> {heartbeat, 600},
> {channel_max, 128}
>]},
> - {kernel,
> -  [
> -  ]},
> + {kernel, [{net_ticktime,  120}]},
>   {rabbitmq_management,
>[
> {listener, [{port, 15672},
> --
> 1.8.3.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Freeze Break Request: s3-mirror adjustments

[Clement Verna]

+1 too

On Mon, 9 Mar 2020 at 17:00, Stephen John Smoogen  wrote:

>
> +1
>
> On Sat, 7 Mar 2020 at 05:17, Adrian Reber  wrote:
>
>> Looks correct from my point of view, for both scripts we are now doing:
>>
>> 1. sync everything besides repodata
>> 2. sync everything including (or only) repodata
>> 3. invalidate repodata
>> 4. delete files
>>
>> The only problem I can see now is that the files on the master are
>> changing between those steps. Not sure how often the master is updated,
>> but probably not more often than once or twice a day, right?
>>
>> In theory this should help with the problems we have been seeing in
>> COPR.
>>
>> +1
>>
>> Adrian
>>
>> On Fri, Mar 06, 2020 at 02:04:21PM -0800, Kevin Fenzi wrote:
>> > Final version? You be the judge. :)
>> >
>> > kevin
>> > --
>>
>> > From bd3c100e3a5fdd453ebbd4b88cc3bba365d260c3 Mon Sep 17 00:00:00 2001
>> > From: Kevin Fenzi 
>> > Date: Thu, 5 Mar 2020 20:46:53 +
>> > Subject: [PATCH] s3-mirror: Split things into 2 sync runs, one without
>> >  repodata and delete, the other with both.
>> >
>> > In order to make sure the s3 mirror always is consistent, split out the
>> commands
>> > to make it sync without repodata and delete, then do another run with
>> those, then finally
>> > invalidate all the repodata/* files.
>> >
>> > Some of the cron jobs are adjusted to allow the repodata invalidation.
>> >
>> > Signed-off-by: Kevin Fenzi 
>> > ---
>> >  roles/s3-mirror/files/s3-sync-path.sh |  42 +
>> >  roles/s3-mirror/files/s3.sh   | 114
>> --
>> >  roles/s3-mirror/tasks/main.yml|   4 +-
>> >  3 files changed, 140 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/roles/s3-mirror/files/s3-sync-path.sh
>> b/roles/s3-mirror/files/s3-sync-path.sh
>> > index e6ac994..79b4d63 100644
>> > --- a/roles/s3-mirror/files/s3-sync-path.sh
>> > +++ b/roles/s3-mirror/files/s3-sync-path.sh
>> > @@ -9,7 +9,30 @@ if [[ "$1" == "" ]] || [[ $1 != /pub* ]] || [[ $1 !=
>> */ ]]; then
>> >exit 1
>> >  fi
>> >
>> > -CMD="aws s3 sync   \
>> > +# first run do not delete anything or copy the repodata.
>> > +CMD1="aws s3 sync   \
>> > +  --exclude */repodata/* \
>> > +  --exclude *.snapshot/*  \
>> > +  --exclude *source/* \
>> > +  --exclude *SRPMS/*  \
>> > +  --exclude *debug/*  \
>> > +  --exclude *beta/*   \
>> > +  --exclude *ppc/*\
>> > +  --exclude *ppc64/*  \
>> > +  --exclude *repoview/*   \
>> > +  --exclude *Fedora/* \
>> > +  --exclude *EFI/*\
>> > +  --exclude *core/*   \
>> > +  --exclude *extras/* \
>> > +  --exclude *LiveOS/* \
>> > +  --exclude *development/rawhide/* \
>> > +  --no-follow-symlinks\
>> > +  --only-show-errors  \
>> > +  "
>> > +  #--dryrun \
>> > +
>> > +# second we delete old content and also copy the repodata
>> > +CMD2="aws s3 sync   \
>> >--delete \
>> >--exclude *.snapshot/*  \
>> >--exclude *source/* \
>> > @@ -32,19 +55,12 @@ CMD="aws s3 sync   \
>> >
>> >  #echo "$CMD /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1"
>> >  echo "Starting $1 sync at $(date)" >> /var/log/s3-mirror/timestamps
>> > -$CMD /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1
>> > -echo "Ending $1 sync at $(date)" >> /var/log/s3-mirror/timestamps
>> > -
>> > +$CMD1 /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1
>> > +$CMD1 /srv$1/repodata/ s3://s3-mirror-us-west-1-02.fedoraproject.org
>> $1/repodata/
>> >  # Always do the invalidations because they are quick and prevent issues
>> >  # depending on which path is synced.
>> > -for file in $(echo /srv/pub/epel/6/*/repodata/repomd.xml | sed
>> 's#/srv##g'); do
>> > -  aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU
>> --paths "$file" > /dev/null
>> > -done
>> > -
>> > -for file in $(echo /srv/pub/epel/7/*/repodata/repomd.xml | sed
>> 's#/srv##g'); do
>> > -  aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU
>> --paths "$file" > /dev/null
>> > -done
>> > -
>> > -for file in $(echo
>> /srv/pub/fedora/linux/updates/*/*/*/repodata/repomd.xml | sed 's#/srv##g');
>> do
>> > +for file in $(echo $1/repodata/* ); do
>> >aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU
>> --paths "$file" > /dev/null
>> >  done
>> > +$CMD2 /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1
>> > +echo "Ending $1 sync at $(date)" >> /var/log/s3-mirror/timestamps
>> > diff --git a/roles/s3-mirror/files/s3.sh b/roles/s3-mirror/files/s3.sh
>> > index 55c1940..c70defb 100644
>> > --- a/roles/s3-mirror/files/s3.sh
>> > +++ b/roles/s3-mirror/files/s3.sh
>> > @@ -3,8 +3,10 @@
>> >  # LGPL
>> >  # Author: Rick Elrod 
>> >
>> > -CMD="aws s3 sync   \

Weekly Backlog Refinement - Week Mar 09 2020

[Clement Verna]

Hi all,

This is the first email with trying to better prioritize our backlog of
ticket ( https://pagure.io/fedora-infrastructure/issues ).

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 : ?
Gain : ?

#8167 Adding topic authorization to our RabbitMQ instances -
https://pagure.io/fedora-infrastructure/issue/8167
Trouble : ?
Gain : ?

#8035 A few final ansible secrets for kerneltest -
https://pagure.io/fedora-infrastructure/issue/8035
Trouble : ?
Gain : ?

#7935 Nightlies (Rawhide and Branched) not imported to PDC -
https://pagure.io/fedora-infrastructure/issue/7935
Trouble : ?
Gain : ?

#7919 Fix fas fedmsg sending in openshift -
https://pagure.io/fedora-infrastructure/issue/7919
Trouble : ?
Gain : ?


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


Thanks
Clément
___
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: Prioritization of tickets and infra work

[Clement Verna]

On Fri, 6 Mar 2020 at 23:20, Kevin Fenzi  wrote:

> On Wed, Mar 04, 2020 at 04:42:12PM +0100, Clement Verna wrote:
> > Hi all,
> >
> > Last week during our weekly meeting we have discuss trying to better
> > prioritize our work and tickets. In order to do that we are going to try
> to
> > use a "yummy vs trouble" [1] index and use a prioritization matrix [0] to
> > order our work.
> > Yummy representing the added value or benefit of a task and Trouble
> > representing how much effort it would take to complete the task. Each
> > property being either small, medium or large.
> >
> > Starting this week, I ll send a email with a list of 5 tickets from our
> > backlog [1], asking opinions about each tickets yummy and trouble level.
> We
> > can use this weekly email to ask questions or provide more context. We
> will
> > then update these tickets with the outcome of the discussion, in case of
> > strong disagreement we can use our weekly IRC meeting to make decision.
> >
> > This will hopefully help us focus on items that provides a high value to
> > our community and also provide a way for everyone to participate in this
> > prioritization.
>
> Sounds good.
>
> For things on pagure at least, the best way I can see to codify this is
> to make some more tags (yeah, I know we have a bunch already).
>
> Something like:
>
> low-trouble
> med-trouble
> high-trouble
> low-gain
> med-gain
> high-gain
>

> Then, we tag the things we discussed and can search on tags:
>
> low-trouble + high-gain -> do these first
> high-trouble + low-gaiin -> try and see if we can WONTFIX these
> etc.
>

Sounds good to me :-)


> 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
>
___
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 pungi configs of F32 for kickstarts

[Clement Verna]

On Fri, 6 Mar 2020 at 17:10, Mohan Boddu  wrote:

> Hi,
>
> Current pungi configs are using kickstarts from master branch, instead
> they should use f32 branch.
>
> This should be fixed by:
>
> https://pagure.io/pungi-fedora/pull-request/812
>
> Look at the last change which is this FBR is totally about.
>

+1

>
> Thanks,
> Mohan Boddu.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] s3-mirror: Run crons to sync s3 mirror a lot more often

[Clement Verna]

+1

On Thu, 5 Mar 2020 at 01:00, Kevin Fenzi  wrote:

> We have been getting complaints from copr users that they are hitting
> out of date cloudfront cached data when they are doing builds.
> We are syncing not all that often currently, and sometimes if a updates
> push or rawhide compose finishes after the sync time it coud be a long
> while before it picks up on it. So, since most of these jobs finish in
> 5-10min when there is nothing to sync, just have them all run every 15min
> or so. If this starts hitting locking too much we can spread them back out
> once we get a sense of when they are hitting that.
>
> Additionally, we should just set them up to only sync when their particular
> thing has finished. This would make it a lot more sane, but require a
> redesign/rewrite.
>
> Amended to use the old values for test releases.
>
> Signed-off-by: Kevin Fenzi 
> ---
>  roles/s3-mirror/tasks/main.yml | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/roles/s3-mirror/tasks/main.yml
> b/roles/s3-mirror/tasks/main.yml
> index 12351cb..075785e 100644
> --- a/roles/s3-mirror/tasks/main.yml
> +++ b/roles/s3-mirror/tasks/main.yml
> @@ -68,7 +68,7 @@
>- s3-mirror
>
>  - name: s3sync cron - updates for current
> -  cron: name="s3sync-updates-current" minute="0" hour="3,9,15,21"
> user="s3-mirror"
> +  cron: name="s3sync-updates-current" minute="2,17,32,47" user="s3-mirror"
>  job='/usr/local/bin/lock-wrapper s3sync-updates-current
> "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{
> FedoraCycleNumber|int }}/" 2>&1 | /usr/local/bin/nag-once
> s3-updates-current.sh 1d 2>&1'
>  cron_file=s3-updates-current.sh
>when: env != 'staging' and
> inventory_hostname.startswith('mm-backend01.')
> @@ -76,7 +76,7 @@
>- s3-mirror
>
>  - name: s3sync cron - updates for development/current+1 x86_64
> -  cron: name="s3sync-updates-current" minute="0" hour="2,7,10"
> user="s3-mirror"
> +  cron: name="s3sync-updates-current" minute="3,18,33,48" user="s3-mirror"
>  job='/usr/local/bin/lock-wrapper
> s3sync-updates-dev-cur-plus-1-x86_64 "/usr/local/bin/s3-sync-path.sh
> /pub/fedora/linux/development/{{ FedoraCycleNumber|int + 1
> }}/Everything/x86_64/os/" 2>&1 | /usr/local/bin/nag-once
> s3-updates-dev-cur-plus-1-x86_64.sh 1d 2>&1'
>  cron_file=s3-updates-dev-cur-plus-1-x86_64.sh
>  disabled={{not FedoraBranched|bool}}
> @@ -85,7 +85,7 @@
>- s3-mirror
>
>  - name: s3sync cron - updates for development/current+1 aarch64
> -  cron: name="s3sync-updates-current" minute="0" hour="4,11,18"
> user="s3-mirror"
> +  cron: name="s3sync-updates-current" minute="4,19,34,49" user="s3-mirror"
>  job='/usr/local/bin/lock-wrapper
> s3sync-updates-dev-cur-plus-1-aarch64 "/usr/local/bin/s3-sync-path.sh
> /pub/fedora/linux/development/{{ FedoraCycleNumber|int + 1
> }}/Everything/aarch64/os/" 2>&1 | /usr/local/bin/nag-once
> s3-updates-dev-cur-plus-1-aarch64.sh 1d 2>&1'
>  cron_file=s3-updates-dev-cur-plus-1-aarch64.sh
>  disabled={{not FedoraBranched|bool}}
> @@ -94,7 +94,7 @@
>- s3-mirror
>
>  - name: s3sync cron - updates for current-1
> -  cron: name="s3sync-updates-previous" minute="30" hour="0,6,12,18"
> user="s3-mirror"
> +  cron: name="s3sync-updates-previous" minute="5,20,35,50"
> user="s3-mirror"
>  job='/usr/local/bin/lock-wrapper s3sync-updates-previous
> "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{
> FedoraCycleNumber|int - 1 }}/" 2>&1 | /usr/local/bin/nag-once
> s3-updates-previous.sh 1d 2>&1'
>  cron_file=s3-updates-previous.sh
>when: env != 'staging' and
> inventory_hostname.startswith('mm-backend01.')
> @@ -102,7 +102,7 @@
>- s3-mirror
>
>  - name: s3sync cron - epel 7 x86_64
> -  cron: name="s3sync-epel7-x86_64" minute="10"
> hour="2,5,8,11,14,17,20,23" user="s3-mirror"
> +  cron: name="s3sync-epel7-x86_64" minute="6,21,36,51" user="s3-mirror"
>  job='/usr/local/bin/lock-wrapper s3sync-epel7-x86_64
> "/usr/local/bin/s3-sync-path.sh /pub/epel/7/x86_64/" 2>&1 |
> /usr/local/bin/nag-once s3-epel7-x86_64.sh 1d 2>&1'
>  cron_file=s3-epel7-x86_64.sh
>when: env != 'staging' and
> inventory_hostname.startswith('mm-backend01.')
> @@ -110,7 +110,7 @@
>- s3-mirror
>
>  - name: s3sync cron - epel 7 aarch64
> -  cron: name="s3sync-epel7-aarch64" minute="20" hour="4,7,10,13,16,19,22"
> user="s3-mirror"
> +  cron: name="s3sync-epel7-aarch64" minute="7,22,37,52" user="s3-mirror"
>  job='/usr/local/bin/lock-wrapper s3sync-epel7-aarch64
> "/usr/local/bin/s3-sync-path.sh /pub/epel/7/aarch64/" 2>&1 |
> /usr/local/bin/nag-once s3-epel7-aarch64.sh 1d 2>&1'
>  cron_file=s3-epel7-aarch64.sh
>when: env != 'staging' and
> inventory_hostname.startswith('mm-backend01.')
> @@ -118,7 +118,7 @@
>- s3-mirror
>
>  - name: s3sync cron - epel 8 Everything x86_64
> -  cron: name="s3sync-epel8-everything-x86_64" minute="43"
> 

Prioritization of tickets and infra work

[Clement Verna]

Hi all,

Last week during our weekly meeting we have discuss trying to better
prioritize our work and tickets. In order to do that we are going to try to
use a "yummy vs trouble" [1] index and use a prioritization matrix [0] to
order our work.
Yummy representing the added value or benefit of a task and Trouble
representing how much effort it would take to complete the task. Each
property being either small, medium or large.

Starting this week, I ll send a email with a list of 5 tickets from our
backlog [1], asking opinions about each tickets yummy and trouble level. We
can use this weekly email to ask questions or provide more context. We will
then update these tickets with the outcome of the discussion, in case of
strong disagreement we can use our weekly IRC meeting to make decision.

This will hopefully help us focus on items that provides a high value to
our community and also provide a way for everyone to participate in this
prioritization.


[0] - https://www.process.st/prioritization-matrix/
[1] -
https://pagure.io/fedora-infrastructure/issues?status=Open=backlog
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Freeze break request: koji autovacuum_freeze_max_age

[Clement Verna]

On Tue, 3 Mar 2020 at 22:39, Kevin Fenzi  wrote:

> And our lazyness and indecision pays off!
>
> The autovac is finally done and load should be back to normal.
>

Should we lower down the autovacuum max age ? so that next times it runs it
does not take that long ?


>
> I am going to re-enable backups.
>
> Thanks everyone.
>
> 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
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Freeze break request: koji autovacuum_freeze_max_age

[Clement Verna]

On Mon, 2 Mar 2020 at 18:53, Kevin Fenzi  wrote:

> On Mon, Mar 02, 2020 at 08:17:38AM -0800, Adam Williamson wrote:
> >
> > I'm fine with 1 or 2, but think we should definitely *not* do 3 unless
> > a) we know quite precisely how long it will take and b) that is
> > substantially faster than the online autovac.
>
> Yeah.
>
> Just as a status update, the auto vac has been running about 1.5 days so
> far. Things are slow, but there hasn't been a flood of complaints yet.
>

Should we try to bite the bullet ? since we are in freeze for F32 beta
there might also be less activity.

Is there any way to see some sort of progress ?


>
> Load on the db server is around 100 or so, when it's normally about 20
>
> I did disable backups last night because backups + this auto vac
> definitely make it unusable.
>
> 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
>
___
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

POST FBR : Bodhi XSS vulnerability

[Clement Verna]

Hi all,

An XSS vulnerability was reported against Bodhi, I have patched the staging
and production instances [0][1] until I get the fix upstream and deploy a
new release.

[0] -
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=9b1336960b307a2a81d6232f0ce40f40dfb0f83a
[1] -
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=1a901aba52a780328f48f7c271f6f84a5333b4f8

Thanks
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Add monitoring for website build fails

[Clement Verna]

On Thu, 27 Feb 2020 at 12:03, Rick Elrod  wrote:

> On Thu, Feb 27, 2020 at 4:31 AM Clement Verna 
> wrote:
> >
> >
> >
> > On Thu, 27 Feb 2020 at 06:53, Rick Elrod  wrote:
> >>
> >> I'd like to apply the following which does:
> >> - Adds a script I wrote for reading a timestamp from a file on disk
> >> and alerting if the timestamp within it is NOT within a particular
> >> delta to now.
> >> - Applies this to sundries01 and uses it to check
> >> /srv/websites/getfedora.org/build.timestamp.txt which now gets
> >> generated as part of the websites build.
> >>
> >> The purpose is because sometimes someone will commit something to the
> >> websites repo which breaks the build, but because of how we have
> >> things set up in openshift (cronjob), we don't get any kind of alert
> >> when that happens.
> >
> >
> > I think it would be better to find a way to monitor the cronjob in
> OpenShift since that will be useful for other projects.
> > Did you investigate that idea ?
> >
> >>
> >>
> >> Right now this sets the delta to 3 hours. In theory it should be 1,
> >> but I figure let it try to build a few times before we start alerting.
> >
> >
> > +1 but I would prefer a way to have notification on a failed cronjob :-)
>
> I'd prefer that too (or probably in addition), but I don't know
> anything about how to set up that monitoring right now.
> It looks like there's an OpenShift API endpoint for monitoring crons:
> https://major.io/2019/11/18/monitoring-openshift-cron-jobs/
> but we'd need to set up an API key for nagios checks to use somehow.
>

Yes I think we would need to have a "nagios" service account, then that
should give us a token to use for authentication.


> Probably worth looking into, but for the time being I'd still like to
> apply this FBR, as we are going to have some Outreachy activity
> happening on websites soon and we need to know that the prod build
> isn't broken.
>

> -re
>
> >
> >>
> >>
> >> Rick
> >>
> >>
> >> commit 657d050f6d699bc43973d968cd93d12131fca7f2
> >> Author: Rick Elrod 
> >> Date:   Thu Feb 27 05:29:24 2020 +
> >>
> >> nagios: Add script and check for checking that a timestamp within
> >> a file is within a delta of now, and then use this for alerting when
> >> websites stop building
> >>
> >> Signed-off-by: Rick Elrod 
> >>
> >> diff --git a/roles/nagios_client/files/scripts/check_timestamp_from_file
> >> b/roles/nagios_client/files/scripts/check_timestamp_from_file
> >> new file mode 100644
> >> index 000..9064337
> >> --- /dev/null
> >> +++ b/roles/nagios_client/files/scripts/check_timestamp_from_file
> >> @@ -0,0 +1,43 @@
> >> +#!/usr/bin/env python
> >> +
> >> +# Takes a path to a file and a delta. The file must simply contain an
> epoch
> >> +# timestamp. It can be an integer or a float, as can the delta.
> >> +#
> >> +# Alerts critical if (now - timestamp contained in file) > delta.
> >> +#
> >> +# Rick Elrod 
> >> +# MIT
> >> +
> >> +import sys
> >> +import time
> >> +
> >> +if len(sys.argv) != 3:
> >> +print('UNKNOWN: Pass path to file and delta as parameters')
> >> +sys.exit(3)
> >> +
> >> +filename = sys.argv[1]
> >> +delta = float(sys.argv[2])
> >> +
> >> +timestamp = None
> >> +
> >> +try:
> >> +with open(filename, 'r') as f:
> >> +timestamp = float(f.read().strip())
> >> +except Exception as e:
> >> +print('UNKNOWN: Unable to open/read file path')
> >> +sys.exit(3)
> >> +
> >> +difference = round(time.time() - timestamp, 2)
> >> +if difference > delta:
> >> +print(
> >> +'CRITICAL: Timestamp in file (%.2f) exceeds delta (%.2f) by
> >> %.2f seconds' % (
> >> +timestamp,
> >> +delta,
> >> +difference - delta))
> >> +sys.exit(2)
> >> +
> >> +print('OK: Timestamp in file (%.2f) is within delta (%.2f) of now, by
> >> %.2f seconds' % (
> >> +timestamp,
> >> +delta,
> >> +abs(difference - delta)))
> >> +sys.exit(0)
> >> diff --git a/roles/nagios_client/tasks/main.yml
> >> b/roles/nagios_client/tasks/main.yml
> >> index 2e5e0df..8e71a3b

Re: FBR: Add monitoring for website build fails

[Clement Verna]

On Thu, 27 Feb 2020 at 06:53, Rick Elrod  wrote:

> I'd like to apply the following which does:
> - Adds a script I wrote for reading a timestamp from a file on disk
> and alerting if the timestamp within it is NOT within a particular
> delta to now.
> - Applies this to sundries01 and uses it to check
> /srv/websites/getfedora.org/build.timestamp.txt which now gets
> generated as part of the websites build.
>
> The purpose is because sometimes someone will commit something to the
> websites repo which breaks the build, but because of how we have
> things set up in openshift (cronjob), we don't get any kind of alert
> when that happens.
>

I think it would be better to find a way to monitor the cronjob in
OpenShift since that will be useful for other projects.
Did you investigate that idea ?


>
> Right now this sets the delta to 3 hours. In theory it should be 1,
> but I figure let it try to build a few times before we start alerting.
>

+1 but I would prefer a way to have notification on a failed cronjob :-)


>
> Rick
>
>
> commit 657d050f6d699bc43973d968cd93d12131fca7f2
> Author: Rick Elrod 
> Date:   Thu Feb 27 05:29:24 2020 +
>
> nagios: Add script and check for checking that a timestamp within
> a file is within a delta of now, and then use this for alerting when
> websites stop building
>
> Signed-off-by: Rick Elrod 
>
> diff --git a/roles/nagios_client/files/scripts/check_timestamp_from_file
> b/roles/nagios_client/files/scripts/check_timestamp_from_file
> new file mode 100644
> index 000..9064337
> --- /dev/null
> +++ b/roles/nagios_client/files/scripts/check_timestamp_from_file
> @@ -0,0 +1,43 @@
> +#!/usr/bin/env python
> +
> +# Takes a path to a file and a delta. The file must simply contain an
> epoch
> +# timestamp. It can be an integer or a float, as can the delta.
> +#
> +# Alerts critical if (now - timestamp contained in file) > delta.
> +#
> +# Rick Elrod 
> +# MIT
> +
> +import sys
> +import time
> +
> +if len(sys.argv) != 3:
> +print('UNKNOWN: Pass path to file and delta as parameters')
> +sys.exit(3)
> +
> +filename = sys.argv[1]
> +delta = float(sys.argv[2])
> +
> +timestamp = None
> +
> +try:
> +with open(filename, 'r') as f:
> +timestamp = float(f.read().strip())
> +except Exception as e:
> +print('UNKNOWN: Unable to open/read file path')
> +sys.exit(3)
> +
> +difference = round(time.time() - timestamp, 2)
> +if difference > delta:
> +print(
> +'CRITICAL: Timestamp in file (%.2f) exceeds delta (%.2f) by
> %.2f seconds' % (
> +timestamp,
> +delta,
> +difference - delta))
> +sys.exit(2)
> +
> +print('OK: Timestamp in file (%.2f) is within delta (%.2f) of now, by
> %.2f seconds' % (
> +timestamp,
> +delta,
> +abs(difference - delta)))
> +sys.exit(0)
> diff --git a/roles/nagios_client/tasks/main.yml
> b/roles/nagios_client/tasks/main.yml
> index 2e5e0df..8e71a3b 100644
> --- a/roles/nagios_client/tasks/main.yml
> +++ b/roles/nagios_client/tasks/main.yml
> @@ -47,6 +47,7 @@
>- check_osbs_api.py
>- check_ipa_replication
>- check_redis_queue.sh
> +  - check_timestamp_from_file
>when: not inventory_hostname.startswith('noc')
>tags:
>- nagios_client
> @@ -226,6 +227,16 @@
>tags:
>- nagios_client
>
> +- name: install nrpe checks for sundries/websites
> +  template: src={{ item }}.j2 dest=/etc/nrpe.d/{{ item }} owner=root
> group=root mode=0644
> +  with_items:
> +  - check_websites_buildtime.cfg
> +  when: inventory_hostname.startswith('sundries')
> +  notify:
> +  - restart nrpe
> +  tags:
> +  - nagios_client
> +
>  - name: install nrpe config for the RabbitMQ checks
>template:
>  src: "rabbitmq_args.ini.j2"
> diff --git a/roles/nagios_client/templates/check_websites_buildtime.cfg.j2
> b/roles/nagios_client/templates/check_websites_buildtime.cfg.j2
> new file mode 100644
> index 000..ff5639d
> --- /dev/null
> +++ b/roles/nagios_client/templates/check_websites_buildtime.cfg.j2
> @@ -0,0 +1,2 @@
> +# Alert if websites haven't been built in 3 hours
> +command[check_websites_buildtime]={{ libdir
> }}/nagios/plugins/check_timestamp_from_file
> /srv/websites/getfedora.org/build.timestamp.txt 10800
> diff --git a/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> b/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> index 85e8f8e..c8958d7 100644
> --- a/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> +++ b/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> @@ -316,4 +316,14 @@ define service {
>use   ppc-secondarytemplate
>  }
>
> +## Auxillary to websites but necessary to make them happen
> +
> +define service {
> +  host_name sundries01.phx2.fedoraproject.org
> +  service_description   websites build happened recently
> +  check_command check_by_nrpe!check_websites_buildtime
> +  use   websitetemplate
> +}
> +
> +
>  {% endif %}
> 

Re: State of FMN (FedMSG Notifications) and Replacement

[Clement Verna]

On Wed, 26 Feb 2020 at 09:17, Adam Williamson 
wrote:

> On Wed, 2020-02-26 at 08:26 +0100, Clement Verna wrote:
> > Hi all,
> >
> > FMN (https://apps.fedoraproject.org/notifications) is currently one of
> the
> > main blocking point for dropping fedmsg in favour of fedora-messaging.
> > FMN is quite important to the community and the composition of Fedora
> > because it gives emails and notifications on commits, composes, builds
> and
> > updates via email and other tools.
> >
> > However, the code base is written in Python 2.7 and not maintained
> anymore.
> > Currently the service has to run on a Fedora 28 system to continue
> running.
> > This causes multiple problems and concerns, and needs to be addressed
> > before the datacenter move in June.
> >
> > In order to start putting together a specification for a replacement, we
> > should try to look at the minimum requirements for a notification system.
> > For example the current system supports sending notifications to IRC,
> > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live
> > without IRC ? Do we need it to monitor everything it does currently or
> just
> > a subset of items that the community has found useful.
> >
> > Let's use this thread to brainstorm ideas on what we need.
>
> I'd note that a key feature of FMN is that it provides human-readable
> summaries of messages. For fedmsg this is achieved through the fedmsg
> metadata system, and the Fedora providers for it:
>
> https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/
>
> for fedora-messaging, the intended way to do approximately the same
> thing is with message schemas:
>
> https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema
>
> as part of modernizing FMN and rewriting it on fedora-messaging, we
> might well need to get fedora-messaging schema coverage up to a similar
> level as we have fedmsg meta coverage. We may want to see if we can
> come up with an automated or semi-automated process for converting
> fedmsg meta providers to fedora-messaging schemas, even...
>

Yes this also part of this thread to identify which messages we really care
about, so that we can focus on providing schema for these first. Messages
that are a little bit less important would come later.


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-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/de...@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

State of FMN (FedMSG Notifications) and Replacement

[Clement Verna]

Hi all,

FMN (https://apps.fedoraproject.org/notifications) is currently one of the
main blocking point for dropping fedmsg in favour of fedora-messaging.
FMN is quite important to the community and the composition of Fedora
because it gives emails and notifications on commits, composes, builds and
updates via email and other tools.

However, the code base is written in Python 2.7 and not maintained anymore.
Currently the service has to run on a Fedora 28 system to continue running.
This causes multiple problems and concerns, and needs to be addressed
before the datacenter move in June.

In order to start putting together a specification for a replacement, we
should try to look at the minimum requirements for a notification system.
For example the current system supports sending notifications to IRC,
emails and SSE (Server Sent Event), Can we live without SSE ? Can we live
without IRC ? Do we need it to monitor everything it does currently or just
a subset of items that the community has found useful.

Let's use this thread to brainstorm ideas on what we need.

Thanks all
___
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 do ..., let try to share our knowledge

[Clement Verna]

On Thu, Feb 13, 2020, 14:11 Matthew Miller  wrote:

> On Tue, Feb 11, 2020 at 05:00:44PM +0100, Clement Verna wrote:
> > In an effort to try to spread knowledge on how to do things in the Fedora
> > Infrastructure, let's try to use a How To git repo [0].
>
> Would it be possible to then publish the contents of that repo to
> https://docs.fedoraproject.org? Or at least
> https://fedora-infra-docs.readthedocs.io/?
>

The git repo was an easy and simple thing to setup to get started, but I
agree that this is not really accessible and user friendly.  In my opinion
for something like this to be useful it needs to have a decent search
functionality which docs.fp.o does not have. The infra-docs supports search
so it might be a good candidate, although I think we need to be careful on
how we would re-structure this page so that it is easy to navigate.



>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

How to do ..., let try to share our knowledge

[Clement Verna]

Hi all,

In an effort to try to spread knowledge on how to do things in the Fedora
Infrastructure, let's try to use a How To git repo [0].

The goal is to add there files with the description on How to complete a
certain task. For example I have added a file for How to delete a virtual
instance [1].
If we try to use this repo when we process tickets, I think it has the
potential to become a good knowledge base that would be useful for all of
us.

Why not add that information in the SOP ?

The SOP[2] are usually dedicated to one system or one application, in order
to complete a task you might have to execute steps on different services
and/or applications.
Also it is, I believe easier to search for something like "How to create a
new mailing list" rather than having to know that we are using mailman for
mailing list and then search for the mailing list SOP.

Let me know what you think about trying this ?

[0] - https://pagure.io/Fedora-Infra/howtos
[1] -
https://pagure.io/Fedora-Infra/howtos/blob/master/f/destroy_a_virt_instance.md
[2] -
https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/index.html
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] openshift-apps/docsbuilding: add dustymabe to owners

[Clement Verna]

I have applied and deployed this patch.

You should be all set now.

On Thu, 16 Jan 2020 at 14:40, Adam Samalik  wrote:

> +1
>
> On Wed, Jan 15, 2020 at 8:44 PM Dusty Mabe  wrote:
>
>> Considering we have CoreOS documentation. I'd like to be able to
>> see the build processes to know when/if they are failing for any
>> reason.
>> ---
>>  playbooks/openshift-apps/docsbuilding.yml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/playbooks/openshift-apps/docsbuilding.yml
>> b/playbooks/openshift-apps/docsbuilding.yml
>> index 431e14392..b3f4f10be 100644
>> --- a/playbooks/openshift-apps/docsbuilding.yml
>> +++ b/playbooks/openshift-apps/docsbuilding.yml
>> @@ -15,6 +15,7 @@
>>  appowners:
>>  - asamalik
>>  - jibecfed
>> +- dustymabe
>>  tags:
>>- apply-appowners
>>- role: openshift/imagestream
>> --
>> 2.24.1
>>
>>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [patch] greenwave: disregard fedora-epel-8-modular

[Clement Verna]

On Tue, 17 Dec 2019 at 21:21, Merlin Mathesius  wrote:

> Greetings.
>
> I've noticed that submitting an EPEL 8 Modular update in bodhi grumbles
> that it "Failed to talk to Greenwave." For example,
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-MODULAR-2019-b3f2d3b5ff
> .
>
> It has been suggested that the attached patch to the greenwave
> configuration in the Infra ansible repo should silence that message.
>

Hi Merlin,

Thanks for the patch, I have applied it and I ran the related playbook in
order to deploy this in staging and production.


>
> Merlin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Help fixing the ansible-review warnings

[Clement Verna]

Hi all,

If you would like to help in solving some of the warnings reported by the
ansible-review tool, there are a few steps on how to run the tool and get
the report in this ticket
https://pagure.io/fedora-infrastructure/issue/8157#comment-611372

You can send your patch to this list for review :-)

Thanks
Clément
___
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: OpenShift-apps playbooks in the master.yml playbook

[Clement Verna]

On Mon, 18 Nov 2019 at 18:13, Rick Elrod  wrote:

> On 2019-11-18 06:59, Clement Verna wrote:
> > Hey all,
> >
> > I have just disabled the openshift-apps playbooks from running in the
> > master playbook run (see
> >
> https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/master.yml?id=dccf42cd510703d6ddb5bb444aed7ce24ee1c334
> ).
>
> I'm -1 on this. Production apps should make use of git branches and
> deploy from, say, a "production" branch. Then a deployment at any moment
> wouldn't unexpectedly break an app.
>
> Staging apps can do similar.
>
> Basically anything that isn't just being tested/experimented with (which
> should happen in communishift) can do similar.
>

I tend to agree with that, I have quickly check the apps we have under
roles/openshift-apps and a few of them are deploying from the master branch
in the production environment. This is not necessarily related to s2i we
also have quite a few applications that are using the Git build strategy to
directly build from a git repository, and we also have a few apps using the
Docker build strategy with a Dockerfile that contains a git clone step.

I also think that we should consider that some of these are deploying the
master in production on purpose and that the maintainers of these
applications are fine with that. What do you think ? should we enforce a
specific strategy (production, staging branch ) ? or leave it as it is and
let the people maintaining and developing these application decide what is
best ?


> >
> > The reason behind is that the openshift-apps playbook are written to
> > trigger a new build and a new deployment of the application at each run,
> > this means that every time the master.yml playbook is run we build a
> > version of the application and deploy it.
> > Since a few of our applications are using source-to-image to build the
> > container directly from git it means that a master.yml run can deploy
> > new code into production without the maintainer of that application
> > being aware of it.
> >
>
> Again, these s2i images should pull from a distinguished branch, then
> this becomes a nonissue.
>

So there is still a problem in creating all these builds, it is consuming
resources for no good valid reasons and it is creating mini outage for the
application that are using a recreate strategy ( all the running pods are
brought down before new pods are started ). This morning I was
investigating why a greenwave build was stuck. Running the following
command `oc get builds --all-namespaces` returned 5 or 6 builds in the
running state, all these builds were running on os-node05 box. Before I
could restart the docker daemon on this box I needed to make sure none of
these builds were actually legitimate deployments, I was quite confused to
see so many running builds at first.

If I understand correctly the purpose of the master.yml playbook is to make
sure that what is running is what we have in ansible, so that any manual
changes is overridden by this run. I think this is not needed for OpenShift
application since no manual changes can be made inside a running container,
and the permission to edit the config maps are disable for the app owners
so the only possible way to make a change in an application running in
OpenShift is via a commit either in the project git repo or in the ansible
repository. Is there another purpose for master playbook that I am missing ?

Overall I don't think we have to run these playbook in the master run, but
if we want too I think we should remove the rollout tasks from the
OpenShift playbooks and have the playbook just configure the projects and
secrets and config maps leaving the rollout strategy to the app owners.
What do you think about that ?


>
> -re
>
>
> > I wanted to raise awareness of this problem and ask the following
> > questions.
> >
> > Do we need to have the openshift-apps in the master.yml ? If yes how do
> > we prevent the run from deploying unwanted changes in production ?
> >
> > Thanks
> > Clément
> >
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
> >
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedor

OpenShift-apps playbooks in the master.yml playbook

[Clement Verna]

Hey all,

I have just disabled the openshift-apps playbooks from running in the
master playbook run (see
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/master.yml?id=dccf42cd510703d6ddb5bb444aed7ce24ee1c334
).

The reason behind is that the openshift-apps playbook are written to
trigger a new build and a new deployment of the application at each run,
this means that every time the master.yml playbook is run we build a
version of the application and deploy it.
Since a few of our applications are using source-to-image to build the
container directly from git it means that a master.yml run can deploy new
code into production without the maintainer of that application being aware
of it.

I wanted to raise awareness of this problem and ask the following
questions.

Do we need to have the openshift-apps in the master.yml ? If yes how do we
prevent the run from deploying unwanted changes in production ?

Thanks
Clément
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: F29 and older instances

[Clement Verna]

On Wed, 13 Nov 2019 at 23:43, Kevin Fenzi  wrote:

> Greetings everyone.
>
> On 2019-11-26 fedora 29 will go end of life and no longer supported.
>
> We still have a number of things that are f29 (or older for various
> reasons). I'd like everyone to look this over and see if you can't move
> things to f31 (or at least f30) before the f29 eol.
>
> builders: I am working on this, builders right now are mostly f29, but
> should be all moved before the eol date I hope.
>
> openshift apps:
>
> modernpaste: fedora-27. :) But I don't think it was ever moved to
> openshift, so we should delete this.
>
> joystick: we should fix this up, I think jdoss was going to take it
> over?
>
> the-new-hotness: can we move to f31?
>
> qa-stg01.qa.fedoraproject.org: f24? can we retire?
>
> autocloud*: f27, but should die when f29 goes eol (it's only used to
> test atomic-host).
>
> mdadpi: f27, but it moved to openshift, can we clean up the non
> openshift instances and files please?
>
> modernpaste: f27. It goes eol soon, so I guess we just wait
>
> notifs-backend: f27. I don't know what to do here. We need a
> replacement, which we don't have. I'm afraid that upgrading will blow it
> up, but I guess we could try and rollback?
>
> qa-prod01: f27. can we retire?
>
> ci-cc-rdu01: f28. Can we retire soon?
>
> copr-frontend01/02.stg: f28 and I don't think we need them anymore, can
> I nuke them?
>
> db-qa03: f28. Can we upgrade please?
>
> osbs: f28, but I think cverna was moving it to newer? any status?
>

I have a cluster in staging on rhel7, so it mostly seems to be working
correctly. I still need to do a bit more testing but I think this will be
moving with the work needed for the IOT objective.


>
> f29's:
>
> aarch64-test01/02 - can be redone as f31 anytime
> composer.stg - should be moved to f31
> db-koji01.stg - should be moved to f31 and a prod->stg sync
> kojipkgs01/02 - I should do these soon to f31, adding to my list.
> os-proxy01 - I should do this one, on my list
> packages03/04 - No idea here. Can we upgrade?
>

In theory we should be able to update to f30. I can give it a try in
staging. It also should not be too complicated to move to OpenShift or even
maybe Communishift.

proxy* - we need to start working on this asap.
> relepel01 - do we need this one anymore?
> resultsdb/taskotron - can qa folks upgrade these?
>
> old cloud instances:
>
> glittergallery-dev: f23, should be nuked
> fedora-bootstrap: f25, should be nuked
> waiverdb-dev: f25, still needed?
> commops: f27, still needed?
> telegram-irc: ? still needed?
> copr*stg: f28, can copr folks upgrade?
> developer: f28, still needed?
> libravatar: f28, should ask them to move to communishift
> simple-koji-ci: f29. Can we upgrade to 31? or move it to communishift?
>
> I think thats all of them.
>
> 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
>
___
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: Upgrading ODCS prod (hopefully) next week.

[Clement Verna]

On Fri, 1 Nov 2019 at 10:48, Jan Kaluža  wrote:

> Hi,
>
> last few weeks, I was working on ODCS upgrade in staging. This is done now
> and I would like to do the same upgrade in prod.
>
> The ODCS running in Fedora prod infra is quite old and lot of things
> changed in the upstream. Therefore this upgrade is somehow big and I
> presume the service will not be running for few hours. The key changes in
> ODCS infrastructure will be:
>
> - ODCS prod VMs will be redeployed to upgrade to Fedora 30.
> - ODCS will stop using fedmsg-hub and starts using fedora-messaging.
> - ODCS will start using Celery over fedora-infrastructure's RabbitMQ for
> job planning.
> - Upgrade to latest ODCS and Pungi will be done.
>
> All of that is already done and tested on staging infrastructure.
>
> The service is currently used mainly by OSBS to build flatpak images and
> therefore I presume the flatpak builds will fail during this upgrade.
>
> I will coordinate the upgrade with Clement Verna (OSBS),  Owen Taylor
> (flatpak) and Mikolaj Izdebski (fedora infra). In case you think you should
> be included in discussions related to this upgrade, please respond here :).
>

+devel for visibility

The outage is now schedule, see below for details

There will be an outage starting at 2019-11-06 08:00 UTC, which will last
approximately 2 hours.

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2019-11-06 08:00 UTC'

Reason for outage: During the outage window On Demand Compose service will
be updated to latest version.

Affected Services:

ODCS : https://odcs.fedoraproject.org/composes
OSBS: Flatpak build will be failing during the time of the outage.
Container builds are not impacted.

Ticket Link:

Contact Information: @cverna <https://pagure.io/user/cverna> , @jkaluza
<https://pagure.io/user/jkaluza>

Please join #fedora-admin in irc.freenode.net or add comments to the ticket
for this outage above.

The outage is tracked in this ticket -->
https://pagure.io/fedora-infrastructure/issue/8353


>
> Regards,
> Jan Kaluza
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-report git hook design

[Clement Verna]

On Mon, 28 Oct 2019 at 18:42, Kevin Fenzi  wrote:

> On Fri, Oct 25, 2019 at 02:33:02PM -0400, Randy Barlow wrote:
> > On Fri, 2019-10-25 at 19:04 +0200, Clement Verna wrote:
> > > I think the main reason why we don't already have it on Pagure is
> > > that we don't want to be dependent of our own infrastructure to host
> > > this repo. It currently lives on the batcave01 host which is the box
> > > we use to deploy our infrastructure. So to me if we are going to host
> > > this repository on a git forge I think using an external service
> > > would make sense.
>
> I don't agree, unless we move/have all/more of our presense there.
>

> ie, I don't want to move just the fedora infrastructure ansible repo to
> say gitlab and have it there by itself. I think thats really poor for
> discoverability, etc.
>

Yes I agree with you.


>
> ...snip...
>
> > > After I am not really interested in a long debate in regards of where
> > > that repo should be hosted, to me what matters is that we should have
> > > the Fedora Community in only one place be it GitLab like the Gnome
> > > community or GitHub where we already have fedora-infra, fedora-cloud,
> > > fedora CoreOS.
>
> Yeah, but any such move will be a long debate I fear.
>

> >
> > Yeah GitHub and GitLab are both great.
>
> Well, from a end user perspective, yes.
>
> There are ideological issues with both, github isn't open source, gitlab
> is open core and has been making odd decisions of late (see the 'we are
> going to collect metrics on everything" and "we don't drop customers due
> to their political views").
>
> But to get back to the initial question here...
>
> It sounds like adding the hook now as things are doesn't make too much
> sense? Althought we could run a daily report or something that points
> out issues after they have been commited (so at least we fix it).
>
> Short term, I'm very keen to have ansible repo PR's. So, perhaps we
> could work something to move it to pagure soon (either repospanner if we
> can handle the performance, or just git on pagure we mirror some way)?
> Happy to discuss this in our meeting thursday? or some other time.
>

+1


> Longer term, yeah, we may want to move to gitlab/github, but I don't
> think the ansible repo is something I want to be a scout or outlyer, I'd
> want us to have a plan and move things in a coordinated way. I think
> thats a bigger discussion we need to have.
>

+1


> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
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: Infrastructure docs & apps.fp.o

[Clement Verna]

On Mon, 28 Oct 2019 at 08:22, Timothée Floure 
wrote:

> https://pagure.io/infra-docs-fpo/pull-request/1
>
> ^ Can someone take a quick look a the changes?
>

Thanks for doing that, I have added a few comments/questions on the PR :-)


> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

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 ?


> Of course, this is also my own opinion, and I welcome disagreement.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: ansible-report git hook design

[Clement Verna]

On Fri, 25 Oct 2019 at 16:47, Brian (bex) Exelbierd 
wrote:

>
>
> On Fri, Oct 25, 2019 at 3:28 PM Randy Barlow 
> wrote:
>
>> On Fri, 2019-10-25 at 15:03 +0200, Clement Verna wrote:
>> > There are basically 2 possibility :
>>
>> There are other possibilities too, such as putting the repo on
>> gitlab.com and using their CI on pull requests
>
>
> Can’t we do this on Pagure with CentOS CI?
>

I think the main reason why we don't already have it on Pagure is that we
don't want to be dependent of our own infrastructure to host this repo. It
currently lives on the batcave01 host which is the box we use to deploy our
infrastructure. So to me if we are going to host this repository on a git
forge I think using an external service would make sense. Of course we
would then be dependent on a third party but I think that the % of
availability of GitHub or GitLab is much higher than ours, they have
dedicated teams working on making sure their service is available when we
struggle to keep all our infra running. Also their main business and
expertise is to run a git forge service, they have the infrastructure and
the hardware for that, while our main business is to build and release a
Linux distribution (A really good one :-)

After I am not really interested in a long debate in regards of where that
repo should be hosted, to me what matters is that we should have the Fedora
Community in only one place be it GitLab like the Gnome community or GitHub
where we already have fedora-infra, fedora-cloud, fedora CoreOS.

Just my 2 cents :-)


>
> Thank you.
>
> regards,
>
> bex
>
>
> .
>> ___
>> 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
>>
> --
> Brian "bex" Exelbierd (he/him/his)
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com | b...@pobox.com
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

ansible-report git hook design

[Clement Verna]

Hi all,

Today jlanda, austinpowered and mizdebsk discussed about ticket
https://pagure.io/fedora-infrastructure/issue/8157 in #fedora-admin and
came up with a few questions on how to implement that solution that I think
would be nice to share with the wider group.

There are basically 2 possibility :

1 - We run ansible-report as a pre-commit hook
This means that ansible-report will be run locally before a contributor
commit a change. This is not ideal since our contributor are running all
kind systems (rhel, fedora, windows ?) so having something that work well
for everyone will not be simple. Also this forces our contributors to
install ansible-report locally.

2 - We run ansible-report as a pre-receive hook
This means that ansible-report is run on batcave01, but we cannot run
ansible-report just on a commit, we need to run the tool against the full
repository every time. That involve making a clone of the repo applying the
changes in the incoming commit, then run ansible-report on that repository.

This has also a few disadvantages, first we first need to clear all the
errors reported by ansible-report in our repo before we enable the hook
otherwise all commits will be rejected. It will also slows down every
pushes (time to clone, apply patch, run the tool).

Do people have other ideas ? Is this change worth the trouble ?

Thanks
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Update koji-sidetag-plugin on Koji hub

[Clement Verna]

+1 too

On Thu, 24 Oct 2019 at 21:07, Pierre-Yves Chibon 
wrote:

> On Thu, Oct 24, 2019 at 03:30:50PM +0200, Mikolaj Izdebski wrote:
> > In order to fix issue 8322 [1] python2-koji-sidetag-plugin-hub needs
> > to be updated. This would be done with the following commands:
> >
> > $ koji move epel7-infra-stg epel7-infra
> koji-sidetag-plugin-0.1-2.el7.infra
> >
> > [root@batcave01]# ansible koji -m package -a
> > 'name=python2-koji-sidetag-plugin-hub state=latest update_cache=yes
> > update_only=yes'
> >
> > [root@batcave01]# ansible koji -m service -a 'name=httpd state=reloaded'
>
> +1 for me, and thanks for looking at this!
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: F31 Final is GO, bodhi config changes

[Clement Verna]

On Thu, 24 Oct 2019 at 20:32, Mohan Boddu  wrote:

> On Thu, Oct 24, 2019 at 2:04 PM Clement Verna 
> wrote:
> >
> >
> >
> > On Thu, 24 Oct 2019 at 19:57, Mohan Boddu  wrote:
> >>
> >> Hi,
> >>
> >> Now that F31 is GO, I would like the make the necessary changes to
> >> bodhi configs.
> >>
> >> "vars/all/Frozen.yaml" 1L, 15C written
> >> [mohanboddu@batcave01 ansible][PROD]$ git diff
> >> diff --git a/vars/all/00-FedoraCycleNumber.yaml
> >> b/vars/all/00-FedoraCycleNumber.yaml
> >> index 22476b0..4bd0d46 100644
> >> --- a/vars/all/00-FedoraCycleNumber.yaml
> >> +++ b/vars/all/00-FedoraCycleNumber.yaml
> >> @@ -1 +1 @@
> >> -FedoraCycleNumber: 30
> >> +FedoraCycleNumber: 31
> >> diff --git a/vars/all/FedoraBranched.yaml b/vars/all/FedoraBranched.yaml
> >> index 42ac534..0bbcc1d 100644
> >> --- a/vars/all/FedoraBranched.yaml
> >> +++ b/vars/all/FedoraBranched.yaml
> >> @@ -1 +1 @@
> >> -FedoraBranched: True
> >> +FedoraBranched: False
> >> diff --git a/vars/all/FedoraBranchedBodhi.yaml
> >> b/vars/all/FedoraBranchedBodhi.yaml
> >> index 380f61d..76ba14d 100644
> >> --- a/vars/all/FedoraBranchedBodhi.yaml
> >> +++ b/vars/all/FedoraBranchedBodhi.yaml
> >> @@ -1,2 +1,2 @@
> >>  #options are: prebeta, postbeta, current
> >> -FedoraBranchedBodhi: postbeta
> >> +FedoraBranchedBodhi: current
> >> diff --git a/vars/all/FedoraPreviousPrevious.yaml
> >> b/vars/all/FedoraPreviousPrevious.yaml
> >> index a8e3d3b..a061e04 100644
> >> --- a/vars/all/FedoraPreviousPrevious.yaml
> >> +++ b/vars/all/FedoraPreviousPrevious.yaml
> >> @@ -1 +1 @@
> >> -FedoraPreviousPrevious: False
> >> +FedoraPreviousPrevious: True
> >> diff --git a/vars/all/Frozen.yaml b/vars/all/Frozen.yaml
> >> index 97d3bc3..7578a88 100644
> >> --- a/vars/all/Frozen.yaml
> >> +++ b/vars/all/Frozen.yaml
> >> @@ -1 +1 @@
> >> -Frozen: True
> >> +Frozen: False
> >
> >
> > I think this is the Frozen variable for the infra, and if I am correct
> that should stay set to True. But I am might be wrong :-)
> Even I thought of the same and checked for it and the only place that
> is using it is:
>
> https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_hub/templates/hub.conf.j2#n149
> Which is not related to infra.
>

Cool thanks for checking


> >
> >>
> >> diff --git a/vars/all/RelEngFrozen.yaml b/vars/all/RelEngFrozen.yaml
> >> index bd7553f..72af779 100644
> >> --- a/vars/all/RelEngFrozen.yaml
> >> +++ b/vars/all/RelEngFrozen.yaml
> >> @@ -1 +1 @@
> >> -RelEngFrozen: True
> >> +RelEngFrozen: False
> >
> >
> > One question otherwise looks good, so +1
> >
> >>
> >>
> >> Thanks.
> >> ___
> >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> >> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
> >
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: The packages app has a short runway

[Clement Verna]

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.


> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: F31 Final is GO, bodhi config changes

[Clement Verna]

On Thu, 24 Oct 2019 at 19:57, Mohan Boddu  wrote:

> Hi,
>
> Now that F31 is GO, I would like the make the necessary changes to
> bodhi configs.
>
> "vars/all/Frozen.yaml" 1L, 15C written
> [mohanboddu@batcave01 ansible][PROD]$ git diff
> diff --git a/vars/all/00-FedoraCycleNumber.yaml
> b/vars/all/00-FedoraCycleNumber.yaml
> index 22476b0..4bd0d46 100644
> --- a/vars/all/00-FedoraCycleNumber.yaml
> +++ b/vars/all/00-FedoraCycleNumber.yaml
> @@ -1 +1 @@
> -FedoraCycleNumber: 30
> +FedoraCycleNumber: 31
> diff --git a/vars/all/FedoraBranched.yaml b/vars/all/FedoraBranched.yaml
> index 42ac534..0bbcc1d 100644
> --- a/vars/all/FedoraBranched.yaml
> +++ b/vars/all/FedoraBranched.yaml
> @@ -1 +1 @@
> -FedoraBranched: True
> +FedoraBranched: False
> diff --git a/vars/all/FedoraBranchedBodhi.yaml
> b/vars/all/FedoraBranchedBodhi.yaml
> index 380f61d..76ba14d 100644
> --- a/vars/all/FedoraBranchedBodhi.yaml
> +++ b/vars/all/FedoraBranchedBodhi.yaml
> @@ -1,2 +1,2 @@
>  #options are: prebeta, postbeta, current
> -FedoraBranchedBodhi: postbeta
> +FedoraBranchedBodhi: current
> diff --git a/vars/all/FedoraPreviousPrevious.yaml
> b/vars/all/FedoraPreviousPrevious.yaml
> index a8e3d3b..a061e04 100644
> --- a/vars/all/FedoraPreviousPrevious.yaml
> +++ b/vars/all/FedoraPreviousPrevious.yaml
> @@ -1 +1 @@
> -FedoraPreviousPrevious: False
> +FedoraPreviousPrevious: True
> diff --git a/vars/all/Frozen.yaml b/vars/all/Frozen.yaml
> index 97d3bc3..7578a88 100644
> --- a/vars/all/Frozen.yaml
> +++ b/vars/all/Frozen.yaml
> @@ -1 +1 @@
> -Frozen: True
> +Frozen: False
>

I think this is the Frozen variable for the infra, and if I am correct that
should stay set to True. But I am might be wrong :-)


> diff --git a/vars/all/RelEngFrozen.yaml b/vars/all/RelEngFrozen.yaml
> index bd7553f..72af779 100644
> --- a/vars/all/RelEngFrozen.yaml
> +++ b/vars/all/RelEngFrozen.yaml
> @@ -1 +1 @@
> -RelEngFrozen: True
> +RelEngFrozen: False
>

One question otherwise looks good, so +1


>
> Thanks.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Working on adding ansible-report to our ansible repo

[Clement Verna]

Hi all,

Tomorrow I am planning to work on the following ticket (
https://pagure.io/fedora-infrastructure/issue/8157 ). If there are people
interested to work on this with me or just to tag along I will be starting
to work on that in #fedora-admin at 12:00 UTC.

Thanks
Clément
___
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] bastion: Add sysadmin-odcs to fas_client_groups

[Clement Verna]

±1

On Tue, Oct 22, 2019, 14:07 Stephen John Smoogen  wrote:

> +1
>
> On Tue, 22 Oct 2019 at 07:01, Mikolaj Izdebski 
> wrote:
> >
> > ---
> >  inventory/group_vars/bastion | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/inventory/group_vars/bastion b/inventory/group_vars/bastion
> > index aeacc87e4..8e63d1a11 100644
> > --- a/inventory/group_vars/bastion
> > +++ b/inventory/group_vars/bastion
> > @@ -23,7 +23,7 @@ custom_rules: [
> >
> >  # TODO - remove modularity-wg membership here once it is not longer
> needed:
> >  # https://fedorahosted.org/fedora-infrastructure/ticket/5363
> > -fas_client_groups:
> >
> sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs
> > +fas_client_groups:
> >
> sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs,sysadmin-odcs
> >
> >  #
> >  # This is a postfix gateway. This will pick up gateway postfix config
> in base
> > --
> > 2.21.0
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
>
>
> --
> 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
>
___
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: Emergency FBR: Lower concurrency on postgres to help load

[Clement Verna]

On Fri, 11 Oct 2019 at 16:07, Pierre-Yves Chibon 
wrote:

> On Fri, Oct 11, 2019 at 09:52:20AM -0400, Stephen John Smoogen wrote:
> > Currently the load on db-koji is 140+ and it is slow and
> > non-responsive to users. I believe it is the below change which has
> > affected this. I would like to lower down io to 32 to see if that
> > affects things and tune further if needed. I am not doing this until
> > Kevin or Patrick are around as it will affect koji and there is an
> > order needed
> >
> > diff --git a/roles/postgresql_server/templates/postgresql.conf
> > b/roles/postgresql_server/templates/postgresql.conf
> > index cbe..341340c 100644
> > --- a/roles/postgresql_server/templates/postgresql.conf
> > +++ b/roles/postgresql_server/templates/postgresql.conf
> > @@ -504,4 +504,4 @@ default_text_search_config = 'pg_catalog.english'
> >  #custom_variable_classes = ''   # list of custom variable class
> names
> >  #
> >  # Number of concurrent i/o operations at the same time. The default is
> 1.
> > -effective_io_concurrency = 100
> > +effective_io_concurrency = 32
>
> +1 for me
>
>
+1 too

>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] postgresql_server / db-koji01: Adjust a bunch more for performance.

[Clement Verna]

On Thu, 10 Oct 2019 at 19:17, Stephen John Smoogen  wrote:

> On Thu, 10 Oct 2019 at 12:59, Kevin Fenzi  wrote:
> >
> > On Thu, Oct 10, 2019 at 12:13:41PM -0400, Stephen John Smoogen wrote:
> > > why is work_mem = 157286kB versus 16MB ?
> >
> > Thats what the pgtune generator gave me. ;)
> >
> > I don't think there's any reason it couldn't be 16MB...
>
> OK sorry.. I expect that the tool does have a reason it isn't so lets
> go with what it gave us. +1
>
>
+1 too


>
> --
> 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
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] bodhi / backend: No longer sync or make aarch64 for epel7.

[Clement Verna]

On Wed, 9 Oct 2019 at 00:47,  wrote:

> From: Kevin Fenzi 
>
> Since rhel dropped alt arch aarch64 with 7.7, we have to drop it in epel
> too.
>
> Signed-off-by: Kevin Fenzi 
> ---
>  roles/bodhi2/backend/files/new-updates-sync| 4 ++--
>  roles/bodhi2/backend/templates/variants.rpm.xml.j2 | 4 +++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/roles/bodhi2/backend/files/new-updates-sync
> b/roles/bodhi2/backend/files/new-updates-sync
> index fde72e3..d08c893 100755
> --- a/roles/bodhi2/backend/files/new-updates-sync
> +++ b/roles/bodhi2/backend/files/new-updates-sync
> @@ -171,12 +171,12 @@ RELEASES = {'f31': {'topic': 'fedora',
>'modules': ['epel'],
>'repos': {'epel-testing': {
>'from': 'epel7-testing',
> -  'to': [{'arches': ['x86_64', 'aarch64',
> 'ppc64le', 'source'],
> +  'to': [{'arches': ['x86_64', 'ppc64le',
> 'source'],
>'dest': os.path.join(EPELDEST,
> 'testing', '7')}
>  ]},
>  'epel': {
>'from': 'epel7',
> -  'to': [{'arches': ['x86_64', 'aarch64',
> 'ppc64le', 'source'],
> +  'to': [{'arches': ['x86_64', 'ppc64le',
> 'source'],
>'dest': os.path.join(EPELDEST, '7')}
>  ]}}
>   },
> diff --git a/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> b/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> index 062a63e..e848632 100644
> --- a/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> +++ b/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> @@ -10,8 +10,10 @@
>  [% if release.id_prefix == "FEDORA" %]
> armhfp
> [% endif %]
> -   [% if release.version_int >= 26 or release.version_int >= 7 %]
> +   [% if release.version_int >= 26 or release.version_int >= 8 %]
> aarch64
> +   [% endif %]
> +   [% if release.version_int >= 26 or release.version_int >= 7 %]
> ppc64le
> [% endif %]
> s390x
> --
> 1.8.3.1
>

+1


> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Meeting Agenda Item: Introduction Stephen Coady

[Clement Verna]

On Tue, 1 Oct 2019 at 16:26, Stephen Coady  wrote:

> Hi everyone.
>
> My name is Stephen Coady and I have just joined the community platform
> engineering team.
>
> I have been using Fedora for about 2 years now on and off. I am looking
> forward to contributing to the platform in any way I can. I am familiar
> with Javascript, GraphQL and Docker and I have done quite a bit of hybrid
> mobile application development. I used Python a few years ago and I am
> looking forward to getting back into it.
>
> My irc nick is scoady. Looking forward to chatting to you all soon.
>

Welcome in the community and in the team :-)


>
> Stephen
>
> --
>
> Stephen Coady
>
> Software Engineer
>
> Red Hat 
>
> 
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Starting to address backlog

[Clement Verna]

On Mon, 30 Sep 2019 at 22:36, Stephen John Smoogen  wrote:

> On Mon, 30 Sep 2019 at 16:22, Kevin Fenzi  wrote:
> >
> > Greetings.
> >
> > A few weeks ago I went and tagged a bunch of old releng and
> > infrastructure tickets with the 'backlog' tag. Clement added some more
> > the other day.
> >
> > In our last meeting we did some simple voting on the list to determine
> > priority.
> >
> > The idea is that we will take the top 1-3 per week and get small groups
> > of people to work on them (at the very least one person can do the work
> > and explain it to another to document/provide feedback on). Then at each
> > meeting we look at the list, confirm what we did and take some more.
> >
> > Of course we have other priorities to deal with too, but focusing on a
> > few tasks and trying to spread knowledge around them will hopefully get
> > our backlog down over time.
> >
> > As a side note we are trying also with this copying these to an internal
> > jira instance to see if we can track backlog flow better and figure out
> > workflows, but this is purely a copy and pagure instances are where all
> > the work and comments are done, so anyone not on the CPE team can ignore
> > this for now. :)
> >
> > So, for this week we decided to work on:
> >
> > 8178 provision new aarch64 builders   xx
> >
> > I have this one, it takes access to get them setup, but I am happy to
> > explain on IRC what I am doing and how the setup works. Assistance could
> > be used to add them to ansible, as well as documentation if there's
> > anything special about them. I intend to work on this tomorrow morning.
> > I'll ping everyone in #fedora-admin on this who is interested.
> >
> > 8157 ansible: enable ansible-report as a hook   xx
> >
> > I'd love someone else to take this one. Any takers?
> > I can provide pointers...
>

I can try to look at that, if anybody else wants to collaborate on that
with me (apprentice ?) let me know :-)

Thanks for driving that Kevin.


> >
> > 8065 Move older koji builds to archive volumes   xx
> >
> > This is already in progress and has been for some time. I'd love to talk
> > to others and explain how it's being done and get some documentation
> > written up on it and others to know how to do it if I am not around.
> > We could also use some discussion about how to split the koji volume a
> > bit more. I might be able to work on this wed morning? Anyone interested
> > in helping?
> >
> > Thanks and hopefully we can start cranking out some of this backlog
> > now...
>
> I am interested in taking this one.
>
>
>
> --
> 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
>
___
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: Meeting Agenda Item: Introduction Joakim

[Clement Verna]

On Mon, 23 Sep 2019 at 17:11, Joakim Lönnegren 
wrote:

> Hello World!
>
> Was really impressed when I installed Fedora on an old laptop and
> everything just works (Cockpit, FreeIPA, kvm). Wanted to come over and see
> if I can give back to the community.
>
> I'm a linux sysadmin and former C# developer. I'd be thrilled to learn
> about python, openshift, openstack and ansible. I have an RHCSA and I'm
> studying for the RHCE.
>
> Originally from Sweden but living in Brazil so I'm in the GMT -3 timezone.
>
> My IRC handle is joalon, I'll try to make it to the infra meeting this
> thursday, as well as the Fridays with Infra event.
>

Hi and welcome Joakim, looking forward to talk with you at the meeting or
at the Friday with infra event :-).


>
> Best regards,
> Joakim Lönnegren
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: State/future of the packages app

[Clement Verna]

On Fri, 13 Sep 2019 at 14:51, 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. https://hackmd.io/DIz7xvfDSpyRu9y6BNG6aw
> >   • FAS replacement. Specification is work in progress
> >   • PDC replacement. https://hackmd.io/Ef4QgBwMSp-6eFQPChuWag
> >   • OSBS support for aarch64. No specification yet
> >   • End to End testing and monitoring for the flatpak build pipeline.
> Specification is work in progress
> >   • Package review process improvement. h
> ttps://hackmd.io/TGbwd2yVTlmR_PKicI3CMA
> >   • Fedora Infra technical debt.
> https://pagure.io/fedora-infrastructure/issues :-D
>
>
> Is there somewhere community members can read more on these tasks of the
> CPE please?
>

Sure see links above, not all of these have a spec yet.

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

Not available now does not mean that it cannot be made available :-). We
have so many code base it is difficult for us to maintain everything, I
would rather identify the 2-3 features that the src.fp.o misses to replace
the packages app and fill some RFE to the pagure-dist-git project (
https://pagure.io/pagure-dist-git) than spend couple months rewriting the
packages app which will fall into maintenance mode after the rewrite and
then we will have the same problem in 2 or 3 years.


>
> - 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
>
>   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", but at least having
>   the `dnf` command there is very useful to most users.
>
> I'm not flask etc savvy enough to know how easy/hard it is to add these
> bits to src.fp.o, but given that src.fp.o is basically a pagure
> instance aimed at the development side of things, I expect it isn't the
> easiest thing to do?
>

Pagure supports third party plugins, which could be used to add specific
functionality to src.fp.o that would not be needed for pagure.io. We are
already doing that for the integration with release-monitoring which is
currently being deployed.


>
> On the other hand, maybe stuff that src.fp.o already provides can be
> removed from the packages app to reduce the maintenance burden
> ---things like "Changelog" "Sources"?
>

> I totally understand how busy the CPE team is and unfortunately I'm not
> in a position to help much with the infrastructure side of things either.
>

Yes I know, we also wish we could help but trying to fix 10 things at the
same time is not working well. So we are taking the approach of focusing on
specific work until complete (currently rawhide gating), unfortunately this
means low priority things will suffer from that. I honestly believe this is
better, I prefer to tell you that the packages app will very likely be
retired in the coming year rather than letting you hope that we will spend
a lot of time on it and develop new features. But again this is my vision
of the world :-).

Just for fun this is the list of the code bases the CPE team is maintains /
look after.


   1. https://github.com/release-monitoring/anitya
   2. https://github.com/fedora-infra/the-new-hotness
   3. https://pagure.io/pagure/
   4. https://pagure.io/mdapi/
   5. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/
   6. https://pagure.io/fedora-gather-easyfix
   7. https://pagure.io/is-it-in-rhel
   8. https://pagure.io/fedora-ci/simple-koji-ci
   9. https://github.com/fedora-infra/fedora-messaging
   10. https://github.com/fedora-infra/fedmsg-migration-tools
   11. https://github.com/fedora-infra/bodhi
   12. https://github.com/fedora-infra/fmn
   13. https://github.com/fedora-infra/fedora-packages
   14. https://github.com/repoSpanner/repoSpanner
   15. https://github.com/fedora-infra/fedimg
   16. https://pagure.io/sigul
   17. https:

Re: State/future of the packages app

[Clement Verna]

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.


On Fri, 13 Sep 2019 at 00:26, Kevin Fenzi  wrote:

> On 9/12/19 3:00 PM, Frantisek Zatloukal wrote:
> > On Thu, Sep 12, 2019 at 10:17 PM Kevin Fenzi  wrote:
> >
> >> I also used 'pkgwat releases packagename' a lot. (pkgwat was the
> >> packages command line app, but it's python2 only, so it went away I
> >> fear.
> >
> >
> > Except it did not :) , it's also using Python 3.
> >
> > https://src.fedoraproject.org/rpms/pkgwat/blob/master/f/pkgwat.spec
>
>
> Cool. I must be thinking of one of the other 11biillion packages that
> was python2 only. :)
>
> 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
>
___
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

[Clement Verna]

On Thu, 12 Sep 2019 at 14:56, Neal Gompa  wrote:

> 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 am pretty sure the search functionality is querying the database.
PostgreSQL supports full text search so we could build a search index
making use of the mdapi info.

>
> 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.
>
>
> As far as I understand it the current info we display in the description
and summary come from the spec file which happened to be maintained by the
packagers :-). I would trust the packagers to add the file for their
packages if they don't want it,  fine but their package

Re: State/future of the packages app

[Clement Verna]

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.


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


>
>
> --
> 真実はいつも一つ！/ 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
>
___
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

[Clement Verna]

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.


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


> otherwise.
>
> [1] https://apps.fedoraproject.org/packages
> [2]
> https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
> [3] https://docs.fedoraproject.org/en-US/neurofedora/compneuro-tools/
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Freeze Break Request: Fix typo in bodhi status variable

[Clement Verna]

+1

On Mon, 9 Sep 2019 at 20:41, Kevin Fenzi  wrote:

> Greetings.
>
> We have a variable in:
> vars/all/FedoraBranchedBodhi.yaml
>
> thats used in our bodhi config to set the proper policies.
> The template uses 'predeta' and 'postbeta'... but the variable was
> updated to 'preBeta', which isn't going to work.
>
> I'd like to apply the following and run the bodhi backend playbook:
>
> diff --git a/vars/all/FedoraBranchedBodhi.yaml
> b/vars/all/FedoraBranchedBodhi.yaml
> index 91f82f2..f0cca9a 100644
> --- a/vars/all/FedoraBranchedBodhi.yaml
> +++ b/vars/all/FedoraBranchedBodhi.yaml
> @@ -1,2 +1,2 @@
> -#options are: preBeta, postBeta, current
> -FedoraBranchedBodhi: preBeta
> +#options are: prebeta, postbeta, current
> +FedoraBranchedBodhi: prebeta
>
> 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
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [PATCH] bodhi-backend / pungi: drop i386 trees for f31+

[Clement Verna]

+1

On Mon, 9 Sep 2019 at 19:56, Kevin Fenzi  wrote:

> This is the last bit of the
> https://fedoraproject.org/wiki/Changes/Noi686Repositories approved f31
> change
> (aside from some documentation).
>
> Signed-off-by: Kevin Fenzi 
> ---
>  roles/bodhi2/backend/templates/variants.rpm.xml.j2 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> b/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> index 569a2ef..062a63e 100644
> --- a/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> +++ b/roles/bodhi2/backend/templates/variants.rpm.xml.j2
> @@ -4,7 +4,7 @@
>  
>  
>  x86_64
> -   [% if release.version_int >= 25 or release.version_int == 6 %]
> +   [% if release.version_int == 29 or release.version_int == 30
> or release.version_int == 6 %]
> i386
> [% endif %]
>  [% if release.id_prefix == "FEDORA" %]
> --
> 1.8.3.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Freeze break request: update registry.redhat.io ip

[Clement Verna]

On Mon, 9 Sep 2019 at 20:16, Kevin Fenzi  wrote:

> diff --git a/roles/hosts/files/os-hosts b/roles/hosts/files/os-hosts
> index e9dc0a2..3c283e3 100644
> --- a/roles/hosts/files/os-hosts
> +++ b/roles/hosts/files/os-hosts
> @@ -1,4 +1,4 @@
>  127.0.0.1   localhost localhost.localdomain localhost4
> localhost4.localdomain4
>  ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
>  104.112.85.238  registry.access.redhat.com
> -104.69.74.100   registry.redhat.io
> +184.86.192.77   registry.redhat.io
>
> This should fix https://pagure.io/fedora-infrastructure/issue/8180
>
> +1s?
>

+1 thanks for looking at that :-)

>
> 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
>
___
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 sysadmin-osbs to SSH into bastion and batcave

[Clement Verna]

+1 nice and easy

On Mon, 9 Sep 2019 at 14:26, Mikolaj Izdebski  wrote:

> Resolves https://pagure.io/fedora-infrastructure/issue/8182
> ---
>  inventory/group_vars/bastion | 2 +-
>  inventory/group_vars/batcave | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/inventory/group_vars/bastion b/inventory/group_vars/bastion
> index 37b6d3e85..aeacc87e4 100644
> --- a/inventory/group_vars/bastion
> +++ b/inventory/group_vars/bastion
> @@ -23,7 +23,7 @@ custom_rules: [
>
>  # TODO - remove modularity-wg membership here once it is not longer
> needed:
>  # https://fedorahosted.org/fedora-infrastructure/ticket/5363
> -fas_client_groups:
>
> sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver
> +fas_client_groups:
>
> sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs
>
>  #
>  # This is a postfix gateway. This will pick up gateway postfix config in
> base
> diff --git a/inventory/group_vars/batcave b/inventory/group_vars/batcave
> index d415cd225..2fe5f4745 100644
> --- a/inventory/group_vars/batcave
> +++ b/inventory/group_vars/batcave
> @@ -8,7 +8,7 @@ tcp_ports: [ 80, 443, 8442, 8443 ]
>  # Neeed for rsync from log01 for logs.
>  custom_rules: [ '-A INPUT -p tcp -m tcp -s 10.5.126.13 --dport 873 -j
> ACCEPT', '-A INPUT -p tcp -m tcp -s 192.168.1.59 --dport 873 -j
> ACCEPT' ]
>
> -fas_client_groups:
>
> sysadmin-ask,sysadmin-atomic,sysadmin-cvs,sysadmin-main,sysadmin-web,sysadmin-noc,sysadmin-hosted,sysadmin-releng,sysadmin-qa,sysadmin-tools,sysadmin-cloud,sysadmin-bot,sysadmin-centos,sysadmin-koschei,sysadmin-datanommer,sysadmin-fedimg,fi-apprentice,sysadmin-regcfp,sysadmin-badges,sysadmin-mbs,sysadmin-veteran,sysadmin-coreos,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-fpdc,sysadmin-messaging,sysadmin-libravatar,sysadmin-gnome,sysadmin-copr
> +fas_client_groups:
>
> sysadmin-ask,sysadmin-atomic,sysadmin-cvs,sysadmin-main,sysadmin-web,sysadmin-noc,sysadmin-hosted,sysadmin-releng,sysadmin-qa,sysadmin-tools,sysadmin-cloud,sysadmin-bot,sysadmin-centos,sysadmin-koschei,sysadmin-datanommer,sysadmin-fedimg,fi-apprentice,sysadmin-regcfp,sysadmin-badges,sysadmin-mbs,sysadmin-veteran,sysadmin-coreos,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-fpdc,sysadmin-messaging,sysadmin-libravatar,sysadmin-gnome,sysadmin-copr,sysadmin-osbs
>
>  ansible_base: /srv/web/infra
>  freezes: false
> --
> 2.21.0
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
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: Sunset of infinote (Gobby) service

[Clement Verna]

On Tue, 27 Aug 2019 at 16:32, Clement Verna 
wrote:

>
>
> On Tue, 27 Aug 2019 at 16:30, Stephen John Smoogen 
> wrote:
>
>> On Tue, 27 Aug 2019 at 03:58, Clement Verna 
>> wrote:
>> >
>> >  On 8/1/19 3:34 AM, Clement Verna wrote:
>> >>
>> >> > Dear all,
>> >> >
>> >> > The Fedora Infrastructure is planning to retire the infinote [0]
>> >> > service. This service allows text collaboration using the Gobby
>> >> > client[1] and was mainly used by the Infrastructure team to
>> coordinate
>> >> > our weekly meeting and the mass update & reboot of the machines.
>> >> >
>> >> > The service will be taken offline on August 30th 2019. If you wish to
>> >> > backup some of the document currently hosted, you should make sure
>> >> > that you have downloaded them locally before that date.
>> >> >
>> >> > The Infrastructure team will most likely use the service provided by
>> >> > hackmd.io [2] for their needs. Other alternatives like public
>> etherpad
>> >> > can also be used to replace this service.
>> >> >
>> >
>> >
>> > Hi all, this is a reminder that this service will be retired this
>> Friday August 30th.
>> >
>> >
>>
>

The service has been retired and the archive of the content is available
here -->
https://infrastructure.fedoraproject.org/infra/retired/infinote.fedoraproject.org/infinote/

Thanks all
___
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: upgrading pagure

[Clement Verna]

+1 here

On Thu, Sep 5, 2019, 15:11 Stephen John Smoogen  wrote:

> +1
>
> On Thu, 5 Sep 2019 at 06:26, Pierre-Yves Chibon 
> wrote:
> >
> > Good Morning,
> >
> > I've just cut a new pagure bugfix release: 5.7.9 the changelog can be
> found at:
> > https://docs.pagure.org/pagure/changelog.html#id1
> > It's basically four small bug fixes one of which we have already
> hotfixed, so
> > this release drops the hotfix but not the fix :)
> >
> > In addition, I'd like to include this configuration file on our dist-git
> > instance:
> >
> > diff --git a/ roles/distgit/pagure/templates/pagure.cfg b/
> roles/distgit/pagure/templates/pagure.cfg
> > index 0aa7c7764..34f4854dd 100644
> > --- a/ roles/distgit/pagure/templates/pagure.cfg
> > +++ b/ roles/distgit/pagure/templates/pagure.cfg
> > @@ -279,6 +279,7 @@ CROSS_PROJECT_ACLS = [
> >  'pull_request_create',
> >  'pull_request_comment',
> >  'update_watch_status',
> > +'pull_request_merge',
> >  ]
> >
> >  ADMIN_API_ACLS = [
> >
> >
> > Which is meant to allow cross-project API token to merge pull-request.
> I'd like
> > to use one of these for monitoring CI on PRs and builds.
> >
> > +1s?
> >
> > Thanks,
> > Pierre
> > ___
> > 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
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

FBR: Sunset infinote

[Clement Verna]

Hi all,

The attached patch remove infinote from ansible. I would like to apply this
then delete the virtual host and finally the run the nagios playbook so
that we don't monitor this service anymore.

Content was backed up here -->
https://infrastructure.fedoraproject.org/infra/retired/infinote.fedoraproject.org/infinote/.


Once all done, I ll communicate that the service was retired on the
different lists the sunset was advertised.

+1s ?

Thanks
From e967e2ae0d2c0c18051cd52bcf58c3ccf143f9e1 Mon Sep 17 00:00:00 2001
From: Clement Verna 
Date: Tue, 3 Sep 2019 21:02:04 +0200
Subject: [PATCH] Remove infinote from ansible

Signed-off-by: Clement Verna 
---
 inventory/backups |  3 +-
 inventory/group_vars/infinote | 41 
 inventory/inventory   |  7 +-
 master.yml|  1 -
 playbooks/groups/infinote.yml | 45 -
 playbooks/include/proxies-websites.yml|  7 +-
 roles/cgit/base/files/cgitrc.infinote | 75 --
 roles/cgit/base/tasks/main.yml|  5 -
 .../files/cgit-projects-infinote  |  1 -
 roles/cgit/make_pkgs_list/tasks/main.yml  |  5 -
 roles/infinote/files/gitconfig|  3 -
 roles/infinote/files/infinoted-git-commit |  4 -
 roles/infinote/files/infinoted.service| 13 ---
 roles/infinote/handlers/main.yml  |  2 -
 roles/infinote/tasks/main.yml | 95 --
 .../templates/infinote.fedoraproject.org.conf | 98 ---
 roles/infinote/templates/infinoted.conf   | 23 -
 17 files changed, 6 insertions(+), 422 deletions(-)
 delete mode 100644 inventory/group_vars/infinote
 delete mode 100644 playbooks/groups/infinote.yml
 delete mode 100644 roles/cgit/base/files/cgitrc.infinote
 delete mode 100644 roles/cgit/make_pkgs_list/files/cgit-projects-infinote
 delete mode 100644 roles/infinote/files/gitconfig
 delete mode 100755 roles/infinote/files/infinoted-git-commit
 delete mode 100644 roles/infinote/files/infinoted.service
 delete mode 100644 roles/infinote/handlers/main.yml
 delete mode 100644 roles/infinote/tasks/main.yml
 delete mode 100644 roles/infinote/templates/infinote.fedoraproject.org.conf
 delete mode 100644 roles/infinote/templates/infinoted.conf

diff --git a/inventory/backups b/inventory/backups
index d072f1f8b..6eb8361d7 100644
--- a/inventory/backups
+++ b/inventory/backups
@@ -1,5 +1,5 @@
 #
-# This is the list of clients we backup with rdiff-backup. 
+# This is the list of clients we backup with rdiff-backup.
 #
 [backup_clients]
 db01.phx2.fedoraproject.org
@@ -8,7 +8,6 @@ db-datanommer02.phx2.fedoraproject.org
 db-fas01.phx2.fedoraproject.org
 batcave01.phx2.fedoraproject.org
 ci-cc-rdu01.fedoraproject.org
-infinote.fedoraproject.org
 pagure01.fedoraproject.org
 people02.fedoraproject.org
 pkgs02.phx2.fedoraproject.org
diff --git a/inventory/group_vars/infinote b/inventory/group_vars/infinote
deleted file mode 100644
index 68ffd7484..0
--- a/inventory/group_vars/infinote
+++ /dev/null
@@ -1,41 +0,0 @@

-# Define resources for this group of hosts here.
-lvm_size: 2
-mem_size: 4096
-num_cpus: 2
-
-# for systems that do not match the above - specify the same parameter in
-# the host_vars/$hostname file
-
-custom_rules: [
-# Need for rsync from log01 for logs.
-'-A INPUT -p tcp -m tcp -s 10.5.126.13 --dport 873 -j ACCEPT',
-'-A INPUT -p tcp -m tcp -s 192.168.1.59 --dport 873 -j ACCEPT',
- ]
-
-tcp_ports: [80, 443, 6523, 9418]
-
-fas_client_groups: sysadmin-noc,fi-apprentice,sysadmin-veteran
-
-freezes: false
-
-git_port: 9418
-git_server: /usr/libexec/git-core/git-daemon
-git_server_args: --export-all --syslog --inetd --verbose
-git_basepath: /srv/web
-git_daemon_user: nobody
-
-# For the MOTD
-csi_security_category: Low
-csi_primary_contact: Fedora admins - ad...@fedoraproject.org
-csi_purpose: Run the 'infinote' backend for gobby
-csi_relationship: |
-There are a few things running here:
-
-- infinote server for gobby
-- cgit server to serve gobby content
-- web server
-
-- This host relies on: Nothing
-
-- Things that rely on this host: Nothing
diff --git a/inventory/inventory b/inventory/inventory
index 6d19ed38c..5831252c0 100644
--- a/inventory/inventory
+++ b/inventory/inventory
@@ -997,8 +997,8 @@ value
 [fedmsg_ircs_stg:children]
 value_stg
 
-# This group is for "instances" we have in inventory but do not 
-# want to monitor in nagios because they don't really exist as 
+# This group is for "instances" we have in inventory but do not
+# want to monitor in nagios because they don't really exist as
 # hosts you can monitor.
 [nixnagios]
 # This is the centos-ci relay hosts as fedmsg sees it
@@ -1284,9 +1284,6 @@ pagure01.fedoraproject.org
 [pagure_stg]
 pagure-stg01.fedoraproject.org
 
-[infinote]
-infinote.fedoraproject.org
-
 [gnome_backups

Re: [PATCH] robosignatory: add f31/f32 infra tags and f31-gnome side tag to be signed.

[Clement Verna]

+1 looks good to me

On Tue, 3 Sep 2019 at 19:31, Kevin Fenzi  wrote:

> Signed-off-by: Kevin Fenzi 
> ---
>  roles/robosignatory/files/robosignatory.production.py | 18
> ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/roles/robosignatory/files/robosignatory.production.py
> b/roles/robosignatory/files/robosignatory.production.py
> index 2d7013b..e2cbc3d 100644
> --- a/roles/robosignatory/files/robosignatory.production.py
> +++ b/roles/robosignatory/files/robosignatory.production.py
> @@ -50,6 +50,12 @@ config = {
>  "keyid": "3c3359c4"
>  },
>  {
> +"from": "f31-gnome",
> +"to": "f31-gnome",
> +"key": "fedora-31",
> +"keyid": "3c3359c4"
> +},
> +{
>  "from": "f31-python",
>  "to": "f31-python",
>  "key": "fedora-31",
> @@ -98,6 +104,18 @@ config = {
>  "key": "fedora-infra",
>  "keyid": "47dd8ef9"
>  },
> +{
> +"from": "f31-infra-candidate",
> +"to": "f31-infra-stg",
> +"key": "fedora-infra",
> +"keyid": "47dd8ef9"
> +},
> +{
> +"from": "f32-infra-candidate",
> +"to": "f32-infra-stg",
> +"key": "fedora-infra",
> +"keyid": "47dd8ef9"
> +},
>
>  # Gated coreos-pool tag
>  {
> --
> 1.8.3.1
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] upgrade the koji fedora-messaging plugin in prod

[Clement Verna]

On Fri, 30 Aug 2019 at 17:06, Pierre-Yves Chibon 
wrote:

> Good Morning,
>
> I would like to propose to upgrade the koji plugin for fedora-messaging so
> it
> integrates these changes:
> https://pagure.io/koji-fedmsg-plugin/pull-request/5
> which hopefully will fix
> https://pagure.io/fedora-infrastructure/issue/8158
>
> Worst case they don't and we can revert and we're back to square one.
> Best case it works :)
>
> We tried testing this in staging but the way koji and bodhi are currently
> configured in koji is making it quite difficult (koji is still on
> rawhide=f31
> while bodhi has already been synced from prod, and koji isn't configured
> to let
> robosignatory signs builds in the f30 tags...).
>
> Thoughts?
>

+1 since the message currently does not work and rolling back in case of
problem is pretty easy.


>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org