Community input requested on potential `unless_uid` addition to user resources

[Jeff Weiss]

Puppet Community,

We need your help.

We have a terrific contribution from Bart ten Brinke that would add an `unless_uid` parameter to user resources.  The pull is request is 628 (https://github.com/puppetlabs/puppet/pull/628).

We acknowledge the clear use case around needing to exclude specific users--not explicitly managed by Puppet--from a purge.  Because we don't yet have an awesome resource collection syntax for this and we feel that would be a decent-sized investment, we're on the fence about the syntax that this would create.  Here's the example from the pull request:

class users::resources {
  resources { 'user':
  purge              => true,
  unless_system_user => true,
  unless_uid => [10_000..20_000];
  }
}

To reiterate, we see value here and can't think of a better near-term solution.

What are your thoughts? Is this intuitive enough? Is it a must-have feature?

Thanks for your input,

Jeff Weiss

Software Developer

Puppet Labs, Inc.

jeff....@puppetlabs.com

[David Schmitt]

Interesting concept. I find the syntax acceptable.

Alternatively a file-inspired syntax comes to mind:

file { "/somewhere": source => "...", purge => true }

user_range { "[10000..15000]": purge => false }

I'm not convinced that would be better.

A more concrete point would be to add more examples into the docstring.
As it stands there is no chance to create a correct range expression
from the documentation alone.


Related point: I'd really like to avoid *creating* users in a specified
range. At a site I've got NIS users and puppet happily creates local
admin users in that range creating clashes in the future. Any ideas?


Best Regards, David

[Peter Meier]

> What are your thoughts? Is this intuitive enough? Is it a must-have feature?

I think it's valuable and as you said there are valid uses cases where
such operations are currently not possible with the default language
features.

Why do you call it terrific? What are your concerns? I couldn't find any
arguments of your internal debate anywhere.

~pete

[Trevor Vaughan]

I very much like the idea of having a separate variable such as
'user_range' as proposed by David.

This would allow for a single declaration instead of having to repeat
things for each user that's created.

There should probably be multiple options though:

user_modifier { 'min_id': value => '1001' }
user_modifier { 'max_id': value => '4000' }
user_modifier { 'ignore': range => [ '2000...3000','10000...40000'] }

It would also be nice to make the 'ignore' segment appendable so that
different hosts could add to the ignore list if necessary.

The syntax above is just to illustrate my point and not necessariliy a
good idea.

+1 for this feature request though.

Thanks,

Trevor

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>



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

-- This account not approved for unencrypted proprietary information --

[Josh Cooper]

I can see value for this on Windows as well, though it would likely require a regex:

  ignore => 'S-1-5-21-*-500' # Administrator

Josh

--
Josh Cooper

Developer, Puppet Labs

[Pieter van de Bruggen]

On Tue, May 15, 2012 at 9:56 AM, Jeff Weiss <jeff....@puppetlabs.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

At the risk of getting booed off, what of this as a syntax?

class users::resources {
  resources { 'user':
    purge  => true,
    unless => 'uid < 10000 OR uid > 20000';
  }
}

This seems to be a more flexible syntax over a wider range of properties and values, with the tradeoff of requiring a bit more effort and explanation to use.  Thoughts?

[Trevor Vaughan]

It's not horrible, but you need to allow for intermediate ranges.

[Luke Kanies]

On May 16, 2012, at 11:27 AM, Pieter van de Bruggen wrote:
>
> […]

> At the risk of getting booed off, what of this as a syntax?
>
> class users::resources {
> resources { 'user':
> purge => true,
> unless => 'uid < 10000 OR uid > 20000';
> }
> }
>
> This seems to be a more flexible syntax over a wider range of properties and values, with the tradeoff of requiring a bit more effort and explanation to use. Thoughts?

I do like the more general syntax - and it's something that's been asked for a lot. I know there's at least one ticket about this.

The counterpoint to your proposal is that there's working code for the other one, so we might ourselves rejecting a patch and instead doing nothing.

--
Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199

[Chris Price]

Aren't we, in effect, introducing another (mini, boolean) language with this sort of proposal, though?  I agree that the generality and flexibility is appealing, but the idea of designing and supporting another parser / lexer gives me pause.

Not to say that the benefits might not be worthwhile... just seems like a big leap to take.

[Chris Price]

p.s., if we do go down this path it would be interesting to see if there is some sort of existing library or standard specification for boolean logic expressions that we could piggy-back off of, rather than rolling our own.

[R.I.Pienaar]

----- Original Message -----
> From: "Chris Price" <ch...@puppetlabs.com>
> To: puppe...@googlegroups.com
> Sent: Wednesday, May 16, 2012 9:07:13 PM
> Subject: Re: [Puppet-dev] Community input requested on potential `unless_uid` addition to user resources
>
> p.s., if we do go down this path it would be interesting to see if
> there is some sort of existing library or standard specification for
> boolean logic expressions that we could piggy-back off of, rather
> than rolling our own.

we wrote one recently for mcollective, no idea if its something that can
be generically used or made to be more generic

[Pieter van de Bruggen]

So, as a WAG, how long might it take to implement the generic version of this?  How does that trade off against merging the pull request but running through a deprecation cycle later?

[Deepak Giridharagopal]

On Wed, May 16, 2012 at 2:07 PM, Chris Price <ch...@puppetlabs.com> wrote:

p.s., if we do go down this path it would be interesting to see if there is some sort of existing library or standard specification for boolean logic expressions that we could piggy-back off of, rather than rolling our own.

There are also other places in the language that may have similar needs around expressing conditions and selection criteria, such as when collecting/realizing virtual or exported resources.

deepak

--
Deepak Giridharagopal / Puppet Labs

[Daniel Pittman]

Those areas do, in fact, define a small boolean logic language already.

Using that elsewhere isn't impossible, but it is a pretty big change
to the definition of what a property or parameter can mean.


In many ways I think that the `tidy` type is the best thing to compare
this to: it explicitly operates on client-side state, and is distinct
from the parent type.

The separate "user range" type is the closes analog there.

It seems like that separation is going to have a whole lot less
unexpected or hard edges than extending the "user" type will.

--
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

[Andrew Parker]

Since the language already has boolean logic expressions (http://docs.puppetlabs.com/guides/language_guide.html#expressions), it seems like what we are looking for is maybe some way of treating expressions as first-class and being able to pass them as parameters in order to be evaluated later.

[Luke Kanies]

People usually compare it to the exec type, which has the onlyif and unless parameters (and very limited boolean behavior - based entirely on the run status of a command).

As you point out, this is logic on the client, rather than on the server.

Another related thing that's been asked for is boolean logic that affects how the graph is traversed - e.g., if A then manage X resource, if B then manage Y resource. This is an even bigger difference, but still related in that it's client-side logic.

[Daniel Pittman]

On Wed, May 16, 2012 at 2:22 PM, Luke Kanies <lu...@puppetlabs.com> wrote:
> On May 16, 2012, at 2:00 PM, Daniel Pittman wrote:
>> On Wed, May 16, 2012 at 1:51 PM, Deepak Giridharagopal <dee...@puppetlabs.com> wrote:
>>> On Wed, May 16, 2012 at 2:07 PM, Chris Price <ch...@puppetlabs.com> wrote:
>>>>
>>>> p.s., if we do go down this path it would be interesting to see if there
>>>> is some sort of existing library or standard specification for boolean logic
>>>> expressions that we could piggy-back off of, rather than rolling our own.
>>>
>>> There are also other places in the language that may have similar needs
>>> around expressing conditions and selection criteria, such as when
>>> collecting/realizing virtual or exported resources.
>>
>> Those areas do, in fact, define a small boolean logic language already.
>>
>> Using that elsewhere isn't impossible, but it is a pretty big change
>> to the definition of what a property or parameter can mean.
>>
>>
>> In many ways I think that the `tidy` type is the best thing to compare
>> this to: it explicitly operates on client-side state, and is distinct
>> from the parent type.
>>
>> The separate "user range" type is the closes analog there.
>>
>> It seems like that separation is going to have a whole lot less
>> unexpected or hard edges than extending the "user" type will.
>
> People usually compare it to the exec type, which has the onlyif and unless parameters (and very limited boolean behavior - based entirely on the run status of a command).

Good catch - that is another example, and appropriately client-side.

There has also been discussion of extending those to all resources,
not just exec, which is interesting.

> As you point out, this is logic on the client, rather than on the server.
>
> Another related thing that's been asked for is boolean logic that affects how the graph is traversed - e.g., if A then manage X resource, if B then manage Y resource.  This is an even bigger difference, but still related in that it's client-side logic.

It feels like we need to go some distance down this path, because a
number of decisions (provider selection, UID details, etc) are only
answerable on the client.

I don't know how comfortable I am with the graph traversal changes,
but I can see why they might attract.

Starting with more resources, or perhaps resource-like-things, that
are focused on "group" operations feels like a reasonable first step.

[Pieter van de Bruggen]

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

 

I've talked before about the notion of converting all logic into client-side logic, effectively leaving no server-side logic, but for reasons like "least privilege" it's probably best to shy away from that approach.

Our current model (with a few notable exceptions) emphasizes server-side logic.  It's my opinion that we should either unify on one side, or find a way to promote both -- clearly! -- to equal status.  Adding `onlyif` and `unless` metaparams to all resources may be one way to achieve that.

[Stig Sandbeck Mathisen]

Peter Meier <peter...@immerda.ch> writes:

> I think it's valuable and as you said there are valid uses cases where
> such operations are currently not possible with the default language
> features.

I'm not sure it is generic enough. Having the functionality would be
great, though.

Having a generic "unless" attribute that spans more than one type would
be great, but you'd need to have a way to specify it to either run on
the master (a function returning a boolean value) or to run on the node
(a program returning an exit code).

Either you'd use some function trickery, or two different attributes.
Both would probably have merits and drawbacks.

> Why do you call it terrific? What are your concerns? I couldn't find
> any arguments of your internal debate anywhere.

"terrific" may be used to indicate simply "extraordinary", alternatively
"extraordinary good" or "extraordinary bad", so you'll have to look in
the context. :)

--
Stig Sandbeck Mathisen
Any sufficiently advanced incompetence
is indistinguishable from malice

[Philip Brown]

Bit of a late entry here..

class users::resources {
  resources { 'user':
  purge              => true,
  unless_system_user => true,
  unless_uid => [10_000..20_000];
  }
}

Puppet seems mostly driven on positives.
Perhaps it would be better to reframe it as a positive directive, something like the following:

class users::resources {
  resources { ' user':

     purge_set {
        (Set definition here, where definition can include !system_user, and so on)
     }
  }
}

This sounds a bit cleaner to me, and could possibly be extended better to other resource types.

[Andrew Parker]

Good point on the positives. I feel like I have to think too hard about what 'unless_system_user => true' means. Being able to give purge some sort of structure (that can include negative expressions) of what to purge seems like a nice way of solving this.

 

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/jN1aIE7U-_MJ.