<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>the goal from our side is to have a very similar experience to
the user. Today the user would:</p>
<p>* run a command (for example, something similar to hammer
content-view version export --content-view-name=foobar
--version=1.0)</p>
<p>* this creates a tarball on disk</p>
<p>* they copy the tarball to external media</p>
<p>* they move the external media to the disconnected katello</p>
<p>* they run 'hammer content-view version import
--export-tar=/path/to/tarball</p>
<p>I don't see this changing much for the user, anything additional
that needs to be done in pulp can be done behind the cli/api in
katello. Thanks!<br>
</p>
<p>Justin<br>
</p>
<div class="moz-cite-prefix">On 2/19/20 12:52 PM, Dennis Kliban
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPmNiuq8PiopX4dAvzUxJ9efHmE5N_2th_Uuhjb9nWaf3Zfkgg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">In Katello that uses Pulp 2, what steps does the
user need to take when importing an export into an air gapped
environment? I am concerned about making the process more
complicated than what the user is already used to. <br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 11:20
AM David Davis <<a href="mailto:daviddavis@redhat.com"
moz-do-not-send="true">daviddavis@redhat.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Thanks for the responses so far. I think we
could export publications along with the repo version by
exporting any publication that points to a repo version.
<div><br>
</div>
<div>My concern with exporting repositories is that users
will probably get a bunch of content they don't care about
if they want to export a single repo version. That said,
if users do want to export entire repos, we could add this
feature later I think?<br clear="all">
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
</div>
<div>David<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at
10:30 AM Justin Sherrill <<a
href="mailto:jsherril@redhat.com" target="_blank"
moz-do-not-send="true">jsherril@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 2/14/20 1:09 PM, David Davis wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Grant and I met today to discuss importers and
exporters[0] and we'd like some feedback before we
proceed with the design. To sum up this feature
briefly: users can export a repository version
from one Pulp instance and import it to another. </div>
<div><br>
</div>
# Master/Detail vs Core
<div><br>
</div>
<div>So one fundamental question is whether we
should use a Master/Detail approach or just have
core control the flow but call out to plugins to
get export formats.</div>
<div><br>
</div>
<div>To give some background: we currently define
Exporters (ie FileSystemExporter) in core as
Master models. Plugins extend this model
which allows them to configure or customize the
Exporter. This was necessary because some plugins
need to export Publications (along with repository
metadata) while other plugins who don't have
Publications or metadata export
RepositoryVersions.</div>
<div><br>
</div>
<div>The other option is to have core handle the
workflow. The user would call a core endpoint and
provide a RepositoryVersion. This would work
because for importing/exporting, you wouldn't ever
use Publications because metadata won't be used
for importing back into Pulp. If needed, core
could provide a way for plugin writers to write
custom handlers/exporters for content types.</div>
<div><br>
</div>
<div>If we go with the second option, the question
then becomes whether we should divorce the concept
of Exporters and import/export. Or do we also
switch Exporters from Master/Detail to core only?</div>
<div><br>
</div>
<div># Foreign Keys</div>
<div><br>
</div>
<div>Content can be distributed across multiple
tables (eg UpdateRecord has UpdateCollection,
etc). In our export, we could either use primary
keys (UUIDs) or natural keys to relate records.
The former assumes that UUIDs are unique across
Pulp instances. The safer but more complex
alternative is to use natural keys. This would
involve storing a set of fields on a record that
would be used to identify a related record.</div>
<div><br>
</div>
<div># Incremental Exports</div>
<div><br>
</div>
<div>There are two big pieces of data contained in
an export: the dataset of Content from the
database and the artifact files. An incremental
export cuts down on the size of an export by only
exporting the differences. However, when
performing an incremental export, we could still
export the complete dataset instead of just a set
of differences (additions/removals/updates). This
approach would be simpler and it would allow us to
ensure that the new repo version matches the
exported repo version exactly. It would however
increase the export size but not by much
I think--probably some number of megabytes at
most.</div>
</div>
</blockquote>
<p>If its simper, i would go with that. Saving even
~100-200 MB isn't that big of a deal IMO. the biggest
savings is in the RPM content. <br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>[0] <a href="https://pulp.plan.io/issues/6134"
target="_blank" moz-do-not-send="true">https://pulp.plan.io/issues/6134</a></div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>David<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Pulp-dev mailing list
<a href="mailto:Pulp-dev@redhat.com" target="_blank" moz-do-not-send="true">Pulp-dev@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank" moz-do-not-send="true">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank"
moz-do-not-send="true">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote>
</div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank"
moz-do-not-send="true">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>