<div dir="ltr">I was also going to bring up that content is currently addressable based on the unit. That's an option we could keep in Pulp 3. It may or may not be best, but it's a viable option. The one thing I like about it is the simplicity of ownership and cleanup. There is no race condition around file management nor a need to manage orphaned files.<div><br></div><div>I also want to clarify again that moving a file within the same filesystem is crazy cheap. I don't think we need to worry about having something transient like FileUpload and also an Artifact model as long as they are being stored on the same filesystem, which /var/lib/pulp/ should always be. Object storage will be even easier I think, because we'd just reference the same remote object from both models.</div><div><br></div><div>All that said, I do like the idea of tracking Artifact uniqueness separately. I just want to figure out exactly what we gain, vs. the expense.</div><div><br></div><div>Jeff, earlier in the thread we talked about using the through table to hold the path. I think that's the right place, because the path would be a property of the relationship between an artifact and a content unit. It also occurred to me that the file name could be different for different content, so maybe the path would need to include the filename. That seems a bit weird, but I think it has to be the case if we use a many-to-many relationship.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 30, 2017 at 8:53 AM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's my understanding that the advantage of the proposed change to how the storage path is calculated to be<br>
based on the sha256 digest of the artifact's file itself, is so that uploads can be stored directly as<br>
Artifacts.  In other words, an artifact can be created independently of a content unit and stored at a<br>
deterministic location.  This is effectively CAS (content addressed storage).  As a result, each artifact is<br>
absolutely unique and stored exactly once.  In pulp2 and pulp3 (currently), each artifact is unique within its<br>
content unit by relative path.  The binary uniqueness introduces a requirement of a many-to-many relationship<br>
between Artifact <-> Content.  For example: an EL7 RPM that is associated with an RPM content unit and an EL7<br>
distribution.<br>
<br>
There is a lot I like about this approach.  However, one thing that needs to be accounted for is the<br>
'relative_path' field on the Artifact.  It represents the artifact's location within the content unit.  This<br>
information is vital to publishing multi-artifact content such as distributions.  Perhaps a modeling change<br>
would resolve this.  Just thinking out loud:<br>
<br>
File 1--n Artifact n--1 Content.<br>
<br>
File<br>
-----------------<br>
[pk] id<br>
path <--- FileField:  MEDIA_ROOT/files/digest[0:2]/<wbr>digest[2:]/<name>  # not sure about <name><br>
downloaded<br>
sha1<br>
sha224<br>
sha256<br>
...<br>
<br>
<br>
Artifact<br>
------------------<br>
[pk] id<br>
[fk] file_id<br>
[fk] content_id<br>
relative_path<br>
<br>
Files can be uploaded directly to `File`.  I think this would support the proposed upload API.<br>
<br>
Thoughts?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 06/30/2017 06:53 AM, Jeff Ortel wrote:<br>
> Perhaps I missed something .. when did the "random path" get proposed?  In pulp2 and in pulp3 (currently), the<br>
> artifact's path is deterministic.<br>
><br>
> MEDIA_ROOT/content/units/<<wbr>type>/digest[0:2]/digest[2:]/<<wbr>relative-path><br>
><br>
> where The digest is the sha256 hex-digest of the content unit's natural key.  For example, the natural key for<br>
> RPM content is the NEVREA and checksum.<br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>