Project

Profile

Help

Story #5662

Manage Pulp via Ansible modules

Added by Timoses about 1 month ago. Updated 22 days ago.

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

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

Description

I've been testing ansible modules to manage Pulp.

https://github.com/ansible/ansible/pull/64388

Please let me know what you think.

History

#1 Updated by bmbouter about 1 month ago

  • Sprint/Milestone deleted (3.0)

#2 Updated by bmbouter about 1 month ago

@Timoses there is another developer @mdellweg (aka x9c4 on IRC) who is also developing a similar thing. I wanted to connect you both to de-duplicate effort and share testing. If I've misread the similarity then please continue!

#3 Updated by mdellweg about 1 month ago

@timoses For completenes sake, here's the link to that project [0].

I have already seen, that you took somehow similar but still different approaches to deal with the api. And you seem to be aiming for less modules that can handle e.g. remotes of different types, while i would rather implement one module for each type of remote. I think that way it is easier to account for the subtle specialities, but i'd like to also hear your reasoning.

[0] https://github.com/mdellweg/ansible_modules_pulp

#4 Updated by Timoses 22 days ago

@mdellweg

Looks great! Your approach looks a bit cleaner.

What would you think of a `PulpApiLoader` class or similar which would be responsible for loading the APIs and handing the correct classes.
All in all I believe that part requires some more abstraction (one function per plugin type and remote/publication/... seems unnecessary since OpenAPI appears to follow strict naming conventions).

If you don't mind I'd try to find the time in the upcoming week to implement something like that to make it easier to add plugin types.

I'd also suggest to take your code base as a basis and combine our efforts. What's your take on it?

Separating modules by plugin type does make the documentation and implementation easier I believe. In my implementation, I like and dislike the dynamic loading of the appropriate module arg_specs for various pulp plugins. It's both convenient but at the same time complicates implementation details. Thinking about it now I'd rather go with separate modules just to keep it simple.
From a user perspective I suppose it would not make much of a difference. What do you think?

Please register to edit this issue

Also available in: Atom PDF