Design reversal of alto-manager?

Y. Richard Yang

Dear team,

I am having some second thought on the alto-manager design. This is triggered when I was (1) thinking about the implications of providing the alto:* scope in the karaf console, and (2) reading through some other ODL projects on how they provide an admin interface. My thinking is that alto is not in the same group as the other scopes defined in karaf commands (bundle, dev, feature, instance, jaas, log, obr, scr, service, shell, ssh, system, web, and wrapper; see Hence, the idea of introducing alto as a karaf command scope may not make sense--after all, alto:* are not karaf commands to manage OSGi related things). I believe that this design was my fault :-(

Then, how do we handle the admin/provisioning aspect? After all, we need an interface for an admin to load, unload, and set configs of ALTO services. Let's still call this interface the alto-manager. For maximum flexibility, alto-manager should not be designed to have to run inside of the same karaf container hosting the server aspect. It should be a client. Hence, it can be a simple, standard-alone restconf client, or better, a wrapper of a restconf client. Make sense?


Join to automatically receive all group messages.