Base Squid Configuration for Repo Mirroring

Hello All. I tried to look some available solutions for transparent (read low maintenance) repository caching and the best thing I have found is the one from Ubuntu available here: https://wiki.ubuntu.com/SquidDebProxy Basically it is fully based on squid with some auto configuration and additional service discovery capabilities. Do not need to use it in full at all, but we can use the config available there as a base point to review and start with: http://bazaar.launchpad.net/~mvo/+junk/squid-deb-proxy/view/head:/squid-deb-... I also think we do not need acl to limit it to the domains as we have several repos used and they are added/removed along the way. So we can try with simply file type based acls. Then if we wisely setup our stats collection we should be able to asses how it perform and if any problems identified - try to address them individually. Those are my 2 cents. Anton. -- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat

Can you update it in the relevant ticket on JIRA? We'll then have all the info in once place to make the best decision. On Wed, Jul 20, 2016 at 10:09 PM, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello All.
I tried to look some available solutions for transparent (read low maintenance) repository caching and the best thing I have found is the one from Ubuntu available here:
https://wiki.ubuntu.com/SquidDebProxy
Basically it is fully based on squid with some auto configuration and additional service discovery capabilities. Do not need to use it in full at all, but we can use the config available there as a base point to review and start with:
http://bazaar.launchpad.net/~mvo/+junk/squid-deb-proxy/view/head:/squid-deb-...
I also think we do not need acl to limit it to the domains as we have several repos used and they are added/removed along the way. So we can try with simply file type based acls. Then if we wisely setup our stats collection we should be able to asses how it perform and if any problems identified - try to address them individually.
Those are my 2 cents.
Anton.
-- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

Hello Eyal. Sure. Added to https://ovirt-jira.atlassian.net/browse/OVIRT-645 On Thu, Jul 21, 2016 at 10:06 AM, Eyal Edri <eedri@redhat.com> wrote:
Can you update it in the relevant ticket on JIRA? We'll then have all the info in once place to make the best decision.
On Wed, Jul 20, 2016 at 10:09 PM, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello All.
I tried to look some available solutions for transparent (read low maintenance) repository caching and the best thing I have found is the one from Ubuntu available here:
https://wiki.ubuntu.com/SquidDebProxy
Basically it is fully based on squid with some auto configuration and additional service discovery capabilities. Do not need to use it in full at all, but we can use the config available there as a base point to review and start with:
http://bazaar.launchpad.net/~mvo/+junk/squid-deb-proxy/view/head:/squid-deb-...
I also think we do not need acl to limit it to the domains as we have several repos used and they are added/removed along the way. So we can try with simply file type based acls. Then if we wisely setup our stats collection we should be able to asses how it perform and if any problems identified - try to address them individually.
Those are my 2 cents.
Anton.
-- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel
phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat
participants (2)
-
Anton Marchukov
-
Eyal Edri