Investigate possibility to externalize holo-cli into its own repository
#12
Assignees
Comments
rwestphal
added a commit
that referenced
this issue
Apr 9, 2024
Add the description field as it's required by crates.io to publish crates. The `holo-yang` crate needs to be published since it's used by `holo-cli`, and `holo-cli` is going to be moved to a separate repository (see #12). Eventually, we want all Holo crates on crates.io, but it's too early for that now. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Merged
|
Closed by #17 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Investigate possibility to externalize
holo-cliinto its own repositoryPros:
1- Enforce
holomodularization. holo-cli is a GRPC client that can be isolated.2- Decouple
holo-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 of
holo-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 include
holosoftware suite andholo-cliThe text was updated successfully, but these errors were encountered: