<div dir="ltr">Bump. Any more questions on this? I'd like to get something agreed on and settled.<div><br></div><div>Thanks!<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 1:28 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Nov 3, 2017 at 11:58 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"><span><br>
<br>
On 11/02/2017 10:25 AM, Michael Hrivnak wrote:<br>
> I've been working on a planning task for how Pulp 3 will handle global importer settings. As part of that,<br>
> I've collected feedback from a number of stakeholders. You can view the planning task here:<br>
><br>
> <a href="https://pulp.plan.io/issues/2373" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/23<wbr>73</a><br>
><br>
> The aspect that everyone seems to agree on is that proxies should be configured once in one place, and that<br>
> other download-related settings are a good fit for the same mechanism. I wrote up a story for that here, and I<br>
> would appreciate feedback and grooming:<br>
><br>
> <a href="https://pulp.plan.io/issues/3108" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/31<wbr>08</a><br>
><br>
> There is much less clarity around other settings. This is because most other settings that we would consider<br>
> for global scope would need the ability to be overridden at the individual importer level. That multi-layered<br>
> approach where an individual importer's settings take precedence over the global settings is how Pulp 2 works,<br>
> but it is not generally liked. Katello for example only uses that feature in Pulp 2 to define download-related<br>
> settings; proxy, concurrency, and bandwidth limits. Many stakeholders expressed concern about retaining a<br>
> multi-layered approach to configuring importers. Doing so also would add substantial complexity to how Pulp 3<br>
> implements settings, and it adds complexity to the user experience.<br>
<br>
</span>Can you elaborate on what pulp2 users don't like about the "multi-layered" approach in pulp2?<br>
<br>
IIRC, pulp2 only supports the "override config" thing (which I agree, few users like) and not something<br>
persistent.  I suspect that users don't like the pulp2 implementation but may find the more sophisticated<br>
profile concept appealing even with a precedence model.  Not supporting a model where the importer attributes<br>
take precedence over the profile will likely limit the properties in the profile to just the proxy.<br>
<br>
This could be a more powerful feature.  I'm imagining cases where users would find it useful for the profile<br>
to include properties beyond proxy URL (or other download properties).  Perhaps even the download or sync<br>
policies.  Who knows.<br>
<br>
I do recognize that we really only have a concrete use case for the proxy but seems short sighted to design<br>
what seems to be intended as a more general concept that would be so limited.<br>
<br>
I don't perceive a precedence model as being particularly complex.</blockquote><div><br></div></div></div><div>Pulp 2 has a three-layer approach. You can define importer settings globally in a json file on disk, on an importer record in the DB, and in an override config passed at the time of requesting an individual sync. That contributes to it being difficult to know what settings actually got used for any particular sync. And since the same setting can be set in multiple places, users are sometimes surprised that a sync doesn't behave the way they expected.</div><div><br></div><div>I think there is a place for having global importer settings that influence how the imports happen. The download policy (immediate, on-demand, etc) is a good example of something a user may want to set globally. I think we could figure out a reasonable 2-layer approach to doing that. But since importers are a master/detail model, that introduces some complexity. And I do not see any particular reason we would need to deliver this feature in 3.0.</div><div><br></div><div>Download settings are different, because I think the best way to model them is in one place without any layering. And from a use-case standpoint, users will logically group download settings differently than importer settings. For example:</div><div><br></div><div>I want to use a proxy for external traffic, a different one for traffic to a data center, and none for internal traffic. It's all about physical network characteristics, and not at all about content and repos.</div><div><br></div><div>I want to set a download policy, or other importer settings, based on other factors. Certain vendors, or certain products/repos within a specific vendor, should get the same download policy based on things like how likely I think it is that I'll need all the content in the repo, how reliable I think that vendor will be at providing it on-demand, whether I expect to test it up-front, etc.</div><div><br></div><div>So based on that, I think these are two different kinds of data that we should handle separately. We can make a DownloadProfile with a well-defined purpose, and that has the single source of data for any attributes it stores. Later we could figure out how to make importer settings configurable globally by adding a second layer, enabling master/detail with that layer, etc.</div></div><span class=""><div><br></div>-- <br><div class="m_6137562205659561574gmail_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>
</span></div></div>
</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>