Project

Profile

Help

Network maintenance. Planio will be observing two scheduled maintenance windows this Tuesday, March 2 and Wednesday, March 3 from 02:00 UTC until 06:00 UTC each in order to perform maintenance on access routers in our primary datacenter. Your account might observe short downtimes during these periods up to several minutes at a time.

Story #6329

Story #6134: [EPIC] Pulp import/export

As a user, I can create/read/update/delete PulpImporters

Added by daviddavis 12 months ago. Updated 11 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Associated revisions

Revision be696b23 View on GitHub
Added by daviddavis 11 months ago

Added support for importing Pulp Exports

fixes #6329 fixes #6137

History

#1 Updated by daviddavis 11 months ago

Looking at the import API in the design document[0], it looks like there's just a resource PulpImporter that's available at /pulp/api/v3/pulp_importers/. I wonder if we should make importers master/detail models though? Mostly to mirror Exporters (eg /pulp/api/v3/exporters/core/pulp/). That said, I can't think of a use case for this since most of the time, plugins import via sync.

[0] https://hackmd.io/HLptudH9R6S4PCmm8nRmmg#Import

#2 Updated by daviddavis 11 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to daviddavis

#3 Updated by ggainey 11 months ago

daviddavis wrote:

Looking at the import API in the design document[0], it looks like there's just a resource PulpImporter that's available at /pulp/api/v3/pulp_importers/. I wonder if we should make importers master/detail models though? Mostly to mirror Exporters (eg /pulp/api/v3/exporters/core/pulp/). That said, I can't think of a use case for this since most of the time, plugins import via sync.

[0] https://hackmd.io/HLptudH9R6S4PCmm8nRmmg#Import

The original intent was for import and export to mirror each other (the APIs originally matched), to among other things minimize user confusion. Also, won't MasterDetail give plugin authors an opportunity to customize/tweak the import process where it may be necessary?

#4 Updated by bmbouter 11 months ago

Making importers master detail is probably the better thing to do. sync's are great for one repo, but we could have future use cases that require us to bring in content to a group of repositories with another mechanism. daviddavis did I understand your question correctly?

#5 Updated by bmbouter 11 months ago

ggainey wrote:

The original intent was for import and export to mirror each other (the APIs originally matched), to among other things minimize user confusion. Also, won't MasterDetail give plugin authors an opportunity to customize/tweak the import process where it may be necessary?

+1 to Master/Detail, but that's not the mechanism plugin writers use to tweak the import/export process for their content and it's associated models.

What Master/Detail allows is for plugin writers to define a whole, new import codepath that they exclusively own with it's own, new URL endpoints.

#6 Updated by daviddavis 11 months ago

We also discussed this at the rpm meeting today and I think support for using Master/Detail was unanimous. I've updated the design doc.

#7 Updated by pulpbot 11 months ago

  • Status changed from ASSIGNED to POST

#8 Updated by daviddavis 11 months ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

#9 Updated by ttereshc 11 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE
  • Sprint/Milestone set to 3.3.0

Please register to edit this issue

Also available in: Atom PDF