Hi Martin,
On Sun, Feb 5, 2017 at 2:35 PM, Martin Alfke <[email protected]> wrote:
> It seems to me as if you are “hiding” some things which are hard to
> understand - similar to mk_resource_methods which is useful when following
> some silent assumptions.
>
My big hope is that we can do away with all that internal machinery and
replace it with a very simple interface between types and providers
(roughly: look up existing resources and change resources, what David has
as set and get in his proposal)
> Think of something like the following (yes, I know, “type” is already a
> reserved word):
>
> type my_module::my_file (
> Enum['file', 'absent' ] $ensure,
> Stdlib::Absolute_path $path = $title,
> String $owner,
> ){
> def create {
> exec { "create file ${path}":
> command => "touch ${path}",
> path => '/usr/bin:/bin',
> creates => $path,
> }
> }
> def destroy {
> file { $path:
> ensure => absent,
> }
> }
> property owner {
> exec { "chown ${owner} on ${path}":
> command => "chown ${owner} ${path}",
> path => '/bin:/usr/bin',
> unless => '',
> }
> }
> }
>
> (I know that exec should not be used in this way.)
>
I think it's totally reasonable for people to write Puppet code that acts
like a type/provider; but that's possible today as you could turn the above
code into a defined type.
To me, the point of the type/provider mechanism is to allow extending what
Puppet can manage beyond what's easily accessible via Puppet. I think that
simplification here means that the provider is exposed to a larger-scale
change, i.e. is told to enforce a particular resource. Looking, for
example, at this systemd provider
<https://github.com/puppetlabs/libral/blob/master/data/providers/systemd.prov>
or this dnf provider
<https://github.com/puppetlabs/libral/blob/master/data/providers/dnf.prov>
makes me think that breaking change into small pieces (per property)
actually makes it harder to write providers, not easier. There's clearly
room for adding some language-specific conveniences, but even without that
I think the code is pretty straightforward.
People with ruby experience will not find types and providers difficult (in
> the way they are done today).
>
> But Puppet was originally written for Ops people who don’t like scripting
> or coding.
>
Yes, this is a really thorny one - my hunch is that writing types and
providers will always be an advanced topic, and it's therefore reasonable
to assume some familiarity with scripting.
David
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev/CAHN%2BA%2BWPfb1q2859uz9xwazDb-0%3DwQ8TnngD-fxoP-90hu5XUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
