Date   

ALTO and OpenFlowPlugin Li Migration

an.ho@huawei.com
 

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


Re: [release] [integration-dev] [netide-dev] BindException in release bits.

Gao Kai <gaok12@...>
 

Jensen, Xiao and all,

We need to check if we have put the right port information on the following wiki pages.

Xiao,

Can you please check if we are still using port 8181? Thanks!

Regards,
Kai


-------- Forwarded Message --------
Subject: Re: [release] [integration-dev] [netide-dev] BindException in release bits.
Date: Fri, 25 Mar 2016 22:08:27 +0000
From: An Ho <An.Ho@...>
To: Abhijit Kumbhare <abhijitkoss@...>, Daniel Farrell <dfarrell@...>
CC: jgoodyear@... <jgoodyear@...>, vpnservice-dev@... <vpnservice-dev@...>, integration-dev@... <integration-dev@...>, Release <release@...>, netide-dev@... <netide-dev@...>


At the moment, we ask projects to report their ports on the wiki [1], the test plan [2], and the milestone readout [3].  We could also add it to the Per-Project Release Plan.  However, as we scale on the growing number of projects, I wish we had some automatic mechanism to detect potential port conflicts using something like static analysis at build time or introspection at runtime.

 

Best Regards,

An Ho

 

[1] https://wiki.opendaylight.org/view/Ports

[2] https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Feature_Integration_System_Test_Template#Feature_Pro-activeness

[3] Question 7.  https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#M4:_API_Freeze

 

 

 

From: release-bounces@... [mailto:release-bounces@...] On Behalf Of Abhijit Kumbhare

Sent: Thursday, March 24, 2016 10:42 PM
To: Daniel Farrell
Cc: Release; jgoodyear@...; vpnservice-dev@...; integration-dev@...; netide-dev@...
Subject: Re: [release] [integration-dev] [netide-dev] BindException in release bits.

 

I was actually suggesting also somewhere in the code this port info is registered - beyond the wiki. BTW the wiki info is accurate for OpenFlow.

 

On Thu, Mar 24, 2016 at 4:45 PM, Daniel Farrell <dfarrell@...> wrote:

@PTLs - Please verify your ports are correct on wiki/Ports (as it
seems to now be fairly important/official).

https://wiki.opendaylight.org/view/Ports

One way we could force an up-to-date port list from projects would
be to add it to the Per-Project Release Plan.

https://wiki.opendaylight.org/view/Simultaneous_Release:Per-Project_Boron_Release_Plan_Template

We could (manually, for now) make sure that wiki/Ports is correct
and that there are no conflicts.

Daniel Farrell
Software Engineer, Red Hat SDN Team
https://wiki.opendaylight.org/view/user:dfarrell07


----- Original Message -----
> May be register in some central place (may be in the datastore) what ports
> are being used?
>
> On Thu, Mar 24, 2016 at 12:00 PM, Luis Gomez <ecelgp@...> wrote:
>
> > Even when 2 projects are not designed to work together we want to avoid
> > port conflicts as much as possible, so for that we ask projects to look and
> > maintain the Ports wiki, at least until we get something better in place.
> >
> > BR/Luis
> >
> >
> > > On Mar 24, 2016, at 11:41 AM, Jamo Luhrsen <jluhrsen@...> wrote:
> > >
> > > Thanks Alec,
> > >
> > > On 03/24/2016 03:56 AM, Leckey, Alexander J wrote:
> > >> All,
> > >>
> > >> Before selecting port 6644, the NetIDE team did review the Port wiki
> > [1] for available ports to ensure 6644 was
> > >> available before choosing it. This was reflected in our M4 status email
> > [2] and updated by An in the tracking
> > >> spreadsheet [3]. I'll ask the VPNservice team to confirm, but it does
> > look like they only selected this port recently
> > >> as their M4 status for ports used was "N/A" [4]
> > >
> > > I think all of this sounds like NetIDE did all the right things with
> > > taking port 6644.
> > >
> > >>
> > >> However, it should be handled more gracefully by the NetIDE code
> > (catching BindException + Karaf Log - I'll open our
> > >> own bug for this).
> > >
> > > if you open another bug, please close 5597 which I opened for the same
> > > reason.
> > >
> > >> Although this is a configurable item in the NetIDE config file, how do
> > you decide who takes precedence on ports?
> > >
> > > Currently, the Ports wiki (which you checked) is our only "official"
> > place
> > > to track these things.
> > >
> > >
> > > JamO
> > >
> > >
> > >
> > >> Rgds, Alec.
> > >>
> > >> [1] https://wiki.opendaylight.org/view/Ports#Ports [2]
> > >>
> > https://lists.opendaylight.org/pipermail/release/2015-December/004723.html
> > [3]
> > >>
> > https://docs.google.com/spreadsheets/d/1Kfp5HVQGydNegEjp6dD2V3XsUnqpice0bysWbdxABA4/edit#gid=1512609931
> > [4]
> > >>
> > https://lists.opendaylight.org/pipermail/release/2015-December/004716.html
> > >>
> > >>
> > >>
> > >> -----Original Message----- From:
> > netide-dev-bounces@...
> > >> [mailto:netide-dev-bounces@...] On Behalf Of Luis
> > Gomez Sent: Wednesday, March 23, 2016 7:07 PM
> > >> To: Jamo Luhrsen <jluhrsen@...>; Release <
> > release@...> Cc: An Ho <An.Ho@...>; Thanh
> > >> Ha <thanh.ha@...>; jgoodyear@...;
> > vpnservice-dev@...;
> > >> integration-dev@...;
> > netide-dev@... Subject: Re: [netide-dev]
> > [integration-dev]
> > >> BindException in release bits.
> > >>
> > >> Adding the release list, I think for now projects should just look at
> > the port wiki [4] before assigning ports and
> > >> update the list once the ports are used. We brought this few times in
> > the past but people may forget.
> > >>
> > >> BR/Luis
> > >>
> > >>
> > >>> On Mar 23, 2016, at 11:45 AM, Jamo Luhrsen <jluhrsen@...> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On 03/23/2016 11:36 AM, Thanh Ha wrote:
> > >>>> Is it possible to script something that either scans the code base or
> > karaf features for potential ports that a
> > >>>> project might be trying to open?
> > >>>
> > >>> My guess is that projects are opening these ports in many different
> > ways so scanning might not be so easy.  In this
> > >>> example netide configures it's port number in an .xml config file, and
> > opens with some zeromq library. vpnservice
> > >>> defines it's port with "static final String" in java and opens with
> > something thrift.
> > >>>
> > >>>> If so we could build a report of potential port conflicts between
> > projects.
> > >>>>
> > >>>> Or maybe build into the controller some sort of port service that
> > allows projects to reserve ports and if
> > >>>> multiple projects request the same ports it can dump the info to log.
> > >>>
> > >>>
> > >>> I don't know how hard/feasible this would be, or if it could even be
> > policed, but maybe...
> > >>>
> > >>> JamO
> > >>>
> > >>>> Regards, Thanh
> > >>>>
> > >>>> On 23 March 2016 at 14:16, Jamo Luhrsen <jluhrsen@... <mailto:
> > jluhrsen@...>> wrote:
> > >>>>
> > >>>> I think I found the issue for this.
> > >>>>
> > >>>> netide [0] and vpnservice [1] both want to use port 6644.
> > >>>>
> > >>>> If vpnservice is loaded first, when netide is then installed it will
> > fail to bind to that port.  However the
> > >>>> BindException is not caught and the library used to do the bind ends
> > up printing to the karaf console.  I filed a
> > >>>> bug [2] for netide to catch this and at least throw it to karaf.log
> > instead of the console.
> > >>>>
> > >>>> It seems that vpnservice does catch this condition and acknowledges
> > so in karaf.log, but it's not noted as a
> > >>>> TTransportException.  I *think* this is a problem right, and makes
> > the two features incompatible.  For this, I
> > >>>> filed another bug [3].  I gave that bug to vpnservice, just to be
> > fair :) It may need to be moved.
> > >>>>
> > >>>> We do track the ports projects use here [4], and I've updated it to
> > note the conflict.
> > >>>>
> > >>>> Why this is seemingly only showing in distributions built by
> > autorelease is still up for question, but my guess
> > >>>> is that the ordering of feature install is consistently different in
> > those distributions making vpnservice
> > >>>> install first.  The problem is still there in our snapshot distros if
> > you reproduce manually.  But, installing
> > >>>> automatically from featuresBoot it seems that netide must be getting
> > installed first.
> > >>>>
> > >>>> There could be other issues like this in the wild, but I can't think
> > of any good way to hunt them down.  We
> > >>>> really need projects to stay in sync with ports they are opening.
> > >>>>
> > >>>> Thanks, JamO
> > >>>>
> > >>>>
> > >>>> [0]
> > https://github.com/opendaylight/netide/blob/master/config/src/main/resources/initial/43-netide.xml#L24
> > [1]
> > >>>>
> > https://github.com/opendaylight/vpnservice/blob/master/bgpmanager/bgpmanager-impl/src/main/java/org/opendaylight/bgpmanager/BgpConfigurationManager.java#L69
> > >>>>
> > >>>>
> > > [2] https://bugs.opendaylight.org/show_bug.cgi?id=5597
> > >>>> [3] https://bugs.opendaylight.org/show_bug.cgi?id=5598 [4]
> > https://wiki.opendaylight.org/view/Ports#Ports
> > >>>>
> > >>>> On 03/18/2016 03:24 PM, Jamo Luhrsen wrote:
> > >>>>> Another odd thing we are facing with the autorelease is in our
> > distribution-deploy [0] job.  This job is
> > >>>>> failing with autorelease bits because it gets a BindException on the
> > karaf console (note: it does not come in
> > >>>>> karaf.log).   this is not coming in our snapshot distros.  Another
> > oddity is that I'm only seeing it if I'm
> > >>>>> loading the features (*all* the projects features) by placing it in
> > featuresBoot.  If I load them directly with
> > >>>>> "feature:install" in the karaf console, we do not see the
> > BindException.
> > >>>>>
> > >>>>> It's worrisome because the distributions we release are starting to
> > feel different than the ones we work with
> > >>>>> and continuously test with the snapshot builds.  This is in
> > reference to the other recent problem where our SR1
> > >>>>> distro would not even come up (not fixed).
> > >>>>>
> > >>>>> What can we do to figure this out?  I'm unsure right now.
> > >>>>>
> > >>>>> Thanks, JamO
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> [0]
> > https://jenkins.opendaylight.org/releng/view/autorelease/job/integra
> > tion-distribution-deploy-beryllium/
> > >>>>>
> > >>>>
> > >>>>
> > >>> _______________________________________________ integration-dev
> > mailing list
> > >>> integration-dev@...
> > https://lists.opendaylight.org/mailman/listinfo/integration-dev
> > >>
> > >> _______________________________________________ netide-dev mailing list
> > netide-dev@...
> > >> https://lists.opendaylight.org/mailman/listinfo/netide-dev
> > >> -------------------------------------------------------------- Intel
> > Research and Development Ireland Limited
> > >> Registered in Ireland Registered Office: Collinstown Industrial Park,
> > Leixlip, County Kildare Registered Number:
> > >> 308263
> > >>
> > >>
> > >> This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any
> > >> review or distribution by others is strictly prohibited. If you are not
> > the intended recipient, please contact the
> > >> sender and delete all copies.
> > >>
> >
> > _______________________________________________
> > integration-dev mailing list
> > integration-dev@...
> > https://lists.opendaylight.org/mailman/listinfo/integration-dev
> >
>

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

 




ALTO M1 Status

Gao Kai <gaok12@...>
 

ALTO

1. Offset: 2

2. Project Lead: Kai Gao/gaok12@.../emiapwil

3. Project Contact: Jensen Zhang/jingxuan.n.zhang@.../jensen_zhang

4. Test Contact: Xiao Lin/linxiao9292@.../XiaoLin

5. Documentation Contact: Xiao Lin/linxiao9292@.../XiaoLin

6. Draft Release Plan: https://wiki.opendaylight.org/view/ALTO:Boron_Release_Plan

7. Project Main Page: https://wiki.opendaylight.org/view/ALTO:Main

8. The ALTO project formally joins the OpenDaylight Boron Simultaneous Release and agrees to the activities and timeline documented on the Boron Release Plan Page: https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan"

Regards,
Kai


Re: Change in alto[master]: Manually merge changes from stable/beryllium to master Inclu...

Gao Kai
 

Thanh Ha,

Thanks a lot for the information and they are very helpful.  I will make sure everyone in the development team really understands the workflow and try to follow the best practice.

Again, thanks for the help!

Regards,
Kai

On 24/03/16 11:09, Thanh Ha wrote:
Thanks Kai,

In case it helps the workflow most OpenDaylight projects use is, when a committer accepts and merges a patch, they make a decision if the patch needs to be cherry-picked to other branches as well. For example if you a merging a patch that was submitted to master you should decide if that patch needs to be backported to stable/beryllium and/or stable/lithium as well at that time, typically this decision is done by the committer who reviews and merges the patch. The best way to do this is to use the Cherry-pick button right inside Gerrit. Choose cherry-pick and enter the branch you'd like to carry the patch over to, most of the time this should work trivially. If you get an error then you'll need to do it manually via git commandline as there is likely some merge conflicts you need to take care of.

If you cherry-pick at time of merge it will save you a lot of effort of porting patches to new branches as your code is kept in sync. Typically you should cherry-pick bug fixes backwards to stable branches and only pull in new features to master branch but that is up to your project.

Another thing I highly recommend all committers review and understand is this blog post regarding how to write well formed commit messages.


This is an excellently written blog post about the importance of writing commit messages that are meaningful and useful. If you've never had to troubleshoot and debug code you may not realize the usefulness but commit messages are immensely useful when you are troubleshooting and trying to find which patch introduced a regression in your code. If you need examples of really well written commit message, the Linux Kernel project is one of the best source of commit messages since they are extremely strict on only accepting patches that have well formed commit messages.


Hope this helps,
Thanh


On 23 March 2016 at 22:04, Gao Kai <gaok12@...> wrote:
Thanh Ha,

Thanks for the help and I apologize for not responding earlier.  I take
major responsibility here since I myself have submitted squashed commits
as well. (Shame on me.)  I'll make sure other members in the team can
learn something from this and avoid similar circumstances.


Jinmin,

Thanks for your work and the efforts are highly appreciated.  Since ALTO
is part of the OpenDaylight, could you please try to follow Thanh's
suggestions on how the community works? Also, merging patches from
stable/beryllium to master is not a task you must accomplish all on your
own.  If you cherry-pick the patches one by one, others such as Thanh,
who has helped us a lot with the development, can also help resolve the
conflicts.  Jensen and I are also watching the commits so we can provide
some help too.


To the rest of the ALTO development team,

This can be a good chance to learn from our mistakes and to get a better
understanding of how open source communities work.  It can take a while
for all of us to fit in the culture but I think it's something we should
always do.

Thanks!

Kai


On 24/03/16 00:28, Gerrit Code Review wrote:
> From Thanh Ha <thanh.ha@...>:
>
> Thanh Ha has posted comments on this change.
>
> Change subject: Manually merge changes from stable/beryllium to master Including commits from 792bc87f7c0b to b5dd44d93 And fixing remained old version tags which caused last failure
> ......................................................................
>
>
> Patch Set 2:
>
>> Sorry for modifying .gitreview file unexpectedly.
>  >
>  > But I have to explain that I did cherry-pick commits from
>  > stable/beryllium one by one by one.. After fixing all the conflicts
>  > and cherry-picking all the commits, I just squashed them into one
>  > commit. And pushing 12 commits to remote is really unnecessary as
>  > we discussed in the laboratory. And every fixes and edition is made
>  > after careful comparation. Thanks for reminding
>
> It is better to cherry-pick and push each patch (actually when you reviewed and merged the patches into stable/beryllium they should have been cherry-picked to all relevant branches). If you squash commits like these you're affecting the statistics of your project. These 12 commits represent 12 contributions to the project and potentially multiple contributors.
>
> When you squash commits like these you are hiding the history of the contributions from your contributor base. All contributions will now appear as if you were the one who contributed the work. While I do see that you kept the commit messages aggregated in your message, tools like spectrometer, github, openhub, etc... do not take this into account and will show that the alto project is less diverse a community than it really is. One of the greatest things about open source development for a contributor is that they can refer back to code that they contributed to a project, squashed commits make this significantly harder.
>





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


Re: Change in alto[master]: Manually merge changes from stable/beryllium to master Inclu...

Thanh Ha <thanh.ha@...>
 

Thanks Kai,

In case it helps the workflow most OpenDaylight projects use is, when a committer accepts and merges a patch, they make a decision if the patch needs to be cherry-picked to other branches as well. For example if you a merging a patch that was submitted to master you should decide if that patch needs to be backported to stable/beryllium and/or stable/lithium as well at that time, typically this decision is done by the committer who reviews and merges the patch. The best way to do this is to use the Cherry-pick button right inside Gerrit. Choose cherry-pick and enter the branch you'd like to carry the patch over to, most of the time this should work trivially. If you get an error then you'll need to do it manually via git commandline as there is likely some merge conflicts you need to take care of.

If you cherry-pick at time of merge it will save you a lot of effort of porting patches to new branches as your code is kept in sync. Typically you should cherry-pick bug fixes backwards to stable branches and only pull in new features to master branch but that is up to your project.

Another thing I highly recommend all committers review and understand is this blog post regarding how to write well formed commit messages.


This is an excellently written blog post about the importance of writing commit messages that are meaningful and useful. If you've never had to troubleshoot and debug code you may not realize the usefulness but commit messages are immensely useful when you are troubleshooting and trying to find which patch introduced a regression in your code. If you need examples of really well written commit message, the Linux Kernel project is one of the best source of commit messages since they are extremely strict on only accepting patches that have well formed commit messages.


Hope this helps,
Thanh


On 23 March 2016 at 22:04, Gao Kai <gaok12@...> wrote:
Thanh Ha,

Thanks for the help and I apologize for not responding earlier.  I take
major responsibility here since I myself have submitted squashed commits
as well. (Shame on me.)  I'll make sure other members in the team can
learn something from this and avoid similar circumstances.


Jinmin,

Thanks for your work and the efforts are highly appreciated.  Since ALTO
is part of the OpenDaylight, could you please try to follow Thanh's
suggestions on how the community works? Also, merging patches from
stable/beryllium to master is not a task you must accomplish all on your
own.  If you cherry-pick the patches one by one, others such as Thanh,
who has helped us a lot with the development, can also help resolve the
conflicts.  Jensen and I are also watching the commits so we can provide
some help too.


To the rest of the ALTO development team,

This can be a good chance to learn from our mistakes and to get a better
understanding of how open source communities work.  It can take a while
for all of us to fit in the culture but I think it's something we should
always do.

Thanks!

Kai


On 24/03/16 00:28, Gerrit Code Review wrote:
> From Thanh Ha <thanh.ha@...>:
>
> Thanh Ha has posted comments on this change.
>
> Change subject: Manually merge changes from stable/beryllium to master Including commits from 792bc87f7c0b to b5dd44d93 And fixing remained old version tags which caused last failure
> ......................................................................
>
>
> Patch Set 2:
>
>> Sorry for modifying .gitreview file unexpectedly.
>  >
>  > But I have to explain that I did cherry-pick commits from
>  > stable/beryllium one by one by one.. After fixing all the conflicts
>  > and cherry-picking all the commits, I just squashed them into one
>  > commit. And pushing 12 commits to remote is really unnecessary as
>  > we discussed in the laboratory. And every fixes and edition is made
>  > after careful comparation. Thanks for reminding
>
> It is better to cherry-pick and push each patch (actually when you reviewed and merged the patches into stable/beryllium they should have been cherry-picked to all relevant branches). If you squash commits like these you're affecting the statistics of your project. These 12 commits represent 12 contributions to the project and potentially multiple contributors.
>
> When you squash commits like these you are hiding the history of the contributions from your contributor base. All contributions will now appear as if you were the one who contributed the work. While I do see that you kept the commit messages aggregated in your message, tools like spectrometer, github, openhub, etc... do not take this into account and will show that the alto project is less diverse a community than it really is. One of the greatest things about open source development for a contributor is that they can refer back to code that they contributed to a project, squashed commits make this significantly harder.
>




