-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] "raw" pulp api providers. #253
Comments
That does sound interesting. I'm working on #252. This includes a bunch of other code to make testing easier. My first plan is to get the admin PR in and hopefully the acceptance testing. With that we know what we have and how well it works. It also gave me much more insight in the puppet types and providers. Regarding the authentication: current providers read the pulp admin config for credentials and even uses the pulp-admin command for some actions. That's similar to your json file, but maybe better for re-use. It should fall back to username/password when the login cert is unavailable though. |
I merged #252 so there's less code to convert now. My plan is to be at the birthday event at Inuits. If you happen to be there as well we could have a look at the implementation. |
The current types combine multiple aspects of a repository into a single type. @SimonPe's types map directly to the API. The benefit is that you can combine multiple distributors into a single repository. As discussed IRL:
At this point we should have a working solution, but there's redundancy. We will look into creating wrappers that provide the same functionality of the current types but use the new types. These might be defines and we can deprecate the current types. |
Hej,
I have some time coming up where I can invest some time and energy into pulp puppet code.
I would like to get https://github.com/SimonPe/puppet-pulpapi merged into puppet-pulp in some way/shape/form.
These providers map 1-on-1 to the pulp api. The idea is that once the objects in the rest api can be managed by the providers, we can build our own abstraction layers in defined types. (Once we have a solid ruby base, other people can stick to normal puppet code)
The main issue here is what to do with the current types/providers and their users. If we start using the straight api calls with these low-level types, we can no longer decently combine them with the existing pulp-admin types.
To ease the migration there are a couple of options.
ofc, we also should probably have a major version release.
I would also love to have some feedback on authentication.
Currently these types and providers use credentials (user/password) stored by puppet in a little json file in $vardir.
This has always looked sub-ideal to me, but I'm not sure what the better way to go is. Any ideas wrt this are welcome.
Any feedback welcome.
ps: cc'ing ~ anybody i can find here with interest in these types providers.
cc: @ehelms @ekohl @joshuabaird @cristifalcas @rgarrigue
pps: wrt the defined types to replace the current native types: I don't plan on reducing any functionality.
ppps: yes, the whole code will get a thorough cleanup before i post a pr.
The text was updated successfully, but these errors were encountered: