1. z.archive.alto-dev@lists.opendaylight.org
  2. Messages
   Date   
Re: Some questions about deleting data by alto-manager

Y. Richard Yang
 

Hi Xin,

Good discussion. Suppose the admin issues alto:delete (btw, I found the verb destroy too violent, so I, as you, will use delete). I assume that then the network will disappear. This means that it should not appear either in northbound or restconf (deleted from data store). Following the principle of minimal amount of work, then your bundle should deregister from all events and stop running. We do not have a restart command yet---we have not designed the whole life cycle thing yet. So the state machine, at this point is:

event: feature:install -> state: running
event: alto:delete hostrackermap -> state: stopped

There is no transition to resurrect it, unless we want to conduct a more complete lifecycle design. 

The outcome of the admin issues feature:install again at the stopped state is not defined.

Agree?

Richard

On Wed, Apr 15, 2015 at 11:15 AM, wangxin <xinwang2014@...> wrote:
Hi Richard,

I didn’t understand if alto-manager deletes alto-hosttracker-generated data (i think delete is only action it can do), how alto-hosttracker reacts?

  1. it stops listening to l2switch and waits for alto-manager’s next command (like restart)?
  2. it continues listening to l2switch and just adds new data to data store? (it’s like option 1’s restart, but it keeps history data about existing hosts)
  3. some other choices?

Thanks,
Xin
Re: [yangtools-dev] Anyxml in yang model

Y. Richard Yang
 

Hi Tony,

We are going down the path of trying augment (based on the cost-mode: numerical vs ordinal vs path-vector vs calendar vs policy). We will keep you updated. If you have new suggestions, please let the alto-dev people know as well--we are still new to this.

Thanks!

Richard

On Wed, Apr 15, 2015 at 12:04 PM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:

Hi, still trying to figure out other possibilites for you how to model cost-maps and do not loose exact type information.

 

Tony

 

From: wangxin [mailto:xinwang2014@...]
Sent: Tuesday, April 14, 2015 2:21 PM
To: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); yangtools-dev@...
Cc: alto-dev@...
Subject: Re: [yangtools-dev] Anyxml in yang model

 

Thanks for your information about DOM APIs, and i am looking into it. If we decide to use it, we need to change a lot of things like data broker, transaction and data change listener. Is this right? And actually there is only one data in alto yang model using anyxml, which is cost in cost-map.

 

Thanks again,

Xin

 

发自 Windows 邮件

 

发件人: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
发送时间: ‎2015‎年‎4‎月‎14‎日, ‎星期二 ‎16‎:‎02
收件人: xin wang, rovarga@..., yangtools-dev@...
抄送: alto-dev@...

 

Hi,

We do not support anyxml in currently generated DTOs, but DOM data and DOM broker support it using different

APIs (called DOM APIs).

 

Which type of data from alto specification do you want to model as anyxml?

 

 

Tony

 

From: yangtools-dev-bounces@... [mailto:yangtools-dev-bounces@...] On Behalf Of wangxin
Sent: Monday, April 13, 2015 6:37 PM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); yangtools-dev@...
Cc: alto-dev@...
Subject: [yangtools-dev] Anyxml in yang model

 

Dear Varga and others in yangtools,

 

I am working at implementing alto in odl and i use anyxml to define some data in yang model considering the data could be an object, array, string, etc. But i find that there is no method to set its value in the class generated by using yang tools, also there is no field of the data in the class. There is no error when generating the code. It looks like it just skips the anyxml defined data. Did i miss something to make it work? Or it doesn’t support anyxml for now?

 

Thanks,

Xin

 

发自 Windows 邮件

 


_______________________________________________
alto-dev mailing list
alto-dev@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opendaylight.org_mailman_listinfo_alto-2Ddev&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=gfMl2yBw4JbwJoEgmcSZTmApIwRrkuZ0NdKr8aUlcaA&s=kO12hE8x_19dUP6Hha2yzYdrrHFC7qRpTjcolf2uBFQ&e=
M4 status of ALTO

