Skip to content
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

Open
LadyNamedLaura opened this issue Jun 9, 2017 · 3 comments
Open

[RFC] "raw" pulp api providers. #253

LadyNamedLaura opened this issue Jun 9, 2017 · 3 comments

Comments

@LadyNamedLaura
Copy link
Contributor

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.

  • put a big fat WARNING in the readme (that everybody will ignore) not to combine these 2 types of types
  • put a deprecation warning on the old types
  • build defined types that mirrors the current native types as close as possible (though they will need to use a different name due to the module scope)
    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.

@ekohl
Copy link
Member

ekohl commented Jun 9, 2017

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.

@ekohl
Copy link
Member

ekohl commented Jul 12, 2017

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.

@ekohl
Copy link
Member

ekohl commented Jul 18, 2017

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:

  • I will look through @SimonPe's repository
    • Submit PRs for obvious fixes
    • Create issues for non-obvious ones
  • We will do it with pure ruby so we don't have to ship a gem into the AIO install. This means we won't be using runcible
  • We will then integrate the types and providers into this repo
    • Both current and new types will co-exist for a while
    • Big fat warning that using both types can give unexpected results, especially if you're purging both.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants