Re: FBR: Make fpaste.org cert use letsencrypt

[Patrick マルタインアンドレアス Uiterwijk]

+1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: Make fpaste.org cert use letsencrypt

[Kevin Fenzi]

+1

kevin



signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Freeze Break Request: Update pungi on bodhi-backend01

[Kevin Fenzi]

Dusty notes that I was wrong here... this particular compose runs on
compose-x86-01, not bodhi-backend01.

It should still be easy enough to revert if it causes any problems tho.

kevin




signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Freeze Break Request: Update pungi on bodhi-backend01

[Stephen John Smoogen]

+1

On 24 April 2018 at 16:49, Kevin Fenzi  wrote:
> Greetings.
>
> I'd like to update pungi on bodhi-backend01 from
> pungi-4.1.23-4.fc27.noarch
> to
> pungi-4.1.23-5.fc27.noarch
>
> The -5 version backports a patch from:
> https://pagure.io/pungi/pull-request/910
> which is already upstream.
>
> This is needed for the f28 atomic composes which we are trying to get
> all set before release. It should be easy to back out if it causes
> issues with anything else.
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Freeze Break Request: Update pungi on bodhi-backend01

[Dusty Mabe]

On 04/24/2018 04:49 PM, Kevin Fenzi wrote:
> Greetings.
> 
> I'd like to update pungi on bodhi-backend01 from
> pungi-4.1.23-4.fc27.noarch
> to
> pungi-4.1.23-5.fc27.noarch
> 
> The -5 version backports a patch from:
> https://pagure.io/pungi/pull-request/910
> which is already upstream.
> 
> This is needed for the f28 atomic composes which we are trying to get
> all set before release. It should be easy to back out if it causes
> issues with anything else.
> 

+1 for me
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Freeze Break Request: Update pungi on bodhi-backend01

[Kevin Fenzi]

Greetings.

I'd like to update pungi on bodhi-backend01 from
pungi-4.1.23-4.fc27.noarch
to
pungi-4.1.23-5.fc27.noarch

The -5 version backports a patch from:
https://pagure.io/pungi/pull-request/910
which is already upstream.

This is needed for the f28 atomic composes which we are trying to get
all set before release. It should be easy to back out if it causes
issues with anything else.

kevin



signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora and PDC

[Michal Novotny]

> * I kinda don't like the tree of files in git. It would work, but it
seems poor, like we don't know how to use a database. Along with just
strange to work with.

We could use Git repo of yaml files as the basis but import data upon
each commit for each branch into a locally mounted sqlite DB. Commits
would be rejected if the import could not be completed. Then setup just
a tiny API upon that sqlite DB served by some micro webapp.

Access control, versioning and write access would be handled by Git,
but user-friendly, fast, read-only data access would be handled by
the sqlite + http API pair.

The Git backend can also probably also added later.

I am writing this because I think it's an interesting option from the
technical perspective, not because I would be actually involved with
PDC at the moment. I just wanted to share the idea in case somebody
finds it applicable.

clime

On Mon, Apr 23, 2018 at 7:34 PM, Ken Dreyer  wrote:

> On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky
>  wrote:
> > The difference is that PDC rpm-mappings API endpoint was result of two
> > sources:
> >  * Manual per-rpm mappings (overrides) - this is sort of suitable if you
> >have a product with just a couple source packages so it's manageable
> >this way (i.e Ceph case)
> >  * Results of compose metadata import - this is what Fedora/RHEL uses
> >because several thousands of source packages are not manageable
> >one-by-one by humans manually.
> >
> > You could still make a system that would create "PRs" for the generated
> > files for second case, but then querying the current state will still be
> > a bit tricky. I guess...
>
> Yeah, the fact that we have (at least) two different input and storage
> methods there is a lot of complexity. I'm not sure that's a good
> design in 2018.
>
> Regardless, you're right, I'm envisioning that we'd have a tool to
> generate the data commits and PRs (or just commit + push directly).
> PDC had included its own rudimentary form of version control for
> auditing and message bus integration. Git's experience is much richer.
>
> - Ken
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: bodhi-3.6.1