Re: Change in alto[master]: Manually merge changes from stable/beryllium to master Inclu...

Gao Kai <gaok12@...>
 

Thanh Ha,

Thanks for the help and I apologize for not responding earlier. I take
major responsibility here since I myself have submitted squashed commits
as well. (Shame on me.) I'll make sure other members in the team can
learn something from this and avoid similar circumstances.


Jinmin,

Thanks for your work and the efforts are highly appreciated. Since ALTO
is part of the OpenDaylight, could you please try to follow Thanh's
suggestions on how the community works? Also, merging patches from
stable/beryllium to master is not a task you must accomplish all on your
own. If you cherry-pick the patches one by one, others such as Thanh,
who has helped us a lot with the development, can also help resolve the
conflicts. Jensen and I are also watching the commits so we can provide
some help too.


To the rest of the ALTO development team,

This can be a good chance to learn from our mistakes and to get a better
understanding of how open source communities work. It can take a while
for all of us to fit in the culture but I think it's something we should
always do.

Thanks!

Kai

On 24/03/16 00:28, Gerrit Code Review wrote:
From Thanh Ha <thanh.ha@...>:

Thanh Ha has posted comments on this change.

Change subject: Manually merge changes from stable/beryllium to master Including commits from 792bc87f7c0b to b5dd44d93 And fixing remained old version tags which caused last failure
......................................................................


Patch Set 2:

Sorry for modifying .gitreview file unexpectedly.
>
> But I have to explain that I did cherry-pick commits from
> stable/beryllium one by one by one.. After fixing all the conflicts
> and cherry-picking all the commits, I just squashed them into one
> commit. And pushing 12 commits to remote is really unnecessary as
> we discussed in the laboratory. And every fixes and edition is made
> after careful comparation. Thanks for reminding

It is better to cherry-pick and push each patch (actually when you reviewed and merged the patches into stable/beryllium they should have been cherry-picked to all relevant branches). If you squash commits like these you're affecting the statistics of your project. These 12 commits represent 12 contributions to the project and potentially multiple contributors.

When you squash commits like these you are hiding the history of the contributions from your contributor base. All contributions will now appear as if you were the one who contributed the work. While I do see that you kept the commit messages aggregated in your message, tools like spectrometer, github, openhub, etc... do not take this into account and will show that the alto project is less diverse a community than it really is. One of the greatest things about open source development for a contributor is that they can refer back to code that they contributed to a project, squashed commits make this significantly harder.


Re: [release] Beryllium SR1 ready to test

linxiao9292
 

Hi Kai,

Just get some inspiration from coretutorial project. I think we could provide a step by step guide scripts for users according the user guide in ALTO wiki page. Something like these,

-rwxr-xr-x 1 shaw shaw   99 Mar 17 21:42 01_get_Simple_IRD_information
-rwxr-xr-x 1 shaw shaw  574 Mar 17 22:54 02_create_a_new_IRD
-rwxr-xr-x 1 shaw shaw  788 Mar 17 22:50 03_add_a_new_entry_to_an_existing_IRD
-rwxr-xr-x 1 shaw shaw  287 Mar 17 22:52 04_display_entries_in_an_existing_IRD
-rwxr-xr-x 1 shaw shaw  403 Mar 17 23:01 05_remove_an_entry_from_an_existing_IRD
-rwxr-xr-x 1 shaw shaw  239 Mar 17 22:52 06_remove_an_IRD
-rwxr-xr-x 1 shaw shaw  269 Mar 17 22:46 get_base_url
-rwxr-xr-x 1 shaw shaw  271 Mar 17 22:29 get_context_id

I have tested the Simple IRD, and it works well. And I will continue the rest tests and re-organize more scripts tomorrow.

Bests,
Xiao


From: linxiao9292@...
To: gaok12@...; alto-dev@...
Subject: RE: [alto-dev] Fwd: [release] Beryllium SR1 ready to test
Date: Wed, 16 Mar 2016 12:44:14 +0000

Hi Kai,

That is great! I will take a look.

Regards,
Xiao


To: alto-dev@...
From: gaok12@...
Date: Wed, 16 Mar 2016 20:27:58 +0800
Subject: [alto-dev] Fwd: [release] Beryllium SR1 ready to test

Hi Xiao and all,

SR1 is released.  Can we test if ALTO works, especially the new features?

Thanks!

Regards,
Kai


