= phenomenon =
I'd like to ask for download service for the Spacewalk project, hosted on yum.spacewalkproject.org.
= background analysis =
Currently, Spacewalk releases are available from http://spacewalk.redhat.com/yum/ and http://spacewalk.redhat.com/source/. At the same time, Red Hat owns the spacewalkproject.org domain for the Spacewalk project. The only live resource is koji.spacewalkproject.org, which is where spacewalk.redhat.com synces the rpms from. We would like to strengthen the Spacewalk project "brand" by putting the releases to its own domain instead of the spacewalk.redhat.com subdomain. I've asked RH's IT to setup the download service and have been recommended to use Fedora's PHX2 infrastructure, since we already use Fedora hosted for Spacewalk's git anyway.
= implementation recommendation =
Could you please approve setup of download service for yum.spacewalkproject.org on Fedora's PHX2 infrastructure?
The content can be synced from koji.spacewalkproject.org via rsync.
The current disk space occupied is 7.6 GB, for two years to come I do not see us exceeding 15 GB.
I assume I would need to know the IP address(es) / FQDN of the machine(s) which would be syncing the content to allow it on koji.spacewalkproject.org, and the IP address(es) / FQDN of the machine(s) which would be hosting the content to tell this to Red Hat's IT, to make changes in the DNS.
Thank you,
Jan
Ok talking with Seth clarified how to do this:
1) On the amazon side set up a vhost yum.spacewalkproject.org which points to some sub-tree of https://fedorahosted.org/releases/s/p/spacewalk/ (say https://fedorahosted.org/releases/s/p/spacewalk/repos/)
2) You can then upload the data and do the createrepos on fedorahosted.org like you are uploading the tar balls there.
3) RHIT will provide an A record in DNS for yum.spacewalkproject.org that points to the existing amazon server at 184.73.181.118
If this causes problems with the existing server, we can set up a vhost on fedorahosted but this seemed to allow you the most flexibility.
Can you be more specific about the "vhost yum.spacewalkproject.org which points to some sub-tree of https://fedorahosted.org/releases/s/p/spacewalk/"?
If the A record points to 184.73.181.118 then any traffic will go to Amazon and be charged, which is what I wanted to avoid in the first place.
Adelton, you set a redirect on the vhost at yum.spacewalkproject.org
any connection there gets redirected to fedorahosted.
so the only billing you'll be hit with is the very small http redirect hit.
not all the data downloaded from the archive.
Replying to [comment:6 skvidal]:
Adelton, you set a redirect on the vhost at yum.spacewalkproject.org any connection there gets redirected to fedorahosted.
Ah, redirect.
Well, I can really do the same with redirect to spacewalk.redhat.com/yum. In both cases, the yum.spacewalkproject.org will be publishable in documentation and usable but the target location will show up in the browser, so people will still be using the "target" URL, because from their point of view, it will save them one 302 request.
How hard would be it to setup that vhost on fedorahosted itself?
Talking with various folks involved, we are going to see if we can't just get the vhost added to the spacewalk.redhat.com server. If that does not work out, we can reopen this and look for other options.
Login to comment on this ticket.