[Randy Barlow]

On 04/23/2018 05:00 PM, Randy Barlow wrote:
> I would like to deploy Bodhi 3.6.1[0,1] to production
This was deployed to production last night and ran fine for a while but
eventually caused an outage, so the traffic was sent back to the 3.5.2 VMs.

This morning Patrick and I got some quality log tailing going and sent
traffic back to OpenShift on the same deployment that had the issue last
night and things seemed to handle the load just fine. In fact, the
constant HTTP 500s that the VMs were sending do not seem to happen in
OpenShift. We watched it for a while and it seemed stable.

Patrick noted that both times Bodhi had failed in OpenShift happened to
be when Bodhi was running composes. We asked Mohan to kick off some
composes, and he started one this morning (well, morning for me anyway).
I noticed that Bodhi's /composes/ endpoint went from loading in about
0.7 s to about 3-6 s from my house with one compose running. I believe
the time this endpoint takes to load might be approximately linear with
the number of composes it needs to serialize.

If 1 compose can take up to 6 seconds to load, 8 composes could easily
take more than 30 seconds in my estimation, and OpenShift was configured
to use this endpoint as a health check. We originally had the health
check on Bodhi's home page, but due to the dogpile cache locks sometimes
the home page could take a long time to load in the past. However, the
home page was also the source of the constant HTTP 500's in Bodhi 3.6.0.
3.6.1 was a refactor of many things, including home page caching. Now
that we see 0 500's on the home page, and now that the home page cache
is warmed up during worker start, it consistently loads in about 0.7 s.

Today we configured OpenShift to again monitor Bodhi's home page. Now
that the home page consistently loads quickly, it should pass the health
check consistently too. I will be monitoring Bodhi throughout the day.
Hopefully this was the last hurdle to having it work in OpenShift!
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: Fix collectd problems with containers

[Ricky Elrod]

+1, thanks for this

-re

On Mon, Apr 23, 2018 at 9:18 PM, Stephen John Smoogen  wrote:
> Updated patch to get the other directories which were filling up collectd
>
> diff --git a/roles/collectd/base/templates/collectd.conf.j2
> b/roles/collectd/base/templates/collectd.conf.j2
> index 91f5a63..0de9b40 100644
> --- a/roles/collectd/base/templates/collectd.conf.j2
> +++ b/roles/collectd/base/templates/collectd.conf.j2
> @@ -39,6 +39,24 @@ LoadPlugin vmem
>  IgnoreSelected false
>  
>
> +
> +  Interface "/^veth/"
> +  IgnoreSelected true
> +
> +
> +
> +  Interface "/^df-var-lib-docker-containers-/"
> +  Interface "/^df-var-lib-docker-overlay2-/"
> +  Interface "/^df-run-user-/"
> +  Interface "/^df-tmp-tweak/"
> +  Interface "/^df-mnt-fedora_koji/"
> +  Interface "/^df-var-lib-mock-fedora/"
> +  Interface "/^df-tmp-iso-mount-/"
> +  Interface "/^df-var-lib-origin-openshift/"
> +  Interface "/^df-.*\.snapshot/"
> +  IgnoreSelected true
> +
> +
>  
> TranslateDevicename false
>  
>
>
>
> On 23 April 2018 at 21:14, Kevin Fenzi  wrote:
>> +1 to fix it.
>>
>> kevin
>>
>>
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>>
>
>
>
> --
> Stephen J Smoogen.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: [Fedocal] Reminder meeting : Bodhi stakeholder's meeting

[Randy Barlow]

On 04/23/2018 11:00 PM, bowlofe...@fedoraproject.org wrote:
> You are kindly invited to the meeting:
>Bodhi stakeholder's meeting on 2018-04-24 from 15:00:00 to 16:00:00 UTC
>At fedora-meetin...@irc.freenode.net

I am going to cancel today's meeting as I need to focus on the
deployment stability issues, and there also isn't much else to discuss.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org