Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #16347: Group properties #2890

Merged

Conversation

fanf
Copy link
Member

@fanf fanf commented Apr 13, 2020

https://issues.rudder.io/issues/16347
First working version of group properties.
Works:

  • inheritance of subgroups is undertood,
  • if a property is defined on two unrelated groups, it's an error (appart if they are exactly the same prop)
  • group properties can be added by API
  • saved in Ldap
  • event log and save in XML
  • no UI
  • when a value is a json object overriden by an other json object, json is merged.

Does not work:

  • global parameters follows same rules

@fanf fanf requested a review from ncharles April 13, 2020 02:08
@fanf fanf added WIP Use that label for a Work In Progress PR that must not be merged yet qa: Can't merge labels Apr 13, 2020
@fanf fanf requested a review from VinceMacBuche April 13, 2020 02:09
@VinceMacBuche
Copy link
Member

Hooks permissions were modified ;)

name : String
, value : JValue
) {
def renderValue: String = value match {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this could be in GenericPropertyUtils

Or having a trait for Properties having this type and then a function in this trait or an implicit class providing this function

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought a bit to that, but I went to GroupProperties because:

  • NodeProperties are reasonably different, both in code (because of provider) and in semantic (because the overriding is totally different, they are the only one that matters in the end: they are the only one to go to node
  • I'm not sure that if we add other properties, they will be the same.

But in current way of doing things, it's rather bad. We have double serialisation for each of them, which mean a change to define incompatible format and make impossible sharing things like the property editor.
So I think it should be done, not sure how (perhaps a property which is just a name + value, and a case class NodeProperty(property: Property, provider: ...) and smart constructor/extractors...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having an inner Property with common behavior for all properties would be interesting, but maybe we can keep it for another PR

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can. And I'm not sure we can makes much more than what is in GenericPropertyUtils, because for three cases (global param, node prop, group prop), we have 3 differents way of serializing (totally different for param, and node has more info than group). Perhaps there's something that can be done regarding event log, and even there, we have similar problems

@fanf fanf removed WIP Use that label for a Work In Progress PR that must not be merged yet qa: Can't merge labels Apr 14, 2020
@fanf fanf force-pushed the ust_16347/group_properties branch from 80ae01e to 1279e30 Compare April 16, 2020 16:43
* - if the overriding value is a simple value or an array, it replaces the previous one
* - if the overriding value is an object and the overriden value is a simple type or an array,
* the latter one is replaced by the former
* - if boeth overriding/overriden are an array, overriding values are appended to overriden array
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure here if we should only keep the overrding values

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now, we have both: [overriden, overriding]. I think it may not be what people want, but I also thing that whatever the choice, half people will want the other one

* - if both overriding/overriden are objects, then each key is overriden recursively as explained,
* and new keys are added.
*/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To sum up,

if overriding is:

  • a value => overrides everything
  • an array => overrides value and object, append value to overriden array
  • an object => overrides value and array but if object :
    ** if key in both object : merge recursive on the values of theses keys
    ** keep keys that are only in one of the two object (either overriding or overriden)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like that

@@ -148,6 +140,7 @@ class GroupsApi(
if(req.json_?) {
req.json match {
case Full(arg) =>
println("****** json:" + compactRender(arg))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove this print

def buildUp(root: GroupProp, all: Map[NodeGroupId, GroupProp]): PureResult[InvertedTree[GroupProp]] = {
// recursively takes parent, keeping criterion line order
for {
parents <- root.parentGroups.accumulatePure { id =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if there is a cycle between two groups ?

It should not happen, because in this case there is lot of chance that that the groups are empty (if combined with an AND),

or the composition is OR and then the groups are filtered from parents and it will trigger an error in case of common property...

So it should be ok

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cycle are forbidden by construction and check when a group is modified

@VinceMacBuche
Copy link
Member

I think I'm ok with the PR and did not find any problems within the code.

It should be tested live to see how it behaves within a real Rudder and how we can use this brand new properties and its limits !

I can't merge because I think a commit is not named fixup!

@VinceMacBuche
Copy link
Member

And no issue number in commits too ;)

@VinceMacBuche
Copy link
Member

And the small feedback about a println too

@fanf
Copy link
Member Author

fanf commented Apr 20, 2020

PR updated with a new commit

@VinceMacBuche
Copy link
Member

You still need to handle the two first commits to have issue number in fisrt one and a fixup! in second commit

@Normation-Quality-Assistant
Copy link
Contributor

OK, merging this PR

@Normation-Quality-Assistant Normation-Quality-Assistant merged commit 271dc76 into Normation:master Apr 20, 2020
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants