On Tue, May 10, 2016 at 08:52:00AM -0400, Stephen John Smoogen wrote: > On 10 May 2016 at 03:02, Adrian Reber <adrian@xxxxxxxx> wrote: > > On Mon, May 09, 2016 at 01:49:26PM -0600, Kevin Fenzi wrote: > >> On Fri, 6 May 2016 17:30:18 -0500 > >> Adam Miller <maxamillion@xxxxxxxxxxxxxxxxx> wrote: > >> > >> ...snip... > >> > >> > > >> > Proposal: > >> > > >> > Pulp[1] + Crane[2] + MirrorManager[3] + Docker Distribution[4] > >> > >> Are all of these packaged up? For EPEL? > >> (aside mirrormanager). > >> > >> ...snip... > >> > >> > Workflow: > >> > OSBS will perform Builds, as these builds complete they will be > >> > pushed to the docker-distribution (v2) registry, these will be > >> > considered "candidate images". Pulp will sync and publish the > >> > candidate repository. > >> > > >> > Testing will occur using the "candidate images" (details of how > >> > we want to handle that are outside the scope of this proposal). > >> > >> So, at this point the 'candidate image' is just in pulp? > >> Or it's been published to a directory and mirrored out? > >> I'm guessing it would be published and mirrored so people could test it? > >> > >> ...snip... > >> > >> > Mirror Manager will Pulp distribute to the mirrors the image > >> > layers and their metadata. > >> > >> This should work for mirrors to just rsync the directories right? > > > > From a MirrorManager point of view it would be important, that this > > does not result in thousands of new files. The atomic directory contains > > over 700000 files which massively increases sync time for the mirrors > > and crawl times from our side as well as an increase in database size. > > Depending on the number of files this might be a candidate for a new > > rsync module. > > > > I was going to bring up that I think that atomic is a good candidate > for its own sync module. The amount of lookups having to be done on > the atomic directory has really increased the amount of IOPS on the > data where only certain groups are interested in it. Agreed. I just did not want to go into more details of the atomic tree in the this thread. Important for me was to mention to not further increase the number of files in fedora/linux/. Adrian
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
