[rudder-users] question on policy change tracking

[Francois Armand]

(aaaannnd I forgot to hit "send" on that email)
(aaaaannnd somehow the ml was removed, sorry Tim for the double sending)

On 15/11/2019 20:54, tim taler wrote:
>
>
>     Yes, we wanted to avoid (by default) to have everything in
>     shared-files in git. We used to do that, but early feedbacks
>     showed that users were very surprised to have binaries and etc
>     going to git, which resulted in bloated git repos and performance
>     degradation.
>
>
> true ... I indeed had those few binaries I had to handle in a 
> separate non-git directory on the cfengine server ...
>
>>     So ... while you on it,
>>     IMO it would be nice it:
>>     a) file changes there, would also be in some way visible in the
>>     GUI (like "notice, somebody copied new files to folder xyz, you
>>     like to confirm?")
>
>     Nice idea, but actually with your second idea, it becomes (almost)
>     unecessary (ok, it is something different, but one could arg that
>     if a gui+rest api is available for upload then we can assume than
>     direct changes in the fs with root access to the server as "admin
>     special action").
>
>
> agreed ;-)
>
>>     b) so far I'm very used to the commandline, but with rudder I see
>>     the benefit of some restiction through a common interface, so you
>>     might want to consider to have a graphical upload of those files
>>     to the shared_folder on the rudder server, that would ease the
>>     change management for that folder, right?
>
>     Excellent idea :)
>
>     And we are working on it for 6.0, with: each technique get a
>     private "resource" directory which is versionned with it and files
>     are automatically transfered with the technique code (typical use
>     case: templates, config files, etc).
>
>     And now that you say it, adding a shared file ui would be simple.
>     We didn't do it for now because of rights ("authz == it's
>     complicated"). But we could have it only for admin. Let me think
>     about it.
>
>
> I haven't looked into the "role" system of rudder yet, but my first 
> idea would be:
> - either a role allows manipulation of a rule/directive/technique (any 
> setting that affects the manged systems) than it can also upload files 
> (the file properties on the rudder-server/shared_folder are 
> irrelevant. what matters are the properties when they are deployed, 
> and that will be controlled through a file property promise)
> - or the role doesn't allow any of those manipulations, than there is 
> also no need to access the upload functionality

Good point. It's a share folder after all.

> But you might have more complex situations (managing a subset of nodes 
> or directives/rules/techniques)

We are working on restricting node/rules by authz. It's not done for now 
("authz == it's complicated" - yeah, my previous life in identity & 
authz management let sequels :)

> Anyway IF there would be an upload possibility through the GUI it may 
> require to distinguish between binary/non-binary content (and 
> according two directories in the shared_folder) to avoid the git bloat?
>
>     For 7.0, we are going much more deeply in what is a configuration
>     (rules/directives/etc), and what is environment/context
>     (nodes/etc), and what is "out of control of Rudder" (node local
>     env variable, etc). We will have different verionning for each,
>     with a full graphe dependency (and possibility to use previous
>     version of subgraphe, for ex "that rule, but with the previous
>     version of that directive (and its technique/resources) because
>     I'm in the middle of a migration).
>>
>>     ... just some ideas
>
> and while I'm on it ;)
>
> Under directive "System settings/System management" along with the 
> management of cron jobs etc. there could be a ready made technique for 
> sysctl settings, or?

We try to do it but AFAIK the semantic was not clear at all (relative to 
peristance etc). I think Felix or Nicolas could have more information.
Acutally, I think we reach the state where we have either an opinaited 
solution that was not very generic, or a generic solution that was 
harder than just editing files in /etc/sysctl.d. But if you have a 
need/use case, we would love to hear about it. In that case, would you 
mind start a new email thread with a meaningfull title so that other 
people can see/contribute to it?

>
> looking forward to the upcoming versions :+1:
>

We too :)


<http://www.rudder.io/> 	*François ARMAND*
CTO
*T:* +33 183 62 99 23 *M:* +33 663 37 60 55


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20191118/d41e0db0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loedkjhdglbkcefn.png
Type: image/png
Size: 5490 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20191118/d41e0db0/attachment.png>