<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 2:17 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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">Originally I scheduled a meeting for tomorrow but on second thought, I figured a pulp-dev thread would be more inclusive than a meeting. I hope to get this resolved by the end of this week and if not then maybe we can have a meeting. <div><br></div><div>This is to design out the replacement of task tags in Pulp 3. I’ve got feedback from a few other developers in terms of how to do that so I wrote up a sort of outline of the problem and two possible proposals. Looking for feedback/questions/etc on what people prefer.</div><div><br></div><div><div><br></div><div><div>Background</div><div>---</div><div><br></div><div>In Pulp 2, tasks have tags that either provide a task name/description or info on what resources a task acts on. Tasks also have reserved resources, which provide a way for tasks to lock a particular resource.</div></div></div></div></blockquote><div><br></div><div>To provide a little more background, the tags are there 100% for clients. It's a way for a client to find and display tasks based on a specific resource, and maybe of a specific type (sync, publish, etc).</div><div><br></div><div>Reserved resources exist for business logic on the server side that is mostly transparent to the client and user.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div>In Pulp 3, we have models TaskTag and ReservedResource[0]. Tasks are associated with the resources they work on via TaskTag. If a resource is locked, a ReservedResource record is created in the db and then removed from the db once the resource is unlocked.</div><div><br></div><div><br></div><div>Problem</div><div>---</div><div><br></div><div>The task tag model doesn't really fit Pulp 3. It's perhaps too generic and totally unnecessary (see Proposal 1), or it could be redesigned to accomodate other things (see Proposal 2).</div><div><br></div><div>Also, we need to support created resources (e.g. publications) with tasks. Refactoring task tags might provide an opportunity to do so.</div><div><br></div><div><br></div><div>User stories</div><div>---</div><div><br></div><div>As an authenticated user, I can see what resource(s) a task acted on.</div><div>As an authenticated user, I can search for a tasks based on what resource they acted on.</div><div><br></div><div><br></div><div>Proposal 1</div><div>---</div><div><br></div><div>Since tags and reserved resources in Pulp 3 will only store information about a particular repository (not 100% sure here), it should be possible to simplify the data model. We could ditch both TaskTag and ReservedResource models and just have a direct relationship between Tasks and Repositories (e.g. TaskRepository). This model could also have some sort of field to indicate whether a particular field is locked (e.g. is_locked). Unlike ReservedResource, this relationship would be persisted—only the is_locked field would be updated when a task is done.</div></div></div></div></blockquote><div><br></div><div>Using a repo and locking a repo are different relationships. Consider an operation that only reads a certain repository and does not need to lock it, such as the dep solving we were talking about today, or applicability calculation. Or consider a publish operation on a repo version, which is immutable; it would not need to lock the repo, but would still use it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div><br></div><div>Proposal 2</div><div>---</div><div><br></div><div>We could keep the TaskTag relationship (perhaps even rename it to TaskResource) and we could add a field to indicate the nature of the relationship between task and resource (e.g. created, updated, etc). This field could not only capture what TaskTag is currently used for but also stuff like created resources (e.g. publications). We could also have a field to indicate which task resources are locked (e.g. is_locked).</div></div></div></div></blockquote><div><br></div><div>That's very interesting. I like the idea of RESTful references to resources that get used, and adding a qualifier for the type of relationship (created, read, locked, deleted, etc) could be very useful.</div><div><br></div><div>If we used strong relationships instead of a string field to identify reserved resources, one thing we would lose is the ability to lock on something more abstract than a resource. We've done that in the past, but I don't think anyone's loved it, so maybe we don't need it. As an example, if we want only one orphan-purge task to run at a time, we can reserve a resource named "orphan-removal". We did this for applicability calculation for some time in Pulp 2 when there were safety questions about running them concurrently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div>This would be useful for <a href="https://pulp.plan.io/issues/3033" target="_blank">https://pulp.plan.io/issues/<wbr>3033</a>.</div><div><br></div><div><br></div><div>Questions</div><div>---</div><div><br></div><div>- What proposal do we want to adopt?</div><div>- When do we need to address these changes?</div><div>- Do we really need to allow users to search tasks by a resource/repo at all?</div></div></div></div></blockquote><div><br></div><div> I think they do need the ability to see what tasks are queued for a given repo, and also what tasks have been recently completed.</div></div><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></div>