Rudder

I understand that these are properties we would not change often, or even easily. But I see no reason to hide them.

We never know what the future is made of, and maybe it will make sense to someone one day to change all these properties.

The first use case that comes to mind is in an enterprise that is only allowed one directory technology, that's not OpenLDAP, so they need to put Rudder's LDAP directory in another directory server, and they need to change the base DN (and therefore all the DNs listed above).

I could come up with other use cases, but in general, what I am trying to say here is: don't hide configurable items. It is good to expose as many as possible. Hiding config properties in code would make us seem like some nasty big "one size fits all" solution. Not a nice idea.

However, I would also add that your underlying point is that the rudder-web.properties file is confusing. And I agree. But this is being solved differently: all important, user-configurable properties, are being exposed in the web interface, so that the average user never has to edit this file. And that makes it an expert's file. And then the LDAP properties are in the right place :)

So, rejecting this for now - of course feel free to re-open and discuss if you disagree strongly.

OK for the main argument about exposing properties, I'm not against that. And OK for the "expert" vision of that file, that seems to be the way we want to go.

But I would like to have the correct granularity about exposed properties, and I don't thing we have it here.

The risk with bad exposed properties is to freeze and architecture that was not chosen to be froze at that level, or at some different time (and is not relevant anymore). And so, in fact, we give the user the feeling of modularity when there is none, i.e we are doing false modularity.
And so, we forbid future evolution (because, as you said, we don't know what the future is made of) for no good reason.

So, it seems that the modularity that make sense for Rudder and may actually matter for user is the following:

- a DN for inventories OU, because I can easily think about use case where for performance or integration with other tools, these data live outside of Rudder,
- a DN for Rudder things (policy related, Rudder configuration, etc), because they are not exposed today and I don't see a more granular split that make sense in isolation

So basically, I would like to merge ldap.node.base / ldap.inventories.software.basedn / ldap.inventories.accepted.basedn / ldap.inventories.pending.basedn / ldap.inventories.removed.based into one property, "ldap.inventories.basedn".

One reason for that is to allow us to change the inventory structure to allow adapt to scalling when we will need to scale to thousand of nodes - not that I already now what we will have to change, if anything, but if we have to, we won't want to deal with case where the user changed these properties.

I won't argues more for that, so feel free to close it again - we can wait to have user & scalling feedback to take a more data-evidence based choice about the inventory structure.

OK, I see what you mean. I have nothing against removing some of the "outer leaves" from this configuration, so long as we keep at least the following properties fully configurable:

ldap.node.base=cn=rudder-configuration
ldap.rudder.base=ou=Rudder, cn=rudder-configuration
ldap.inventories.basedn=ou=Inventories, cn=rudder-configuration

(note that the last one in the list doesn't currently exist, I thought it did, but it was called ldap.inventories.*software*.basedn, which seems clearly wrong)

However, if we don't know where we're going with this, and since this is not hurting anyone at this point in time, and we have many other higher priorities (bugs to fix! new features to implement!) I would like to set this aside for now, and avoid spending precious time on it until we have a good reason to.

In that spirit, leaving the ticket open, but unassigned, and targeted for "sometime in the future". Is that OK for you?

They were removed in rudder 5.0