Date   

Re: [controller-dev] [OpenDaylight Discuss] Next vHackfest

David Meyer <dmm@...>
 

On Thu, Oct 10, 2013 at 5:27 PM, Colin Dixon <ckd@...> wrote:
For the vHackfest, I'd like to propose a topic around how we can test and
migrate to the MD-SAL without breaking the current code.

The naive approach of a single mega-update that introduces the MD-SAL, any
relevant adaptor bundles, and any other changes that need to be made to the
bundles above/below the SAL seems untenable. Based on some of the commits
I've been seeing, I'm not sure that the plan is to go the route of full
backward compatibility via adaptor bundles either.

I think a lot of us would be interested in discussing and better
understanding how we're going to move forward here given the far-reaching
ramifications of this shift.
Excellent topic. I'll put it on the TSC agenda for next week. We
should take it up on the TWS call as well.

--dmm


--Colin

discuss-bounces@... wrote on 10/03/2013 12:17:33 PM:
From: "Ed Warnicke (eaw)" <eaw@...>
Date: 10/03/2013 01:01 PM
Subject: Re: [OpenDaylight Discuss] Next vHackfest
Sent by: discuss-bounces@...

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

Guys,
What would you find useful for the next vHackfest in terms of themes
and
dates/times? Keep in mind API freeze is Oct 14.

Possibilities that occur to me would be:

1) Modeling and MD-SAL integration
2) Cross project collaboration
3) Plugging into the OpenStack Neutron Service

What do you guys think? If we wanted to do this before Oct 14,
next Thursday might be a
good day.

Also, what worked and didn't work last time, how could we do it
better this time?

Ed
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

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


Re: [OpenDaylight Discuss] Next vHackfest

Colin Dixon <ckd@...>
 

For the vHackfest, I'd like to propose a topic around how we can test and migrate to the MD-SAL without breaking the current code.

The naive approach of a single mega-update that introduces the MD-SAL, any relevant adaptor bundles, and any other changes that need to be made to the bundles above/below the SAL seems untenable. Based on some of the commits I've been seeing, I'm not sure that the plan is to go the route of full backward compatibility via adaptor bundles either.

I think a lot of us would be interested in discussing and better understanding how we're going to move forward here given the far-reaching ramifications of this shift.

--Colin

discuss-bounces@... wrote on 10/03/2013 12:17:33 PM:
> From: "Ed Warnicke (eaw)" <eaw@...>

> Date: 10/03/2013 01:01 PM
> Subject: Re: [OpenDaylight Discuss] Next vHackfest
> Sent by: discuss-bounces@...
>
> Looping in all the dev lists to the conversation.
>
> Ed
> On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
>  wrote:
>
> > Guys,
> >    What would you find useful for the next vHackfest in terms of themes and
> > dates/times?  Keep in mind API freeze is Oct 14.
> >
> >    Possibilities that occur to me would be:
> >
> > 1)  Modeling and MD-SAL integration
> > 2)  Cross project collaboration
> > 3)  Plugging into the OpenStack Neutron Service
> >
> > What do you guys think?  If we wanted to do this before Oct 14,
> next Thursday might be a
> > good day.
> >
> > Also, what worked and didn't work last time, how could we do it
> better this time?
> >
> > Ed
>
> _______________________________________________
> Discuss mailing list
> Discuss@...
> https://lists.opendaylight.org/mailman/listinfo/discuss
>


Re: [controller-dev] Next vHackFest - Scheduled

Srinivasa T N <seenutn@...>
 

I wanted to be part of Neutron Service, but me being in IST, 2 pm PDT is wee hours for me.. Can you guys take the trouble of recording it making it available?

Regards,
Seenu.


On Thu, Oct 10, 2013 at 10:23 PM, Ed Warnicke (eaw) <eaw@...> wrote:
OK… the next vHackfest, based on feedback, is scheduled for:


Oct 17, 2013 1am PST - 1pm PST (you are not expected to attend all 24 hours)

Topics include:

1)  Integration with the ODL Neutron Service
2)  Integration with the MD-SAL


Ed
On Oct 7, 2013, at 8:30 PM, Hideyuki Tai <h-tai@...> wrote:

Hi all,
 
For the OpenStack Neutron Service part, Sarath and I, from VTN project, will be fine between 2:00pm to 4:00pm PDT (6:00am – 8:00am JST).
 
I mean the following time slot:
Oct 17. 2:00pm – 4:00pm PDT
Oct 17. 4:00pm – 6:00pm US CDT
Oct 18. 6.00am – 8:00am JST
 
Thanks,
Hideyuki Tai
 
 
 
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ryan Moats
Sent: Tuesday, October 08, 2013 2:52 AM
To: Ed Warnicke (eaw)
Cc: discuss@...; openflowplugin-dev@...; tsc@...; ovsdb-dev@...; dlux-dev@...; bgpcep-dev@...; <affinity-dev@...>; <defense4all-dev@...>; opendove-dev@...; snmp4sdn@...; lispflowmapping-dev@...; openflowjava-dev@...; <controller-dev@...>; infrastructure@...; <controller-dev-bounces@...>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Next vHackfest
 

So long as the Neutron Service part is between 1:00pm to 5:00pm US CDT, I'm fine.  My morning of 10/17 is already booked up.

Ryan

<image001.gif>
"Ed Warnicke (eaw)" ---10/07/2013 12:32:22 PM---How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 1)  Model and MD

From: "Ed Warnicke (eaw)" <eaw@...>
To: Ryan Moats/Omaha/IBM@IBMUS, 
Cc: "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<controller-dev@...>" <controller-dev@...>, "<controller-dev-bounces@...>" <controller-dev-bounces@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "discuss@..." <discuss@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, "tsc@..." <tsc@...>
Date: 10/07/2013 12:32 PM
Subject: Re: [controller-dev] Next vHackfest





How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan


<graycol.gif>
"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: 
"Ed Warnicke (eaw)" <eaw@...>
To: 
"
discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, 
Cc: 
"
tsc@..." <tsc@...>
Date: 
10/03/2013 12:17 PM
Subject: 
Re: [controller-dev] Next vHackfest
Sent by: 
controller-dev-bounces@...




Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <
eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and 
> dates/times?  Keep in mind API freeze is Oct 14.
> 
> Possibilities that occur to me would be:
> 
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
> 
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a 
> good day.
> 
> Also, what worked and didn't work last time, how could we do it better this time?
> 
> Ed

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



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



Next vHackFest - Scheduled

Ed Warnicke (eaw) <eaw@...>
 

OK… the next vHackfest, based on feedback, is scheduled for:


Oct 17, 2013 1am PST - 1pm PST (you are not expected to attend all 24 hours)

Topics include:

1)  Integration with the ODL Neutron Service
2)  Integration with the MD-SAL


Ed
On Oct 7, 2013, at 8:30 PM, Hideyuki Tai <h-tai@...> wrote:

Hi all,
 
For the OpenStack Neutron Service part, Sarath and I, from VTN project, will be fine between 2:00pm to 4:00pm PDT (6:00am – 8:00am JST).
 
I mean the following time slot:
Oct 17. 2:00pm – 4:00pm PDT
Oct 17. 4:00pm – 6:00pm US CDT
Oct 18. 6.00am – 8:00am JST
 
Thanks,
Hideyuki Tai
 
 
 
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ryan Moats
Sent: Tuesday, October 08, 2013 2:52 AM
To: Ed Warnicke (eaw)
Cc: discuss@...; openflowplugin-dev@...; tsc@...; ovsdb-dev@...; dlux-dev@...; bgpcep-dev@...; <affinity-dev@...>; <defense4all-dev@...>; opendove-dev@...; snmp4sdn@...; lispflowmapping-dev@...; openflowjava-dev@...; <controller-dev@...>; infrastructure@...; <controller-dev-bounces@...>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Next vHackfest
 

