<div dir="ltr"><div>@asmacdo, your points cause me to also think that all importer/publisher update and delete operations should be tasks that use the tasking reservations system. That will cause them to never run while a sync or publish for instance is running. I'm interested in hearing more thoughts on this from others.<br><br></div>A related question... are importers or publishers ever shared with multiple repos in Pulp3?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 17, 2017 at 12:08 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"> I think everyone seems to be leaning in the direction that update does not [need to be a task].</span></blockquote><div><br></div><div>I am leaning that updates and deletes should be tasks for importers and publishers in order to get the full benefit of the reserved resource system. The most important point is that related work will be done in a predictable order.</div><div> <br></div><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><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></div><div>Delete could be a little more challenging, because of the potential desire for an importer or publisher to want to update attributes on it, like the last time a sync succeeded. Maybe we can manage to avoid the need for a plugin to write to its config, which also seems like a very reasonable goal, but that again could be part of the plugin API discussion. Although thinking about relationships that are likely to exist in the database, having an importer or publisher disappear while a corresponding task is running sounds like it could cause a lot of potential problems.</div></div></blockquote><div><br></div></span><div>Deletes are simplest if they aren't allowed to "cut in line". Then it is the user's responsibility to ask Pulp to do work in a reasonable order, and failures will be deterministic.</div><div><br class="m_2689017911515108662gmail-Apple-interchange-newline">Another scenario comes up because we removed overrides from our MVP. A workaround would be: Update to temp config, sync, update back to old config. If update and delete are synchronous, the user would have to monitor the state of the sync task, and could not issue the second update request until the sync task is complete (or at least started).<br></div></div></div></div></div>
</blockquote></div><br></div>