<div dir="ltr">I've posted a PR[0] that resolves this issue. I tested that I can upload content, publish it, download it from a distribution. I also tested that I can sync, publish, download from the distribution. The file path is also correct when requesting an artifact via REST API. <br><br>[0] <a href="https://github.com/pulp/pulp/pull/3178">https://github.com/pulp/pulp/pull/3178</a><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 1:27 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/28/2017 10:39 AM, Brian Bouterse wrote:<br>
> One of the things I heard was that we aren't sure why we have this custom storage backend> I was very surprised to hear that because it was developed and merged.<br>
<br>
Yes, implementing a custom storage back-end for no good reason would be surprising. But, that's not what<br>
happened.<br>
<br>
The detailed reasons where very well understood at the time. Basically, the behavior of the FileSystemStorage<br>
with regard to the way it calculated actual storage paths and how it stored files was incompatible with our<br>
needs. I should have documented those exact details but didn't. I was more interested in getting pulp3<br>
storage working. Given the unexpected (and undocumented) behavior and code complexity in the<br>
FileSystemStorage, it seemed safer and easier to implement a few extra methods than to extend.<br>
<span class="gmail-"><br>
> I want to make sure we understand custom code we've written before we go too much further. > I think that is why we put it on the sprint currently.<br>
<br>
</span>If the purpose is to document requirements, do a gap analysis and re-design a solution, this task should not<br>
yet be groomed and aligned to a sprint.<br>
<span class="gmail-"><br>
><br>
> On Thu, Sep 28, 2017 at 11:06 AM, Jeff Ortel <<a href="mailto:jortel@redhat.com">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> On 09/28/2017 08:56 AM, Dennis Kliban wrote:<br>
</span><div><div class="gmail-h5">> > On Tue, Sep 26, 2017 at 11:14 AM, Jeff Ortel <<a href="mailto:jortel@redhat.com">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>>>> wrote:<br>
> ><br>
> > Team,<br>
> ><br>
> > I am fine with revisiting storage as some point but disagree that #2950 should be *high* priority (higher than<br>
> > most other tasks) and should not aligned with sprint 26. As noted in redmine, Our FileStorage implementation<br>
> > conforms to the django storage interface, is simple and tested. The django provided FileSystemStorage has<br>
> > concerning code quality and is completely undocumented. To safely subclass it will require inspecting the<br>
> > code line-by-line to ensure predictable behavior when overriding any of it's methods. As you all know,<br>
> > reliable storage is a critical part of Pulp.<br>
> ><br>
> ><br>
> > We use the rest of Django without inspecting every line of code, so I don't see a reason to treat the<br>
> > FileSystem storage backend any different. We are using Django so we can reduce the amount of code we are<br>
> > maintaining ourselves. Completely reimplementing the storage backend goes against that goal. I plan to work on<br>
> > this issue today.<br>
><br>
> The rest of django is documented. The FileSystemStorage class is not. Not even docstrings. It has<br>
> undocumented behaviors and the only way to understand them is to read the code.<br>
><br>
> I just have a hard time understanding why this is higher priority than these other sprint tasks like:<br>
><br>
> 3024 content creation API does not validate the hostname portion of the URL.<br>
> 3021 Database writes are not all recorded in DB<br>
> 2994 Erratum not updated after upstream change<br>
> 2988 Exception when raising a user-Defined that has a custom __init__.<br>
> 2373 Planning on how to support global importer<br>
><br>
> And ... everything else left to do for the MVP.<br>
><br>
> ><br>
> > -Dennis<br>
> ><br>
> ><br>
> > As I said, it's a fine idea to revisit this. But, looking at the other tasks aligned to sprint 26 (and, all<br>
> > the work left to do for the MVP), this is not higher priority.<br>
> ><br>
> > -jeff<br>
> ><br>
> ><br>
> > <a href="https://pulp.plan.io/issues/2950" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>2950</a> <<a href="https://pulp.plan.io/issues/2950" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>2950</a>><br>
> <<a href="https://pulp.plan.io/issues/2950" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>2950</a> <<a href="https://pulp.plan.io/issues/2950" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/<wbr>2950</a>>><br>
> ><br>
> ><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Pulp-dev mailing list<br>
</div></div>> <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <mailto:<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> <<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>
><br>
<br>
</blockquote></div><br></div></div></div>