Date   

ALTO Boron M5 Status

Gao Kai <gaok12@...>
 

ALTO Boron M5 Status

1. Please provide updates on any previously-incomplete items from prior milestone readouts.

N/A

2. Has your project met code freeze, i.e., only bug fixes are allowed from now on? (Yes/No)

Yes

3. Are all externally visible strings frozen to allow for translation & documentation? (Yes/No)

Yes

4. Is your documentation complete such that only editing and enhancing should take place after this point? (Yes/No)
* (For each document, link to the file in gerrit)

Yes


https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=manuals/developer-guide/src/main/asciidoc/alto/alto-developer-guide.adoc;h=b97142fb5abb423614dd9ab5e9645a32d2a11d04;hb=HEAD

https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=manuals/user-guide/src/main/asciidoc/alto/alto-user-guide.adoc;h=046d9f8392f7b0872ab44d0ce567763be7a74ffa;hb=HEAD


* (Link to pending gerrit patches waiting approval)

N/A

5. Were project-specific deliverables planned for this milestone delivered successfully? (No Deliverables/Yes/No)

Yes

6. Are you running at least one basic automated system test job for each top-level feature? (Yes/No)
* (If yes, link to test report)

Yes
https://jenkins.opendaylight.org/releng/view/alto/job/alto-csit-1node-setup-only-boron/
https://jenkins.opendaylight.org/releng/view/alto/job/alto-csit-1node-setup-all-boron/

* (If not, explain why)

Stables Features (only for projects with stable features)

7. Do your stable features fulfill quality requirements (i.e. unit and/or integration test coverage of at least 75%)? (Yes/No)

No stable feature

* (If yes, link to sonar report)
* (If not, explain why)

8. Are you running several automated system test jobs including functionality, cluster, scalability, performance, longevity/stability for each stable feature? (Yes/No)

No stable feature

* (If yes, link to test reports)
* (If not, explain why)


Re: [release] distribution still not good

Gao Kai <gaok12@...>
 

FYI



-------- Forwarded Message --------
Subject: Re: [release] distribution still not good
Date: Thu, 4 Aug 2016 15:57:56 -0400
From: Colin Dixon <colin@...>
To: Luis Gomez <ecelgp@...>
CC: release@... <release@...>


mvn help:effective-pom is sometimes useful for this

--Colin


On Thu, Aug 4, 2016 at 3:47 PM, Luis Gomez <ecelgp@...> wrote:

Last failure in master distribution:

[ERROR] Failed to execute goal on project features-integration-index: Could not resolve dependencies for project org.opendaylight.integration:features-integration-index:jar:0.5.0-SNAPSHOT: Failed to collect dependencies at org.opendaylight.ocpplugin:features-ocpplugin:xml:features:0.1.0-SNAPSHOT -> org.opendaylight.ocpplugin.ocpjava:features-ocpjava:xml:features:0.1.0-SNAPSHOT -> org.opendaylight.ocpplugin.ocpjava:ocp-protocol-api:jar:0.1.0-SNAPSHOT -> org.opendaylight.controller.model:model-inventory:jar:1.3.3-Beryllium-SR3: Failed to read artifact descriptor for org.opendaylight.controller.model:model-inventory:jar:1.3.3-Beryllium-SR3: Could not find artifact org.opendaylight.odlparent:bundle-parent:pom:1.6.3-Beryllium-SR3 in opendaylight-mirror 
Still investigating why this  Boron feature shows this dependency in just created Be SR3.
BR/Luis
_______________________________________________ release mailing list release@... https://lists.opendaylight.org/mailman/listinfo/release


Re: Distribution Size Failures: ALTO

Stephen Kitt <skitt@...>
 

On Thu, 4 Aug 2016 09:54:16 +0800
Gao Kai <gaok12@...> wrote:
I replied to the thread in the release mailing list [1] about the
issue. We found that tsdr alone uses two different Jetty versions,
one of which is identical to the one that we use
(8.1.198.1.19.v20160209:compile).

Meanwhile, the two "jetty" belong to different packages
(org.eclipse.jettyand org.mortbay.jetty). Not sure we can/should make
them one.
It may be worth checking whether the version of Jetty bundled with
Karaf is suitable (8.1.15.v20140411 as of Karaf 3.0.6, available as the
"jetty" feature in the standard repository).

Regards,

Stephen


Re: Distribution Size Failures: ALTO

Gao Kai <gaok12@...>
 

Hello An Ho,


I replied to the thread in the release mailing list [1] about the issueWe found that tsdr alone uses two different Jetty versions, one of which is identical to the one that we use (8.1.198.1.19.v20160209:compile).

Meanwhile, the two "jetty" belong to different packages (org.eclipse.jetty and org.mortbay.jetty).  Not sure we can/should make them one.

Regards,

Kai


[1] https://lists.opendaylight.org/pipermail/release/2016-July/007455.html

On 04/08/16 04:22, An Ho wrote:

Hi ALTO,

We are currently running into distribution size failures [1] where the Boron Common Karaf Distirbution is greater than 512MB.  In order to decrease the size of the distribution, we believe there is potential for your project to help reduce the size of the distribution [2].  Please take a look at the action item below and let us know if such work can be achieved to assist in reducing the distribution size.  We are tracking this task on the Google Tracking Spreadsheet [3].

Action Item: alto and tsdr can agree on a common version of jetty

Best Regards,
An Ho

[1] https://lists.opendaylight.org/pipermail/release/2016-August/007584.html
[2] https://lists.opendaylight.org/pipermail/release/2016-July/007248.html
[3] https://docs.google.com/spreadsheets/d/1zImtd764e-hOgJAxoJKl85fxHCPu2agLfqsBtf13zQY/edit#gid=1408329875


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


Distribution Size Failures: ALTO

an.ho@huawei.com
 

Hi ALTO,

We are currently running into distribution size failures [1] where the Boron Common Karaf Distirbution is greater than 512MB. In order to decrease the size of the distribution, we believe there is potential for your project to help reduce the size of the distribution [2]. Please take a look at the action item below and let us know if such work can be achieved to assist in reducing the distribution size. We are tracking this task on the Google Tracking Spreadsheet [3].

Action Item: alto and tsdr can agree on a common version of jetty

Best Regards,
An Ho

[1] https://lists.opendaylight.org/pipermail/release/2016-August/007584.html
[2] https://lists.opendaylight.org/pipermail/release/2016-July/007248.html
[3] https://docs.google.com/spreadsheets/d/1zImtd764e-hOgJAxoJKl85fxHCPu2agLfqsBtf13zQY/edit#gid=1408329875


Re: [alto-design] alto-fcimap feature request

Gao Kai
 

I agree, but to proceed we need to have someone investigate the related documents, especially how to gather the informationAlso, do we need to set up some CDN or contact existing CDN providers to do testing and evaluation?

On 01/08/16 13:07, Jensen Zhang wrote:

I think it is a good idea. I will discuss with alto-dev group and try to add this feature into the release plan of OpenDaylight Carbon.

@Kai: what do you think about?

Best,
Jensen

On Sat, Jul 30, 2016 at 5:55 AM, Y. Richard Yang <yry@...> wrote:
Hi all,

One outcome of this IETF is that ALTO introduces the footprint and capability interface (fci) map, to support the CDNi use case. I feel that this is an important use case and hence may I request that we add this in the next release?

Thank you!

Richard 
--
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/285719065.8262966.1469829327985.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.



Re: [alto-design] alto-fcimap feature request

Jensen Zhang
 

I think it is a good idea. I will discuss with alto-dev group and try to add this feature into the release plan of OpenDaylight Carbon.

@Kai: what do you think about?

Best,
Jensen

