Investigate possibility to externalize holo-cli into its own repository
Pros:
1- Enforce holo modularization. holo-cli is a GRPC client that can be isolated.
2- Decouple holo-cli to all other software. Net-devs can focus on routing modules while app-devs can focus on cli development.
3- holo node can have holo-cli NOT installed. This reduces code size & surface (good for embedded devices)
4- A sort of holo-cli-ctl installed only on an out of band admin network can be implemented in order to connect multiple holo nodes from a sigle host. (no need to installed software like OpenSSHD on the holo nodes)
Cons:
1- Need to use common holo protobuf and yang definition (can be alleviated with git- submodules)
2- Is having a holo-proto repository worth to add in order to have a better tracking of new features addition/deletion in a central place?
3- holo container needs adjustment in order to include holo software suite and holo-cli
rwestphal
commented
6 months ago
Investigate possibility to externalize
holo-cliinto its own repositoryPros: 1- Enforce
holomodularization. holo-cli is a GRPC client that can be isolated. 2- Decoupleholo-clito all other software. Net-devs can focus on routing modules while app-devs can focus on cli development. 3- holo node can have holo-cli NOT installed. This reduces code size & surface (good for embedded devices) 4- A sort ofholo-cli-ctlinstalled only on an out of band admin network can be implemented in order to connect multipleholonodes from a sigle host. (no need to installed software like OpenSSHD on the holo nodes)Cons: 1- Need to use common holo protobuf and yang definition (can be alleviated with git- submodules) 2- Is having a
holo-protorepository worth to add in order to have a better tracking of new features addition/deletion in a central place? 3- holo container needs adjustment in order to includeholosoftware suite andholo-cli