Populate discovery metadata in generated config #1033
Conversation
.gitignore
Outdated
| @@ -44,6 +44,7 @@ __pycache__/ | |||
|
|
|||
| .vscode | |||
| .class | |||
| .idea | |||
There was a problem hiding this comment.
we shouldn't be ignoring all of this -- some of the .idea files are actually useful to have in source control... if done properly! Are there some specific ones that are causing you grief?
| }); | ||
| } | ||
|
|
||
| return discoveryConfig; |
There was a problem hiding this comment.
this should return null if there is no discovery block in the metadata
| @@ -275,4 +279,26 @@ public String getUpdatedTimestamp() { | |||
| return isoConvert(metadata.timestamp); | |||
| } | |||
|
|
|||
| private DiscoveryConfig getDiscoveryConfig() { | |||
| DiscoveryConfig discoveryConfig = new DiscoveryConfig(); | |||
| discoveryConfig.families = new HashMap<>(); | |||
There was a problem hiding this comment.
I try to be pedantic with some of this and only set values that are defined in the source. Theoretically (future proofing) there might be a DiscoveryModel that does NOT have a families block, and in that case this should be null as well. There's an easy construct we have to do that, something like:
discoveryConfig.families = ifNotNullGet(metadata.discovery.families, families --> new HashMap());
basically, at each level of the hierarchy, there should be a config entry If-and-only-if there's a corresponding metadata entry!
| FamilyDiscoveryModel familyModel = metadata.discovery.families.get(family); | ||
|
|
||
| if (familyModel != null) { | ||
| familyDiscoveryConfig.generation = familyModel.generation; |
There was a problem hiding this comment.
One thing registrar does is some light error checking on things in the model, just to provide clues as to what might be wrong as early in the process as possible. Towards that, take a look at the discovery docs: https://github.com/faucetsdn/udmi/blob/master/docs/specs/sequences/discovery.md#sporadic-scan
If you chart it out, it's somewhat of an error in this case if a generation is supplied for a sporadic scan (meaning scan_interval_sec is not defined) in the sense of this being a model. So, maybe add some logic here to detect that case and flag an error. This will also get you slowly introduced to some of the logical behavior of the system. Something like:
checkState(familyModel.generation != null && familyModel.scan_interval_sec == null, "generation specified without scan_interval_sec parameter")
| @@ -0,0 +1,81 @@ | |||
| { | |||
| "version": "1.5.2", | |||
There was a problem hiding this comment.
In addition to this schema-only test (it's just the input!), it would be good to add in a dynamic test as well of the output generated_config -- see here:
peringknife@peringknife:~/udmi/tests/sites/basic/devices/AHU-1$ ls -l expected/generated_config.json
-rw-r--r-- 1 peringknife primarygroup 651 Nov 20 22:12 expected/generated_config.json
Basically if you add something into that metadata.json file the test infrastructure picks it up and should generate (and then verify) the generated_config.json file.
You can run this test locally with something like "bin/test_sites basic"
You'll actually see that the current tests are failing with your code because of the comment below about "this should be null if the input is null" -- https://github.com/faucetsdn/udmi/actions/runs/11971809492/job/33377389955?pr=1033#step:12:62
One thing maybe to do next is to setup GitHub Actions on your own account so you can see the results locally!
No description provided.