Y. Richard Yang
 

Hi all,

This is an update of our M4 status:

1)  API freeze achieved. (All externally accessible APIs [Stable and Provisional] may not be modified.)  
Yes

2)  Document word counts for each documents: (Please provide word counts for ascii docs) 
docs/manuals/user-guide/src/main/asciidoc/alto/odl-alto-user.adoc: 348 words
docs/manuals/dev-guide/src/main/asciidoc/alto/odl-alto-dev.adoc: 202 words
docs/manuals/install-guide/src/main/asciidoc/alto/odl-alto-install.adoc: 235 words 

3)  Project meet the requirements to be included in Maven Central [0] 
Yes (Javadoc/sources, GPG key, Sufficient Meta)

4)  Defined a simple system test for karaf distribution with recommended features installed. 
Still working on tests: feature template, system test. Expect to be done within 5 days.

Thanks.
Y
About cost in yang model

xinwang
 

Hi all,

We haven’t decided how to handle anyxml issue in yang model. And here is my idea. We use augment instead of changing anyxml into string. The backgroud is though cost has multiple structures like string, list, etc, for one provider, the type of cost should be static, which means for example, alto-xxx provides one and just one type of cost, cost-xxx, at the same time alto-yyy provides another one and only one type of cost, cost-yyy. Any provider provides only one type. And if it provides cost, then it should use augment statement to add new cost type.

This still has limitations considering when using restconf to get value, it should specify the cost type instead of getting any type of cost.

Does this make sense?

Thanks,
Xin

发自 Windows 邮件
Re: CLI

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.


OK.

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

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


Richard

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 = {
      list
    | 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/static-map-04542ead1343.map"
    }
}

A host tracker costmap description file example:

{
    name : "hosttrack-map-singleton",
    generator : {
        class : "hosttracker-generator",
        dependency: [
            "static-map-1",
        ]
    },
    autostart : true,
    registry : [
        "remote:http://someoneelse.com/ird/registry",
        "local:root-ird",
    ]
}

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

Yours,

K

​


--
Richard

​


--
Richard
Re: CLI

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.


Richard

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 = {
      list
    | 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/static-map-04542ead1343.map"
    }
}

A host tracker costmap description file example:

{
    name : "hosttrack-map-singleton",
    generator : {
        class : "hosttracker-generator",
        dependency: [
            "static-map-1",
        ]
    },
    autostart : true,
    registry : [
        "remote:http://someoneelse.com/ird/registry",
        "local:root-ird",
    ]
}

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

Yours,

K

​


--
Richard

​
Re: CLI

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

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

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

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

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

- The commands map to old projects.

Richard

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 = {
      list
    | 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/static-map-04542ead1343.map"
    }
}

A host tracker costmap description file example:

{
    name : "hosttrack-map-singleton",
    generator : {
        class : "hosttracker-generator",
        dependency: [
            "static-map-1",
        ]
    },
    autostart : true,
    registry : [
        "remote:http://someoneelse.com/ird/registry",
        "local:root-ird",
    ]
}

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

Yours,

K

​


--
Richard
CLI

Gao Kai
 

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 = {
      list
    | 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/static-map-04542ead1343.map"
    }
}

A host tracker costmap description file example:

{
    name : "hosttrack-map-singleton",
    generator : {
        class : "hosttracker-generator",
        dependency: [
            "static-map-1",
        ]
    },
    autostart : true,
    registry : [
        "remote:http://someoneelse.com/ird/registry",
        "local:root-ird",
    ]
}

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

Yours,

K

​

?
alto-ird-service.yang
?
alto-ird-data.yang

Re: Design reversal of alto-manager?

Y. Richard Yang
 

Dear team,

I added the initial version due to the feature template requirement:
https://wiki.opendaylight.org/view/ALTO:Lithium_User_Facing_Features

I will add more tomorrow. Including the documents that I just checked in today, we are getting closer to meet the M4 milestone.

Kai/Xin: Please try to get the integration test in as soon as you can.

