[hostcfgd]: Add Ability To Configure Feature During Run-time #6700
Conversation
tahmed-dev
force-pushed
the
taahme/hostcfg-add-ability-of-runntime-config
branch
from
49ae3a8 to
9de2704
Compare
|
Can you provide an example/description of how this template is to be passed to hostcfgd? |
in the "How I did it" section above, there is an example template. |
I see the template. Just want to understand how it is to be passed to the daemon. |
The template gets written to the config_db past of the bootstrapping when init_cfg.json is loaded to the config_db. hostcfgd will consume it from there. |
The template gets written as a bogus feature state? |
Initially, this line should write the rendered value. Here is an example of before/after hostcgd is invoked: Before: "mux": {
"auto_restart": "enabled",
"has_global_scope": "True",
"has_per_asic_scope": "False",
"has_timer": "False",
"high_mem_alert": "disabled",
"set_owner": "local",
"state": "{% if 'subtype' in DEVICE_METADATA['localhost'] and DEVICE_METADATA['localhost']['subtype'] == 'DualToR' %}enabled{% else %}always_disabled{% endif %}"
},After "mux": {
"auto_restart": "enabled",
"has_global_scope": "True",
"has_per_asic_scope": "False",
"has_timer": "False",
"high_mem_alert": "disabled",
"set_owner": "local",
"state": "always_disabled"
}, |
|
Thanks for the details. While this is a clever solution, I feel it is a bit hacky and complex. Can we not do something simpler, like when hostcfgd first starts, if it detects the subtype is |
Welcome! I was kind of thinking of more generic approach as if there are more features as such, we would ended filling up hostcfgd with special cases instead of caring about the feature attributes. I open to other solutions. |
tahmed-dev
force-pushed
the
taahme/hostcfg-add-ability-of-runntime-config
branch
from
ea7408d to
d0d14bb
Compare
Features may be enabled/disabled for the same topology based on run-time configuration. This PR adds the ability to enable/disable feature based on config db data. singed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
tahmed-dev
force-pushed
the
taahme/hostcfg-add-ability-of-runntime-config
branch
from
d0d14bb to
a5e4fb5
Compare
tahmed-dev
changed the title
Features may be enabled/disabled for the same topology based on run-time configuration. This PR adds the ability to enable/disable feature based on config db data. signed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
…et#6700) Features may be enabled/disabled for the same topology based on run-time configuration. This PR adds the ability to enable/disable feature based on config db data. signed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
…et#6700) Features may be enabled/disabled for the same topology based on run-time configuration. This PR adds the ability to enable/disable feature based on config db data. signed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
Features may be enabled/disabled for the same topology based on run-time
configuration. This PR adds the ability to enable/disable feature based
on config db data.
singed-off-by: Tamer Ahmed tamer.ahmed@microsoft.com
- Why I did it
Dual ToR topology have mux docker while non single ToR topology does not and hence the need to disable feature during run-time.
- How I did it
Added the ability to pass Jinja2 template to hostcfgd. The template could be as follows:
"{% if 'subtype' in DEVICE_METADATA['localhost'] and DEVICE_METADATA['localhost']['subtype'] == 'DualToR' %}enabled{% else %}always_disabled{% endif %}"- How to verify it
On Target:
Single ToR
Dual ToR
- Which release branch to backport (provide reason below if selected)
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)