hi guys,
I've been looking at using pulp ( pulpproject.org ) as a means to promote rpms into the evolving repos ( updates/ extras/ plus/ etc ) as opposed to static repos ( os/ ). So that people running large infra do not need to rely on the msync targets, leaving those available for public mirror use.
This is very much a spike test to see if pulp is usable for such a role. The thinking is that there is a .centos.org hosted pulp master ( or a few ) and Content nodes in various geo distributed places, with every one wanting to run a private mirror just bringing up a content node, associating it with the repo's they care about and letting that content instance sync on schedule. removing the need to repo-manage completely.
The pulp project guys have been very very receptive of constructive criticism and have even offered to take up some of the recommendations I had, as feature requests. So even if we do find there are massive holes that are not filled in a way by pulp today, there might be scope for them to find workarounds or even see if they can find suitable fix's
I have asked on IRC and the main list for people who might be willing to help trial and evaluate this process, but havent been able to get much support. So asking here as well, anyone with a few machines willing to spend a few hours working out the issues that such a setup might have ?
- KB
On Fri, Jan 27, 2012 at 9:13 AM, Karanbir Singh mail-lists@karan.org wrote:
hi guys,
I've been looking at using pulp ( pulpproject.org ) as a means to promote rpms into the evolving repos ( updates/ extras/ plus/ etc ) as opposed to static repos ( os/ ). So that people running large infra do not need to rely on the msync targets, leaving those available for public mirror use.
Not sure I understand the project concept. I don't ever want to mirror anything anywhere or do anything that needs per-disto, per-version configuration and maintenance, but I'd love to be able to point yum at a pair of my own proxies (preferred/failover) and have those proxies cache things in a configurable/usable way.
On 01/27/2012 07:55 PM, Les Mikesell wrote:
I've been looking at using pulp ( pulpproject.org ) as a means to promote rpms into the evolving repos ( updates/ extras/ plus/ etc ) as opposed to static repos ( os/ ). So that people running large infra do
Not sure I understand the project concept. I don't ever want to mirror anything anywhere or do anything that needs per-disto, per-version configuration and maintenance, but I'd love to be able to point yum at a pair of my own proxies (preferred/failover) and have those proxies cache things in a configurable/usable way.
This effort is targeting people who want to run complete distro mirrors internally within their own network.
On Fri, Jan 27, 2012 at 6:15 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/27/2012 07:55 PM, Les Mikesell wrote:
I've been looking at using pulp ( pulpproject.org ) as a means to promote rpms into the evolving repos ( updates/ extras/ plus/ etc ) as opposed to static repos ( os/ ). So that people running large infra do
Not sure I understand the project concept. I don't ever want to mirror anything anywhere or do anything that needs per-disto, per-version configuration and maintenance, but I'd love to be able to point yum at a pair of my own proxies (preferred/failover) and have those proxies cache things in a configurable/usable way.
This effort is targeting people who want to run complete distro mirrors internally within their own network.
I'd like a program that fixed the underlying reasons that make you need a local distro mirror, but don't think copying a bunch of stuff just because it is there is the solution.
On 01/28/2012 04:30 AM, Les Mikesell wrote:
I'd like a program that fixed the underlying reasons that make you need a local distro mirror, but don't think copying a bunch of stuff just because it is there is the solution.
feel free to write something, suggest an app. This specific efforts has a different problem:solution pair.
On 01/27/2012 04:13 PM, Karanbir Singh wrote:
hi guys,
I've been looking at using pulp ( pulpproject.org ) as a means to promote rpms into the evolving repos ( updates/ extras/ plus/ etc ) as opposed to static repos ( os/ ). So that people running large infra do not need to rely on the msync targets, leaving those available for public mirror use.
This is very much a spike test to see if pulp is usable for such a role. The thinking is that there is a .centos.org hosted pulp master ( or a few ) and Content nodes in various geo distributed places, with every one wanting to run a private mirror just bringing up a content node, associating it with the repo's they care about and letting that content instance sync on schedule. removing the need to repo-manage completely.
The pulp project guys have been very very receptive of constructive criticism and have even offered to take up some of the recommendations I had, as feature requests. So even if we do find there are massive holes that are not filled in a way by pulp today, there might be scope for them to find workarounds or even see if they can find suitable fix's
I have asked on IRC and the main list for people who might be willing to help trial and evaluate this process, but havent been able to get much support. So asking here as well, anyone with a few machines willing to spend a few hours working out the issues that such a setup might have ?
- KB
It seams that I would have use for this project, so I will try to find some time to help out. I will not promise anything, but I AM interested in this.
First off, I will study the docs and then probably create one server instance to see how this works.
Do you have server set up? Any time frame so I can decide what and when I could set aside some time?
On Sat, Jan 28, 2012 at 7:40 AM, Karanbir Singh mail-lists@karan.org wrote:
On 01/28/2012 04:30 AM, Les Mikesell wrote:
I'd like a program that fixed the underlying reasons that make you need a local distro mirror, but don't think copying a bunch of stuff just because it is there is the solution.
feel free to write something, suggest an app. This specific efforts has a different problem:solution pair.
I think the problem is generally the same. Or problems: yum with a mirrorlist makes caching problematic, without one it has a failure point, and yum doesn't do repeatable updates. But if you would arrange the picture on the pulp site into small groups of clients doing different services at several different remote sites it might be easier to why I don't think an intermediate mirror is a good solution. What I want is to be able to test updates to a machine configured for a service, then repeat that update predictably across the set of machines at disparate locations, perhaps concurrently with another set at a different update level. I'd prefer to not bother the official mirrors for more than one copy of a package, but not badly enough to copy packages I don't need or create my own failure point. I have standard caching proxies at most locations, but they don't help much until you have pulled a copy from each mirror. Everyone with more than one machine at a location is going to have the caching issue. Everyone with different testing groups is going to have the multiple state issue. There has to be a way to deal with the problems that doesn't involve maintaining a mirror per-distribution, per-version, per-location, per-reproducible-state. Even if a tool makes that easy, it can't be the right thing to do. Who even wants to keep track of the last user of each mirror to know when to deactivate it?
-
Karanbir Singh -
Les Mikesell -
Ljubomir Ljubojevic