L2switch has been converted to blueprint [0],

so *-config artifacts are no longer defined.

Alto was depending on them.

Possible fix for the autorelease build: [1].

 

But even after that fix, the new value [2]

for is-proactive-flood-mode will NOT get applied.

Is there a way for downstream feature

to override the default value [3]?

 

Vratko.

 

[0] https://git.opendaylight.org/gerrit/40707

[1] https://git.opendaylight.org/gerrit/41285
[2] https://git.opendaylight.org/gerrit/gitweb?p=alto.git;a=blob;f=alto-extensions/simple-pce/network-tracker/config/src/main/config/default-config.xml;h=954c068ca890942e061de81fd6eb7ff4fcbcd69b;hb=refs/heads/master#l28

[3] https://git.opendaylight.org/gerrit/#/c/40707/3/arphandler/src/main/yang/arp-handler-config.yang@54

 

_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release

Hi , Jensen ..

I checked as per your idea. 

I did not get the ""flow-node-inventory:current-speed": 0," in my flow !. I simply launched ODL, installed openflowplugin ,mininet running .

Except this i am getting everything? May i know the reason?

Thanks,

-Karthik

plz check the data which i got ..

{
  "nodes": {
    "node": [
      {
        "id": "openflow:1",
        "node-connector": [
          {
            "id": "openflow:1:1",
            "opendaylight-port-statistics:flow-capable-node-connector-statistics": {
              "transmit-errors": 0,
              "collision-count": 0,
              "duration": {},
              "receive-drops": 0,
              "transmit-drops": 0,
              "packets": {
                "transmitted": 1022,
                "received": 1074
              },
              "receive-frame-error": 0,
              "receive-errors": 0,
              "receive-over-run-error": 0,
              "receive-crc-error": 0,
              "bytes": {
                "transmitted": 147250,
                "received": 156973
              }
            },
            "flow-node-inventory:current-feature": "copper ten-gb-fd",
            "flow-node-inventory:name": "s1-eth1",
            "flow-node-inventory:port-number": "1",
            "flow-node-inventory:supported": "",
            "flow-node-inventory:configuration": "",
            "flow-node-inventory:peer-features": "",
            "flow-node-inventory:state": {
              "link-down": false,
              "blocked": false,
              "live": false
            },
            "flow-node-inventory:advertised-features": "",
            "flow-node-inventory:hardware-address": "82:59:9A:B9:67:3D",
            "stp-status-aware-node-connector:status": "forwarding"
          }

---

---

From: Jensen Zhang <jingxuan.n.zhang@...>
Sent: Thursday, April 28, 2016 2:42:29 PM
To: Karthikeyan D (Product Engineering Service)
Cc: Junzhuo Wang; alto-dev@...; Kai GAO
Subject: Re: [alto-dev] How to check Network Speed at each link in DLUX ui?

 

** This mail has been sent from an external source **

Hi Karthik,

In current implementation, you can get rate of speed (both current speed and maximum speed) from opendaylight-inventory. After installing openflowplugin, you can send a GET request to the url http://localhost:8181/restconf/operational/opendaylight-inventory:nodes to get a JSON format response.

The JSON response is like this schema:

~~~ json

{

  "nodes": {

    "node": [

      {

        "id": "openflow:7",

        "node-connector": [

          {

            "id": "openflow:7:LOCAL",

            "flow-node-inventory:state": {

              "link-down": false,

              "blocked": false,

              "live": false

            },

            "flow-node-inventory:configuration": "",

            "flow-node-inventory:hardware-address": "6A:13:45:A1:4F:48",

            "flow-node-inventory:current-speed": 0,

            "flow-node-inventory:advertised-features": "",

            "flow-node-inventory:name": "n7",

            "flow-node-inventory:supported": "",

            "flow-node-inventory:current-feature": "",

            "flow-node-inventory:port-number": "LOCAL",

            "flow-node-inventory:maximum-speed": 0,

            "flow-node-inventory:peer-features": "",

...

~~~

I think it is enough for your requirement. I'm not familiar with DLUX, so I cannot give more suggestions. If you want to improve DLUX, you can contact DLUX team to talk about more details. I believe they will be happy for your contribution. :)

Best,

Jensen

On Thu, Apr 28, 2016 at 12:19 PM, <karthikeyan.d17@...> wrote:

Hi Team ,

 Myself karthik , working in ODL.I have a questions. Please help me!.

When I am giving iperf or ping between two hosts , I need to check the network speed (rate at which data is traveling) in each link.For example you could see the ONOS UI , It will show you the data speed in each link.

So I think In ODL DLUX-UI we dont have that kind of stuffs. I would like to develop that. I need your help. From where can i get the details of rate of speed? L2switch or OpenflowPlugin project or anything else? Give me some idea I will do it.

Thanks,

-Karthik

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

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

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

Jensen and Tony,

I think we should follow the guidance and make sure our committer list is clean.

Regards,
Kai

-------- Forwarded Message --------

Subject:	Re: [release] Committer List Cleanup
Date:	Thu, 21 Apr 2016 12:33:53 -0400
From:	Colin Dixon <colin@...>
To:	An Ho <An.Ho@...>
CC:	release (release@...) <release@...>

Thanks. I've added these policies here as well:
https://wiki.opendaylight.org/view/TSC:Main#Keeping_Clean_Committer_Lists

--Colin

On Thu, Apr 21, 2016 at 10:52 AM, An Ho <An.Ho@...> wrote:

In order to help maintain a cleaner committer list, we would like to kindly ask that projects routinely review and update their committer list approximately every 6 months.  As discussed and agreed upon by the TSC [1] [2], we would like projects to:

* Identify committers who have been inactive for more than 6 months
* Reach out to them to understand if they would like to step down or if there are compelling reasons they would like to stay a committer despite their inactivity.
* In the event of a non-response despite repeated attempts to contact the committer and/or the committer asks to step down from the role, have them removed as a committer and notify the TSC.
* Ensure that everyone knows the TSC is willing to arbitrate any disputes and note that this process is intended to ensure the committer list better reflects reality rather than anything political.

A more detailed description of the process can be found on the TSC Main Page [3].  Perhaps we can start tracking the progress of this cleanup, either as an M5 milestone item or on the Boron tracking sheet.

Best Regards,
An Ho

[1] https://meetings.opendaylight.org/opendaylight-meeting/2016/tsc/opendaylight-meeting-tsc.2016-04-07-17.00.html
[2] https://lists.opendaylight.org/pipermail/tsc/2016-April/005002.html
[3] https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process

In order to help maintain a cleaner committer list, we would like to kindly ask that projects routinely review and update their committer list approximately every 6 months.  As discussed and agreed upon by the TSC [1] [2], we would like projects to:

* Identify committers who have been inactive for more than 6 months
* Reach out to them to understand if they would like to step down or if there are compelling reasons they would like to stay a committer despite their inactivity.
* In the event of a non-response despite repeated attempts to contact the committer and/or the committer asks to step down from the role, have them removed as a committer and notify the TSC.
* Ensure that everyone knows the TSC is willing to arbitrate any disputes and note that this process is intended to ensure the committer list better reflects reality rather than anything political.

A more detailed description of the process can be found on the TSC Main Page [3].  Perhaps we can start tracking the progress of this cleanup, either as an M5 milestone item or on the Boron tracking sheet.

Best Regards,
An Ho

[1] https://meetings.opendaylight.org/opendaylight-meeting/2016/tsc/opendaylight-meeting-tsc.2016-04-07-17.00.html
[2] https://lists.opendaylight.org/pipermail/tsc/2016-April/005002.html
[3] https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process

Hello OpenDaylight Project Leads and developers;

We have historically held a hackfest for the OpenDaylight community around M4 of each release cycle so that projects can come together face to face to finish coding and begin testing.  This also is a great opportunity for interdependent projects to ensure that all needed functionality is working as expected and to jump-start the testing of all new features.

During last release, we held such a hackfest as usual, but the turnout was pretty low.  So now we're trying to figure out if there is enough interest for doing one during Boron, and if so, when is the best time for everyone.

So, please answer the following two questions and respond to me by next Thursday (4/21).  I'll collect the responses and report the results to the TSC and we'll make a decision on if and when to have a hackfest.

1) Do you want to participate in a hackfest?

2) If yes, when you would prefer (M3 is mid May, M4 is mid June as two likely candidates)?

Thanks for your prompt reply.  If we're going to get  venue for this hackfest we need to decided soon.

Thanks!

Phil.

--

Phil Robb

Sr. Director Of Technical Operations

OpenDaylight Project

(O) 970-229-5949

(M) 970-420-4292

Skype: Phil.Robb

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Hi Kai Gao, Jensen Zhang, and ALTO Team,

According to the Boron dependency log, your project has a dependency on OpenFlowPlugin [1].

In order to facilitate the migration for dependent projects to the OpenFlowPlugin Lithium design as the default for the Boron release, we would like dependant projects to identify issues, feedback, objections, and bugs by 4/7 with a target migration at Boron Offset 1 M2/M3 [2].

Would it be possible for you to kindly vote "GO" or "NOGO" and identify any bugs/issues pending at this spreadsheet [3].

Your feedback is greatly appreciated.  Please do not hesitate to reach out to Abhijit Kumbhare and the OpenFlowPlugin team if you have any further questions regarding the timeline for the migration.

Best Regards,
An Ho

[1] https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-project-report-boron/lastSuccessfulBuild/artifact/dependencies.log
[2] https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-April/004883.html
[3] https://docs.google.com/spreadsheets/d/1zImtd764e-hOgJAxoJKl85fxHCPu2agLfqsBtf13zQY/edit#gid=251530127