The system that you are describing will look something like this. (ascii graphics are a bit off but best I can do)

            [dnf/yum]<-+
               |
            [mirrors]<-+               [other clients]
                       |                   |
[copr]  <-> [aws-cdn] <-> [dl.fpo] <-> [NFS-server]
                                           |   
                                  +--------+-------+----------+
                                  |        |       |          |
                             [some builders]   [koji]    [other backend tools]

The pipe that dl.fpo (and other parts) has is a 2 gigabit pipe and we are mostly using it for dnf/yum from users and mirrors. The aws cdn shows up for some of the user traffic but we have been at 100% utilization with mirrors not able to get traffic. The NFS server is on 40GB but the koji shares are a large share with a lot of clients asking stuff from it. The CPU/cache on the server is pretty loaded with this.

The aws cdn could help on this but it would need to balance out what can be done.

So, we actually already do this for ostree... and could for this... but the problem is that the content changes very often, so I am not sure cloudfront is going to help too much.

On the other side, I don't think copr builders could cause that much load. Builds would be staggered I would think right, not generally hitting all at the same time?

So, personally, I would say it would be ok to just use directly and if there's some issue we could try and add cloudfront, but as smooge notes we have had BW problems, so it might be nice to get those solved before enabling ?

So my summary: wait a bit to make this easier until we have more BW, then enable it directly and unless we see a issue we are done, if we do, we look at cloudfront?

@praiskup does that all sound fine to you?

Do you want us to keep this open to let you know when we have more BW? or do you just want to look at enabling it and see how it goes?

While repodata changes quite often, new builds are not added that often, and the actual RPM packages don't ever change. I believe that with cache TTL varying for repodata and RPM package, and with toplink rewrite technique (as described in ticket #7383) the load on Koji servers would be quite limited.

Sure, we could, but it seems like a lot of work for not much gain. I mean we have 191 koji builders right now using those repos...

I think there's fewer copr builders than that * the fraction that have enabled these repos = small number

I don't see it really impacting things much. I could be wrong, but if so, we can always setup a cdn then?

So, gonna close this now. If you see any problems with the repos after you enable them, we can revisit (But I do not think you will :)