So long as the Neutron Service part is between 1:00pm to 5:00pm US CDT, I'm fine.  My morning of 10/17 is already booked up.

Ryan

<image001.gif>
"Ed Warnicke (eaw)" ---10/07/2013 12:32:22 PM---How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 1)  Model and MD

From: "Ed Warnicke (eaw)" <eaw@...>
To: Ryan Moats/Omaha/IBM@IBMUS, 
Cc: "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<controller-dev@...>" <controller-dev@...>, "<controller-dev-bounces@...>" <controller-dev-bounces@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "discuss@..." <discuss@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, "tsc@..." <tsc@...>
Date: 10/07/2013 12:32 PM
Subject: Re: [controller-dev] Next vHackfest





How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan


<graycol.gif>
"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: 
"Ed Warnicke (eaw)" <eaw@...>
To: 
"
discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, 
Cc: 
"
tsc@..." <tsc@...>
Date: 
10/03/2013 12:17 PM
Subject: 
Re: [controller-dev] Next vHackfest
Sent by: 
controller-dev-bounces@...




Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <
eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and 
> dates/times?  Keep in mind API freeze is Oct 14.
> 
> Possibilities that occur to me would be:
> 
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
> 
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a 
> good day.
> 
> Also, what worked and didn't work last time, how could we do it better this time?
> 
> Ed

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



Re: [OpenDaylight Discuss] [controller-dev] Next vHackfest

Hideyuki Tai <h-tai@...>
 

Hi all,

 

For the OpenStack Neutron Service part, Sarath and I, from VTN project, will be fine between 2:00pm to 4:00pm PDT (6:00am – 8:00am JST).

 

I mean the following time slot:

Oct 17. 2:00pm – 4:00pm PDT

Oct 17. 4:00pm – 6:00pm US CDT

Oct 18. 6.00am – 8:00am JST

 

Thanks,

Hideyuki Tai

 

 

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ryan Moats
Sent: Tuesday, October 08, 2013 2:52 AM
To: Ed Warnicke (eaw)
Cc: discuss@...; openflowplugin-dev@...; tsc@...; ovsdb-dev@...; dlux-dev@...; bgpcep-dev@...; <affinity-dev@...>; <defense4all-dev@...>; opendove-dev@...; snmp4sdn@...; lispflowmapping-dev@...; openflowjava-dev@...; <controller-dev@...>; infrastructure@...; <controller-dev-bounces@...>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Next vHackfest

 

So long as the Neutron Service part is between 1:00pm to 5:00pm US CDT, I'm fine.  My morning of 10/17 is already booked up.

Ryan

"Ed Warnicke (eaw)" ---10/07/2013 12:32:22 PM---How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 1)  Model and MD

From: "Ed Warnicke (eaw)" <eaw@...>
To: Ryan Moats/Omaha/IBM@IBMUS,
Cc: "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<controller-dev@...>" <controller-dev@...>, "<controller-dev-bounces@...>" <controller-dev-bounces@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "discuss@..." <discuss@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, "tsc@..." <tsc@...>
Date: 10/07/2013 12:32 PM
Subject: Re: [controller-dev] Next vHackfest





How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally:

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:


I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan


<graycol.gif>
"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From:
"Ed Warnicke (eaw)" <eaw@...>
To:
"
discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc:
"
tsc@..." <tsc@...>
Date:
10/03/2013 12:17 PM
Subject:
Re: [controller-dev] Next vHackfest
Sent by:
controller-dev-bounces@...





Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <
eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

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

 


Re: [OpenDaylight TSC] [controller-dev] Next vHackfest

Vina Ermagan (vermagan) <vermagan@...>
 

Oct 17 is also fine. What is the time slot? If possible, morning time is best, so we can have people from Europe participate as well.

Thanks,
Vina


How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally:

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

<graycol.gif>"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...





Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

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




Re: [controller-dev] Next vHackfest

Ryan Moats <rmoats@...>
 

So long as the Neutron Service part is between 1:00pm to 5:00pm US CDT, I'm fine.  My morning of 10/17 is already booked up.

Ryan

"Ed Warnicke (eaw)" ---10/07/2013 12:32:22 PM---How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 1)  Model and MD

From: "Ed Warnicke (eaw)" <eaw@...>
To: Ryan Moats/Omaha/IBM@IBMUS,
Cc: "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<controller-dev@...>" <controller-dev@...>, "<controller-dev-bounces@...>" <controller-dev-bounces@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "discuss@..." <discuss@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, "tsc@..." <tsc@...>
Date: 10/07/2013 12:32 PM
Subject: Re: [controller-dev] Next vHackfest





How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally:

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:


Re: [controller-dev] Next vHackfest

Ed Warnicke (eaw) <eaw@...>
 

How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally:

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

<graycol.gif>"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...





Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

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




Re: [controller-dev] Next vHackfest

Ryan Moats <rmoats@...>
 

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...





Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

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



Re: [controller-dev] [OpenDaylight Discuss] Next vHackfest

Prasanna Huddar <prasanna.huddar@...>
 

+1 for MD-SAL integration both with reference to NSF and plugin.
-Prasanna

-----Original Message-----
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Anees A Shaikh
Sent: Monday, October 07, 2013 11:24 AM
To: Ed Warnicke (eaw)
Cc: discuss@...; openflowplugin-dev@...; tsc@...; ovsdb-dev@...; dlux-dev@...; infrastructure@...; <affinity-dev@...>; discuss-bounces@...; <defense4all-dev@...>; opendove-dev@...; snmp4sdn@...; lispflowmapping-dev@...; openflowjava-dev@...; <controller-dev@...>; bgpcep-dev@...
Subject: Re: [controller-dev] [OpenDaylight Discuss] Next vHackfest

(next Thursday/Friday 10/10-11 are also the ONF workdays)

+1 for the MD-SAL integration topic, including backward compatibility of
current AD-SAL apps/bundles.

thanks.

-- Anees

discuss-bounces@... wrote on 10/03/2013 01:17:33 PM:

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..."
<discuss@...>, "<controller-
dev@...>" <controller-
dev@...>, "<affinity-dev@...>"
<affinity-dev@...>, "bgpcep-
dev@..." <bgpcep-dev@...>,
"<defense4all-dev@...>" <defense4all-
dev@...>, "dlux-dev@..."
<dlux-dev@...>,
"infrastructure@..."
<infrastructure@...>, "lispflowmapping-
dev@..." <lispflowmapping-
dev@...>, "opendove-dev@..."
<opendove-dev@...>, "openflowplugin-
dev@..." <openflowplugin-
dev@...>, "openflowjava-
dev@..." <openflowjava-
dev@...>, "ovsdb-dev@..."
<ovsdb-dev@...>,
"snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 02:01 PM
Subject: Re: [OpenDaylight Discuss] Next vHackfest
Sent by: discuss-bounces@...

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

Guys,
What would you find useful for the next vHackfest in terms of
themes and
dates/times? Keep in mind API freeze is Oct 14.

Possibilities that occur to me would be:

1) Modeling and MD-SAL integration
2) Cross project collaboration
3) Plugging into the OpenStack Neutron Service

What do you guys think? If we wanted to do this before Oct 14,
next Thursday might be a
good day.

Also, what worked and didn't work last time, how could we do it
better this time?

Ed
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [OpenDaylight Discuss] Next vHackfest

Anees A Shaikh <aashaikh@...>
 

(next Thursday/Friday 10/10-11 are also the ONF workdays)