Thanks!
Richard

On Wed, Apr 15, 2015 at 11:05 PM, Y. Richard Yang <yry@...> wrote:
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 http://karaf.apache.org/manual/latest/commands/commands.html). 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?

Richard
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 http://karaf.apache.org/manual/latest/commands/commands.html). 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?

Richard
[release] remote Karaf command does not take multiple arguments?

Y. Richard Yang
 

Issues that we may face as well. For those of us who are not on slacks:

Here is a summary on alto: commands. There are 4 design considerations:
1. The design is to be consistent with karaf commandline.
2. karaf access can be remote (http://karaf.apache.org/manual/latest/users-guide/remote.html). Hence, we need to consider how an admin can edit,  upload, and download resource files. 
3. An admin may need to upload a set of resources. Hence, how this is accomplished (automation, scripts) should be considered.
4. The admin ci should support both upload, download but also set control options.

---------- Forwarded message ----------
From: <Yuling_C@...>

---------- Forwarded message ----------
From: <Yuling_C@...>
Date: Wed, Apr 15, 2015 at 1:47 PM
Subject: [release] remote Karaf command does not take multiple arguments?
To: controller-dev@..., release@..., integration-dev@...


Hi All,
 
We’re facing issues in automated system test that it seems the remote Karaf command does not take multiple arguments and complained “too many arguments specified”. On the same test bed, manually executing the same command that takes a few arguments worked fine. However, if we issue the command through remote connection to the Karaf, then we hit the issue.
 
Just wondering if anyone has tried remote Karaf command and if the multiple arguments work well through Karaf remote connection?
 
Thanks very much,
 
YuLing
 
_____________________________________________
From: Balasubram, Vasanthan
Sent: Wednesday, April 15, 2015 7:16 AM
To: C, Yuling; 'syedbahm@...'; 'saichler@...'; Anumala, Mohnish; Panemangalore, Sachin; Sethuraman, Hariharan
Cc: Jagannathan, Madhavan; Rajesh, N; 'jmedved@...'; Manivasagam, Mahesh
Subject: RE: latest local dump with data collection integration
 
 
Hi Yuling,
When issuing “tsdr:list  InterfaceMetrics ‘04/15/2015 15:00:00’ ‘04/15/2015 16:00:00’ command remotely got the error as “Error executing the command tsdr:list too many arguments specified”.
 
Its blocking my issue integration test automation execution. Can you pls me look in to this.
 
How to connect Karaf remotely:
Step 1:  ssh-keygen -t dsa -f karaf.id_dsa -N karaf
Step 2:  sshpass  -p karaf ssh  -p 8101 karaf.id_dsa.pub karaf@<ControllerIPaddress>  <karaf-command>
 
Error Screenshot:
 
Thanks
Vasanthan
 
 
 
 

_______________________________________________
release mailing list
release@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opendaylight.org_mailman_listinfo_release&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=iQmaE4AATOjmQiM_M1Z8q1zB-f9ZhGYGWUg8WJuO0is&s=jzLHEUXcbn_qh9v4hvVR4T_xa8M9C4BKf3ZjzD72nTw&e=




--
-- 
 =====================================
| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |
 =====================================
Re: [yangtools-dev] Anyxml in yang model

Tony Tkacik -X (ttkacik - Pantheon Technologies SRO@Cisco) <ttkacik@...>
 

Hi, still trying to figure out other possibilites for you how to model cost-maps and do not loose exact type information.

 

Tony

 

From: wangxin [mailto:xinwang2014@...]
Sent: Tuesday, April 14, 2015 2:21 PM
To: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); yangtools-dev@...
Cc: alto-dev@...
Subject: Re: [yangtools-dev] Anyxml in yang model

 

Thanks for your information about DOM APIs, and i am looking into it. If we decide to use it, we need to change a lot of things like data broker, transaction and data change listener. Is this right? And actually there is only one data in alto yang model using anyxml, which is cost in cost-map.

 

Thanks again,