On Sat, Jul 30, 2016 at 5:55 AM, Y. Richard Yang <yry@...> wrote:
Hi all,

One outcome of this IETF is that ALTO introduces the footprint and capability interface (fci) map, to support the CDNi use case. I feel that this is an important use case and hence may I request that we add this in the next release?

Thank you!

Richard 

--
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/285719065.8262966.1469829327985.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.


Re: Alto merge job failing

Jensen Zhang
 

Okay. Thank you very much!

Jensen

On Mon, Aug 1, 2016 at 12:12 PM, Thanh Ha <thanh.ha@...> wrote:
Looks like an Intermittent issue. I just ran a remerge and it passed.


In the future if you see a connection refused to Nexus it's probably intermittent so just leave a comment in Gerrit that simply says "remerge" and Jenkins will retrigger the build.

Thanh


On Sun, Jul 31, 2016 at 11:08 PM, Jensen Zhang <jingxuan.n.zhang@...> wrote:
Hi Thanh,

Thanks for your help. It is indeed a missing license header issue. I think this should fix it:

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

But when we try to merge this patch, the merge job failed with "Connection refused" errors. I have no idea about how to fix it. Could you please take a look?

https://jenkins.opendaylight.org/releng/job/alto-merge-boron/49/console

Thanks,
Jensen

On Mon, Aug 1, 2016 at 10:12 AM, Thanh Ha <thanh.ha@...> wrote:
Looks like a file is missing license headers. This should fix it:

https://git.opendaylight.org/gerrit/42870

Regards,
Thanh


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





Re: Alto merge job failing

Thanh Ha <thanh.ha@...>
 

Looks like an Intermittent issue. I just ran a remerge and it passed.


In the future if you see a connection refused to Nexus it's probably intermittent so just leave a comment in Gerrit that simply says "remerge" and Jenkins will retrigger the build.

Thanh

On Sun, Jul 31, 2016 at 11:08 PM, Jensen Zhang <jingxuan.n.zhang@...> wrote:
Hi Thanh,

Thanks for your help. It is indeed a missing license header issue. I think this should fix it:

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

But when we try to merge this patch, the merge job failed with "Connection refused" errors. I have no idea about how to fix it. Could you please take a look?

https://jenkins.opendaylight.org/releng/job/alto-merge-boron/49/console

Thanks,
Jensen

On Mon, Aug 1, 2016 at 10:12 AM, Thanh Ha <thanh.ha@...> wrote:
Looks like a file is missing license headers. This should fix it:

https://git.opendaylight.org/gerrit/42870

Regards,
Thanh


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




Re: Alto merge job failing

Jensen Zhang
 

Hi Thanh,

Thanks for your help. It is indeed a missing license header issue. I think this should fix it:

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

But when we try to merge this patch, the merge job failed with "Connection refused" errors. I have no idea about how to fix it. Could you please take a look?

https://jenkins.opendaylight.org/releng/job/alto-merge-boron/49/console

Thanks,
Jensen

On Mon, Aug 1, 2016 at 10:12 AM, Thanh Ha <thanh.ha@...> wrote:
Looks like a file is missing license headers. This should fix it:

https://git.opendaylight.org/gerrit/42870

Regards,
Thanh


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



Re: Alto merge job failing

Thanh Ha <thanh.ha@...>
 

Looks like a file is missing license headers. This should fix it:

https://git.opendaylight.org/gerrit/42870

Regards,
Thanh


Alto merge job failing

Luis Gomez <ecelgp@...>
 

Hi alto devs,

Your merge job started to fail recently [1]. Please address the issue before it hits the integration distribution.

BR/Luis

[1] https://jenkins.opendaylight.org/releng/view/Merge-Boron/job/alto-merge-boron/


Re: [release] [OpenDaylight TSC] committing to an outline of a Carbon release plan

Gao Kai <gaok12@...>
 

FYI


-------- Forwarded Message --------
Subject: Re: [release] [OpenDaylight TSC] committing to an outline of a Carbon release plan
Date: Thu, 28 Jul 2016 16:36:55 -0400
From: Nadeau Thomas <tnadeau@...>
To: Colin Dixon <colin@...>
CC: tsc@... <tsc@...>, Release <release@...>



For this to be successful, I think we need to hear from each of the project PTLs (at least the core projects) to agree to commit to this.

—Tom

On Jul 28, 2016:4:30 PM, at 4:30 PM, Colin Dixon <colin@...> wrote:

During the TSC meeting, some of you asked why we didn't have a 6 month cadence and if we could get to one. I did my best to answer that on another thread here:
https://lists.opendaylight.org/pipermail/tsc/2016-July/005665.html

Generally, given that we're talking about rearranging *everything* in releases after Carbon, my take is that trying to align ourselves to 6 months now is probably more pain that it's worth. That being said, I'm open to other views if it really helps things.

--Colin


On Thu, Jul 28, 2016 at 12:47 PM, Colin Dixon <colin@...> wrote:
Also, no, I just missed skipped #2 by accident.

--Colin


On Thu, Jul 28, 2016 at 12:46 PM, Colin Dixon <colin@...> wrote:
I think that doing #1 internally while still externally following the traditional M0-M5, six-month release is not only doable, but will be essential if we want to actually get to the end of Carbon with some idea of if any of this works or not.

--Colin


On Thu, Jul 28, 2016 at 12:31 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Fair point on #3. Was there a #2?

About #1 - an internal cycle by the individual downstream projects will likely not happen if its not a coordinated experiment with the participation by all the projects - as the projects will still need to proceed/develop as per the traditional Carbon schedule. Since that is likely to be the case - it might be better to have the Carbon release as per the traditional schedule.

On Thu, Jul 28, 2016 at 6:44 AM, Colin Dixon <colin@...> wrote:
A few quick notes:

1.) I think most of the hard/interest parts of a fast/phased release come in not just int he first 2-month cycle, but as that 2-month cycle cascades downstream into the next cycle and so on. A way to split the difference would be to have (some of) the offset 0 projects try a faster release cadence and/or semantic versioning with downstream projects relying on version range instead of a fixed SNAPSHOT version. They could have 2-month internal cycles as long as the APIs others were relying on were frozen and code-frozen in line with the 6-month release.

3.) I think we agreed that the TSC terms would end at the end of the Boron cycle, so it would take another vote (of the board) to change that.

Cheers,
--Colin


On Thu, Jul 28, 2016 at 1:56 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
One possibility that I had mentioned in the TSC meeting:

A small two-month bubble trial release (Oct-Nov) to explore the feasibility of a fast paced/staged release. If it works - we have a new fast paced staged release paradigm. If it does not work then the only bad side effect is that the release cycle got shifted by 2 months - and we will also have learned something. Based on the learning/experience we can then arrive at a decision that we will stick to the regular 6 month cycles for the foreseeable future (next few releases).  
Otherwise we will likely be at the same spot regarding the fast paced / staged release idea as we were at the beginning of Boron - i.e. the fast paced/staged idea being pushed to the next release.

The side-effect advantage of this will be that the TSC terms of the CAL members will be nearly restored to be on the calendar year boundaries with a November election to start the term of the new TSC just after this trial 2 month release. This also gets the time to get the mechanics of the new TSC membership sorted out in the DDF at the ODL Summit - as well as time for getting more projects to become mature, etc.

On Wed, Jul 27, 2016 at 11:14 AM, Daniel Farrell <dfarrell@...> wrote:
Colin's consensus summery sounds good to me.

+1 to Boron-like plan for Carbon. I think it's too late to build
understanding and momentum around something drastically different,
especially among less-active projects.

I'd love to see us use the ODL Dev Design Forum at Summit to put
a concrete pilot/test/plan in place, to run during Carbon and serve
as training/testing for adoption in Nitrogen.

Can we #action someone deeply involved to propose a DDF talk?

https://wiki.opendaylight.org/view/Events:Carbon_Dev_Forum#Topics

Thanks all,

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

----- Original Message -----
> I just wanted to bump this for any feedback before the TSC meeting on
> Thursday.
>
> --Colin
>
>
> On Thu, Jul 21, 2016 at 12:35 PM, Colin Dixon <colin@...> wrote:
>
> > During the debate leading to the approval of the Boron release plan, we
> > agreed that we would try have a concrete release plan ready by M2 to start
> > discussion [0]. However, despite repeated attempts [1,2,3] to spark a
> > discussion, it has been muted.
> >
> > During last week's TSC call [4], the consensus on the call was that
> > realistically, we did not have the time or cycles to invest in the tooling
> > required to do a Carbon release in a fast and/or phased way and have it
> > start anytime soon after Boron.
> >
> > Instead, the consensus seemed to be moving toward having a normal,
> > 5-milestone, 6-month Carbon release, but with more concrete details about
> > how we might actually make progress with tools and experience to enable
> > future releases to realistically consider different approaches. People
> > stated they'd really like to see those baked into release plans (both for
> > the whole simultaneous release and projects) so that they don't fall by the
> > wayside.
> >
> > On the other side, we have the need to provide some clarity to
> > projects—especially new projects as well as offset 1 and 2 projects, which
> > tend to follow discussions like this less closely—about what to expect from
> > a Carbon release.
> >
> > Along those lines, we agreed to set down "basic outline of the main Carbon
> > release, e.g., approx length and milestones w/approx dates" by 7/28.
> >
> > There's a draft version of a Carbon Release Plan that's just a the Boron
> > Release Plan with updated dates here:
> > https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan
> >
> > The basic sketch of dates is:
> >         offset 0        offset 1        offset 2
> > M0      9/22/2016 (2 weeks after Boron Release)
> > proj
> > prop du 10/6/2016       10/13/2016      10/20/2016
> > M1      10/20/2016      10/27/2016      11/3/2016
> > M2      11/17/2016      12/1/2016       12/8/2016
> >            shift dates after 11/24 by 1 week b/c Thanksgiving
> > M3      12/22/2016      1/19/2017       2/2/2017
> >            shift dates after 12/25 by 2 more weeks b/c
> >            Christmas and New Years
> > M4      2/2/2017        2/16/2017       3/2/2017
> > M5      3/2/2017        3/16/2017       3/30/2017
> > RC0     4/13/2017
> > RC1     4/20/2017
> > RC2     4/27/2017
> > RC3     5/4/2017
> > Release 5/11/2017 (8 months after Boron)
> > SR1     6/22/2017
> > SR2     8/10/2017 (shifted by 1 more week because of July 4th)
> > SR3     11/2/2017
> > SR4     2/15/2018 (shifted by 3 more weeks b/c of Thanksgiving,
> >                    Christmas and New Years)
> >
> > Cheers,
> > --Colin
> >
> > [0]
> > https://meetings.opendaylight.org/opendaylight-meeting/2016/tsc/opendaylight-meeting-tsc.2016-03-03-18.00.html
> > bullet 10.aq
> > [1] https://lists.opendaylight.org/pipermail/tsc/2016-May/005206.html
> > [2] https://lists.opendaylight.org/pipermail/tsc/2016-June/005428.html
> > [3] https://lists.opendaylight.org/pipermail/tsc/2016-July/005536.html
> > [4]
> > https://meetings.opendaylight.org/opendaylight-meeting/2016/tsc/opendaylight-meeting-tsc.2016-07-14-17.00.html
> > bullet 9
> >
>
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release






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




alto-fcimap feature request

Y. Richard Yang
 

Hi all,

One outcome of this IETF is that ALTO introduces the footprint and capability interface (fci) map, to support the CDNi use case. I feel that this is an important use case and hence may I request that we add this in the next release?

Thank you!

Richard 


Getting errors in ALTO feature.

Asjad Sohail <asjadsohail@...>
 

When using maven to resolve the dependencies of Application Layer Traffic Optimization in eclipse oomph after its installation through its installer I'm getting errors of tool-1.7.0.jar not found. I'm stuck in this problem for about a month now and can't solve it.

My FYP is optimizing big data processing using SDN. I also want to know if there are other ways to optimize big data processing through Opendaylight when the nodes of hadoop environment are on different systems. I really need help in this.

Regards,
Asjad


Re: [release] Distribution size issue

Gao Kai <gaok12@...>
 

Jensen, can you take a look at this?

You can download tsdr and use dependency:tree to see what jetty version we/they are using.

Ours is 8.1.19.  Haven't been able to see theirs at the moment.


-------- Forwarded Message --------
Subject: Re: [release] Distribution size issue
Date: Wed, 13 Jul 2016 18:32:23 +0200
From: Robert Varga <nite@...>
To: Luis Gomez <ecelgp@...>, Release (release@...) <release@...>


On 07/12/2016 05:23 AM, Luis Gomez wrote:
> Is there anything we can do to address this?

So I do not know what caused the growth, but looking at output of:

user@work : ~/odl/distribution/distribution-karaf on master $ mvn
dependency:tree

the distribution is one sorry mess, and it is not just one project. What
we can do are actually multiple things:

1) snmp4sdn can stop pulling in AD-SAL components from previous
releases, two versions of Spring Framework plus the entire pre-karaf
container

2) lispflowmapping would do some good if it did not pull jmock via its
unittest-tools

3) nemo could use a more modern version of netty than 3.2.6

4) alto and tsdr can agree on a common version of jetty

5) capwap can start using odl-netty instead of requiring netty-all

6) usc can stop pulling in akka-testkit

7) gbp can stop pulling in long-dead controller's third-party jersey

8) sfc could take a look if they really need jersey containers for their
sfc-vnfm-tracker

9) tsdr can try to not pull the 13MiB jruby-all for hbase client

These are relatively simple and would go a long way towards reducing the
distro.

Bye,
Robert





Re: [Action Needed] Upgrade ietf-{inet,yang}-types

Gao Kai <gaok12@...>
 

An Ho,

Copy that.

Thanks!

Regards,
Kai

On 12/07/16 01:55, An Ho wrote:

Hi ALTO Team,

 

There are plans to upgrade ietf-inet-types@2010-09-24 and ietf-yang-types@2010-09-24 (RFC 6021) to ietf-inet-types-2013-07-15 and ietf-yang-types@2013-07-15 (RFC 6991) in the Boron release [1], and a patch has been generated to address the impacts to your project.  Please take a moment to +2 but DO NOT MERGE the following patch:

 

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

 

Best Regards,

An Ho

 

[1] https://wiki.opendaylight.org/view/Weather#Upgrade_ietf-.7Binet.2Cyang.7D-types_to_2013-07-15

 

 

 

 



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


[Action Needed] Upgrade ietf-{inet,yang}-types

an.ho@huawei.com
 

Hi ALTO Team,

 

There are plans to upgrade ietf-inet-types@2010-09-24 and ietf-yang-types@2010-09-24 (RFC 6021) to ietf-inet-types-2013-07-15 and ietf-yang-types@2013-07-15 (RFC 6991) in the Boron release [1], and a patch has been generated to address the impacts to your project.  Please take a moment to +2 but DO NOT MERGE the following patch:

 

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

 

Best Regards,

An Ho

 

[1] https://wiki.opendaylight.org/view/Weather#Upgrade_ietf-.7Binet.2Cyang.7D-types_to_2013-07-15

 

 

 

 


Re: [release] considering documentation migration to ReStructuredText/Sphinx from AsciiDoc/Asciidoctor

Gao Kai <gaok12@...>
 

Jensen, Xiao and other folks,

Please see the e-mail and prepare for migrations ahead of time.

Thanks!


-------- Forwarded Message --------
Subject: Re: [release] considering documentation migration to ReStructuredText/Sphinx from AsciiDoc/Asciidoctor
Date: Thu, 7 Jul 2016 11:32:11 -0400
From: Alexis de Talhouët <adetalhouet@...>
To: Colin Dixon <colin@...>
CC: release@... <release@...>, ODL Docs <documentation@...>


Awesome, great look and feel! Thanks Colin, Thanh and all the others involved in this migration.

Thanks,
Alexis

On Jul 7, 2016, at 9:38 AM, Colin Dixon <colin@...> wrote:

For what it's worth, thanks to Thanh, we've been able to get the migrated documentation showing up here:
http://docs.opendaylight.org/

--Colin


On Thu, Jun 23, 2016 at 12:05 PM, Colin Dixon <colin@...> wrote:
I think many of you may have heard that the documentation team has been experimenting with migrating toolchains to address complaints people have had—especially that we don't produce good HTML-formatted documentation.

For that and a few other reasons, we've been looking into moving from the current system we used with a custom maven plugin that then invokes Asciidoctor [0] to build AsciiDoc in favor of using Sphinx [2] to build ReStructuredText [3], which is the standard adopted for the documentation of most Python projects.

As a proof-of-concept, we've migrated the Beryllium-revised getting started guide [4], OpenDaylight and OpenStack guide [5] and infrastructure guide [6] into the new toolchain [7] and gotten it so it publishes automatically on every merge to read the docs [8]. There are outstanding patches [9] to migrate the older Getting Started Guide content into this toolchain as well.

The new toolchain also offers nice features like the ability to automatically allow people to switch between different versions of the documentation for different releases, automatically provide warnings when looking at documentation corresponding to outdated release and the like.

Also, the infrastructure guide [6] is already a working example of including documentation from another project thus allowing for projects to host their own documentation files in their repository if they would like.

With this experience, we're hoping to write some short tutorials about migrating documentation from AsciiDoc to ReStructuredText (it's been pretty easy) and talk about maybe migrating the bulk of the documentation as part of the Carbon release unless there's such overwhelming support that we feel like we should push to migrate everything in Boron.

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




Re: [release] Boron autorelease fails: alto, l2switch, blueprint

Gao Kai
 

Thanh,

I've contacted the committers to accept the patch.  It should be done within minutes.  Sorry for the trouble.

Regards,
Kai

On 06/07/16 22:08, Thanh Ha wrote:

What's the plan here? the alto patch is still unapplied and boron still broken.

Regards,
Thanh

On 4 July 2016 at 12:19, Gao Kai <gaok12@...> wrote:
Vratko,

The current patch might do now, at least for BoronCurrently we can work around it but in the long run we may still need to enable reactive routingActually we don't care much about ARP packets so it's OK to flood them.  But if I'm not mistaken when that option is enabled, l2switch will flood other packets as well (see [1]).

It will be great to know how we can change the options automatically, so we may disable flooding when our module is installed and re-enable it when removed.

Thanks!

Regards,
Kai

[1] https://github.com/opendaylight/l2switch/blob/fc88da4024fa83b440b4176f90d88b077052c20d/arphandler/src/main/java/org/opendaylight/l2switch/arphandler/core/ProactiveFloodFlowWriter.java

On 04/07/16 23:29, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) wrote:

L2switch has been converted to blueprint [0],

so *-config artifacts are no longer defined.

Alto was depending on them.

Possible fix for the autorelease build: [1].

 

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

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

Is there a way for downstream feature

to override the default value [3]?

 

Vratko.

 

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

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

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

 



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


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




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

141 - 160 of 542