Pulp

Here are questions I have:

1) What are the arguments for the task? scheduled_calls is not part of 3.0 so the signature would become: def sync(repo_id, sync_config_override=None) or maybe def sync(importer_id, importer_config_override=None)

2) Will validation of the importer's config occur in the task AND in the view layer? The 2.y code does it in both.

3) How will we handle unit counts? Is that going to be implicit in the unit creation or will the task have to "fully rebuild" the unit counts at the end?

bmbouter wrote:

Here are questions I have:

1) What are the arguments for the task? scheduled_calls is not part of 3.0 so the signature would become: def sync(repo_id, sync_config_override=None) or maybe def sync(importer_id, importer_config_override=None)

Having it take a reference to the importer seems most appropriate. The importer is the thing doing the sync, and the thing that has the data necessary to do the sync.

2) Will validation of the importer's config occur in the task AND in the view layer? The 2.y code does it in both.

Seems reasonable. I'm not sure the task should make any assumptions about how it got queued, or how good the validation was at that point. Generally in multi-service design, the less trust that's required between services, the more robust the system will be. "Every service for itself."

3) How will we handle unit counts? Is that going to be implicit in the unit creation or will the task have to "fully rebuild" the unit counts at the end?

Do you mean managing the repo counts that are stored on the repo? I think we're going to try auto-generating that on the fly in pulp 3 when a repo endpoint handles a request, which is much easier and cheaper to do with a relational DB than mongodb.

mhrivnak wrote:

bmbouter wrote:

Here are questions I have:

1) What are the arguments for the task? scheduled_calls is not part of 3.0 so the signature would become: def sync(repo_id, sync_config_override=None) or maybe def sync(importer_id, importer_config_override=None)

Having it take a reference to the importer seems most appropriate. The importer is the thing doing the sync, and the thing that has the data necessary to do the sync.

What do you mean by importer_id? UUID? repo + importer name?
Is it possible that importer will be deleted and then created again after the task was created? Or is deletion of importer going to be a celery task as well (and not just something performed in a view) so it is safe to refer to importer directly?

I think some of the removed deliverables need to come back.

• validating the importer
• setting the current working directory for the interpreter and then unsetting it at the end

Per discussion on pulp-dev[0] I'll suggest that these are the two pieces that we need to add back:

• raise a ValueError('feed cannot be null') if the feed is null <--- this is business logic
• setting the current working directory for the interpreter and then unsetting it at the end

[0]: https://www.redhat.com/archives/pulp-dev/2017-April/msg00007.html