+1 for the MD-SAL integration topic, including backward compatibility of
current AD-SAL apps/bundles.

thanks.

-- Anees

discuss-bounces@... wrote on 10/03/2013 01:17:33 PM:

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..."
<discuss@...>, "<controller-
dev@...>" <controller-
dev@...>, "<affinity-dev@...>"
<affinity-dev@...>, "bgpcep-
dev@..." <bgpcep-dev@...>,
"<defense4all-dev@...>" <defense4all-
dev@...>, "dlux-dev@..."
<dlux-dev@...>,
"infrastructure@..."
<infrastructure@...>, "lispflowmapping-
dev@..." <lispflowmapping-
dev@...>, "opendove-dev@..."
<opendove-dev@...>, "openflowplugin-
dev@..." <openflowplugin-
dev@...>, "openflowjava-
dev@..." <openflowjava-
dev@...>, "ovsdb-dev@..."
<ovsdb-dev@...>,
"snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 02:01 PM
Subject: Re: [OpenDaylight Discuss] Next vHackfest
Sent by: discuss-bounces@...

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

Guys,
What would you find useful for the next vHackfest in terms of
themes and
dates/times? Keep in mind API freeze is Oct 14.

Possibilities that occur to me would be:

1) Modeling and MD-SAL integration
2) Cross project collaboration
3) Plugging into the OpenStack Neutron Service

What do you guys think? If we wanted to do this before Oct 14,
next Thursday might be a
good day.

Also, what worked and didn't work last time, how could we do it
better this time?

Ed
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Re: Next vHackfest

Ed Warnicke (eaw) <eaw@...>
 

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

Guys,
What would you find useful for the next vHackfest in terms of themes and
dates/times? Keep in mind API freeze is Oct 14.

Possibilities that occur to me would be:

1) Modeling and MD-SAL integration
2) Cross project collaboration
3) Plugging into the OpenStack Neutron Service

What do you guys think? If we wanted to do this before Oct 14, next Thursday might be a
good day.

Also, what worked and didn't work last time, how could we do it better this time?

Ed


Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

Ed Warnicke (eaw) <eaw@...>
 

Huang,
We have some tunnel models coming out of bgpcep… hopefully we can get folks to 
converge on a general tunnel model.


Ed
On Oct 1, 2013, at 9:46 PM, huang denghui <huangdenghui@...> wrote:

Hi Evan
     Great,then,Will it be in place in the ODL first release?

在 2013 10 2 10:15,"Evan Zeller" <evanrzeller@...>写道:
Huang,

No we don't implement any sort of tunnel manager. Once the full capabilities of ovsdb are in place we will provide the ability to create and discover tunnels in a remote open vswitch database.

Evan


On Tue, Oct 1, 2013 at 8:46 PM, huang denghui <huangdenghui@...> wrote:

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57,"Colin Dixon" <ckd@...>写道:

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>

> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>

> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

> Sent by: controller-dev-bounces@...
>
> Hi

>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.

>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others

> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.

>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 

> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.

>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others

> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

> I second this viewpoint as well.
>
> Thanks,

> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>

>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  

>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?

>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.

>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.

>
> My .02c

>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...

> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.

> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */

>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?

> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.

> But, we have to make sure the functionality is not redundant with
> something that exists already.

> So, please share all the functionalities that this module addresses.
>
> Thanks,

> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

>
> Hi

>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?

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

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


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


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


Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

denghui huang
 

Hi Evan
     Great,then,Will it be in place in the ODL first release?

在 2013 10 2 10:15,"Evan Zeller" <evanrzeller@...>写道:

Huang,

No we don't implement any sort of tunnel manager. Once the full capabilities of ovsdb are in place we will provide the ability to create and discover tunnels in a remote open vswitch database.

Evan


On Tue, Oct 1, 2013 at 8:46 PM, huang denghui <huangdenghui@...> wrote:

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57,"Colin Dixon" <ckd@...>写道:

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>

> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>

> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

> Sent by: controller-dev-bounces@...
>
> Hi

>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.

>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others

> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.

>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 

> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.

>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others

> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

> I second this viewpoint as well.
>
> Thanks,

> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>

>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  

>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?

>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.

>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.

>
> My .02c

>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...

> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.

> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */

>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?

> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.

> But, we have to make sure the functionality is not redundant with
> something that exists already.

> So, please share all the functionalities that this module addresses.
>
> Thanks,

> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

>
> Hi

>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?

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

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


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



Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

Evan Zeller <evanrzeller@...>
 

Huang,

No we don't implement any sort of tunnel manager. Once the full capabilities of ovsdb are in place we will provide the ability to create and discover tunnels in a remote open vswitch database.

Evan


On Tue, Oct 1, 2013 at 8:46 PM, huang denghui <huangdenghui@...> wrote:

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57,"Colin Dixon" <ckd@...>写道:

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>

> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>

> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

> Sent by: controller-dev-bounces@...
>
> Hi

>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.

>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others

> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.

>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 

> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.

>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others

> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

> I second this viewpoint as well.
>
> Thanks,

> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>

>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  

>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?

>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.

>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.

>
> My .02c

>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...

> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.

> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */

>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?

> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.

> But, we have to make sure the functionality is not redundant with
> something that exists already.

> So, please share all the functionalities that this module addresses.
>
> Thanks,

> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

>
> Hi

>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?

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

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


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



[controller-dev] Porting net-virt-platform TunnelManager into ODL?

denghui huang
 

Hi folks,
      Forwarding this to the correct mail list.

---------- Forwarded message ----------
From: huang denghui <huangdenghui@...>
Date: 2013/10/2
Subject: Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?
To: Colin Dixon <ckd@...>
Cc: controller-dev-bounces@..., "Madhu Venugopal (vmadhu)" <vmadhu@...>, "controller-dev@..." <controller-dev@...>, ovsdb-dev@...


Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57,"Colin Dixon" <ckd@...>写道:

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>

> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>

> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

> Sent by: controller-dev-bounces@...
>
> Hi

>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.

>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others

> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.

>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 

> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.

>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others

> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

> I second this viewpoint as well.
>
> Thanks,

> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>

>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  

>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?

>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.

>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.

>
> My .02c

>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...

> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.

> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */

>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?

> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.

> But, we have to make sure the functionality is not redundant with
> something that exists already.

> So, please share all the functionalities that this module addresses.
>
> Thanks,

> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

>
> Hi

>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?

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

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



Re: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

denghui huang
 

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57,"Colin Dixon" <ckd@...>写道:

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>

> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>

> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

> Sent by: controller-dev-bounces@...
>
> Hi

>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.

>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others

> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.

>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 

> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 

> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities

> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.

>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others

> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.

> I second this viewpoint as well.
>
> Thanks,

> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>

>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  

>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?

>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.

>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.

>
> My .02c

>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?

>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...

> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.

> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */

>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?

> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.

> But, we have to make sure the functionality is not redundant with
> something that exists already.

> So, please share all the functionalities that this module addresses.
>
> Thanks,

> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?

>
> Hi

>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?

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

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


Re: Jenkins issue preventing integration

Evan Zeller <evanrzeller@...>
 

Taken care of, thanks Ed!

Evan


On Mon, Sep 30, 2013 at 10:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
        I am trying to put together the integration project's distribution directories for the various versions.
As part of that, I am finding a problem with integrating OVSDB into the virtualization edition.  The good news is its
 a simple problem :)

        I am pulling in:

    <dependency>
      <groupId>org.opendaylight.ovsdb</groupId>
      <artifactId>ovsdb</artifactId>
      <version>0.4.0-SNAPSHOT</version>
    </dependency>

and getting an error:

[ERROR] Failed to execute goal on project distributions-virtualization: Could not resolve dependencies for project org.opendaylight.integration:distributions-virtualization:pom:0.1.0-SNAPSHOT: Failed to collect dependencies for [org.opendaylight.integration:distributions-base:zip:osgipackage:0.1.0-SNAPSHOT (provided), org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT (compile)]: Failed to read artifact descriptor for org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT: Could not find artifact org.opendaylight.ovsdb:commons.ovsdb:pom:1.0.0-SNAPSHOT in jsonrpc4j-webdav-maven-repo (${nexus.proxy}/repositories/jsonrpc4j-webdav-maven-repo/) -> [Help 1]

Basically, what's happening is that your commons/parent/pom.xml is not being pushed to Nexus… but since the ovsdb maven… but its needed as a dependency.
If you guys could just make sure your Jenkin's jobs (both verify and merge) build from pom commons/parent/pom.xml so that everything gets pushed properly out
to Nexus that would clean this right out :)

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


Jenkins issue preventing integration

Ed Warnicke (eaw) <eaw@...>
 

Guys,
I am trying to put together the integration project's distribution directories for the various versions.
As part of that, I am finding a problem with integrating OVSDB into the virtualization edition. The good news is its
a simple problem :)

I am pulling in:

<dependency>
<groupId>org.opendaylight.ovsdb</groupId>
<artifactId>ovsdb</artifactId>
<version>0.4.0-SNAPSHOT</version>
</dependency>

and getting an error:

[ERROR] Failed to execute goal on project distributions-virtualization: Could not resolve dependencies for project org.opendaylight.integration:distributions-virtualization:pom:0.1.0-SNAPSHOT: Failed to collect dependencies for [org.opendaylight.integration:distributions-base:zip:osgipackage:0.1.0-SNAPSHOT (provided), org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT (compile)]: Failed to read artifact descriptor for org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT: Could not find artifact org.opendaylight.ovsdb:commons.ovsdb:pom:1.0.0-SNAPSHOT in jsonrpc4j-webdav-maven-repo (${nexus.proxy}/repositories/jsonrpc4j-webdav-maven-repo/) -> [Help 1]

Basically, what's happening is that your commons/parent/pom.xml is not being pushed to Nexus… but since the ovsdb maven… but its needed as a dependency.
If you guys could just make sure your Jenkin's jobs (both verify and merge) build from pom commons/parent/pom.xml so that everything gets pushed properly out
to Nexus that would clean this right out :)

Ed


hacking around

Zhipeng Huang <zhipengh512@...>
 



---------- Forwarded message ----------
From: Zhipeng Huang <zhipengh512@...>
Date: Thu, Sep 19, 2013 at 11:45 AM
Subject: Re: [ovsdb-dev] hacking around
To: "Madhu Venugopal (vmadhu)" <vmadhu@...>


hi madhu, 

thanks for the reply, I'm pretty new to this, i think i maybe could contribute to 4, could you provide more info on that subject? THX a lot


On Thu, Sep 19, 2013 at 11:41 AM, Madhu Venugopal (vmadhu) <vmadhu@...> wrote:
Hi,

The OVSDB infrastructure code is undergoing a major revamp.
  1. We are moving away from jsonrpc4j towards netty based custom 2-way JSON-RPC implementation.
  2. Moving away from String and custom message parsing towards Jackson Marshalling/Demarshalling to POJOs directly.
  3. Better Monitor / Update handling
  4. Protocol Library / Plugin separation.
Hacking with the current existing code will be rendered unusable soon.
So, I would suggest to hold off on that.

If you are interested in contributing to any of the above topics, please let me know.

Thanks,
Madhu

From: Zhipeng Huang <zhipengh512@...>
Date: Thursday, September 19, 2013 10:07 AM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] hacking around

Hi, I've successfully build ovsdb, is there a guide for hack around the code?

--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Office: Calit2 Building Room 2402



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Office: Calit2 Building Room 2402



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402