On 11/07/2014 05:59 AM, Luke Kanies wrote:
>> To get a behavior that matches today's resources type, we'd need to
>> > explicitly query unmanaged resources.
>> >
>> > User<~| managed == false |~> { ensure => absent }
>> >
>> > This has the advantage of being more explicit about the unmanaged part than
>> >
>> > resources { 'user': purge => true }
> Agreed.
>
> We do need some way to make it clear that this query happens on the client,
> rather than on the server, and then the catalog needs some way to store that
> query.
>
> The only other way to do it would be to have the server be able to do
> real-time queries against the client, but I think that would have too many
> crazy consequences.
>
> It’s been a long time, but I seem to remember trying to treat the resource as
> a query; something like:
>
> user { *:
> uid >= 100,
> purge => true
> }
>
> But I think this is not the right answer.
>
> Maybe something like:
>
> user { <| uid > 100 |>:
> purge => true
> }
>
> Then the title is the query, and the parameters get applied to all resources
> that match that title.
>
> Thoughts?
>
I think I would prefer a mix of both approaches:
user { 'arbitrary-purger-title':
match => <| uid > 100 && !managed |>,
ignore => <| title == sysmaint |>,
ensure => absent,
}
This would have the benefit that the user can
exec { 'tidy-all-home-dirs: require => User['arbitrary-purger-title'] }
at the expense of more metaparameters, putting restraints on type
authors wrt. attribute names that they can use for their own types.
Hell, we have at least one core type that uses "ignore" even today.
So perhaps a more dedicated syntax like
user { 'arbitrary-purger-title':
<| uid > 100 && !managed |>,
...
}
has more merit.
On 11/07/2014 05:39 AM, Luke Kanies wrote:> On Nov 7, 2014, at 2:02 PM,
Joshua Hoblitt <jhobl...@cpan.org> wrote:
>> How would make use of that information on the agent if expressions are
>> > evaluated on the master? As an example, I'd like to be able to 'query'
>> > the home dir of a role account (without having to install a fact) and
>> > interpolate it into a string to form a path. I've always found this
>> > scenario a bit frustrating as the type has the data I want; it's just
>> > inaccessible while the catalog is built.
> As others have mentioned, the only way this is possible is if we find
a way to send the query down to the client. We need different queries
for different locations, but hopefully similar enough that it doesn’t
like a completely different system, like it is today.
There be dragons.
System entities are queried at the start of the agent transaction at the
moment. The transaction starts after the catalog has been retrieved. We
would have to intertwine these steps, and this would raise a plethora of
problems, I imagine.
For example - you cannot be sure what provider the catalog will end up
assigning to the resource that you are querying before everything is
properly resolved. It would be awkward if a query is performed using the
default provider, but the catalog ends up specifying that the user in
question be managed through LDAP, for example.
The compiler calling back to the agent during its catalog request would
be a major game changer. I'm thinking "whole new paradigm".
Cheers,
Felix
--
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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/545C88B5.7020707%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.
