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?
|
|
||
| ## CLI use cases | ||
|
|
||
| The CLI should be bundled with the router and exist in the default path. |
There was a problem hiding this comment.
Is the cli expected to be called from the vendor cli, or a linux shell?
| 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
| The CLI must be named `oc_cli` it must have the following heirarchy for calling specific services. | ||
|
|
||
| ``` | ||
| oc_cli |
There was a problem hiding this comment.
Given that we don't have test cases for the non-gNOI cases here, are they as critical?
There was a problem hiding this comment.
they are probably not p0 as if we can recover. the box with the bootconfig then we can use other tools for troubleshooting after recovery
| 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?
No description provided.