if you ever work on a specific module within the company, let us know and we can probably open source that within Vox Pupuli. That's the best way to learn

Are there any live jam sessions out there where people take questions/answers about general puppet stuff? Slack is great but video sessions would be even better.

or use our modules, find a missing feature and together we can hack that into

I'm trying to put together a module for a product called "Manhattan" that my company uses for supply-chain stuff we offer to our customers. It's a terribly convoluted product that requires so much effort I'm surprised the "Manhattan" company hasn't at least made an RPM. The install document is about 20 pages long.

This message was deleted.

I really really enjoyed that and learned a lot about Puppet and how to review a PR

Vox Pupuli has monthly office hours in #CFD8Z9A4T and parallel in zoom where you can ask questions, but we usually dont discuss PRs but bigger topics

I attended one a few months back but it didn't seem appropriate to ask support-type questions.

if you have a specific question/problem you can always ask in #C0W1Y5VL0 or here we can probably figure something out

This message was deleted.

I have the same ordering problem with creating a mounted filesystem. PV -> VG -> LV -> filesystem -> dirtree -> mount -> directory. I've had to put a bunch of "before" and "require" statements in my hiera yaml files but since a Physical Volume must exist before a volume group can be created there must be some way to say, "Order all PVs before all VGs." Is the spaceship operator the proper way?

The Puppet Relationships and Ordering site talks about automatic relationships. Are those relationships defined in stdlib? Or, say, for a volume group, somewhere in the volume group module?

Automatic relationships are not defined in stdlib. If they are defined at all, they are defined per resource type in that resource's internal Ruby code. And if that auto-relationship exists, you'll see a blurb about "*autorequires*" on that resource's docs page. For example, the

user

resource: https://www.puppet.com/docs/puppet/7/types/user.html#user-description

Automatic relationships are not defined in stdlib. If they are defined at all, they are defined per resource type in that resource's internal Ruby code. And if that auto-relationship exists, you'll see a blurb about "*autorequires*" on that resource's docs page. For example, the

user

resource: https://www.puppet.com/docs/puppet/7/types/user.html#user-description

Hiera also only auto-populates class parameters. Before and Require are meta-parameters --- so they cannot be set via Hiera. They have to be set explicitly on the resources.

Actually, I am doing before and require in hiera.

It seems to be working unless it's not working and I'm just getting lucky.

I have a whole chain of requires in my common.yaml file for creating a Physical Volume all the way to files on the newly-created LVM filesystem.

Never understood fascination with code in hiera

https://github.com/puppetlabs/puppetlabs-accounts/blob/main/manifests/user.pp#L190 it even manages the group by default, so you can probably drop your code

why not use actual code instead of suffering from ansible ?

Most likely, because I don't know better.

I always thought that it was best to separate the code from the [company's] data.

imho, hiera should look like this

corp::profile::lvm::filesystems:
  opt:
    volume_group: 'vg1'
    size: '50G'
  var:
    size: '8G'

and your profile interprets it properly

Puppet will translate the string

'Some_resource[instance]'

to the actual resource instance when provided via

before/require/notify/subscribe

meta-parameter. I'm not sure I'd describe that as code, though, and it is pretty handy when defining resource parameters in Hiera

@vchepkov yeah, I'm trying to migrate towards that style.

This is fragment of my profile, if it helps

$fs_defaults = {
    volume_group    => 'vg0',
    fs_type         => $fs_type,
    options         => 'relatime',
    size_is_minsize => true,
    dump            => '1',
  }

  if $filesystems {
    $filesystems.each |$fs, $fs_attributes| {

      $attributes = $fs_defaults + $fs_attributes

      lvm::logical_volume { $fs:
        * => $attributes,
      }
    }
  }

@vchepkov agreed. I came to that "aha" moment about a week ago when faced with this issue. My relationship ordering is still badly in need of an education.

one could also assume that the LVM types do automatic ordering