Type inheritance

27 views
Skip to first unread message

Andreas Zuber

unread,
Sep 9, 2014, 8:56:38 AM9/9/14
to puppet...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello

I just came across an interesting problem with the mount provider. We
try to manage NFS mounts on the servers and purge all instances which
are not in the catalog.

Since the mount type/provider collects all the mounts it would simply
destroy the system if we activate purging. So I started to look into
different ways how this could be done right.

Unfortunately I did not find a solution which is very attractive.
Currently I simply copied the puppet mount type and provider and created
a modified version of it under a different name. This is very ugly as it
basically c&p some hundred lines of code to add a few lines which reject
all non NFS mounts in the instances method.

Is there a better way to do this? Is there some way I can limit the
purging to a set of parameters or a specific provider for the mount
type? Or is there a way to inherit a type and to inherit providers from
such inherited types?

Greetings
Andreas

- --
Andreas Zuber
Linux System-Ingenieur
Puzzle ITC GmbH
www.puzzle.ch

Telefon +41 31 370 22 00
Direkt +41 31 370 22 49
Mobile +41 79 766 25 51
Fax +41 31 370 22 01

Werfen Sie einen Blick in unseren Blog:
<http://www.puzzle.ch/blog>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlQO+ScACgkQc2hfmdKpdfXUyQCcC9lwZrmuh0YxR0p40XgEbxMo
pLQAnAxoF6YyMuyFR8pgpVBt4qGEGBR/
=j7we
-----END PGP SIGNATURE-----


Felix Frank

unread,
Sep 9, 2014, 7:29:45 PM9/9/14
to puppet...@googlegroups.com
Hi,

well, no, there is currently no way to implement effective subtypes or
create an inheritance hierarchy at this point. Not that it's not wanted
- we could have made good use of such a for years. Some things are
really hard to solve with the current RAL model.

Fortunately, purging is usually not one of them. You may want to take a
closer look at the resources type, rather than the mount type. Its
purging works by just collecting the list of instances, as gathered by
the respective type's provider. It is quite possible to apply special
filters, e.g. target only mount resources with an fstype of nfs.

It should be much simpler to build your own specialized mount purger as
a clone of the resources type, rather than cloning the mount type for
better purging through the resources type proper.

I hope this makes sense. Cheers,
Felix

Andreas Zuber

unread,
Sep 10, 2014, 4:20:53 AM9/10/14
to puppet...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Felix

Thanks for the advice, this is exactly the kind of thing I was looking
for :-) . I will take a look at the resources type and write back how it
worked out.

Greetings
Andreas
- --
Andreas Zuber
Linux System-Ingenieur
Puzzle ITC GmbH
www.puzzle.ch

Telefon +41 31 370 22 00
Direkt +41 31 370 22 49
Mobile +41 79 766 25 51
Fax +41 31 370 22 01

Werfen Sie einen Blick in unseren Blog:
<http://www.puzzle.ch/blog>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlQQCYQACgkQc2hfmdKpdfXgGACfZn/2E7Ogsla2fw2VQTGA5cqd
Q2AAnjAwg2xKc60INzOxZ8duLGkxemdb
=zQZM
-----END PGP SIGNATURE-----

Trevor Vaughan

unread,
Sep 10, 2014, 9:16:53 AM9/10/14
to puppet...@googlegroups.com
As an alternate to Felix's proposal, you could write your own custom provider that does the following:

*In the Property state query define*
- Collect all system resources of type Mount with type NFS into an instance variable

*In the Property insync? method*
- Prune the list of system resources of type Mount with the list of Mount NFS resources that are actually in your catalog
- Return that the property is in sync if the resultant list is empty, and not otherwise

*In the Property sync method*
- Send the collected resources that need to be unmounted a signal to do so

This is very clean since it doesn't rely on any sort of inheritance model. All you need are the system statements and the in-memory compiled catalog. However, it is quite complex to get right.

Good luck!

Trevor



--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/540EF927.8010407%40puzzle.ch.
For more options, visit https://groups.google.com/d/optout.



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --
Reply all
Reply to author
Forward
0 new messages