Add README.md for describing bootconfig and oc_cli #209
Conversation
Pull Request Test Coverage Report for Build 12638591029Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
| oc_cli | ||
| gnoi | ||
| bootconfig | ||
| factoryreset | ||
| gnmi | ||
| get | ||
| set | ||
| subscribe | ||
| ``` |
There was a problem hiding this comment.
Are these real gnmi/gnoi calls, e.g. there's a gnmi and gnoi clients on the node that can be accessed using this brand new cli? And, correspondingly, there's a grpc server that listens for these commands?
There was a problem hiding this comment.
no they would use the same expected library that the server on device would use for consistency but would not be an RPC call to those services as the point of this cli is to bypass those services not working due to auth or other system configuration issues
There was a problem hiding this comment.
This seems quite critical to call out in this documentation -- a comment could be (especially for the gNMI requirements) that we should make this binary just be gnmic, but you're explicitly saying that this isn't the case.
Given this, I wonder whether we have use cases for these that are well understood, and understand how this would be implemented - since (for example) this might mean duplicating code for e.g., OC translation across the daemon that does this, and the CLI tool itself. It's not immediately clear to me whether this comes at a high cost or not -- and how it would be operationally used. Can't I do most "fixing things in the config" by just being able to set the boot config assuming I've bricked the device?
There was a problem hiding this comment.
so that is the most general of use case yes and that is one of the cli commands (the set boot config has to be standard and recoverable without a remote client being able to call into the device as the breakage may have broken grpc connectivity
| The bootconfig service is responsible for the setting of bootstrap configuration for the device after initial Bootz bootstrap. | ||
| This message may include both the base device configuration but also the new gNSI artifacts. | ||
|
|
||
| While this is service which can be used out of band it also allows for the development of an industry standard CLI for recovery |
There was a problem hiding this comment.
Industry-standard CLI tool? When I read "industry standard" and "CLI" I think CLI format, which I think isn't what you're proposing.
There was a problem hiding this comment.
i don't quite follow? i am saying that all vendors should provide a binary which has a standard set of sub commands and args
There was a problem hiding this comment.
if you mean the cli has consistent args / params for calls and always returns structured data that is exactly what i am saying is a requirement here
| oc_cli | ||
| gnoi | ||
| bootconfig | ||
| factoryreset | ||
| gnmi | ||
| get | ||
| set | ||
| subscribe | ||
| ``` |
There was a problem hiding this comment.
This seems quite critical to call out in this documentation -- a comment could be (especially for the gNMI requirements) that we should make this binary just be gnmic, but you're explicitly saying that this isn't the case.
Given this, I wonder whether we have use cases for these that are well understood, and understand how this would be implemented - since (for example) this might mean duplicating code for e.g., OC translation across the daemon that does this, and the CLI tool itself. It's not immediately clear to me whether this comes at a high cost or not -- and how it would be operationally used. Can't I do most "fixing things in the config" by just being able to set the boot config assuming I've bricked the device?
4 participants
No description provided.