Added pulp_repo custom type

[rothgar]

See README for usage and examples.

[jeremycline]

Hey, sorry (again) for leaving this so long. I want to talk to some people before digging into this, but I don't want to leave you in the dark about what's going on.

I'm convinced this is a good thing for our Puppet module to offer. Unfortunately, the Pulp CLI is not very machine-friendly right now, so using it in Puppet is hard. I'm not yet sure whether the same functionality in this PR can be done with a few clever (or hacky) execs in Puppet, which would be easier to deal with (because I don't know Ruby very well) until we get a nicer CLI.

If it is doable, I would prefer to use that method for the sake of maintence. Hopefully before the end of the work day today I will let you know.

[rothgar]

I wouldn't expect the CLI to need to be cleaned up too much because most of what types/providers do in puppet is just call execs and check the output (that's what this one does).

There are some areas that need cleaning up (parsing/checking existing repos and settings) but for now it is working.

One other option instead of re-writing the entire CLI or making ruby bindings would be to make a tool using the existing python bindings that is more machine friendly. It could output in a more usable format and we could change the provider to use that tool instead.

[jeremycline]

Small update: I played a bit (https://gist.github.com/jeremycline/dfc31f8659cedc2186b5) and I think this is very doable without Ruby custom types. I may play a bit more over the weekend. It sure isn't pretty, but that will be less of an issue when the CLI starts doing things like using reasonable return codes.

[rothgar]

I think it would just matter if that is the right solution. I like the simplicity of that option but not sure it can handle as many options as a custom type.

This is my first type but I'm really not sure which is a better approach with such a complex tool like pulp

[mhrivnak]

Publishes can also be scheduled. If these schedules will only be for sync, then it would be more clear to call this parameter something like sync_schedules.

[rothgar]

This still needs some testing, but syntax was updated.

[i11]

Any progress guys? It would be great to finally have this type.

[rothgar]

Someone just last week brought up an issue where feed_cert and feed_key are ignored on repo creation. There is also a bug where multiple sync_schedules are created that I haven't looked at.

I'll try to get the feed_cert and feed_key working this week. Everything at that point should work as advertised with just some minor bugs to deal with.

[bowlofeggs]

Hello @rothgar! I've been looking at this PR. First, apologies that it has been ridiculously long since we've looked at it. We don't have any Puppet or Ruby experts on our team, so I think we've all been shy about it.

I got a friend who knows Puppet and Ruby to check it out, and so I feel comfortable merging. I also tried out the code and it does appear to work. Thanks!

One thing - we have a policy of having all commits being atomic. I tried to squash all the commits in this pull request into one, and something seems to be odd about them (they seem to conflict). I think this might be the reason the README.md file has some of the example code repeated.

Can you squash the commits into one, resolving the conflicts? Let me know when you are done with that and I'll test it again.

One more thing you should know - the Katello project has also independently developed a Puppet module for Pulp. We have been talking with them about eliminating this Puppet module in favor of theirs since they have Puppet and Ruby experts on their project. It would be better to have one module than two anyway, and then the Pulp project wouldn't have PRs that sit for so long either. We haven't decided for sure what we will do, but I wanted to let you know that this module might have an uncertain future. If you are interested in following our progress on this, see https://pulp.plan.io/issues/1023

Sorry again for the long delay.

[rothgar]

@rbarlow I haven't spent much time on this because I've moved from stand alone pulp to katello. If they have a manifest that does the same thing I'd probably rather people use that because I am no ruby expert. Even this custom type has some known bugs (duplicate schedules).
Maybe it would be better for me to look at katello's custom type and merge features into it if any are lacking.
This first hack could be closed, save me time rebasing and squashing commits and then a single custom type could be used moving forward.
How does that sound?

[bowlofeggs]

@rothgar That sounds good to me. Again, we are very sorry for taking so long with your pull request. Hopefully we will be able to merge with Katello's to avoid these problems in the future!

[rothgar]

Just for clarification, is this the katello puppet repo you were referencing? https://github.com/Katello/puppet-pulp
I don't see any repo creating options there but could talk to them if they would even want me to add them to their module.

[bowlofeggs]

On 06/02/2015 03:47 PM, Justin Garrison wrote:

Just for clarification, is this the katello puppet repo you were
referencing? https://github.com/Katello/puppet-pulp
I don't see any repo creating options there but could talk to them if
they would even want me to add them to their module.

Yes, that is correct. I believe that module is maintained much more
actively than our own is. It is true that they do not have all the
features that we have, and we also do not have all the features they
have. Hopefully, we will be able to achieve something together so we
don't have to maintain two!

Randy Barlow