Gao Kai

On 16/04/15 13:04, Y. Richard Yang wrote:

Hi Kai,

Good work! Here are some quick initial feedback:

- In the long run, alto:* should not be karaf commands. The CLI should be a standard alone admin client that manages the alto info at a server. Hence, there may need a param to indicate the server (container running alto service).

I don’t get it. If we don’t use them as karaf commands in ODL, why bother implementing CLI in ODL?

Also the CLI is just a northbound tool, it justs take the parameters, maybe validates them and invokes the corresponding service to do the job. It’s just for administrative convenience after all. The CLI doesn’t actually do anything about the services themselves and in some way they are also clients to the services. And yes of course they can be made standalone and be named whatever people want.

The design for CLI syntax has nothing to do with the functionalities of the services. The reason I write down the details of the syntax is to demonstrate what functionalities should be supported by the services.

And since it is brought up, certainly the CLI tool can be configured to connect a remote server. In karaf, I imagine it is possible to implement that with subshell so things will look like:

karaf $ alto-cli:connect <server-uri>
karaf(alto-cli) $ networkmap list
karaf(alto-cli) $ networkmap status default-networkmap

- My understanding is that your :service command is to decide if a category of service is available. What is the autostart? Why stop a service? For consistent updates?

The idea is simple. All alto services can run independently. It is possible to run networkmap services without running an IRD service.

Setting autostart to true means the service should be activated once the controller is up.

Why stop a service: when you don’t want to run such a service. For example I have one controller running both networkmap/costmap services then one day I decide to use the networkmap from a standalone server I can just turn off my networkmap service and configure my costmap service to use that networkmap.

- Instead of :x commands, how about instanceop <service> <instance-pool-operation>?

Why make it harder than it has to be? alto:ird register is so much better than alto:instanceop ird register in my opinion.

- A key flexibility you are considering, I believe, is ird.

Not actually. The only reason I provide the yang models for IRD alone is that IRD is the simplest service among all.

- The commands map to old projects.

I wouldn’t worry about it. Changing the scope such as “alto-cli” can simply do the trick. And if the subshell is confirmed then there will be no confusion.


On Thursday, April 16, 2015, Gao Kai <godrickk@...> wrote:

Hi all,

Yesterday I was asked to give a brief description about my understanding of the design and here is the response.

A deployment scenario through the command line:

When feature alto-service is installed:

karaf $ alto:service <service-name> <operation> [<parameters>]
service-name = { ird-pool | networkmap-pool | costmap-pool | endpointmap-pool }
operation = service-operation

service-operation = { start | stop | autostart { true | false } | status }

instance-pool-operation = {
    | create <id> <description-file>
    | destroy <id>
    | start <id>
    | stop <id>
    | autostart <id> { true | false }
    | status <id> [<version-tag>]
    | update <id> <new-description-file>
    | configure <id> <property> [<parameters>] }

When no parameters are given to configure the command will return the value of
the property.

ird-registry-operation = {
      register <resource-id> { remote <ird-registry-uri> | local <ird-id> }
    | unregister <resource-id> { remote <ird-registry-uri> | local <ird-id> }}

When ird-pool service is activated:

karaf $ alto:ird <operation> [<parameters>]
operation = instance-pool-operation | ird-registry-operation

When networkmap-pool service is activated:

karaf $ alto:networkmap <operation> [<parameters>]
operation = instance-pool-operation | ird-registry-operation

When costmap-pool service is activated:

karaf $ alto:costmap <operation> [<parameters>]
operation = instance-pool-operation | ird-registry-operation

When endpointmap-pool service is activated:

karaf $ alto:endpointmap <operation> [<parameters>]
operation = instance-pool-operation | ird-registry-operation

Here are some examples for the description files:
A static networkmap description file example:

    name : "static-map-1",
    generator : {
        class : "static-file-generator",
        file : "/opt/alto/configuration/networkmap/"

A host tracker costmap description file example:

    name : "hosttrack-map-singleton",
    generator : {
        class : "hosttracker-generator",
        dependency: [
    autostart : true,
    registry : [

The yang-models for ird-pool service and data are described in the attached files (still not complete though).




Join to automatically receive all group messages.