Xin

 

发自 Windows 邮件

 

发件人: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
发送时间: ‎2015‎年‎4‎月‎14‎日, ‎星期二 ‎16‎:‎02
收件人: xin wang, rovarga@..., yangtools-dev@...
抄送: alto-dev@...

 

Hi,

We do not support anyxml in currently generated DTOs, but DOM data and DOM broker support it using different

APIs (called DOM APIs).

 

Which type of data from alto specification do you want to model as anyxml?

 

 

Tony

 

From: yangtools-dev-bounces@... [mailto:yangtools-dev-bounces@...] On Behalf Of wangxin
Sent: Monday, April 13, 2015 6:37 PM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); yangtools-dev@...
Cc: alto-dev@...
Subject: [yangtools-dev] Anyxml in yang model

 

Dear Varga and others in yangtools,

 

I am working at implementing alto in odl and i use anyxml to define some data in yang model considering the data could be an object, array, string, etc. But i find that there is no method to set its value in the class generated by using yang tools, also there is no field of the data in the class. There is no error when generating the code. It looks like it just skips the anyxml defined data. Did i miss something to make it work? Or it doesn’t support anyxml for now?

 

Thanks,

Xin

 

发自 Windows 邮件

 
Some questions about deleting data by alto-manager

xinwang
 

Hi Richard,

I didn’t understand if alto-manager deletes alto-hosttracker-generated data (i think delete is only action it can do), how alto-hosttracker reacts?

  1. it stops listening to l2switch and waits for alto-manager’s next command (like restart)?
  2. it continues listening to l2switch and just adds new data to data store? (it’s like option 1’s restart, but it keeps history data about existing hosts)
  3. some other choices?

Thanks,
Xin

发自 Windows 邮件
Re: Agenda for next meeting

Gao Kai <gaok12@...>
 

I have submitted another review that merges the work of Li into the latest master branch.

https://git.opendaylight.org/gerrit/#/c/18335/

On 15/04/15 18:45, Y. Richard Yang wrote:

Wonderful progress, Kai & Xin! Could you please approve the alto patches?

Thanks!

Richard 

On Wednesday, April 15, 2015, Xin Li <yakumolx@...> wrote:
I have cleaned up the build enviroment, you can review it at https://git.opendaylight.org/gerrit/18320

On Wed, Apr 15, 2015 at 3:57 PM, Gao Kai <godrickk@...> wrote:
I have passed the integration test and submitted a review.

https://git.opendaylight.org/gerrit/18309 for alto
https://git.opendaylight.org/gerrit/18310 for integration

On 15/04/15 14:31, Y. Richard Yang wrote:
Dear team,

Some of us (Kai and Xin L.) made some good progress this evening to clean up the build environment. If Xin L. can finish the remaining items, we can focus on the design issues during the meeting. But Xin L. please still be prepared to still give an overview so that our whole team ramps up on the basics.

Here are some key design issues and the lead (please read and be prepared to lead):

1. ALTO (provision) manager design (Shu and Kai: please lead the design review). Please give us the complete CI spec (since it runs in karaf, consistent with karaf ci style makes senses to me), if possible, and then the implementation structure. If you can write up a bit in the user guide, it will be so cool (goto https://wiki.opendaylight.org/view/ALTO:Main and you will see the link to user guide, and this should be under admin). The current version is my placeholder. Please feel free to modify.

2. Auto map (need a better name). Xin W. please lead.

3. Northbound (Kai please lead).

4. IRD generation (Kai please lead).

We will progress according to the proceeding, but limit the meeting to 1.5 hours max. Hence we may not be able to cover all items.

Richard


On Tuesday, April 14, 2015, Y. Richard Yang <yry@...> wrote:
Dear team,

Given that we are in the RED state regarding meeting ODL deadlines, we should first focus on getting the basic things ready, i.e., the build environment clean and setup. Hence, my plan is that we spend as much time--please be prepared for a long meeting--to go over the build environment (i.e., pom.xml files), until we get the basic build structure right. In other words, it will not be a discussion meeting, but rather a working session, to set our standard right.

Talk to you Wednesday (9 am US ET, 9 pm Beijing).

Richard



--
Richard


_______________________________________________
alto-dev mailing list
alto-dev@...
https://lists.opendaylight.org/mailman/listinfo/alto-dev




--
Richard
Re: [release] M3 Integration status for projects

Y. Richard Yang
 

Dear Luis,

Thanks for doing the check. We updated ALTO and integration:

Could you please take a look again at ALTO and let us know if you see any issues? If there are still remaining issues, any advice on how to fix  is greatly appreciated.

Thanks a lot!

Richard


On Monday, April 13, 2015, Luis Gomez <ecelgp@...> wrote:
Hi all,

We are not yet done with M4 but I spent some time today to collect M3 integration information and status for all projects. Basically I was looking for features in integration + feature templates (FT). 

This is the summary:

GREEN - Features + FT OK:
 
BGP LS PCEP:Main - features + FT
Group Policy:Main - features + FT
LACP:Main - features + FT
NeutronNorthbound:Main - features + FT
OpenDaylight Controller:Main - features + FT
OpenDaylight Lisp Flow Mapping:Main - features + FT
OpenDaylight Virtual Tenant Network (VTN):Main - features + FT
OVSDB Integration:Main - features + FT
Service Function Chaining:Main  - features + FT
TCPMD5:Main - features + FT
USC:Main - features + FT
VPNService:Main - features + FT
 
YELLOW - Missing Features or FT:
 
AAA:Main - features + No FT
CAPWAP:Main - features + No FT
DIDM:Main - features + No FT
IoTDM:Main - features + No FT
L2 Switch:Main - features + No FT
OpenDaylight dlux:Main - features + No FT
OpenDaylight OpenFlow Plugin:Main - features + No FT
Persistence:Main - No features + FT
SecureNetworkBootstrapping:Main - features + No FT
SNMP Plugin:Main - features + No FT
SNMP4SDN:Main - features + No FT
SXP:Main - features + No FT
TSDR:Main - No features + FT
 
RED - No features + No FT:
 
ALTO:Main - No features + No FT
Defense4All:Main - No features + No FT
Discovery:Main - No features + No FT
Southbound plugin to the OpenContrail platform:Main - No features + No FT
 
NA - No user-facing features:
 
ODL-SDNi App:Main
Defense4All:Main
Openflow Protocol Library:Main
OpFlex:Main
PacketCablePCMM:Main
Reservation:Main 
Table Type Patterns
Topology Processing Framework:Main
YANG Tools:Main

Please let me know if I missed anything.

BR/Luis



--
Richard
Re: Agenda for next meeting

Y. Richard Yang
 

Wonderful progress, Kai & Xin! Could you please approve the alto patches?

Thanks!

Richard 

On Wednesday, April 15, 2015, Xin Li <yakumolx@...> wrote:
I have cleaned up the build enviroment, you can review it at https://git.opendaylight.org/gerrit/18320

On Wed, Apr 15, 2015 at 3:57 PM, Gao Kai <godrickk@...> wrote:
I have passed the integration test and submitted a review.

https://git.opendaylight.org/gerrit/18309 for alto
https://git.opendaylight.org/gerrit/18310 for integration

On 15/04/15 14:31, Y. Richard Yang wrote:
Dear team,

Some of us (Kai and Xin L.) made some good progress this evening to clean up the build environment. If Xin L. can finish the remaining items, we can focus on the design issues during the meeting. But Xin L. please still be prepared to still give an overview so that our whole team ramps up on the basics.

Here are some key design issues and the lead (please read and be prepared to lead):

1. ALTO (provision) manager design (Shu and Kai: please lead the design review). Please give us the complete CI spec (since it runs in karaf, consistent with karaf ci style makes senses to me), if possible, and then the implementation structure. If you can write up a bit in the user guide, it will be so cool (goto https://wiki.opendaylight.org/view/ALTO:Main and you will see the link to user guide, and this should be under admin). The current version is my placeholder. Please feel free to modify.

2. Auto map (need a better name). Xin W. please lead.

3. Northbound (Kai please lead).

4. IRD generation (Kai please lead).

We will progress according to the proceeding, but limit the meeting to 1.5 hours max. Hence we may not be able to cover all items.

Richard


On Tuesday, April 14, 2015, Y. Richard Yang <yry@...> wrote:
Dear team,

Given that we are in the RED state regarding meeting ODL deadlines, we should first focus on getting the basic things ready, i.e., the build environment clean and setup. Hence, my plan is that we spend as much time--please be prepared for a long meeting--to go over the build environment (i.e., pom.xml files), until we get the basic build structure right. In other words, it will not be a discussion meeting, but rather a working session, to set our standard right.

Talk to you Wednesday (9 am US ET, 9 pm Beijing).

Richard



--
Richard


_______________________________________________
alto-dev mailing list
alto-dev@...
https://lists.opendaylight.org/mailman/listinfo/alto-dev




--
Richard
Re: Agenda for next meeting

Xin Li <yakumolx@...>
 

I have cleaned up the build enviroment, you can review it at https://git.opendaylight.org/gerrit/18320

On Wed, Apr 15, 2015 at 3:57 PM, Gao Kai <godrickk@...> wrote:
I have passed the integration test and submitted a review.

https://git.opendaylight.org/gerrit/18309 for alto
https://git.opendaylight.org/gerrit/18310 for integration

On 15/04/15 14:31, Y. Richard Yang wrote:
Dear team,

Some of us (Kai and Xin L.) made some good progress this evening to clean up the build environment. If Xin L. can finish the remaining items, we can focus on the design issues during the meeting. But Xin L. please still be prepared to still give an overview so that our whole team ramps up on the basics.

Here are some key design issues and the lead (please read and be prepared to lead):

1. ALTO (provision) manager design (Shu and Kai: please lead the design review). Please give us the complete CI spec (since it runs in karaf, consistent with karaf ci style makes senses to me), if possible, and then the implementation structure. If you can write up a bit in the user guide, it will be so cool (goto https://wiki.opendaylight.org/view/ALTO:Main and you will see the link to user guide, and this should be under admin). The current version is my placeholder. Please feel free to modify.

2. Auto map (need a better name). Xin W. please lead.

3. Northbound (Kai please lead).

4. IRD generation (Kai please lead).

We will progress according to the proceeding, but limit the meeting to 1.5 hours max. Hence we may not be able to cover all items.

Richard


On Tuesday, April 14, 2015, Y. Richard Yang <yry@...> wrote:
Dear team,

Given that we are in the RED state regarding meeting ODL deadlines, we should first focus on getting the basic things ready, i.e., the build environment clean and setup. Hence, my plan is that we spend as much time--please be prepared for a long meeting--to go over the build environment (i.e., pom.xml files), until we get the basic build structure right. In other words, it will not be a discussion meeting, but rather a working session, to set our standard right.

Talk to you Wednesday (9 am US ET, 9 pm Beijing).

Richard



--
Richard


_______________________________________________
alto-dev mailing list
alto-dev@...
https://lists.opendaylight.org/mailman/listinfo/alto-dev


Re: Agenda for next meeting

Gao Kai
 

I have passed the integration test and submitted a review.

https://git.opendaylight.org/gerrit/18309 for alto
https://git.opendaylight.org/gerrit/18310 for integration

On 15/04/15 14:31, Y. Richard Yang wrote:

Dear team,

Some of us (Kai and Xin L.) made some good progress this evening to clean up the build environment. If Xin L. can finish the remaining items, we can focus on the design issues during the meeting. But Xin L. please still be prepared to still give an overview so that our whole team ramps up on the basics.

Here are some key design issues and the lead (please read and be prepared to lead):

1. ALTO (provision) manager design (Shu and Kai: please lead the design review). Please give us the complete CI spec (since it runs in karaf, consistent with karaf ci style makes senses to me), if possible, and then the implementation structure. If you can write up a bit in the user guide, it will be so cool (goto https://wiki.opendaylight.org/view/ALTO:Main and you will see the link to user guide, and this should be under admin). The current version is my placeholder. Please feel free to modify.

2. Auto map (need a better name). Xin W. please lead.

3. Northbound (Kai please lead).

4. IRD generation (Kai please lead).

We will progress according to the proceeding, but limit the meeting to 1.5 hours max. Hence we may not be able to cover all items.

Richard


On Tuesday, April 14, 2015, Y. Richard Yang <yry@...> wrote:
Dear team,

Given that we are in the RED state regarding meeting ODL deadlines, we should first focus on getting the basic things ready, i.e., the build environment clean and setup. Hence, my plan is that we spend as much time--please be prepared for a long meeting--to go over the build environment (i.e., pom.xml files), until we get the basic build structure right. In other words, it will not be a discussion meeting, but rather a working session, to set our standard right.

Talk to you Wednesday (9 am US ET, 9 pm Beijing).

Richard



--
Richard


_______________________________________________
alto-dev mailing list
alto-dev@...
https://lists.opendaylight.org/mailman/listinfo/alto-dev

Re: Agenda for next meeting

Y. Richard Yang
 

Dear team,

Some of us (Kai and Xin L.) made some good progress this evening to clean up the build environment. If Xin L. can finish the remaining items, we can focus on the design issues during the meeting. But Xin L. please still be prepared to still give an overview so that our whole team ramps up on the basics.

Here are some key design issues and the lead (please read and be prepared to lead):

1. ALTO (provision) manager design (Shu and Kai: please lead the design review). Please give us the complete CI spec (since it runs in karaf, consistent with karaf ci style makes senses to me), if possible, and then the implementation structure. If you can write up a bit in the user guide, it will be so cool (goto https://wiki.opendaylight.org/view/ALTO:Main and you will see the link to user guide, and this should be under admin). The current version is my placeholder. Please feel free to modify.

2. Auto map (need a better name). Xin W. please lead.

3. Northbound (Kai please lead).

4. IRD generation (Kai please lead).

We will progress according to the proceeding, but limit the meeting to 1.5 hours max. Hence we may not be able to cover all items.

Richard


On Tuesday, April 14, 2015, Y. Richard Yang <yry@...> wrote:
Dear team,

Given that we are in the RED state regarding meeting ODL deadlines, we should first focus on getting the basic things ready, i.e., the build environment clean and setup. Hence, my plan is that we spend as much time--please be prepared for a long meeting--to go over the build environment (i.e., pom.xml files), until we get the basic build structure right. In other words, it will not be a discussion meeting, but rather a working session, to set our standard right.

Talk to you Wednesday (9 am US ET, 9 pm Beijing).

Richard



--
Richard
[release] M5 status template - Reminder : offset 0 projects M5 status due on 4/16 Thursday

Y. Richard Yang
 

Just in case not everyone subscribed to release...

---------- Forwarded message ----------
From: George Zhao <George.Y.Zhao@...>
Date: Monday, April 13, 2015
Subject: [release] M5 status template - Reminder : offset 0 projects M5 status due on 4/16 Thursday
To: release <release@...>


1, Code Freeze has been met (i.e. only bug fixes is allowed from now on)  Yes/No

2, Stability branch (stable/lithium) is cut and local project versions bumped on master complete.  Yes/No

 

a)     Please provide gerrit patch URL for version bump.

3, String Freeze (all externally visible strings frozen to allow for translation & documentation)  Yes/No

4, Documentation complete. (Only editing and enhancing should take place after this point) Yes/No

 

a)     Please provide github location URL for documentations.

5, Integration & System test

 

a)     Each user-facing feature system test complete Yes/No

 

b)    Test run on code merge, upstream project code merge, release weekly Yes/No  (Please provide a merge job link)

 




--
Richard
501 - 520 of 542