Story #5662

Manage Pulp via Ansible modules

Added by Timoses 8 months ago. Updated 8 months ago.

Start date:
Due date:
% Done:


Estimated time:
Platform Release:
Sprint Candidate:


I've been testing ansible modules to manage Pulp.

Please let me know what you think.


#1 Updated by bmbouter 8 months ago

  • Sprint/Milestone deleted (3.0.0)

#2 Updated by bmbouter 8 months 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 8 months 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.


#4 Updated by Timoses 8 months ago


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