Pulp

@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!

@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

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?