SOFIE-47 | add automatic configuration of peripheral devices if there is only 1 studio#1569
SOFIE-47 | add automatic configuration of peripheral devices if there is only 1 studio#1569
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
anteeek
force-pushed
the
feat/SOFIE-47
branch
2 times, most recently
from
49c725c to
08dc25e
Compare
|
|
|
||
| const configId = unprotectString(deviceId) | ||
|
|
||
| await Studios.updateAsync(studio._id, { |
There was a problem hiding this comment.
I'm not sure how I feel about this creating a config object for itself when attaching..
There are 2 scenarios:
- blueprints provide config objects for each device. meaning the user will need to go to the settings to reassign it to the correct one and delete this temporary object
- blueprints done provide config objects. meaning this was helpful.
As the recommended approach for blueprints is 1, should we be prioritising that being smoother?
I dont know, Im curious what anyone else thinks
There was a problem hiding this comment.
I too feel that this is a false friend in our "Configuration as Code" philosophy. I think we should probably re-think our "first run story": we should have the blueprints be the first thing that gets set up in a System, have them pre-populate the deviceSettings for a Studio and then, on first connection, the Peripheral Devices are matched to a known config.
There was a problem hiding this comment.
Yeah I dont disagree with that, but even if blueprints are supposed to pre-generate the configurations, there will be cases where they havent so having a fallback to attach them with an empty config is still good.
So I am leaning towards leaving that larger rethinking until we have actually removed support for multiple studios; as that should in theory simplify these things even further
There was a problem hiding this comment.
@anteeek I seem to be seeing a convention brewing that matches a property called parentDeviceName with configId, but I'm not an expert in this field, so I might be mistaking things. Maybe @scriptorian could provide some insight into the intended use? All my thoughts are around that this should work same-ish.
There was a problem hiding this comment.
I can try to give a short review of my understanding in my usage...
A studio instance in the studios collection has a BlueprintConfigWithOverrides property that can support 'parent' devices that are the gateways - playout, mos, live status etc - and other devices that are supported by these gateways.
The configuration data for each gateway has an objectID that should match the id that the gateway process is started with - mentioned further below.
The configuration data for eg playout devices can specify the parentConfigId property that should match the id of the playout gateway that is expected to support it. In my usage it theoretically allows me to run multiple playout gateways with different playout devices on each.
When the studio blueprint config is upgraded (through the UI or API) the job-worker/src/playout/upgrade.ts code parses the blueprintConfig and does the best it can to connect the devices to the parents, writing the resulting configuration to the studio peripheralDeviceSettings with the objectID becoming the key for the device settings.
When eg the playoutGateway is started up for the first time it will create a new document the the peripheralDevices collection of the studio. This document has a studioAndConfigId property where the configId property is set to be the id that the gateway was started with. This id is then used as a lookup into the studio peripheralDeviceSettings for the particular settings that are to be used by this device - eg debug logging / multi threading etc - hence the join back to the blueprint config objectID.
The result of this in my usage is that a blank studio can now be configured entirely from the API.
Apologies - I failed to make it short. Too late in the day!
| $push: { | ||
| [`peripheralDeviceSettings.deviceSettings.overrides`]: { | ||
| op: 'set', | ||
| path: configId, |
There was a problem hiding this comment.
While the risk is low, it is possible that this will replace an existing config with this empty one. I think this needs to make sure that configId isnt already defined before adding this override
There was a problem hiding this comment.
@Julusian I added a safeguard to prevent overriding, would appreciate if you can take a look 🙏
Saftret
added
the
Contribution from SuperFly.tv
… is only 1 studio
anteeek
force-pushed
the
feat/SOFIE-47
branch
from
08dc25e to
046a5bf
Compare
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
It seems to be creating a config for each child device that gets added: Each time I set the 'Parent Config ID' of a playout device to a gateway, it is creating a row in this table |
6 participants
About the Contributor
superfly.tv
Type of Contribution
This is a:
Feature
Current Behavior
Currently, a new device needs to be manually configured after first launch & discovery by Sofie
New Behavior
This PR adds automatic configuration of the new device, attaching it to the studio, but only if there is exactly 1 studio configured
Testing
Affected areas
This PR affects the behavior of Sofie after a new device connects for the first time
Time Frame
Not urgent, but we would like to get this merged into the in-development release
Other Information
Status