-------- Forwarded Message --------
Subject: [release] Beryllium SR1 ready to test
Date: Wed, 16 Mar 2016 02:19:17 -0400
From: Thanh Ha <thanh.ha@...>
To: release@... <release@...>, odl-dev-list <dev@...>


Beryllium SR1 is ready for testing. Details are available here [0]. For those interested in NeXt toolkit it is also available here [1]
Regards,
Thanh
[1] https://nexus.opendaylight.org/content/repositories/autorelease-1125/org/opendaylight/next/next/0.9.1-Beryllium-SR1/




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


Re: [release] Beryllium SR1 ready to test

linxiao9292
 

Hi Kai,

That is great! I will take a look.

Regards,
Xiao


To: alto-dev@...
From: gaok12@...
Date: Wed, 16 Mar 2016 20:27:58 +0800
Subject: [alto-dev] Fwd: [release] Beryllium SR1 ready to test

Hi Xiao and all,

SR1 is released.  Can we test if ALTO works, especially the new features?

Thanks!

Regards,
Kai


-------- Forwarded Message --------
Subject: [release] Beryllium SR1 ready to test
Date: Wed, 16 Mar 2016 02:19:17 -0400
From: Thanh Ha <thanh.ha@...>
To: release@... <release@...>, odl-dev-list <dev@...>


Beryllium SR1 is ready for testing. Details are available here [0]. For those interested in NeXt toolkit it is also available here [1]
Regards,
Thanh
[1] https://nexus.opendaylight.org/content/repositories/autorelease-1125/org/opendaylight/next/next/0.9.1-Beryllium-SR1/




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


[release] Beryllium SR1 ready to test

Gao Kai <gaok12@...>
 

Hi Xiao and all,

SR1 is released.  Can we test if ALTO works, especially the new features?

Thanks!

Regards,
Kai


-------- Forwarded Message --------
Subject: [release] Beryllium SR1 ready to test
Date: Wed, 16 Mar 2016 02:19:17 -0400
From: Thanh Ha <thanh.ha@...>
To: release@... <release@...>, odl-dev-list <dev@...>


Beryllium SR1 is ready for testing. Details are available here [0]. For those interested in NeXt toolkit it is also available here [1]
Regards,
Thanh
[1] https://nexus.opendaylight.org/content/repositories/autorelease-1125/org/opendaylight/next/next/0.9.1-Beryllium-SR1/




[release] Weather report: Unmerged Patch for projects to test OpenFlow Plugin default design to Lithium

Gao Kai <gaok12@...>
 

We might want to test OpenFlow Plugin as well and declare our dependency on that too from the Boron release.


-------- Forwarded Message --------
Subject: [release] Weather report: Unmerged Patch for projects to test OpenFlow Plugin default design to Lithium
Date: Thu, 10 Mar 2016 21:53:48 -0800
From: Abhijit Kumbhare <abhijitkoss@...>
To: Release <release@...>, faas-dev@..., GroupBasedPolicy-dev@... <groupbasedpolicy-dev@...>, l2switch-dev@... <l2switch-dev@...>, lacp-dev@..., nemo-dev@..., nic-dev@... <nic-dev@...>, Sdninterfaceapp-dev@..., netide-dev@..., <ovsdb-dev@...> <ovsdb-dev@...>, sfc-dev@... <sfc-dev@...>, vpnservice-dev@..., vtn-dev@... <vtn-dev@...>


Hi folks,

We need all the dependent projects of OpenFlow Plugin (OFP) to move to the Lithium design for the Boron release. To help in this process OpenFlow Plugin has created an unmerged patch which swaps the default design to the 
​new ​
Lithium design. The patch is: https://git.opendaylight.org/gerrit/#/c/35892. The purpose of this patch is for projects to identify issues in the migration and help OpenFlow Plugin fix them. 

To use this patch projects should:
1. 
clone the openflowplugin and then checkout this patch
 it locally
​ and build
2. 
​​
t
​est​
 
​their project with the locally swapped new plugin 

We would like this activity to identify issues to conclude in the next 2 weeks or so (say March 24 - which happens to be the current offset 2 projects M1 date in the provisional traditional release plan ). That way OpenFlow Plugin can factor the gaps needed to fix in the OpenFlow Plugin release plan which is due by M2 for us (current date in the provisional traditional release plan for OFP is April 21). The OFP target for fixing the issues and actually changing the default plugin would likely be either OFP M2 or M3 - depending on the complexity of the issues identified. The issues which cannot be worked around 
​and blocking development of the project ​
should be raised as blocker issues on OpenFlow Plugin.

Again as I mentioned - please try this patch out and let us know the issues by March 24. If there is an issue in providing this info - please let us know as well.


Thanks,
Abhijit




ALTO Boron Release Plan

Gao Kai
 

Hi all,

As you may or may not know the Boron release plan has been "provisionally" approved by the TSC and [0] is the link to the template wiki page.

The due date is March 24th and we should start to discuss some details about the next release.  I suggest we walk through the template in our next weekly meeting.

Regards,
Kai

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan


Re: [alto-design] Fwd: L2switch - Help

Gao Kai
 

Karthik,

We'd like to help.  Can you provide us some more detailed information such as the error log?

Regards,
Kai

On 01/03/16 13:34, Junzhuo Austin Wang wrote:
Hi all,

This person from wipro.com sent an email to me. Please check it below. Should we engage with him? If so, how?

Regards,
Junzhuo


2016-02-29 21:25 GMT-08:00 <karthikeyan.d17@...>:

Hi ,

        Myself Karthik , working in OpenDay Light . I checked your code CS512/l2switch to get shortest path.I cloned it and built it success ! But I dont know how to use it with ODL! .

How to install your modified l2switch to ODL?. I checked your version "0.2.1-ALTO-SNAPSHOT" and tried to add this version to ODL, but faced version miss match error. I need your help . Can you guide me how to use your modified code ?



Thanks,

-Karthik

09003444434

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

--
You received this message because you are subscribed to the Google Groups "alto-design" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alto-design+unsubscribe@....
To post to this group, send email to alto-design@....
To view this discussion on the web visit https://groups.google.com/d/msgid/alto-design/CAOz7UywXCtQt72Um%3DHqObCxDXRjTeYu-F_701XEcLfO7hotpaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Tips on writing commit messages

Gao Kai <gaok12@...>
 

Hi all,

Sorry that I forgot to paste the link....

[0] http://chris.beams.io/posts/git-commit/

Regards,
Kai

On 29/02/16 16:37, Gao Kai wrote:
Hello all,

If you have spare time, please take a look at this article [0].  It is encouraged that everyone of us follow these tips in future commits.

Thanks!

Regards,
Kai


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


Tips on writing commit messages

Gao Kai <gaok12@...>
 

Hello all,

If you have spare time, please take a look at this article [0].  It is encouraged that everyone of us follow these tips in future commits.

Thanks!

Regards,
Kai


Re: Updated user guide

linxiao9292
 

Hi Jensen,

Thanks for your update. And I would like to read this wiki page as soon as possible after I finish standard-northbound-route-endpointproperty.

Bests,
Xiao


Date: Sun, 28 Feb 2016 14:32:06 +0800
Subject: Updated user guide
From: jingxuan.n.zhang@...
To: alto-dev@...; gaok12@...; linxiao9292@...; gc19931011jy@...

Hi all,

I have updated the user guide wiki page for ALTO [1]. I refined the layout and updated section 4 and 5. Currently, we still miss a section for the comprehensive usage and some reasonable use cases. I am very looking forward some volunteers to reviewing the finished sections and giving some thoughts about the missed section.


Updated user guide

Jensen Zhang
 

Hi all,

I have updated the user guide wiki page for ALTO [1]. I refined the layout and updated section 4 and 5. Currently, we still miss a section for the comprehensive usage and some reasonable use cases. I am very looking forward some volunteers to reviewing the finished sections and giving some thoughts about the missed section.


Re: [releng] Maven Site generation

linxiao9292
 

Hi Thanh,

That is really helpful, thank you for the information!

Bests,
Xiao


From: thanh.ha@...
Date: Fri, 26 Feb 2016 11:40:28 -0500
Subject: Re: [releng] Maven Site generation
To: linxiao9292@...
CC: dev@...; godrickk@...; alto-dev@...; jingxuan.n.zhang@...

Hi Xiao,

Yes all of the ODL merge jobs are configured to automatically detect the existence of the deploy-site.xml file and automatically build and deploy the docs once your code is merged.

Regards,
Thanh

On 26 February 2016 at 00:40, Xiao Lin <linxiao9292@...> wrote:
Hi Thanh,

Thanks a lot! That works. I could see the right pages and the links are working too. After my patch being merged by that project, the maven site will be automatically generated in https://nexus.opendaylight.org/content/sites/site/{myproject}/ ?

Thanks,
Xiao Lin


From: thanh.ha@...
Date: Thu, 25 Feb 2016 10:49:10 -0500
Subject: [releng] Maven Site generation
To: linxiao9292@...; dev@...


Hi Xiao,

In the future please send these types of inquiries to the [releng] topic at dev@...

The best way to test Maven Site locally that I've found is to run 2 commands as follows:

    mvn clean install
    mvn site:deploy -Dstream=latest

The 1st command generates your documentation, because the way Maven Site generation works it produces all the documentation but does not produce working URL paths that you can use so we need the 2nd command.

The 2nd command aggregates all the documentation into a staging site. This will produce a directory in your project root called "target/staged-site". The string -Dstream can be set to anything, it just represents what version of your site documentation you want to call it. Typically Jenkins will use our release names such as -Dstream=beryllium or -Dstream=boron etc...

You can now open the site with your webbrowser by opening any of the html files for example:

    google-chrome target/staged-site/index.html

Hope this helps,
Thanh

On 25 February 2016 at 08:31, Xiao Lin <linxiao9292@...> wrote:
Hi Thanh,

