<div dir="ltr">Talking ReservedResource over further with @mhrivnak and @bmbouter on IRC, it sounds like only repositories can be ReservedResources. Therefore, we should probably convert the resource text field into a resource_id foreign key to the repositories table instead of having a generic foreign key. <div class="gmail_extra"><div><div class="m_4315667291687455341m_-2268665772423357020gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jun 30, 2017 at 3:03 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"><span>On Fri, Jun 30, 2017 at 2:36 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for digging into this.<div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Jun 29, 2017 at 3:16 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I've been working on supporting tags in Pulp 3[0] and have gotten some feedback from various other developers. I'd like to open up the discussion though to a broader audience and see if anyone has any feedback.</div><div><br></div><div>Background:</div><div><br></div><div>Currently in Pulp 2, there are two types of task tags: action and resource. Action tags indicate the action being performed (sync, publish, etc), while resource tags indicate the resource type (repository, publisher, etc) and the resource id of the resource being acted upon.</div></div></blockquote><div><br></div></span><div>For extra context, this is all a relic from before Pulp was even using celery. Back then it had a home-grown task system that all operated inside a single process, and these tags were used more extensively than today. At this point I think they are primarily used by REST API clients to have some understanding of what a task is doing. There may be no other use.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Proposal:</div><div><br></div><div>In Pulp 3, we ought to get rid of tags. For action tags, we'll simply add a field named "name" to the task table. This will store information about which action the tag is performing (sync, publish, etc).</div></div></blockquote><div><br></div></span><div>I suggest these correlate directly to the task name as celery knows it, which we can (and probably should) manually set. It defaults to the python path, but it's better to have a stable value that won't change due to refactor.</div></div></div></div></blockquote><div><br></div></span><div>Agreed.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>For resource tags, these will be replaced with Task Resources. Like resource tags, these will be a one-to-many relationship to tasks (ie a task will have many task resources). These Task Resources then have a one-to-one generic relation[1] to any object in Pulp that a task can act on.</div></div></blockquote><div><br></div></span><div>When you say one-to-one, I think that would actually be a one-to-many, right? A GenericForeignKey ? A resource needs to be able to be referenced by more than one task.</div></div></div></div></blockquote><div><br></div></span><div>Yes, good catch.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Should we use the same generic relation for ReservedResource? Currently it stores "resource" as a text field. Consistency seems valuable.</div></div></div></div></blockquote><div><br></div></span><div>Yea, I think that would be a good idea.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Database Tables:</div><div><br></div><div>Task</div><div>---</div><div>...</div><div>name - varchar</div><div><br></div><div>TaskResource</div><div>---</div><div>id - uuid</div><div>task_id - uuid (foreign key to a task)</div><div>content_type - varchar (e.g. "Repository")</div><div>object_id - uuid (generic foreign key to a repo/publisher/etc)</div><div><br></div><div>Rest API:</div><div><br></div><div>For task names, this field will be returned when querying tasks and can also be filtered, etc when searching tasks. Pretty straightforward.</div><div><br></div><div>For Task Resources, I'm imagining that there won't be a separate API for Task Resources. Instead, task resource information will be returned along with tasks in a list field such as "resources." This presents a bit of a problem though: each resource will have different data depending on the type of resource (repo, publisher, etc)[2]. Alternatively, we could return a homogeneous list of hashes with fields like type (Publisher/Repository, etc), id, and href. However, I think this is less useful to users.</div></div></blockquote><div><br></div></span><div>I think this should be serialized as a simple list of URLs to the corresponding resources. That is REST's way of Uniformly doing Resource Identification. ;) This is a topic I've been meaning to email this list about anyway, to get us thinking more RESTful than in the past. We need to break away from the idea that REST API clients should know about primary keys, natural keys, or anything similar as the means through which to reference a resource. This rant by the creator of REST is a fun starting point for reading about how to identify resources:</div><div><br></div><div><a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" target="_blank">http://roy.gbiv.com/untangled/<wbr>2008/rest-apis-must-be-hyperte<wbr>xt-driven</a></div></div></div></div></blockquote><div><br></div></span><div>+1</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>For filtering, I think it would be possible to filter on content_type and object_id in Task Resource but I think this would be inconvenient for users. I think it would be easier if we define some shortcuts (e.g. repository_id, publisher_id, etc) that users can use to filter on. I'm imagining one such id filter for every possible content_type.</div></div></blockquote><div><br></div></span><div>If they can filter based on a resource's URI, I think that would cover the basic filtering use cases for this field.</div></div></div></div></blockquote><div><br></div></span><div>+1</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="m_4315667291687455341m_-2268665772423357020m_2406315373559524070m_-3560116297527330644HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_4315667291687455341m_-2268665772423357020m_2406315373559524070m_-3560116297527330644m_-5661131568453067016gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">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;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div>
</font></span></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>