Secret management for discovery handler draft #61
Conversation
johnsonshih
requested review from
kate-goldenring,
bfjelds,
romoh,
jiria and
edrickwong
as code owners
Signed-off-by: Johnson Shih <[email protected]>
johnsonshih
force-pushed
the
discovery-handler-auth-info
branch
from
9d78756 to
98fa16d
Compare
| - onvif://www.onvif.org/name/GreatONVIFCamera | ||
| - onvif://www.onvif.org/name/AwesomeONVIFCamera | ||
| discoveryTimeoutSeconds: 2 | ||
| discoveryProperties: |
There was a problem hiding this comment.
Why a generalized name of discoveryProperties instead of something more specific and narrowly scoped like deviceCredentials?
There was a problem hiding this comment.
on purpose to use a generic name, users can use this field to pass information required for DH, not just credentials.
| - onvif://www.onvif.org/name/AwesomeONVIFCamera | ||
| discoveryTimeoutSeconds: 2 | ||
| discoveryProperties: | ||
| - name: dev-common-data |
There was a problem hiding this comment.
In what scenario do we see this non-auth related dev-common-data needing to be passed to the DH and why here and not in discoveryDetails? IMO, if there is another category of data that needs to be passed that isnt filtering/discovery related (discoveryDetails) or auth related (`deviceCredentials) then we should make one rather than adding it to a box of everything.
There was a problem hiding this comment.
it can be something related to credentials for example a url for DH to query information related to credentials by device id (it's similar to configMap but there is only one entry)
What's the concern of adding a generic field to pass in information to DH? If we just provide discoveryDetails and deviceCredentials, and later we have to support scenarios that is not filtering/discovery related, we will still need to add another field that is almost the same as what we provided for plain text here but just a different (redundant, IMO) field name.
Signed-off-by: Johnson Shih <[email protected]>
|
implementation of this proposal: project-akri/akri#567 |
Signed-off-by: Johnson Shih <[email protected]>
No description provided.