As an admin of a domain-ized system, I can use an un-domain-ized tasking API

[bmbouter]

We admin a Pulp system which has hundreds of domains, e.g. ~600. Recently we wanted to look at the tasking system via API to see how many tasks were in the waiting state. Is it right that we can only do that per domain? If so, we need some way to get the total picture in a more practical sense.

So more or less: As an admin I can have the un-domain-ized tasking API endpoint available on domain-enabled installations.

[bmbouter]

We are using this in the services installation, see this patch.

That roots the URL on domain-enabled systems at api/pulp/admin/tasks/. For domain-disabled systems this new viewset wouldn't even exist since users should all use the existing api/pulp/v3/tasks/ endpoint.

@ggainey and @mdellweg what do you think about:

1. the URL for domain-ized systems will be api/pulp/admin/tasks
2. that if a system is domain-disabled the viewset won't be visible or present at all?

[mdellweg]

It should live at api/v3/pulp/tasks/ in all cases. And it should not behave special in any way apart from not be scoped to a domain, right? In the case of Domains not enabled nothing changes.

[bmbouter]

That makes sense. What we did on the services install is very simple, but I'm suspecting here that what needs to be done to contribute this upstream is actually pretty complicated. My naive plan was to take the snippet below from this patch in services and add an entry for it in urlpatterns at api/v3/pulp/tasks/.

class TaskViewSet(TaskViewSet):

    LOCKED_ROLES = {}

    def get_queryset(self):
        qs = self.queryset
        if isinstance(qs, QuerySet):
            # Ensure queryset is re-evaluated on each request.
            qs = qs.all()

        if self.parent_lookup_kwargs and self.kwargs:
            filters = {}
            for key, lookup in self.parent_lookup_kwargs.items():
                filters[lookup] = self.kwargs[key]
            qs = qs.filter(**filters)

        return qs

    @classmethod
    def view_name(cls):
        return "admintasks"

I suspect we'll run into a bunch of issues if we do that though:

1. That's not how to add a viewset into Pulp typically
2. What happens when we try to subclass a domainized viewset and turn it into a non-domainized view set...
3. What about all the Roles stuff? We don't use any of that on our services install so I'm not sure what we would do there
4. What about tests? If everything else was solved I think we can solve this one too

We'll need someone to help explain what the path to contribution here is. The original idea of taking a patch from services and handing it back is looking non-feasible to me at this point.