<div dir="ltr"><div>Discussions with Katello uncovered a use-case that we thought about briefly in the initial design of import/export, and then put aside to get to first-light. That issue is "must be able to export a specific set of RepositoryVersions for the specified Repositories" (as opposed to "export current-version always"). This is a large use case for katello's lifecycle-workflows.<br></div><div><br></div><div>In the design doc this is mentioned under 'Exporter' - the implication being that if one wants this, one creates a new Exporter every time. This is...not a great approach. </div><div><br></div><div>Exporter and Importer work at the Repository level. This is so that the user can map upstream and downstream repositories once, at Importer-create-time, and then reuse that Importer repeatedly. If an Exporter is a single-use entity, as this approach would imply, it requires the user to do that startup work every time.</div><div><br></div><div>A better (imho) approach is to allow a set of RepositoryVersions to be specified at Export-creation time (by, say, providing a repositories=[<href-list.] parameter to POST .../exports/) . The impact on the Export process is minimal - where now it runs down the list of Repositories in the Exporter and gets latest-version from each, it would just take the provided list instead. </div><div><br></div><div>There is an extra validation step needed.  The provided RepositoryVersions <b>MUST </b>be <b>1-to-1</b> associated with the Repositories on the Exporter, or Import isn't going to know what to do with them. (must be 1-to-1, but not necessarily 'onto' - you may specify fewer RepositoryVersions than you have Repositories, it just means the missed-Repositories aren't provided in the Export)</div><div><br></div><div>There is an open question: How does this interact with incrementals and last_export? Current implementation assumes that today's export is going to be 'newer than' the last time an Exporter fired. and an incremental is the difference, for a given Repository, between the RepoVersion in last_export and today's state. Allowing export-by-specific-version might break that, will need to do some POC work to convince myself one way or another.</div><div><br></div><div>I have a nagging feeling that we are still missing something about this use case. I definitely need more viewpoints on this; can I get comments/thoughts by COB 29-APR? This is pretty important to be flattened to support katello's workflows.</div><div><br></div><div>Thanks for reading this far!</div><div>G</div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Grant Gainey</div><div>Principal Software Engineer, Red Hat System Management Engineering</div></div></div></div></div></div>