<div dir="ltr"><div>We (Katello) have been working to expose the "iso" type to users as a "file" type repository for exposing generic content support. In this way, users can use Katello as a single gateway for any content and Pulp to store and manage the underlying content for them. I've created a feature request [1] to make this a first-class plugin in Pulp.</div><div><br></div><div>On to my questions. As I understand it, users can either upload content directly or sync a "file" location in the same way that say an RPM repository is synced. The difference being that Pulp requires a PULP_MANIFEST file that indicates:</div><div><br></div><div> * filename</div><div> * filesize</div><div> * checksum</div><div><br></div><div>And while we can provide a script to generate this recursively for users [2], this requires them to have access to the content to place the PULP_MANIFEST file or to mirror the content locally, generate the manifest file and then sync. However, the latter seems both redundant and the intent of Pulp (to mirror content for me!). Now for my questions:</div><div><br></div><div>1) Is there a work around or way to configure Pulp to not require the manifest file and simply slurp up whatever it finds?</div><div>2) Is there a strategy we could implement to do #1 if it does not already exist? Something that perhaps scans the structure, builds some base level knowledge of what is present and allows Pulp to sync it?</div><div><br></div><div>I think this would also play into the situation where I want to slurp up larger files without having to upload (as I feel Pulp syncing them is more robust than me uploading, this could however be a misconception on my part). I'm thinking of the situation where I want to use Pulp or Katello as a repository for my internal Vagrant boxes for example.</div><div><br></div><div><br></div><div>Thanks,</div><div>Eric</div><div><br></div><div>[1] <a href="https://pulp.plan.io/issues/2110">https://pulp.plan.io/issues/2110</a></div><div>[2] <a href="https://gist.github.com/ehelms/3fd956ee887db3d7bac20b29efa3dd51">https://gist.github.com/ehelms/3fd956ee887db3d7bac20b29efa3dd51</a></div></div>