Why not just use arrays for the parent attribute?
|project {'Z':
ensure=>present,
parent =>[ 'B', 'C' ],
inherit =>false,
}
|
On 01/12/2016 12:17 PM, Quaternaire wrote:
Hi,
I am creating a Module for Mantis Bug Tracker (an issue tracker,
https://www.mantisbt.org/), and I need to create new resource types
for Project and User.
The idea is to have Projects which can inherit from other Projects.
Each Project can have multiple parent and/or childs, such as:
|
ProjectA
>ProjectB
>>ProjectZ
>ProjectC
>>ProjectZ
|
Where B an C are child of A, and Z is child of both B and C.
Also, project inheritance is parameterized (such a whether a child
inherit parent properties).
I have no issue implementing the types and providers themselves, it is
more with the end-user usage. Lets say I want to write a manifest
representing the example above. The first soluton that comes in mind
could be:
|
project {'A':
ensure=>present,
}
project {'B':
ensure=>present,
parent =>'A',
inherit =>true,
}
project {'C':
ensure=>present,
parent =>'A',
inherit =>false,
}
project {'Z':
ensure=>present,
parent =>'B',
inherit =>false,
}
# Crap, how can Z have multiple parents?
# Same problem if we use something like "child => 'B'" on A, how could
A have multiple children?
|
... which is not viable.
Another solution could be:
|
project {'A':
ensure=>present,
}
project {'B':
ensure=>present,
}
project {'C':
ensure=>present,
}
hierarchy {'A>B':
child =>'B',
parent =>'A',
inherit =>true,
}
hierarchy {'B>Z':
child =>'Z',
parent =>'B',
inherit =>false,
}
hierarchy {'C>Z':
child =>'Z',
parent =>'C',
inherit =>true,
}
|
This way it works fine, but it is quite cumbersome to write and maintain.
So another way would be using hashes to define children (of parents):
|
project {'A':
ensure=>present,
child =>{
name =>'B',
inherit =>true,
}
}
project {'B':
ensure=>present,
child =>{
name =>'Z',
inherit =>false,
}# We may add more child in this hash...
}
project {'C':
ensure=>present,
child =>{
name =>'Z',
inherit =>true,
}# We may add more child in this hash...
}
|
Which also works fine, is easier to read, but does it respects Puppet
conventions? Users will be able to define whatever they want in these
hashes, and the Puppet mechanism of param/property linked to methods
would be broken.
What do you think would be the best possibility? Having a Project type
and using a Hierarchy type to link it together, granting the
possibility to use hashes, or another solution?
A final note: a similar problem is posed for users. How can we define
a user resource, and manage user specific parameters for each
projects? I think answering for projects will solve it for users.
Thanks by advance for your ideas or advices!
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/c0de16c7-4e56-4dae-a123-058651acc22e%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/c0de16c7-4e56-4dae-a123-058651acc22e%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/569539E1.7010804%40alter3d.ca.
For more options, visit https://groups.google.com/d/optout.
