The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #11864

zypper repository type

Added by Darin Perusich almost 3 years ago. Updated over 1 year ago.

Status:ClosedStart date:01/10/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:package
Target version:-
Affected Puppet version:2.7.9 Branch:https://github.com/puppetlabs/puppet/pull/468
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Hello,

Attached is a new type for describing zypper software repositories for OpenSUSE/SUSE systems, or any distribution using zypper for software management. It is a port of the ‘yumrepo’ repo type from the Puppet 2.7.9 code base.

zypprepo.rb Magnifier (11.7 KB) Darin Perusich, 01/10/2012 09:23 am

History

#1 Updated by James Turnbull almost 3 years ago

  • Category set to package
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Anonymous
  • Affected Puppet version set to 2.7.9

#2 Updated by Dominic Cleal almost 3 years ago

Darin, would you be able to submit a pull request via github for this? It’ll make sure the code doesn’t fall through the cracks then.

https://github.com/puppetlabs/puppet/blob/master/CONTRIBUTING.md contains the information you need. Looks like the CLA’s already done, so fork on github and submit a pull request through there.

Cheers!

#3 Updated by Darin Perusich almost 3 years ago

Dominic,

I “think” my pull request has been completed, I’ve seen an email come through on the puppet-dev mailing list for it.

#4 Updated by Dominic Cleal almost 3 years ago

  • Status changed from Needs Decision to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/puppet/pull/468

Thanks Darin, the merge request’s been opened so one of the dev team will review it and provide feedback there usually.

#5 Updated by Anonymous almost 3 years ago

Darin Perusich wrote:

I “think” my pull request has been completed, I’ve seen an email come through on the puppet-dev mailing list for it.

Darin, thanks for submitting this code. It actually looks solid, and effective. With everything you have done we could merge that into core.

That said, we are trying to do the opposite right now: to encourage code like this to be distributed through the Puppet Forge as a module.

That has a bunch of advantages for you, but the single most compelling advantage is that you can release an updated module any time, and users can update it any time.

If we merge this into core then any bug fix has to go through our release cycle, testing, and get out to the world – at least a couple of weeks, and usually longer.

Worse, once we release the fixed package folks who use Puppet through, say, Debian, or RedHat, or SuSE, or CentOS need to wait longer: they need to wait for their distribution to update the package, which for most of them means “the next major release” – which is anything up to two years!

In view of that, would you still like to submit this for inclusion in the core of Puppet, or would you rather take it to the forge?

We think there are really, solidly compelling reasons that helps everyone out, but if you feel super-strong about getting this into the core of Puppet we will look at that.

(In the longer term we expect to move, for example, the yumrepo type into a module as well, so that it isn’t tied to the core release cycle as it is today.)

#6 Updated by Darin Perusich almost 3 years ago

Daniel Pittman wrote:

Darin, thanks for submitting this code. It actually looks solid, and effective. With everything you have done we could merge that into core.

Thanks! I’ve actually just made a number of modifications to it earlier today removing all the yum specific crud that zypper ignores.

Worse, once we release the fixed package folks who use Puppet through, say, Debian, or RedHat, or SuSE, or CentOS need to wait longer: they need to wait for their distribution to update the package, which for most of them means “the next major release” – which is anything up to two years!

This is why I create my own packages and deploy them locally or use OBS for things like this.

In view of that, would you still like to submit this for inclusion in the core of Puppet, or would you rather take it to the forge?

I can understand why you’re moving these features/types/etc out of the puppet core and into modules, it certainly makes updating and getting those modules into peoples hands easier and quicker. While I haven’t “played” with pluginsync yet, but from what I’ve read it’s nearly the equivalent to installing perl modules via CPAN or python egg’s via setuptools. Granted it doesn’t pollute anything outside of /etc/puppet/modules, this kind of “variable” stuff belong under /var/lib/puppet IMO, which is slightly more palatable but you still lose track of who/what owns the file because you can’t query the packaging systems about it.

Now that I’m done subjecting you all to my rant I will take and move this module to the forge.

I realize this probably isn’t something on your radar but it would be really nice if there was a way to reference these additional types from the “type reference” document. I know I almost never look at the forge for these things and when I do it’s always with a bit of skepticism.

#7 Updated by Anonymous almost 3 years ago

  • Status changed from In Topic Branch Pending Review to Closed

Darin Perusich wrote:

Daniel Pittman wrote:

Darin, thanks for submitting this code. It actually looks solid, and effective. With everything you have done we could merge that into core.

Thanks! I’ve actually just made a number of modifications to it earlier today removing all the yum specific crud that zypper ignores.

Awesome.

In view of that, would you still like to submit this for inclusion in the core of Puppet, or would you rather take it to the forge?

I can understand why you’re moving these features/types/etc out of the puppet core and into modules, it certainly makes updating and getting those modules into peoples hands easier and quicker.

That is it: it means that people are not stuck for too long waiting for bugs to get fixed. Nothing like knowing that 2.7.11 fixes your bug, and that you can’t get it until you do lots of work, or your distro updates. :/

While I haven’t “played” with pluginsync yet, but from what I’ve read it’s nearly the equivalent to installing perl modules via CPAN or python egg’s via setuptools. Granted it doesn’t pollute anything outside of /etc/puppet/modules, this kind of “variable” stuff belong under /var/lib/puppet IMO, which is slightly more palatable but you still lose track of who/what owns the file because you can’t query the packaging systems about it.

On the server you can put anything you want in the module path, so if you prefer /var/lib/puppet you can totally hide them away there.

On the agents, where we copy that content down to, it lives in /var/lib/puppet/lib by default … for exactly the reason you name. :)

I realize this probably isn’t something on your radar but it would be really nice if there was a way to reference these additional types from the “type reference” document. I know I almost never look at the forge for these things and when I do it’s always with a bit of skepticism.

I will pass that on to our web folks, and see if we can’t figure out something useful to do there. We are actively working to make the forge more awesome and all, because the counterpoint to “move stuff there” is “if it sucks, life sucks for our users”, and … well, our priority is the opposite of that. :)

Thank you again for the code. That is awesome.

#8 Updated by Anonymous over 1 year ago

  • Assignee deleted (Anonymous)

Also available in: Atom PDF