Y. Richard Yang <yang.r.yang@...>

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

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?

Here is a simple test on if a command belongs to karaf console: can it apply to a large number of features. For example, bundle:, feature: ... can be used by others (e.g., sfc, l2switch), but alto: can be used by only alto. Make sense?

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.

 This is a lot of flexibility, which is quite interesting. An alternative is that the CLI deletes the related data instance (e.g., network map). Hence, the benefit of your design is that it might be more efficient: instead of delete a network map and then reload, you stop and then restart. One question is how often this happens. But I like the idea of applying it to Xin's auto map. Consider future extension, then such auto generators need to stop running. It needs some kind of interface to stop in a consistent way. Make sense?

- 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.

I am thinking in the context of a new command line tool. Hence, we have a single program instead of multiple. Then your shortcut can be created by alias. If it is commands inside a shell, then the shorthand is good. But such a shell designs makes scripting harder. 
- 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.


Good insight! Let's discuss at the sync up.

- 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.