<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 26, 2017 at 11:14 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">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></blockquote><div><br></div><div>We use the rest of Django without inspecting every line of code, so I don't see a reason to treat the FileSystem storage backend any different. We are using Django so we can reduce the amount of code we are maintaining ourselves. Completely reimplementing the storage backend goes against that goal. I plan to work on this issue today. <br></div><div><br></div><div>-Dennis<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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/29<wbr>50</a><br>
<br>
</blockquote></div><br></div></div>