collector in class with same name as tag causes all virtual resources of the type to be realized

[Neil - Puppet List]

Hello

I'm upgrading from 3.6 to 3.7 and have it a issue/bug

I'm using users/groups but to keep it short and something others can run without the mess of users being made I've made up a file example

====== modules/filegroups/manifests/matches.pp =======

class filegroups::matches {

  include files

  Files::Afile <| tag == matches |>

}

====== modules/files/manifests/afile.pp =======

define files::afile {

  file { $title: ensure=>present, content=>'hello', }

}

====== modules/files/manifests/data.pp =======

class files::data {

  @files::afile { '/tmp/meanttobemade': tag=>['matches'], }

  @files::afile { '/tmp/notmeanttobemade': tag=>['doesnotmatch'], }

}

====== modules/files/manifests/init.pp =======

class files {

  include files::data

}

====== site.pp =======

node default {

  include filegroups::matches

}

makes both files

Notice: /Stage[main]/Files::Data/Files::Afile[/tmp/notmeanttobemade]/File[/tmp/notmeanttobemade]/ensure: created

If I rename modules/filegroups/manifests/matches.pp to  modules/filegroups/manifests/iwantmatches.pp (and change the first line)

or rename the tag I get the desired behaviour

Anyone else seen this? Is this a bug?

There is a matching old question at askpuppetlabs https://ask.puppetlabs.com/question/14349/upgrade-to-371-causes-resource-collectors-to-realize-everything/ that I've chipped in on the end off

Thanks,

Neil

[Neil - Puppet List]

Here is a similar example using notify

====== site.pp ======

node default {

  include noticegroups::matches

}

====== modules/noticegroups/manifests/matches.pp ======

class noticegroups::matches {

  include notices

  Notices::Anotice <| tag == matches |>

}

====== modules/notices/manifests/anotice.pp ======

define notices::anotice {

  notify { $title: }

}

====== modules/notices/manifests/data.pp ======

class notices::data {

  @notices::anotice { 'meant to be made': tag=>['matches'], }

  @notices::anotice { 'NOT meant to be made': tag=>['doesnotmatch'], }

}

====== modules/notices/manifests/init.pp ======

class notices {

  include notices::data

}

with that I get the behaviour I expect in puppet 3.6 and broken in 3.7

if I change class noticegroups::matches to noticegroups::iwantmatches then only the resource I want gets realized

this just seems like 3.7 broke something to me

[jcbollinger]

On Tuesday, April 7, 2015 at 2:54:20 PM UTC-5, Neil - Puppet List wrote:

Here is a similar example using notify

====== site.pp ======

node default {

  include noticegroups::matches

}

====== modules/noticegroups/manifests/matches.pp ======

class noticegroups::matches {

  include notices

  Notices::Anotice <| tag == matches |>

}

====== modules/notices/manifests/anotice.pp ======

define notices::anotice {

  notify { $title: }

}

====== modules/notices/manifests/data.pp ======

class notices::data {

  @notices::anotice { 'meant to be made': tag=>['matches'], }

  @notices::anotice { 'NOT meant to be made': tag=>['doesnotmatch'], }

}

====== modules/notices/manifests/init.pp ======

class notices {

  include notices::data

}

with that I get the behaviour I expect in puppet 3.6 and broken in 3.7

if I change class noticegroups::matches to noticegroups::iwantmatches then only the resource I want gets realized

this just seems like 3.7 broke something to me

I agree.  You should file a ticket.

Puppet automatically tags resources that are declared by a given class with each segment of that class's name.  Possibly it does similarly to resources collected by classes (which would make sense), and I can imagine that a regression might have crept in in that area.  For instance, it may be that P3.7 erroneously tags collected resources *before* filtering by tag (and perhaps before filtering at all, which would be significantly worse).


John

[Neil - Puppet List]

Thanks John,

Filing aticket.