Project

Profile

Help

Issue #3818

The AnsibleRole as a content unit is problematic

Added by daviddavis over 1 year ago. Updated 7 months ago.

Status:
MODIFIED
Priority:
Normal
Assignee:
Sprint/Milestone:
Start date:
Due date:
Severity:
2. Medium
Platform Release:
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
Yes
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 51

Description

A couple example problems:

- Orphan cleanup will probably remove AnsibleRole records
- Users can add AnsibleRoles (instead of AnsibleRoleVersions) to a content view

Make AnsibleRole not extend Content.


Related issues

Related to Pulp - Issue #4653: Orphan cleanup fails for some model types due to database cascade PROTECTED options CLOSED - WONTFIX Actions
Related to Ansible Plugin - Test #4756: Test sync from galaxy.ansible.com CLOSED - DUPLICATE Actions

Associated revisions

Revision ea5135e7 View on GitHub
Added by daviddavis 7 months ago

Combining role and role version into a single content unit

https://pulp.plan.io/issues/3818
fixes #3818

History

#1 Updated by daviddavis over 1 year ago

  • Triaged changed from No to Yes

#2 Updated by bmbouter 7 months ago

  • Description updated (diff)

+1 to this

#3 Updated by bmbouter 7 months ago

  • Groomed changed from No to Yes

#4 Updated by bmbouter 7 months ago

  • Sprint set to Sprint 51

#5 Updated by bmbouter 7 months ago

  • Related to Issue #4653: Orphan cleanup fails for some model types due to database cascade PROTECTED options added

#6 Updated by daviddavis 7 months ago

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

#7 Updated by daviddavis 7 months ago

Currently our endpoints for roles and role versions are:

/pulp/api/v3/content/ansible/roles/
/pulp/api/v3/content/ansible/roles/1/
/pulp/api/v3/content/ansible/roles/1/versions/
/pulp/api/v3/content/ansible/roles/1/versions/1/

If role is no longer Content, what should the new endpoints be?

#8 Updated by bmbouter 7 months ago

Do we maybe just go with role and have version be a field and consolidate on 1 model?

#9 Updated by daviddavis 7 months ago

When you install a role version with the ansible galaxy cli, it performs these steps:

1. First it gets the role pk from GET /api/v1/roles/ owner__username=... name=...
2. Then it queries a list of versions from /api/v1/roles/<role_pk>/versions/
3. It looks at these versions and downloads either the newest one or whichever one the user specified

Any thoughts on how to support this without a role pk?

#10 Updated by bmbouter 7 months ago

Well this explains why we modeled it this way I guess. So going back to the two-model option, we would end up making one of them a Viewset since it wouldn't be provided through Content's Master/Detail?

#11 Updated by daviddavis 7 months ago

I suppose so. Another option would be just have a content viewset for AnsibleRoleVersions and not expose Roles to users. They would have no way to CRUD roles but it would be an easy/simple solution.

#12 Updated by bmbouter 7 months ago

I think we want DRF to do the CRUD. And overall having these related models was making it more complex for DRF to provide basic CRUD for this type.

#13 Updated by daviddavis 7 months ago

  • Status changed from ASSIGNED to POST

#14 Updated by daviddavis 7 months ago

  • Status changed from POST to MODIFIED

#15 Updated by bmbouter 7 months ago

  • Tags deleted (Pulp 3)

#16 Updated by kersom 6 months ago

  • Related to Test #4756: Test sync from galaxy.ansible.com added

Please register to edit this issue

Also available in: Atom PDF