'groups' promise type?

16 views
Skip to first unread message

David Lee

unread,
May 11, 2019, 8:36:59 AM5/11/19
to dev-cfengine
There is a 'users' promise-type:

   https://docs.cfengine.com/docs/3.12/reference-promise-types-users.html

So it would seem natural for there to be an analogous 'groups' promise-type.  Indeed, wouldn't a site wishing to use 'users' reasonably expect also to find 'groups'?  But it seems to be absent.  Is there any particular reason for this surprising absence?

If I were to think about coding it, modelled after 'users', are there any "surprise points" that might have tripped up previous explorers of this terrain?

-- David Lee

Nick Anderson

unread,
May 11, 2019, 2:24:05 PM5/11/19
to David Lee, dev-cfengine
It is absent, unfortunately. There is a ticket here https://tracker.mender.io/browse/CFE-2215

I don't know of any surprises. And while it's quite annoying to be missing, it just hasn't risen to a high enough priority for us to implement it (though we would love to have it).



--
You received this message because you are subscribed to the Google Groups "dev-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-cfengine...@googlegroups.com.
To post to this group, send email to dev-cf...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dev-cfengine/1803a04b-b38c-4c88-9c83-53c81a73ff93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Lee

unread,
May 13, 2019, 3:26:09 PM5/13/19
to dev-cfengine
Thanks, Nick.  (I should have checked that issue tracker.)

I see there are 50 comments on the ticket, with some interesting debate.  It looks to be decidedly non-trivial, so I'll probably back away from my initial rush of enthusiasm.

-- David


On Saturday, 11 May 2019 19:24:05 UTC+1, Nick Anderson wrote:
It is absent, unfortunately. There is a ticket here https://tracker.mender.io/browse/CFE-2215

I don't know of any surprises. And while it's quite annoying to be missing, it just hasn't risen to a high enough priority for us to implement it (though we would love to have it).



On Sat, May 11, 2019 at 7:37 AM David Lee <t....@servicemusic.org.uk> wrote:
There is a 'users' promise-type:

   https://docs.cfengine.com/docs/3.12/reference-promise-types-users.html

So it would seem natural for there to be an analogous 'groups' promise-type.  Indeed, wouldn't a site wishing to use 'users' reasonably expect also to find 'groups'?  But it seems to be absent.  Is there any particular reason for this surprising absence?

If I were to think about coding it, modelled after 'users', are there any "surprise points" that might have tripped up previous explorers of this terrain?

-- David Lee

--
You received this message because you are subscribed to the Google Groups "dev-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-cf...@googlegroups.com.

Mike Weilgart

unread,
May 14, 2019, 2:10:24 PM5/14/19
to David Lee, dev-cfengine
From a look over that issue, it looks like the worst of waterfall methodology.  Sorry to sound harsh, but it can be observed that the giant spec has NOT been implemented, and as seen in this thread it has actually scared off a potential implementer.  That’s counter-productive.

I think what would make a lot more sense than implementing a giant spec, would be implementing a MINIMAL spec, while allowing for eventual expansion with backward compatibility.

For instance: for the first iteration, implement absolutely nothing but:

groups:
  “somegroup”
    policy => “present”;

Make the “policy” attribute required even though only the “present” value will be allowed, just because that will allow the most flexibility for future changes, while retaining backward compatibility.  (E.g. maybe later that attribute will become optional, but the behavior of having the attribute THERE will not change.)

This should be really easy to code, then, and should be immune to bikeshedding.

It could go before or after users in normal ordering; I don’t think it really matters.  For the minimal implementation, “before users” makes more sense, but later on “after” could be preferable; either way there are minor trade offs, so flip a coin.

Best,
—Mike Weilgart
Vertical Sysadmin, Inc.

Sent from my iPod
To unsubscribe from this group and stop receiving emails from it, send an email to dev-cfengine...@googlegroups.com.

To post to this group, send email to dev-cf...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages