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

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Feature #13045

stdlib module should have a contains function

Added by Anonymous about 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:03/09/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:function
Target version:not yet targeted
Keywords: Branch:

We've Moved!

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


Description

Overview

We need to get rid of the Anchor pattern. It’s not delightful at all.

Steps to reproduce

See #8040

Implementation

Nick Lewis, Deepak and I burned some time investigating the issues that make Anchor’s a necessity in many cases. We came up with a fairly low cost solution that is basically:

Implement a function named contains(). The function behaves just like inlcude(). The class gets added to the “top scope” but relationships are automatically set up to the class containing the contains() function’s sentinal resources.

That’s about it…

I’m writing this from memory, so please correct anything I’ve gotten wrong.


Related issues

Related to Puppet - Bug #8040: Classes should be able to contain other classes to provid... Closed 06/22/2011

History

#1 Updated by Ken Barber about 4 years ago

What’s your angle in making this a stdlib fix, not a core fix Jeff?

#2 Updated by Anonymous about 4 years ago

Ken Barber wrote:

What’s your angle in making this a stdlib fix, not a core fix Jeff?

Puppet 2.6 and backwards compatibility.

-Jeff

#3 Updated by Stefan Schulte about 4 years ago

so I can then pick between three choices to include a class:

include my_class
class { 'my_class': }
contains my_class

how does contains work if I want to pass parameters?

What about a class like

class ssh {
  contains ssh::package
  file { '/etc/ssh/sshd_config':
    require => Package['openssh']
  }
}

Will this cause a dependency cycle between the file and the package?

#4 Updated by Nick Lewis about 4 years ago

Stefan Schulte wrote:

so I can then pick between three choices to include a class: […]

how does contains work if I want to pass parameters?

I guess you would have to declare the class like normal, and then also call contains. It’s a little unfortunate, but I can’t think of anything better.

What about a class like […] Will this cause a dependency cycle between the file and the package?

No, because the containment relationship simply means that for ssh to be considered “done” (that is, its dependents are allowed to be evaluated), ssh::package must also be done. It doesn’t imply any ordering between ssh::package and the resources inside of ssh, so they are free to make whatever relationships they want.

#5 Updated by Anonymous about 4 years ago

  • Project changed from Puppet Labs Modules to Standard Library
  • Category deleted (stdlib)
  • Assignee set to Anonymous

#6 Updated by Anonymous about 4 years ago

  • Category set to function
  • Target version set to 238

#7 Updated by Anonymous about 4 years ago

  • Target version changed from 238 to stdlib 2.4.x

#8 Updated by Anonymous about 4 years ago

  • Target version changed from stdlib 2.4.x to not yet targeted

Setting to “untargeted” until we have code to review or we have a product decision to explicitly target a planned release.

#9 Updated by Chris Price almost 4 years ago

Admittedly I am just now starting to familiarize myself with this whole set of issues around the “Anchor Pattern”—but this proposal seems frightening to me. This feels like something that should be solved in puppet core, as opposed to in stdlib—and I share Stefan’s concern about introducing a third way to specify inclusion of a class.

It feels to me like containment relationships should be implicit based on class declarations nested inside of class definitions, and should not require new language semantics. What am I missing that makes that the wrong way to approach this?

#10 Updated by Anonymous almost 4 years ago

  • Status changed from Unreviewed to Closed

Closing this ticket as I too agree it should be fixed in core.

At the time, we were only half way through the 2.7.x series and I wanted a solution that would work with 2.6 as well. That was my angle, but it’s no longer relevant.

-Jeff

Also available in: Atom PDF