Resource ordering not working for module classes (top-level)

[Abhijeet Rastogi]

Hi Puppet users, 

I have the following code and all resources inside class ipvsadm are not executed before all resources in class ipvs_keepalived. 

class profile::ipvs {
  # Removed other classes for readability
  include '::ipvs_keepalived'
  include '::ipvsadm'

  # Need ipvsadm kernel module changes before keepalived loads the ip_vs module
  Class['::ipvsadm'] -> Class['::ipvs_keepalived']
}

But, below is my puppet run log in debug mode, column 1 being the line number. 

556445 Debug: Adding relationship from Class[Ipvsadm] to Class[Ipvs_keepalived] with 'before'
...
556633 Notice: /Stage[main]/Ipvs_keepalived::Service/Service[keepalived]/ensure: ensure changed 'stopped' to 'running'

...
556776 Notice: /Stage[main]/Ipvsadm::Config/File[/etc/modprobe.d/ipvs.conf]/ensure: defined content as '{md5}eccf22fd99f92d076e2c7b74cff506d1'

We can see that even though the resource order was processed in puppet run, Ipvs_keepalived::Service decides to execute before Ipvsadm::Config.

I think there's something fundamentally wrong in my approach, will appreciate the help.

Thanks,

Abhijeet

[Ramin K]

You're running afoul of class containment or more precisely the lack
thereof. Covered here https://puppet.com/blog/class-containment-puppet/

You can swap 'include ipvsadm::config' for 'contain ipvsadm::config'
though you may need more contain statements. If they are third party
modules you'd prefer not to modify, you can create more specific order
between the modules in your profile. something like this might work.

Class['ipvsadm::config'] -> Class['ipvs_keepalived::service']

I'm not a huge fan of creating relationships between components of
modules, but sometimes that's the best way forward.

Watch the use of contain. It can be easy to create dependency cycles
particularly if you're using resources from systemd and yum in your modules.

Ramin

On 11/26/2019 11:33 AM, Abhijeet Rastogi wrote:
> Hi Puppet users,
>
> I have the following code and all resources inside class ipvsadm are not
> executed before all resources in class ipvs_keepalived.
>
> class profile::ipvs {
>   # Removed other classes for readability
>   include '::ipvs_keepalived'
>   include '::ipvsadm'
>
>   # Need ipvsadm kernel module changes before keepalived loads the
> ip_vs module
>   Class['::ipvsadm'] -> Class['::ipvs_keepalived']
> }
>
>
> But, below is my puppet run log in debug mode, column 1 being the line
> number.
>

> 556445 Debug: Adding relationship fromClass[Ipvsadm] toClass[Ipvs_keepalived] with'before'

> ...
> 556633 Notice: /Stage[main]/Ipvs_keepalived::Service/Service[keepalived]/ensure: ensure changed'stopped' to'running'
>
> ...
> 556776 Notice: /Stage[main]/Ipvsadm::Config/File[/etc/modprobe.d/ipvs.conf]/ensure: defined content as'{md5}eccf22fd99f92d076e2c7b74cff506d1'
>
>
> We can see that even though the resource order was processed in puppet
> run, Ipvs_keepalived::Service decides to execute before Ipvsadm::Config.
>
> I think there's something fundamentally wrong in my approach, will
> appreciate the help.
>
> Thanks,
> Abhijeet
>

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-users...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/53fbade6-10f5-4973-931a-17bc40be7d50%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/53fbade6-10f5-4973-931a-17bc40be7d50%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Abhijeet Rastogi]

Hi Ramin,

Thanks for the details and the link. That was indeed the cause of this issue.

I wonder what official puppet guidelines are for managing this sort of inter-module dependencies. I couldn't find a guideline on official docs. https://puppet.com/docs/puppet/latest/lang_relationships.html

Thanks,
Abhijeet

You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/KX7RjGnzwr0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b0f1ce0c-b85d-7bd1-0d5c-80e9a7d0ccd6%40badapple.net.

--

Cheers,

Abhijeet (https://abhi.host)

[jcbollinger]

On Monday, December 2, 2019 at 1:56:32 PM UTC-6, Abhijeet Rastogi wrote:

Hi Ramin,

Thanks for the details and the link. That was indeed the cause of this issue.

I wonder what official puppet guidelines are for managing this sort of inter-module dependencies. I couldn't find a guideline on official docs. https://puppet.com/docs/puppet/latest/lang_relationships.html

Module compatibility and inter-module dependencies have always been tricky issues with Puppet.  I am unaware of any guidelines on the topic from Puppet, Inc., and I'm not too surprised about that because there are a lot of situation-dependent details. To a large extent, however, the onus is on module authors to make their modules play well with others.  If you have to work with modules that present interoperability problems then you pretty much have to figure it out on a case-by-case basis.

As far as writing your own modules to be maximally interoperable, there's a bit of art and a bit of science.  You'll find suggestions and discussions of that topic in the archives of this group, among other places.  Here are some off-the-cuff suggestions:

• Provide a very small number of module interfaces.  Oftentimes, just one is ideal.  An "interface" in this sense is a front-end class or a defined type that is intended to be declared by code outside the module.
• Such public classes should exercise proper containment of any private module classes they declare.
• All module classes should express appropriate ordering of external classes they declare, which typically is one or more "require" or "before" relationships instead of full containment.  Do not over constrain ordering, however, as that can be as bad as or even worse than under-constraining it.
• Modules should maintain a tight focus, so as to minimize the risk that two modules serving different purposes attempt to manage the same resource.
• Where there is a potential or actual resource-management collision, the best solution is usually to factor the affected resource out into its own module, but it is sometimes more practical to use class parameters to control which module has responsibility for managing the resource.
• Overall, module designers and implementers must bear ordering requirements in mind as they work, not only as they affect the module itself, but also as they relate to the module's interactions with others.
• Write good documentation.  What does the module manage?  What are its public interfaces? What do its class parameters signify, what are their allowed values, what are their defaults (if any)? What other modules does it use, and how?

John