ADCM-6125 Configuration management #17
Conversation
| version: 1.0 | ||
|
|
||
| config: | ||
| - name: root_int |
There was a problem hiding this comment.
what about usage of structure (list and dict)?
There was a problem hiding this comment.
more complex example, will try it with real ADCM
| return wrapper | ||
|
|
||
|
|
||
| class Value[T](_ConfigWrapper): |
There was a problem hiding this comment.
seems ValueWrapper was more complimentary, or maybe something like class Parameter or ConfigParameter? cause it will be strange that Value class has also value property.
There was a problem hiding this comment.
ValueWrapper is a bit long to use it for typehints, but if you insist, I can rename (see Desyncable also)
Parameter isn't the value, it's something like description of value (Value doesn't have name for now, for example)
There was a problem hiding this comment.
on second thought, Parameter may be a good term, let me think about it
There was a problem hiding this comment.
You are right, we can introduce term Parameter, because later we will most likely have schema associated with it alongside the value (description, type properties, etc.)
So naming can be like:
- Parameter
- ParameterGroup
- ActivatableParameterGroup (this one bit too long, but I see no alternatives to
Activatableterm
Or we can shorten Parameter to Param, but user can do that as well, so not a lot of sense in here.
Then we have Host Groups to think about.
IMO we can go with HG suffix for HostGroup, because full HostGroup will be confusing when used with ParameterGroup
Then we'll have:
- ParameterHG
- ParameterGroupHG
- ActivatableParameterGroupHG
or as a prefix:
- HGParameter
- HGParameterGroup
- HGActivatableParameterGroup
In these cases HG works like "modifier" that it's the same entity, but for HostGroups
Desyncable term speaks about property of an entity, not it's context.
| return self | ||
|
|
||
|
|
||
| class Group(_Group): |
There was a problem hiding this comment.
as we have Group in RBAC it may lead to misunderstanding. may be use GroupParameter or GroupOfParameter?
There was a problem hiding this comment.
As you wish, but for me it seems easier:
- Let the user decide (when he wants Group from config and rbac both in the same code, he can rename one of them)
- Name RBACGroup or UserGroup, etc.
IMO name that's used in typing shouldn't be too long
GroupOfConfigParameter => DesyncableGroupOfConfigParameter or GroupOfConfigParameterOfHostGroup (very long)
same as about parameter, I'll think about consistent and convenient naming
tests/unit/test_config.py
Outdated
|
|
||
| # inner type won't be checked (list), | ||
| # but here we pretend "to be 100% sure" it's `list`, not `None` | ||
| config["root_list", Value].set([*config["root_list", Value[list]].value, new_config["root_list"][-1]]) |
There was a problem hiding this comment.
why set accept two parameter? seems it invoked as instance method of existing instance why do we need to pass self?
There was a problem hiding this comment.
set accept 1 parameter
No description provided.