I have followed the steps here [0] to automatically generate Maven Site. I could see auto generated files in /target/staged-site/odlparent-lite/ .
But I have some difficulties in how deploy this maven site locally. Because I want to test the auto generated links work or not and then I would try to  submit the patch. 
And I have read tutorial in [1], and I have executed mvn site:stage, and then executed mvn site:run. After that, I could get right message in localhost:8080, but when I clicked links on that page, 404 not found page appeared. Could you please give me some advice ?  And I am not sure which mailing lists should I post this type of questions.

Thanks,
Xiao Lin




Re: [releng] Maven Site generation

Thanh Ha <thanh.ha@...>
 

Hi Xiao,

Yes all of the ODL merge jobs are configured to automatically detect the existence of the deploy-site.xml file and automatically build and deploy the docs once your code is merged.

Regards,
Thanh

On 26 February 2016 at 00:40, Xiao Lin <linxiao9292@...> wrote:
Hi Thanh,

Thanks a lot! That works. I could see the right pages and the links are working too. After my patch being merged by that project, the maven site will be automatically generated in https://nexus.opendaylight.org/content/sites/site/{myproject}/ ?

Thanks,
Xiao Lin


From: thanh.ha@...
Date: Thu, 25 Feb 2016 10:49:10 -0500
Subject: [releng] Maven Site generation
To: linxiao9292@...; dev@...


Hi Xiao,

In the future please send these types of inquiries to the [releng] topic at dev@...

The best way to test Maven Site locally that I've found is to run 2 commands as follows:

    mvn clean install
    mvn site:deploy -Dstream=latest

The 1st command generates your documentation, because the way Maven Site generation works it produces all the documentation but does not produce working URL paths that you can use so we need the 2nd command.

The 2nd command aggregates all the documentation into a staging site. This will produce a directory in your project root called "target/staged-site". The string -Dstream can be set to anything, it just represents what version of your site documentation you want to call it. Typically Jenkins will use our release names such as -Dstream=beryllium or -Dstream=boron etc...

You can now open the site with your webbrowser by opening any of the html files for example:

    google-chrome target/staged-site/index.html

Hope this helps,
Thanh

On 25 February 2016 at 08:31, Xiao Lin <linxiao9292@...> wrote:
Hi Thanh,

I have followed the steps here [0] to automatically generate Maven Site. I could see auto generated files in /target/staged-site/odlparent-lite/ .
But I have some difficulties in how deploy this maven site locally. Because I want to test the auto generated links work or not and then I would try to  submit the patch. 
And I have read tutorial in [1], and I have executed mvn site:stage, and then executed mvn site:run. After that, I could get right message in localhost:8080, but when I clicked links on that page, 404 not found page appeared. Could you please give me some advice ?  And I am not sure which mailing lists should I post this type of questions.

Thanks,
Xiao Lin




Updated developer guide

Gao Kai <gaok12@...>
 

Hi all,

I have updated the developer guide wiki page for ALTO[0], it's still in progress but I think we can still benefit from your feedbacks.  In this update, some out-dated contents are removed from the page and I also did a little tweak on the whole structure.  It would be great if someone can take a look and see if there is anything that is missing or needs clarification.

Your thoughts and suggestions are highly appreciated!

Regards,
Kai

[0] https://wiki.opendaylight.org/view/ALTO:Beryllium_Developer_Guide


Re: [releng] Maven Site generation

linxiao9292
 

Hi Thanh,

Thanks a lot! That works. I could see the right pages and the links are working too. After my patch being merged by that project, the maven site will be automatically generated in https://nexus.opendaylight.org/content/sites/site/{myproject}/ ?

Thanks,
Xiao Lin


From: thanh.ha@...
Date: Thu, 25 Feb 2016 10:49:10 -0500
Subject: [releng] Maven Site generation
To: linxiao9292@...; dev@...

Hi Xiao,

In the future please send these types of inquiries to the [releng] topic at dev@...

The best way to test Maven Site locally that I've found is to run 2 commands as follows:

    mvn clean install
    mvn site:deploy -Dstream=latest

The 1st command generates your documentation, because the way Maven Site generation works it produces all the documentation but does not produce working URL paths that you can use so we need the 2nd command.

The 2nd command aggregates all the documentation into a staging site. This will produce a directory in your project root called "target/staged-site". The string -Dstream can be set to anything, it just represents what version of your site documentation you want to call it. Typically Jenkins will use our release names such as -Dstream=beryllium or -Dstream=boron etc...

You can now open the site with your webbrowser by opening any of the html files for example:

    google-chrome target/staged-site/index.html

Hope this helps,
Thanh

On 25 February 2016 at 08:31, Xiao Lin <linxiao9292@...> wrote:
Hi Thanh,

I have followed the steps here [0] to automatically generate Maven Site. I could see auto generated files in /target/staged-site/odlparent-lite/ .
But I have some difficulties in how deploy this maven site locally. Because I want to test the auto generated links work or not and then I would try to  submit the patch. 
And I have read tutorial in [1], and I have executed mvn site:stage, and then executed mvn site:run. After that, I could get right message in localhost:8080, but when I clicked links on that page, 404 not found page appeared. Could you please give me some advice ?  And I am not sure which mailing lists should I post this type of questions.

Thanks,
Xiao Lin


181 - 200 of 542