Date   

Re: Decommision Ubuntu 16.04 images on ODL Jenkins and update to Ubuntu 18.04 images on releng/builder repo.

Anil Belur
 

Hello Luis: 

That was cut and paste typo, the correct label should have been.

"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-25-1c-4g)

We only have Ubuntu 18.04 images for 'mininet-ovs-25', while 'mininet-ovs-26' and 'mininet-ovs-28' images fails to build the binaries.

With mininet-ovs-28 build, throws make errors while building binaries:


03:01:06     openstack: STDERR:
03:01:06     openstack:
03:01:06     openstack: configure.ac:24: installing 'build-aux/compile'
03:01:06     openstack: configure.ac:22: installing 'build-aux/missing'
03:01:06     openstack: Makefile.am: installing 'build-aux/depcomp'
03:01:06     openstack: configure: WARNING: unrecognized options: --disable-maintainer-mode
03:01:06     openstack: configure: WARNING: cannot find libcap-ng.
03:01:06     openstack: --user option will not be supported on Linux.
03:01:06     openstack: (you may use --disable-libcapng to suppress this warning).
03:01:06     openstack: configure: WARNING: unrecognized options: --disable-maintainer-mode
03:01:06     openstack: lib/dhparams.c:2:12: error: static declaration of ‘get_dh1024’ follows non-static declaration
03:01:06     openstack:  static DH *get_dh1024(void)

Cheers,
Anil


On Mon, Mar 29, 2021 at 6:26 AM Luis Gomez <ecelgp@...> wrote:
Sorry this is confusing:

- Are all the mininet VMs converging to this one?

"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-28-1c-4g)

- If so, why it says ovs-25 in the name but ovs-28 in the label?

BR/Luis


On Mar 27, 2021, at 5:59 PM, Anil Belur <abelur@...> wrote:

Please review CR to remove Ubuntu 16.04 packer jobs:


Cheers,
Anil

On Fri, Mar 26, 2021 at 11:51 AM Anil Belur via lists.opendaylight.org <abelur=linuxfoundation.org@...> wrote:
Hello all,

Ubuntu 16.04 is going to be EOL by April 2021 and these images would no longer be supported on our infrastructure to receive updates/new builds. The version of python 2.7 that is available on Ubuntu 16.04 is already EOL and does not works with some of the tox/verify jobs. Therefore, it's required to update existing jobs to use the Ubuntu 18.04 image and decommission Ubuntu 16.04 images.

The below Ubuntu 16.04 images are in use in the releng/builder repo CSIT jobs:
"ZZCI - Ubuntu 16.04 - mininet-ovs-25 - x86_64 - 20200813-044931.688" (Label: ubuntu1604-mininet-ovs-25-1c-4g)
"ZZCI - Ubuntu 16.04 - mininet-ovs-28 - x86_64 - 20200813-051640.743" (Label: ubuntu1604-mininet-ovs-28-1c-4g)

Which needs to be updated to:
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-4c-4g)
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-2c-2g)
"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-28-1c-4g)

Note: To test the CSIT jobs with the Ubuntu 18.04 images, update the image labels on the JJB/project before pushing the job to ODL Jenkins sandbox. 


Regards,
Anil Belur





Re: Decommision Ubuntu 16.04 images on ODL Jenkins and update to Ubuntu 18.04 images on releng/builder repo.

Luis Gomez
 

Sorry this is confusing:

- Are all the mininet VMs converging to this one?

"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-28-1c-4g)

- If so, why it says ovs-25 in the name but ovs-28 in the label?

BR/Luis


On Mar 27, 2021, at 5:59 PM, Anil Belur <abelur@...> wrote:

Please review CR to remove Ubuntu 16.04 packer jobs:


Cheers,
Anil

On Fri, Mar 26, 2021 at 11:51 AM Anil Belur via lists.opendaylight.org <abelur=linuxfoundation.org@...> wrote:
Hello all,

Ubuntu 16.04 is going to be EOL by April 2021 and these images would no longer be supported on our infrastructure to receive updates/new builds. The version of python 2.7 that is available on Ubuntu 16.04 is already EOL and does not works with some of the tox/verify jobs. Therefore, it's required to update existing jobs to use the Ubuntu 18.04 image and decommission Ubuntu 16.04 images.

The below Ubuntu 16.04 images are in use in the releng/builder repo CSIT jobs:
"ZZCI - Ubuntu 16.04 - mininet-ovs-25 - x86_64 - 20200813-044931.688" (Label: ubuntu1604-mininet-ovs-25-1c-4g)
"ZZCI - Ubuntu 16.04 - mininet-ovs-28 - x86_64 - 20200813-051640.743" (Label: ubuntu1604-mininet-ovs-28-1c-4g)

Which needs to be updated to:
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-4c-4g)
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-2c-2g)
"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-28-1c-4g)

Note: To test the CSIT jobs with the Ubuntu 18.04 images, update the image labels on the JJB/project before pushing the job to ODL Jenkins sandbox. 


Regards,
Anil Belur





Re: Decommision Ubuntu 16.04 images on ODL Jenkins and update to Ubuntu 18.04 images on releng/builder repo.

Anil Belur
 

Please review CR to remove Ubuntu 16.04 packer jobs:


Cheers,
Anil

On Fri, Mar 26, 2021 at 11:51 AM Anil Belur via lists.opendaylight.org <abelur=linuxfoundation.org@...> wrote:

Hello all,

Ubuntu 16.04 is going to be EOL by April 2021 and these images would no longer be supported on our infrastructure to receive updates/new builds. The version of python 2.7 that is available on Ubuntu 16.04 is already EOL and does not works with some of the tox/verify jobs. Therefore, it's required to update existing jobs to use the Ubuntu 18.04 image and decommission Ubuntu 16.04 images.

The below Ubuntu 16.04 images are in use in the releng/builder repo CSIT jobs:
"ZZCI - Ubuntu 16.04 - mininet-ovs-25 - x86_64 - 20200813-044931.688" (Label: ubuntu1604-mininet-ovs-25-1c-4g)
"ZZCI - Ubuntu 16.04 - mininet-ovs-28 - x86_64 - 20200813-051640.743" (Label: ubuntu1604-mininet-ovs-28-1c-4g)

Which needs to be updated to:
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-4c-4g)
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-2c-2g)
"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-28-1c-4g)

Note: To test the CSIT jobs with the Ubuntu 18.04 images, update the image labels on the JJB/project before pushing the job to ODL Jenkins sandbox. 


Regards,
Anil Belur




[OpenDaylight TSC] $PROJECT Termination review (based on inactivity)

Anil Belur
 

Hello TSC team:

As per section TSC Charter 2.3.5 [1.], the TSC is initiating a termination review for lack of activity (no commits in the last 18 months).

The list of ODL $PROJECT's that are candidates for archival, with the commit date for the last commit.
1. usc:
Total 3674 (delta 0), reused 3674 (delta 0)
* master - 56eca9d - Merge "Remove obsolete Maven Site configuration" - A H (2 years, 11 months ago)
2. packetcable:
* master - 71996a6 - Bump to odlparent 3.1.0 and yangtools 2.0.3 - Stephen Kitt (3 years ago)
3. opflex:
* master - 46b19e9 - Fix issues with config directory watching - Rob Adams (3 years, 1 month ago)

Once the review is approved by the TSC:
1. All jobs for the $PROJECT would be purged from Jenkins releng/builder repo.
2. The $PROJECT will be set to an inactive state on Gerrit.
3. The $PROJECT will be renamed/prefixed as "archived-$PROJECT" on Github/Gerrit.  

Please add if I missed any projects, refer to the logs attached. 

[1.] https://www.opendaylight.org/about/lifecycle-releases

Regards,
Anil


Re: Decommision Ubuntu 16.04 images on ODL Jenkins and update to Ubuntu 18.04 images on releng/builder repo.

Anil Belur
 

Hello all,

Ubuntu 16.04 is going to be EOL by April 2021 and these images would no longer be supported on our infrastructure to receive updates/new builds. The version of python 2.7 that is available on Ubuntu 16.04 is already EOL and does not works with some of the tox/verify jobs. Therefore, it's required to update existing jobs to use the Ubuntu 18.04 image and decommission Ubuntu 16.04 images.

The below Ubuntu 16.04 images are in use in the releng/builder repo CSIT jobs:
"ZZCI - Ubuntu 16.04 - mininet-ovs-25 - x86_64 - 20200813-044931.688" (Label: ubuntu1604-mininet-ovs-25-1c-4g)
"ZZCI - Ubuntu 16.04 - mininet-ovs-28 - x86_64 - 20200813-051640.743" (Label: ubuntu1604-mininet-ovs-28-1c-4g)

Which needs to be updated to:
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-4c-4g)
"ZZCI - Ubuntu 18.04 - docker - x86_64 - 20200901-040308.994" (Label: ubuntu1804-docker-2c-2g)
"ZZCI - Ubuntu 18.04 - mininet-ovs-25 - x86_64 - 20200813-035525.790" (Label: ubuntu1804-mininet-ovs-28-1c-4g)

Note: To test the CSIT jobs with the Ubuntu 18.04 images, update the image labels on the JJB/project before pushing the job to ODL Jenkins sandbox. 


Regards,
Anil Belur


Re: global-jjb vs. packer vs. Jenkins jobs

Anil Belur
 

Greetings Robert:

We'll need to pin the cryptography module < 3.4 since rust dependencies are broken upstream pyca repo.

This issue should be addressed once this is merged. 

Cheers,
Anil

On Mon, Feb 8, 2021 at 6:58 AM Robert Varga <nite@...> wrote:
On 05/02/2021 10:16, Robert Varga wrote:
> On 03/02/2021 00:03, Anil Belur wrote:
>> Greetings Robert:
>
> Hello Anil,

Hello again,

sorry, for self-reply, but as it happens ...

[snip]

>> 2. All releng/global-jjb (templates) scripts do not require all of the
>> PyPi dependencies to be installed and are tied down to the $job or
>> $project, since this approach binding them all into the same env has a
>> risk of the deps being broken more frequently.
>> 3. PyPi libs/modules are updated more frequently.
>
> While that is true, this line of reasoning completely ignores the
> failure mode and recovery.
>
> As it stands any of:
> - busted global-jjb
> - PyPi package updates
> - PyPi repository unavailability
>
> As we have seen in these past weeks, any such failure immediately
> propagates to all jobs and breaks them -- resulting in nothing working
> anymore, with no real avenue for recovery without help of LF IT.

... we just got hit by this.

[snip]

>
> I am sorry, but I fail to see how Python packages special enough to inflict:
> - breakages occurring at completely random times

A case in point:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/yangtools-maven-verify-master-mvn35-openjdk11/3761/console.log.gz
just failed with:

> [yangtools-maven-verify-master-mvn35-openjdk11] $ /bin/bash /tmp/jenkins2774821607907773560.sh
> ---> python-tools-install.sh
> Generating Requirements File
>   ERROR: Command errored out with exit status 1:
>    command: /usr/bin/python3 /home/jenkins/.local/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /tmp/tmpyskb3tqv
>        cwd: /tmp/pip-install-ibprnn2v/cryptography_c4b114d9e7a14d488215cb74c3a04315
>   Complete output (144 lines):

[...]

>   writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
>   running build_ext
>   generating cffi module 'build/temp.linux-x86_64-3.6/_padding.c'
>   creating build/temp.linux-x86_64-3.6
>   generating cffi module 'build/temp.linux-x86_64-3.6/_openssl.c'
>   running build_rust
>   
>       =============================DEBUG ASSISTANCE=============================
>       If you are seeing a compilation error please try the following steps to
>       successfully install cryptography:
>       1) Upgrade to the latest pip and try again. This will fix errors for most
>          users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
>       2) Read https://cryptography.io/en/latest/installation.html for specific
>          instructions for your platform.
>       3) Check our frequently asked questions for more information:
>          https://cryptography.io/en/latest/faq.html
>       4) Ensure you have a recent Rust toolchain installed.
>       =============================DEBUG ASSISTANCE=============================
>   
>   error: Can not find Rust compiler
>   ----------------------------------------
>   ERROR: Failed building wheel for cryptography
> ERROR: Could not build wheels for cryptography which use PEP 517 and cannot be installed directly
> Build step 'Execute shell' marked build as failure

python-tools-install.sh comes from global-jjb. This means jobs are
currently broken because of global-jjb stopped working.

I have filed
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21509
and we are blocked on it. Let's see what sort KPIs that issue will have.

Bye,
Robert


Re: [releng][TSC] stable/silicon branch cut, master moved to next

Anil Belur
 



On Tue, Feb 23, 2021 at 11:37 AM Anil Belur <abelur@...> wrote:
Hello Everyone,

Sharing an update on the branch cutting today. The version bump and is complete and the master branch is moved to the next release (phosphorus) and open for development. 
The stable/silicon branch is cut presently locked on code freeze as requested.

I'm still working on the JJB (releng/builder), to update the jobs on Jenkins to update the branches "stable/silicon", will update here one the changes are ready for review. 

The below CR on the releng/builder repository would create new jobs for "stable/silicon" branch on Jenkins.


Cheers,
Anil  


[releng][TSC] stable/silicon branch cut, master moved to next

Anil Belur
 

Hello Everyone,

Sharing an update on the branch cutting today. The version bump and is complete and the master branch is moved to the next release (phosphorus) and open for development. 
The stable/silicon branch is cut presently locked on code freeze as requested.

I'm still working on the JJB (releng/builder), to update the jobs on Jenkins to update the branches "stable/silicon", will update here one the changes are ready for review. 

Note: A reminder for projects to rebase their existing master branch patches to ensure they are building against the post version bumped versions of code base.

Regards,
Anil


Re: global-jjb vs. packer vs. Jenkins jobs

Robert Varga
 

On 05/02/2021 10:16, Robert Varga wrote:
On 03/02/2021 00:03, Anil Belur wrote:
Greetings Robert:
Hello Anil,
Hello again,

sorry, for self-reply, but as it happens ...

[snip]

2. All releng/global-jjb (templates) scripts do not require all of the
PyPi dependencies to be installed and are tied down to the $job or
$project, since this approach binding them all into the same env has a
risk of the deps being broken more frequently.
3. PyPi libs/modules are updated more frequently.
While that is true, this line of reasoning completely ignores the
failure mode and recovery.

As it stands any of:
- busted global-jjb
- PyPi package updates
- PyPi repository unavailability

As we have seen in these past weeks, any such failure immediately
propagates to all jobs and breaks them -- resulting in nothing working
anymore, with no real avenue for recovery without help of LF IT.
... we just got hit by this.

[snip]


I am sorry, but I fail to see how Python packages special enough to inflict:
- breakages occurring at completely random times
A case in point:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/yangtools-maven-verify-master-mvn35-openjdk11/3761/console.log.gz
just failed with:

[yangtools-maven-verify-master-mvn35-openjdk11] $ /bin/bash /tmp/jenkins2774821607907773560.sh
---> python-tools-install.sh
Generating Requirements File
ERROR: Command errored out with exit status 1:
command: /usr/bin/python3 /home/jenkins/.local/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /tmp/tmpyskb3tqv
cwd: /tmp/pip-install-ibprnn2v/cryptography_c4b114d9e7a14d488215cb74c3a04315
Complete output (144 lines):
[...]

writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
running build_ext
generating cffi module 'build/temp.linux-x86_64-3.6/_padding.c'
creating build/temp.linux-x86_64-3.6
generating cffi module 'build/temp.linux-x86_64-3.6/_openssl.c'
running build_rust

=============================DEBUG ASSISTANCE=============================
If you are seeing a compilation error please try the following steps to
successfully install cryptography:
1) Upgrade to the latest pip and try again. This will fix errors for most
users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
2) Read https://cryptography.io/en/latest/installation.html for specific
instructions for your platform.
3) Check our frequently asked questions for more information:
https://cryptography.io/en/latest/faq.html
4) Ensure you have a recent Rust toolchain installed.
=============================DEBUG ASSISTANCE=============================

error: Can not find Rust compiler
----------------------------------------
ERROR: Failed building wheel for cryptography
ERROR: Could not build wheels for cryptography which use PEP 517 and cannot be installed directly
Build step 'Execute shell' marked build as failure
python-tools-install.sh comes from global-jjb. This means jobs are
currently broken because of global-jjb stopped working.

I have filed
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21509
and we are blocked on it. Let's see what sort KPIs that issue will have.

Bye,
Robert


Re: [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

Daniel de la Rosa
 

Ok :) So i can start with Aluminium SR3 ahead of schedule, if that's what's needed here... 

On Tue, Feb 2, 2021 at 1:11 PM Robert Varga <nite@...> wrote:
We are not.

We are picking candidates for SR3 -- and
https://jenkins.opendaylight.org/releng/job/autorelease-release-aluminium-mvn35-openjdk11/360/
is good as any :)

Regards,
Robert

On 02/02/2021 15:58, Daniel de la Rosa wrote:
> Thanks Luis. So we are not updating the downloads page for Aluminium SR2
> right? we have release notes though
>
> On Thu, Jan 28, 2021 at 9:40 PM Luis Gomez <ecelgp@...
> <mailto:ecelgp@...>> wrote:
>
>     OK, although we are not going to officially release Aluminium SR2, I
>     went ahead and released the distribution for completeness and also
>     in case someone wants to use this release for testing purposes: 
>
>     https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/opendaylight/0.13.2/
>     <https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/opendaylight/0.13.2/>
>
>     BR/Luis
>
>
>>     On Jan 28, 2021, at 2:37 PM, <guillaume.lambert@...
>>     <mailto:guillaume.lambert@...>>
>>     <guillaume.lambert@...
>>     <mailto:guillaume.lambert@...>> wrote:
>>
>>     I  agree with the suggestion to skip Al SR2.____
>>     __ __
>>     Best Regards____
>>     Guillaume____
>>     __ __
>>     *De :* Luis Gomez [mailto:ecelgp@... <mailto:ecelgp@...>] 
>>     *Envoyé :* jeudi 28 janvier 2021 22:11
>>     *À :* Venkatrangan Govindarajan
>>     *Cc :* Daniel de la Rosa; Oleksii Mozghovyi; THOUENON Gilles
>>     TGI/OLN; integration-dev@...
>>     <mailto:integration-dev@...>; Anil Belur; Casey
>>     Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert
>>     Varga; TSC; Transportpce-dev@...
>>     <mailto:Transportpce-dev@...>
>>     *Objet :* Re: [integration-dev] [OpenDaylight TSC]
>>     [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release
>>     status____
>>     __ __
>>     Well, since the odl-restconf feature includes both draft and
>>     RFC8040 API, I believe this bug is effectively a security hole
>>     with a non trivial workaround even for the draft users (e.g.
>>     repack the restconf feature to skip RFC8040).____
>>     __ __
>>     So my suggest is to skip Aluminium SR2 official release. Other TSC
>>     (or not TSC) opinions?____
>>     __ __
>>     BR/Luis____
>>
>>
>>     ____
>>     On Jan 28, 2021, at 10:33 AM, Venkatrangan Govindarajan
>>     <gvrangan@... <mailto:gvrangan@...>> wrote:____
>>     __ __
>>     The problem occurs if the RFC8040 is used____
>>     __ __
>>     curl http://127.0.0.1:8181/rests/data/network-topology:network-topology
>>     <http://127.0.0.1:8181/rests/data/network-topology:network-topology>  -v
>>     *   Trying 127.0.0.1...
>>     * Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
>>     > GET /rests/data/network-topology:network-topology HTTP/1.1
>>     > Host: 127.0.0.1:8181 <http://127.0.0.1:8181/>
>>     > User-Agent: curl/7.47.0
>>     > Accept: */*
>>     > 
>>     < HTTP/1.1 200 OK
>>     < ETag: "2013-10-21-network-topology"
>>     < Last-Modified: 2021-Jan-28 18:31:25
>>     < Content-Type: application/yang-data+json
>>     < Content-Length: 133
>>     < 
>>     * Connection #0 to host 127.0.0.1 left intact
>>     {"network-topology:net____
>>     __ __
>>     __ __
>>     It does not require authorization. The  issue seems to be
>>     recreated.____
>>     __ __
>>     வியா., 28 ஜன., 2021, பிற்பகல் 11:46 அன்று, Daniel de la Rosa
>>     <ddelarosa0707@...
>>     <mailto:ddelarosa0707@...>> எழுதியது:____
>>
>>         Thanks Oleksii... IMHO, this issue is not a show stopper for
>>         Aluminium SR2 but please confirm____
>>         __ __
>>         On Thu, Jan 28, 2021 at 10:09 AM Oleksii Mozghovyi
>>         <Oleksii.Mozghovyi@...
>>         <mailto:Oleksii.Mozghovyi@...>> wrote:____
>>
>>             __ __
>>             Hello everyone,____
>>             __ __
>>             This issue is related only to the RFC8040 implementation
>>             of the RESTconf, so you have to use a proper endpoint for
>>             the testing, for example:____
>>             http://127.0.0.1:8181/rests/data
>>             <http://127.0.0.1:8181/rests/data>____
>>             __ __
>>             The thing is that {apiRoot}/restconf is managed by a
>>             different web initializer and doesn't have such an issue.____
>>             __ __
>>             ------------------------------------------------------------------------
>>             *From:* release@...
>>             <mailto:release@...> <release@...
>>             <mailto:release@...>> on behalf of
>>             Venkatrangan Govindarajan <gvrangan@...
>>             <mailto:gvrangan@...>>
>>             *Sent:* Thursday, January 28, 2021 8:01:59 PM
>>             *To:* Luis Gomez
>>             *Cc:* Daniel de la Rosa; THOUENON Gilles
>>             TGI/OLN; integration-dev@...
>>             <mailto:integration-dev@...>; Anil
>>             Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume
>>             TGI/OLN; Release; Robert Varga;
>>             TSC; Transportpce-dev@...
>>             <mailto:Transportpce-dev@...>
>>             *Subject:* Re: [integration-dev] [OpenDaylight TSC]
>>             [opendaylight-dev][release] OpenDaylight - Aluminium SR2
>>             release status____
>>              ____
>>             Just downloaded SR2 and installed some project that uses
>>             topology model and executed this...____
>>             __ __
>>             ******************____
>>             curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
>>             <http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> -v
>>             *   Trying 127.0.0.1...
>>             * Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
>>             > GET
>>             /restconf/operational/network-topology:network-topology
>>             HTTP/1.1
>>             > Host: 127.0.0.1:8181 <http://127.0.0.1:8181/>
>>             > User-Agent: curl/7.47.0
>>             > Accept: */*
>>             > 
>>             < HTTP/1.1 401 Unauthorized
>>             < WWW-Authenticate: BASIC realm="application"
>>             < Content-Length: 0
>>             < 
>>             * Connection #0 to host 127.0.0.1 left intact
>>             gvrangan@gvrangan-Latitude-3490:~\>
>>             curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
>>             <http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
>>             'admin:admin;
>>             > ^C
>>             gvrangan@gvrangan-Latitude-3490:~\>
>>             curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
>>             <http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
>>             'admin:admin'
>>             {"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
>>             gvrangan@gvrangan-Latitude-3490:~\> 
>>             gvrangan@gvrangan-Latitude-3490:~\> 
>>             gvrangan@gvrangan-Latitude-3490:~\> 
>>             gvrangan@gvrangan-Latitude-3490:~\>
>>             curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
>>             <http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
>>             'admin:admin'
>>             {"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
>>             gvrangan@gvrangan-Latitude-3490:~\> 
>>             gvrangan@gvrangan-Latitude-3490:~\>
>>             curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
>>             <http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
>>             'admin:admin'
>>             {"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}____
>>             ************____
>>             __ __
>>             The GET seems to require authorization. Also used wrong
>>             password which was also blocked.____
>>             __ __
>>             __ __
>>             __ __
>>             __ __
>>             __ __
>>             வியா., 28 ஜன., 2021, பிற்பகல் 10:53 அன்று, Luis Gomez
>>             <ecelgp@... <mailto:ecelgp@...>> எழுதியது:____
>>
>>                 It seems like we have to stop the Aluminium SR2
>>                 release after hearing the authentication issue from
>>                 Robert.____
>>
>>
>>                 ____
>>                 On Jan 27, 2021, at 4:32 PM, Daniel de la Rosa
>>                 <ddelarosa0707@...
>>                 <mailto:ddelarosa0707@...>> wrote:____
>>                 __ __
>>                 Thank you all.. @Luis Gomez
>>                 <mailto:ecelgp@...> please proceed with
>>                 distribution at your earliest convenience____
>>                 __ __
>>                 On Mon, Jan 25, 2021 at 10:25 AM
>>                 <gilles.thouenon@...
>>                 <mailto:gilles.thouenon@...>> wrote:____
>>
>>                     Hello,____
>>                      ____
>>                     I’ve proceeded to the TransportPCE release merge
>>                     job for Aluminium SR2 which is tagged with version
>>                     2.2.0.____
>>                     https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge/lastBuild/
>>                     <https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge/lastBuild/>____
>>                     Everything on our side seems ok.____
>>                     Tell us if additional action is required from our
>>                     side.____
>>                      ____
>>                     Best Regards,____
>>                      ____
>>                     Gilles Thouénon____
>>                      ____
>>                     *De :* release@...
>>                     <mailto:release@...> [mailto:release@...
>>                     <mailto:release@...>] *De la
>>                     part de* Gilles Thouenon
>>                     via lists.opendaylight.org
>>                     <http://lists.opendaylight.org/>
>>                     *Envoyé :* lundi 25 janvier 2021 08:31
>>                     *À :* Daniel de la Rosa <ddelarosa0707@...
>>                     <mailto:ddelarosa0707@...>>; Anil Belur
>>                     <abelur@...
>>                     <mailto:abelur@...>>; Luis Gomez
>>                     <ecelgp@... <mailto:ecelgp@...>>;
>>                     LAMBERT Guillaume TGI/OLN
>>                     <guillaume.lambert@...
>>                     <mailto:guillaume.lambert@...>>
>>                     *Cc :* 'integration-dev@...
>>                     <mailto:integration-dev@...>'
>>                     (integration-dev@...
>>                     <mailto:integration-dev@...>)
>>                     (integration-dev@...
>>                     <mailto:integration-dev@...>)
>>                     <integration-dev@...
>>                     <mailto:integration-dev@...>>;
>>                     Release <release@...
>>                     <mailto:release@...>>; TSC
>>                     <tsc@...
>>                     <mailto:tsc@...>>; Jordan
>>                     Conway <jconway@...
>>                     <mailto:jconway@...>>; Casey Cain
>>                     <ccain@...
>>                     <mailto:ccain@...>>; Robert Varga
>>                     <nite@... <mailto:nite@...>>; Venkatrangan
>>                     Govindarajan <gvrangan@...
>>                     <mailto:gvrangan@...>>
>>                     *Objet :* Re: [integration-dev] [OpenDaylight TSC]
>>                     [opendaylight-dev][release] OpenDaylight -
>>                     Aluminium SR2 release status____
>>                      ____
>>                     Thanks Daniel.____
>>                     On TransportPCE side, our stable/aluminium branch
>>                     is ready. We encountered the same issue as ____
>>                     https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21406
>>                     <https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21406>
>>                     to stage the release.____
>>                     So, we are waiting for the resolution of Jenkins
>>                     jobs failing issue.____
>>                     Best Regards,____
>>                      ____
>>                     Gilles Thouenon____
>>                      ____
>>                     *De :* integration-dev@...
>>                     <mailto:integration-dev@...> [mailto:integration-dev@...
>>                     <mailto:integration-dev@...>] *De
>>                     la part de* Daniel de la Rosa
>>                     *Envoyé :* lundi 25 janvier 2021 06:39
>>                     *À :* Anil Belur <abelur@...
>>                     <mailto:abelur@...>>; Luis Gomez
>>                     <ecelgp@... <mailto:ecelgp@...>>;
>>                     LAMBERT Guillaume TGI/OLN
>>                     <guillaume.lambert@...
>>                     <mailto:guillaume.lambert@...>>
>>                     *Cc :* 'integration-dev@...
>>                     <mailto:integration-dev@...>'
>>                     (integration-dev@...
>>                     <mailto:integration-dev@...>)
>>                     (integration-dev@...
>>                     <mailto:integration-dev@...>)
>>                     <integration-dev@...
>>                     <mailto:integration-dev@...>>;
>>                     Release <release@...
>>                     <mailto:release@...>>; TSC
>>                     <tsc@...
>>                     <mailto:tsc@...>>; Jordan
>>                     Conway <jconway@...
>>                     <mailto:jconway@...>>; Casey Cain
>>                     <ccain@...
>>                     <mailto:ccain@...>>; Robert Varga
>>                     <nite@... <mailto:nite@...>>; Venkatrangan
>>                     Govindarajan <gvrangan@...
>>                     <mailto:gvrangan@...>>
>>                     *Objet :* Re: [integration-dev] [OpenDaylight TSC]
>>                     [opendaylight-dev][release] OpenDaylight -
>>                     Aluminium SR2 release status____
>>                      ____
>>                     Thanks Anil. TransportPCE team, please proceed at
>>                     your earliest convenience.____
>>                      ____
>>                      ____
>>                      ____
>>                     On Sun, Jan 24, 2021 at 7:43 PM Anil Belur
>>                     <abelur@...
>>                     <mailto:abelur@...>> wrote:____
>>
>>                         Hello All,
>>
>>                         OpenDaylight Aluminium SR2 version bump is
>>                         complete and the staging repository is been
>>                         promoted. The 'stable/aluminum' branch is
>>                         unlocked and ready for development.____
>>
>>                         Pending activities that need to be completed
>>                         for the release:
>>                         1. Self-managed projects release of Aluminum SR2.
>>                         2. Release Distribution once the 1. is complete.
>>                         3. Release notes - to be merged CR [1.]
>>                         4. Update ODL downloads page [1.].
>>
>>                         Thanks to everyone who contributed to the release.
>>
>>                         Regards,
>>                         Anil Belur
>>
>>                         [0.] https://docs.opendaylight.org/en/latest/downloads.html
>>                         <https://docs.opendaylight.org/en/latest/downloads.html>
>>                         [1.] https://git.opendaylight.org/gerrit/c/docs/+/94758
>>                         <https://git.opendaylight.org/gerrit/c/docs/+/94758>____
>>
>>                          ____
>>
>>                     _____________________________________________________________________________________________________________________________
>>
>>                      ____
>>
>>                     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc____
>>
>>                     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler____
>>
>>                     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,____
>>
>>                     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.____
>>
>>                      ____
>>
>>                     This message and its attachments may contain confidential or privileged information that may be protected by law;____
>>
>>                     they should not be distributed, used or copied without authorisation.____
>>
>>                     If you have received this email in error, please notify the sender and delete this message and its attachments.____
>>
>>                     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.____
>>
>>                     Thank you.____
>>
>>                     _____________________________________________________________________________________________________________________________
>>
>>                     __ __
>>
>>                     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc____
>>
>>                     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler____
>>
>>                     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,____
>>
>>                     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.____
>>
>>                     __ __
>>
>>                     This message and its attachments may contain confidential or privileged information that may be protected by law;____
>>
>>                     they should not be distributed, used or copied without authorisation.____
>>
>>                     If you have received this email in error, please notify the sender and delete this message and its attachments.____
>>
>>                     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.____
>>
>>                     Thank you.____
>>
>>                 __ __
>>
>>
>>             ____
>>             __ __
>>             -- ____
>>             Venkatrangan Govindarajan
>>             ( When there is no wind...Row )____
>>
>>
>>     ____
>>     __ __
>>     -- ____
>>     Venkatrangan Govindarajan
>>     ( When there is no wind...Row )____
>>     __ __
>>     _________________________________________________________________________________________________________________________
>>
>>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>>     they should not be distributed, used or copied without authorisation.
>>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>     Thank you.
>
>
>
>
>


Re: global-jjb vs. packer vs. Jenkins jobs

Robert Varga
 

On 03/02/2021 00:03, Anil Belur wrote:
Greetings Robert:
Hello Anil,

lf-env.sh: Creates a virtual env and sets up the environment, while the
python-tools-install.sh Installs the python tools/utils during Job
runtime. Since releng/global-jjb is a repo of Generic JJB templates (can
be used by any of the CI management repositories), its up to the
$project/$job to install the dependencies required for running the job. 
Understood. At the end of the day, though, we have only a few classes of
jobs and there is a ton of commonalities between them.

We have discussed this in the past, installing PyPI dependencies during
packer image build time, comes with its own set of problems and added costs:
1. This requires maintaining a large number of packer images (if the
project needs to support multiple versions of python/PyPI deps).
I do not believe this is the case for OpenDaylight jobs. For example
each and every job I looked at performs two things:
- python-tools-install.sh (70 seconds)
- job-cost.sh (39 seconds)

2. All releng/global-jjb (templates) scripts do not require all of the
PyPi dependencies to be installed and are tied down to the $job or
$project, since this approach binding them all into the same env has a
risk of the deps being broken more frequently.
3. PyPi libs/modules are updated more frequently.
While that is true, this line of reasoning completely ignores the
failure mode and recovery.

As it stands any of:
- busted global-jjb
- PyPi package updates
- PyPi repository unavailability

As we have seen in these past weeks, any such failure immediately
propagates to all jobs and breaks them -- resulting in nothing working
anymore, with no real avenue for recovery without help of LF IT.

We actually went through exactly this discussion when we had Sigul
failures -- and Sigul is now part of base images.

It is deemed sufficient to update our cloud images once a month -- and
that includes all sorts security fixes and similar. As a community we
are free to decide when to spin new images and can do that completely
without LF IT intervention.

I am sorry, but I fail to see how Python packages special enough to inflict:
- breakages occurring at completely random times
- incur 2-5 minutes of infra install to *each and every job* we run[*]

I am sorry to say that the world has changed in the past 5 years and we
no longer have the attention of LF IT staff that made resolution of
these failures a matter of hours -- it really is multiple days. That
fact alone makes a huge difference when weighing pros and cons.

Regards,
Robert

[*]
Just take a good look at what
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/aaa-maven-verify-master-mvn35-openjdk11/3/console-timestamp.log.gz
did:

Total job runtime: 9m56s
Useful build time: 7m16s
Setup/teardown time: 2m40s

That's **27%** of the time spent on infra, amounting to **37%** overhead.


Thanks,
Anil


On Mon, Jan 25, 2021 at 7:44 PM Robert Varga <nite@...
<mailto:nite@...>> wrote:

Hello everyone,

as the (still current) failure to start Jenkins jobs shows, our current
way of integrating with external dependencies (global-jjb) is beyond
fragile.

The way our jobs work is that:

1) we have a base image, created by builder-packer-* jobs on a regular
basis and roll up distro upgrades plus some other things (like mininet,
etc.) that we need

2) the Jenkins job launches on that base image and call two scripts from
global-jjb, both of which end up installing more things:
   a) python-tools-install.sh
   b) lf-env.sh

3) the actual job runs

4) some more stuff invoking lf-env.sh to setup another Python
environment runs.

Now, it is clear that everything in 1) is invariant and updated in a
controlled way.

The problem is with 2), where again, everything is supposed to be
invariant for a particular version of global-jjb -- yet we reinstall
these things on every single job run.

Not only is this subject to random breakage (like now, or when pip
repositories are unavailable), etc.

It also takes around 3 minutes of each job execution, which does not
sound like much, but it is full 30%(!) of runtime of
yangtools-release-merge (which takes around 10 minutes).

We obviously can and must do better: global-jjb's environment-impacting
scripts must all be executed during builder-packer, so that they become
proper invariants.

For that, global-jjb needs to grow two things:

1) a way to install *all* of its dependencies without doing anything
else, for use in packer jobs

2) compatibility checks on the environment to ensure it is uptodate
enough to run a particular global-jjb version's scripts

With that, our jobs should be both faster and more reliable.

Does anybody see a problem why this would not work?

If not, I will be filing LFIT issues to get this done.

Regards,
Robert




Re: global-jjb vs. packer vs. Jenkins jobs

Anil Belur
 

Greetings Robert:

lf-env.sh: Creates a virtual env and sets up the environment, while the python-tools-install.sh Installs the python tools/utils during Job runtime. Since releng/global-jjb is a repo of Generic JJB templates (can be used by any of the CI management repositories), its up to the $project/$job to install the dependencies required for running the job.  

We have discussed this in the past, installing PyPI dependencies during packer image build time, comes with its own set of problems and added costs:
1. This requires maintaining a large number of packer images (if the project needs to support multiple versions of python/PyPI deps).
2. All releng/global-jjb (templates) scripts do not require all of the PyPi dependencies to be installed and are tied down to the $job or $project, since this approach binding them all into the same env has a risk of the deps being broken more frequently.
3. PyPi libs/modules are updated more frequently. 

Thanks,
Anil


On Mon, Jan 25, 2021 at 7:44 PM Robert Varga <nite@...> wrote:
Hello everyone,

as the (still current) failure to start Jenkins jobs shows, our current
way of integrating with external dependencies (global-jjb) is beyond
fragile.

The way our jobs work is that:

1) we have a base image, created by builder-packer-* jobs on a regular
basis and roll up distro upgrades plus some other things (like mininet,
etc.) that we need

2) the Jenkins job launches on that base image and call two scripts from
global-jjb, both of which end up installing more things:
   a) python-tools-install.sh
   b) lf-env.sh

3) the actual job runs

4) some more stuff invoking lf-env.sh to setup another Python
environment runs.

Now, it is clear that everything in 1) is invariant and updated in a
controlled way.

The problem is with 2), where again, everything is supposed to be
invariant for a particular version of global-jjb -- yet we reinstall
these things on every single job run.

Not only is this subject to random breakage (like now, or when pip
repositories are unavailable), etc.

It also takes around 3 minutes of each job execution, which does not
sound like much, but it is full 30%(!) of runtime of
yangtools-release-merge (which takes around 10 minutes).

We obviously can and must do better: global-jjb's environment-impacting
scripts must all be executed during builder-packer, so that they become
proper invariants.

For that, global-jjb needs to grow two things:

1) a way to install *all* of its dependencies without doing anything
else, for use in packer jobs

2) compatibility checks on the environment to ensure it is uptodate
enough to run a particular global-jjb version's scripts

With that, our jobs should be both faster and more reliable.

Does anybody see a problem why this would not work?

If not, I will be filing LFIT issues to get this done.

Regards,
Robert





Re: [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

Robert Varga
 

We are not.

We are picking candidates for SR3 -- and
https://jenkins.opendaylight.org/releng/job/autorelease-release-aluminium-mvn35-openjdk11/360/
is good as any :)

Regards,
Robert

On 02/02/2021 15:58, Daniel de la Rosa wrote:
Thanks Luis. So we are not updating the downloads page for Aluminium SR2
right? we have release notes though

On Thu, Jan 28, 2021 at 9:40 PM Luis Gomez <ecelgp@...
<mailto:ecelgp@...>> wrote:

OK, although we are not going to officially release Aluminium SR2, I
went ahead and released the distribution for completeness and also
in case someone wants to use this release for testing purposes: 

https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/opendaylight/0.13.2/
<https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/opendaylight/0.13.2/>

BR/Luis


On Jan 28, 2021, at 2:37 PM, <guillaume.lambert@...
<mailto:guillaume.lambert@...>>
<guillaume.lambert@...
<mailto:guillaume.lambert@...>> wrote:

I  agree with the suggestion to skip Al SR2.____
__ __
Best Regards____
Guillaume____
__ __
*De :* Luis Gomez [mailto:ecelgp@... <mailto:ecelgp@...>] 
*Envoyé :* jeudi 28 janvier 2021 22:11
*À :* Venkatrangan Govindarajan
*Cc :* Daniel de la Rosa; Oleksii Mozghovyi; THOUENON Gilles
TGI/OLN; integration-dev@...
<mailto:integration-dev@...>; Anil Belur; Casey
Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert
Varga; TSC; Transportpce-dev@...
<mailto:Transportpce-dev@...>
*Objet :* Re: [integration-dev] [OpenDaylight TSC]
[opendaylight-dev][release] OpenDaylight - Aluminium SR2 release
status____
__ __
Well, since the odl-restconf feature includes both draft and
RFC8040 API, I believe this bug is effectively a security hole
with a non trivial workaround even for the draft users (e.g.
repack the restconf feature to skip RFC8040).____
__ __
So my suggest is to skip Aluminium SR2 official release. Other TSC
(or not TSC) opinions?____
__ __
BR/Luis____


____
On Jan 28, 2021, at 10:33 AM, Venkatrangan Govindarajan
<gvrangan@... <mailto:gvrangan@...>> wrote:____
__ __
The problem occurs if the RFC8040 is used____
__ __
curl http://127.0.0.1:8181/rests/data/network-topology:network-topology
<http://127.0.0.1:8181/rests/data/network-topology:network-topology>  -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /rests/data/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181 <http://127.0.0.1:8181/>
> User-Agent: curl/7.47.0
> Accept: */*

< HTTP/1.1 200 OK
< ETag: "2013-10-21-network-topology"
< Last-Modified: 2021-Jan-28 18:31:25
< Content-Type: application/yang-data+json
< Content-Length: 133

* Connection #0 to host 127.0.0.1 left intact
{"network-topology:net____
__ __
__ __
It does not require authorization. The  issue seems to be
recreated.____
__ __
வியா., 28 ஜன., 2021, பிற்பகல் 11:46 அன்று, Daniel de la Rosa
<ddelarosa0707@...
<mailto:ddelarosa0707@...>> எழுதியது:____

Thanks Oleksii... IMHO, this issue is not a show stopper for
Aluminium SR2 but please confirm____
__ __
On Thu, Jan 28, 2021 at 10:09 AM Oleksii Mozghovyi
<Oleksii.Mozghovyi@...
<mailto:Oleksii.Mozghovyi@...>> wrote:____

__ __
Hello everyone,____
__ __
This issue is related only to the RFC8040 implementation
of the RESTconf, so you have to use a proper endpoint for
the testing, for example:____
http://127.0.0.1:8181/rests/data
<http://127.0.0.1:8181/rests/data>____
__ __
The thing is that {apiRoot}/restconf is managed by a
different web initializer and doesn't have such an issue.____
__ __
------------------------------------------------------------------------
*From:* release@...
<mailto:release@...> <release@...
<mailto:release@...>> on behalf of
Venkatrangan Govindarajan <gvrangan@...
<mailto:gvrangan@...>>
*Sent:* Thursday, January 28, 2021 8:01:59 PM
*To:* Luis Gomez
*Cc:* Daniel de la Rosa; THOUENON Gilles
TGI/OLN; integration-dev@...
<mailto:integration-dev@...>; Anil
Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume
TGI/OLN; Release; Robert Varga;
TSC; Transportpce-dev@...
<mailto:Transportpce-dev@...>
*Subject:* Re: [integration-dev] [OpenDaylight TSC]
[opendaylight-dev][release] OpenDaylight - Aluminium SR2
release status____
 ____
Just downloaded SR2 and installed some project that uses
topology model and executed this...____
__ __
******************____
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
<http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET
/restconf/operational/network-topology:network-topology
HTTP/1.1
> Host: 127.0.0.1:8181 <http://127.0.0.1:8181/>
> User-Agent: curl/7.47.0
> Accept: */*

< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: BASIC realm="application"
< Content-Length: 0

* Connection #0 to host 127.0.0.1 left intact
gvrangan@gvrangan-Latitude-3490:~\>
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
<http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
'admin:admin;
> ^C
gvrangan@gvrangan-Latitude-3490:~\>
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
<http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\>
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
<http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\>
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
<http://127.0.0.1:8181/restconf/operational/network-topology:network-topology> --user
'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}____
************____
__ __
The GET seems to require authorization. Also used wrong
password which was also blocked.____
__ __
__ __
__ __
__ __
__ __
வியா., 28 ஜன., 2021, பிற்பகல் 10:53 அன்று, Luis Gomez
<ecelgp@... <mailto:ecelgp@...>> எழுதியது:____

It seems like we have to stop the Aluminium SR2
release after hearing the authentication issue from
Robert.____


____
On Jan 27, 2021, at 4:32 PM, Daniel de la Rosa
<ddelarosa0707@...
<mailto:ddelarosa0707@...>> wrote:____
__ __
Thank you all.. @Luis Gomez
<mailto:ecelgp@...> please proceed with
distribution at your earliest convenience____
__ __
On Mon, Jan 25, 2021 at 10:25 AM
<gilles.thouenon@...
<mailto:gilles.thouenon@...>> wrote:____

Hello,____
 ____
I’ve proceeded to the TransportPCE release merge
job for Aluminium SR2 which is tagged with version
2.2.0.____
https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge/lastBuild/
<https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge/lastBuild/>____
Everything on our side seems ok.____
Tell us if additional action is required from our
side.____
 ____
Best Regards,____
 ____
Gilles Thouénon____
 ____
*De :* release@...
<mailto:release@...> [mailto:release@...
<mailto:release@...>] *De la
part de* Gilles Thouenon
via lists.opendaylight.org
<http://lists.opendaylight.org/>
*Envoyé :* lundi 25 janvier 2021 08:31
*À :* Daniel de la Rosa <ddelarosa0707@...
<mailto:ddelarosa0707@...>>; Anil Belur
<abelur@...
<mailto:abelur@...>>; Luis Gomez
<ecelgp@... <mailto:ecelgp@...>>;
LAMBERT Guillaume TGI/OLN
<guillaume.lambert@...
<mailto:guillaume.lambert@...>>
*Cc :* 'integration-dev@...
<mailto:integration-dev@...>'
(integration-dev@...
<mailto:integration-dev@...>)
(integration-dev@...
<mailto:integration-dev@...>)
<integration-dev@...
<mailto:integration-dev@...>>;
Release <release@...
<mailto:release@...>>; TSC
<tsc@...
<mailto:tsc@...>>; Jordan
Conway <jconway@...
<mailto:jconway@...>>; Casey Cain
<ccain@...
<mailto:ccain@...>>; Robert Varga
<nite@... <mailto:nite@...>>; Venkatrangan
Govindarajan <gvrangan@...
<mailto:gvrangan@...>>
*Objet :* Re: [integration-dev] [OpenDaylight TSC]
[opendaylight-dev][release] OpenDaylight -
Aluminium SR2 release status____
 ____
Thanks Daniel.____
On TransportPCE side, our stable/aluminium branch
is ready. We encountered the same issue as ____
https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21406
<https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21406>
to stage the release.____
So, we are waiting for the resolution of Jenkins
jobs failing issue.____
Best Regards,____
 ____
Gilles Thouenon____
 ____
*De :* integration-dev@...
<mailto:integration-dev@...> [mailto:integration-dev@...
<mailto:integration-dev@...>] *De
la part de* Daniel de la Rosa
*Envoyé :* lundi 25 janvier 2021 06:39
*À :* Anil Belur <abelur@...
<mailto:abelur@...>>; Luis Gomez
<ecelgp@... <mailto:ecelgp@...>>;
LAMBERT Guillaume TGI/OLN
<guillaume.lambert@...
<mailto:guillaume.lambert@...>>
*Cc :* 'integration-dev@...
<mailto:integration-dev@...>'
(integration-dev@...
<mailto:integration-dev@...>)
(integration-dev@...
<mailto:integration-dev@...>)
<integration-dev@...
<mailto:integration-dev@...>>;
Release <release@...
<mailto:release@...>>; TSC
<tsc@...
<mailto:tsc@...>>; Jordan
Conway <jconway@...
<mailto:jconway@...>>; Casey Cain
<ccain@...
<mailto:ccain@...>>; Robert Varga
<nite@... <mailto:nite@...>>; Venkatrangan
Govindarajan <gvrangan@...
<mailto:gvrangan@...>>
*Objet :* Re: [integration-dev] [OpenDaylight TSC]
[opendaylight-dev][release] OpenDaylight -
Aluminium SR2 release status____
 ____
Thanks Anil. TransportPCE team, please proceed at
your earliest convenience.____
 ____
 ____
 ____
On Sun, Jan 24, 2021 at 7:43 PM Anil Belur
<abelur@...
<mailto:abelur@...>> wrote:____

Hello All,

OpenDaylight Aluminium SR2 version bump is
complete and the staging repository is been
promoted. The 'stable/aluminum' branch is
unlocked and ready for development.____

Pending activities that need to be completed
for the release:
1. Self-managed projects release of Aluminum SR2.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [1.].

Thanks to everyone who contributed to the release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html
<https://docs.opendaylight.org/en/latest/downloads.html>
[1.] https://git.opendaylight.org/gerrit/c/docs/+/94758
<https://git.opendaylight.org/gerrit/c/docs/+/94758>____

 ____

_____________________________________________________________________________________________________________________________

 ____

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc____

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler____

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,____

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.____

 ____

This message and its attachments may contain confidential or privileged information that may be protected by law;____

they should not be distributed, used or copied without authorisation.____

If you have received this email in error, please notify the sender and delete this message and its attachments.____

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.____

Thank you.____

_____________________________________________________________________________________________________________________________

__ __

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc____

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler____

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,____

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.____

__ __

This message and its attachments may contain confidential or privileged information that may be protected by law;____

they should not be distributed, used or copied without authorisation.____

If you have received this email in error, please notify the sender and delete this message and its attachments.____

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.____

Thank you.____

__ __


____
__ __
-- ____
Venkatrangan Govindarajan
( When there is no wind...Row )____


____
__ __
-- ____
Venkatrangan Govindarajan
( When there is no wind...Row )____
__ __
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




Re: [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

Daniel de la Rosa
 

Thanks Luis. So we are not updating the downloads page for Aluminium SR2 right? we have release notes though


On Thu, Jan 28, 2021 at 9:40 PM Luis Gomez <ecelgp@...> wrote:
OK, although we are not going to officially release Aluminium SR2, I went ahead and released the distribution for completeness and also in case someone wants to use this release for testing purposes: 


BR/Luis


On Jan 28, 2021, at 2:37 PM, <guillaume.lambert@...> <guillaume.lambert@...> wrote:

I  agree with the suggestion to skip Al SR2.
 
Best Regards
Guillaume
 
De : Luis Gomez [mailto:ecelgp@...] 
Envoyé : jeudi 28 janvier 2021 22:11
À : Venkatrangan Govindarajan
Cc : Daniel de la Rosa; Oleksii Mozghovyi; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Well, since the odl-restconf feature includes both draft and RFC8040 API, I believe this bug is effectively a security hole with a non trivial workaround even for the draft users (e.g. repack the restconf feature to skip RFC8040).
 
So my suggest is to skip Aluminium SR2 official release. Other TSC (or not TSC) opinions?
 
BR/Luis


On Jan 28, 2021, at 10:33 AM, Venkatrangan Govindarajan <gvrangan@...> wrote:
 
The problem occurs if the RFC8040 is used
 
curl http://127.0.0.1:8181/rests/data/network-topology:network-topology  -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /rests/data/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< ETag: "2013-10-21-network-topology"
< Last-Modified: 2021-Jan-28 18:31:25
< Content-Type: application/yang-data+json
< Content-Length: 133
< 
* Connection #0 to host 127.0.0.1 left intact
{"network-topology:net
 
 
It does not require authorization. The  issue seems to be recreated.
 
வியா., 28 ஜன., 2021, பிற்பகல் 11:46 அன்று, Daniel de la Rosa <ddelarosa0707@...> எழுதியது:
Thanks Oleksii... IMHO, this issue is not a show stopper for Aluminium SR2 but please confirm
 
On Thu, Jan 28, 2021 at 10:09 AM Oleksii Mozghovyi <Oleksii.Mozghovyi@...> wrote:
 
Hello everyone,
 
This issue is related only to the RFC8040 implementation of the RESTconf, so you have to use a proper endpoint for the testing, for example:
 
The thing is that {apiRoot}/restconf is managed by a different web initializer and doesn't have such an issue.
 

From: release@... <release@...> on behalf of Venkatrangan Govindarajan <gvrangan@...>
Sent: Thursday, January 28, 2021 8:01:59 PM
To: Luis Gomez
Cc: Daniel de la Rosa; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Subject: Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Just downloaded SR2 and installed some project that uses topology model and executed this...
 
******************
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /restconf/operational/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: BASIC realm="application"
< Content-Length: 0
< 
* Connection #0 to host 127.0.0.1 left intact
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin;
> ^C
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}
************
 
The GET seems to require authorization. Also used wrong password which was also blocked.
 
 
 
 
 
வியா., 28 ஜன., 2021, பிற்பகல் 10:53 அன்று, Luis Gomez <ecelgp@...> எழுதியது:
It seems like we have to stop the Aluminium SR2 release after hearing the authentication issue from Robert.


On Jan 27, 2021, at 4:32 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:
 
Thank you all.. @Luis Gomez please proceed with distribution at your earliest convenience
 
On Mon, Jan 25, 2021 at 10:25 AM <gilles.thouenon@...> wrote:
Hello,
 
I’ve proceeded to the TransportPCE release merge job for Aluminium SR2 which is tagged with version 2.2.0.
Everything on our side seems ok.
Tell us if additional action is required from our side.
 
Best Regards,
 
Gilles Thouénon
 
De : release@... [mailto:release@...] De la part de Gilles Thouenon via lists.opendaylight.org
Envoyé : lundi 25 janvier 2021 08:31
À : Daniel de la Rosa <ddelarosa0707@...>; Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Thanks Daniel.
On TransportPCE side, our stable/aluminium branch is ready. We encountered the same issue as 
So, we are waiting for the resolution of Jenkins jobs failing issue.
Best Regards,
 
Gilles Thouenon
 
De : integration-dev@... [mailto:integration-dev@...] De la part de Daniel de la Rosa
Envoyé : lundi 25 janvier 2021 06:39
À : Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Thanks Anil. TransportPCE team, please proceed at your earliest convenience.
 
 
 
On Sun, Jan 24, 2021 at 7:43 PM Anil Belur <abelur@...> wrote:
Hello All,

OpenDaylight Aluminium SR2 version bump is complete and the staging repository is been promoted. The 'stable/aluminum' branch is unlocked and ready for development.

Pending activities that need to be completed for the release:
1. Self-managed projects release of Aluminum SR2.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [1.].

Thanks to everyone who contributed to the release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html
[1.] https://git.opendaylight.org/gerrit/c/docs/+/94758

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 

 
-- 
Venkatrangan Govindarajan
( When there is no wind...Row )

 
-- 
Venkatrangan Govindarajan
( When there is no wind...Row )
 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Re: [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

Oleksii Mozghovyi <Oleksii.Mozghovyi@...>
 

Hello everyone,

This issue is related only to the RFC8040 implementation of the RESTconf, so you have to use a proper endpoint for the testing, for example:
http://127.0.0.1:8181/rests/data

The thing is that {apiRoot}/restconf is managed by a different web initializer and doesn't have such an issue.


From: release@... <release@...> on behalf of Venkatrangan Govindarajan <gvrangan@...>
Sent: Thursday, January 28, 2021 8:01:59 PM
To: Luis Gomez
Cc: Daniel de la Rosa; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Subject: Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Just downloaded SR2 and installed some project that uses topology model and executed this...

******************
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /restconf/operational/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: BASIC realm="application"
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin;
> ^C
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}
************

The GET seems to require authorization. Also used wrong password which was also blocked.





வியா., 28 ஜன., 2021, பிற்பகல் 10:53 அன்று, Luis Gomez <ecelgp@...> எழுதியது:
It seems like we have to stop the Aluminium SR2 release after hearing the authentication issue from Robert.

On Jan 27, 2021, at 4:32 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:

Thank you all.. @Luis Gomez please proceed with distribution at your earliest convenience

On Mon, Jan 25, 2021 at 10:25 AM <gilles.thouenon@...> wrote:

Hello,

 

I’ve proceeded to the TransportPCE release merge job for Aluminium SR2 which is tagged with version 2.2.0.

https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge/lastBuild/

Everything on our side seems ok.

Tell us if additional action is required from our side.

 

Best Regards,

 

Gilles Thouénon

 

De : release@... [mailto:release@...] De la part de Gilles Thouenon via lists.opendaylight.org
Envoyé : lundi 25 janvier 2021 08:31
À : Daniel de la Rosa <ddelarosa0707@...>; Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

 

Thanks Daniel.

On TransportPCE side, our stable/aluminium branch is ready. We encountered the same issue as

https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21406
to stage the release.

So, we are waiting for the resolution of Jenkins jobs failing issue.

Best Regards,

 

Gilles Thouenon

 

De : integration-dev@... [mailto:integration-dev@...] De la part de Daniel de la Rosa
Envoyé : lundi 25 janvier 2021 06:39
À : Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

 

Thanks Anil. TransportPCE team, please proceed at your earliest convenience.

 

 

 

On Sun, Jan 24, 2021 at 7:43 PM Anil Belur <abelur@...> wrote:

Hello All,

OpenDaylight Aluminium SR2 version bump is complete and the staging repository is been promoted. The 'stable/aluminum' branch is unlocked and ready for development.


Pending activities that need to be completed for the release:
1. Self-managed projects release of Aluminum SR2.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [1.].

Thanks to everyone who contributed to the release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html
[1.] https://git.opendaylight.org/gerrit/c/docs/+/94758

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



--
Venkatrangan Govindarajan
( When there is no wind...Row )


Re: shellcheck broken

Luis Gomez
 

Thanks Andy :)

On Jan 29, 2021, at 6:47 AM, Andrew Grimberg <agrimberg@...> wrote:

On 1/28/21 8:11 PM, Luis Gomez wrote:
FYI, not sure which jobs are impacted but shellcheck pre-commit is broken here:

https://jenkins.opendaylight.org/releng/job/builder-tox-verify-master/

BR/Luis
The pre-commit project released 2.10.0 which seems to have introduced an
incompatibility with jumanjihouse/pre-commit-hooks and in particular the
shellcheck hook.

At this time we don't know if it was intentional or not, but we've taken
to pinning pre-commit to version 2.9.3 in our tox.ini for the time being.

This is a project by project change for projects that use shellcheck in
their .pre-commit-config.yaml file that would need to happen as it
doesn't come from global-jjb.

For releng/builder I've pushed up [0] that does this pinning.

-Andy-

[0] https://git.opendaylight.org/gerrit/c/releng/builder/+/94887

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation
<OpenPGP_0x3360FFB703A9DA1F_and_old_rev.asc>


Re: shellcheck broken

Andrew Grimberg
 

On 1/28/21 8:11 PM, Luis Gomez wrote:
FYI, not sure which jobs are impacted but shellcheck pre-commit is broken here:

https://jenkins.opendaylight.org/releng/job/builder-tox-verify-master/

BR/Luis
The pre-commit project released 2.10.0 which seems to have introduced an
incompatibility with jumanjihouse/pre-commit-hooks and in particular the
shellcheck hook.

At this time we don't know if it was intentional or not, but we've taken
to pinning pre-commit to version 2.9.3 in our tox.ini for the time being.

This is a project by project change for projects that use shellcheck in
their .pre-commit-config.yaml file that would need to happen as it
doesn't come from global-jjb.

For releng/builder I've pushed up [0] that does this pinning.

-Andy-

[0] https://git.opendaylight.org/gerrit/c/releng/builder/+/94887

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

Luis Gomez
 

OK, although we are not going to officially release Aluminium SR2, I went ahead and released the distribution for completeness and also in case someone wants to use this release for testing purposes: 


BR/Luis


On Jan 28, 2021, at 2:37 PM, <guillaume.lambert@...> <guillaume.lambert@...> wrote:

I  agree with the suggestion to skip Al SR2.
 
Best Regards
Guillaume
 
De : Luis Gomez [mailto:ecelgp@...] 
Envoyé : jeudi 28 janvier 2021 22:11
À : Venkatrangan Govindarajan
Cc : Daniel de la Rosa; Oleksii Mozghovyi; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Well, since the odl-restconf feature includes both draft and RFC8040 API, I believe this bug is effectively a security hole with a non trivial workaround even for the draft users (e.g. repack the restconf feature to skip RFC8040).
 
So my suggest is to skip Aluminium SR2 official release. Other TSC (or not TSC) opinions?
 
BR/Luis


On Jan 28, 2021, at 10:33 AM, Venkatrangan Govindarajan <gvrangan@...> wrote:
 
The problem occurs if the RFC8040 is used
 
curl http://127.0.0.1:8181/rests/data/network-topology:network-topology  -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /rests/data/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< ETag: "2013-10-21-network-topology"
< Last-Modified: 2021-Jan-28 18:31:25
< Content-Type: application/yang-data+json
< Content-Length: 133
< 
* Connection #0 to host 127.0.0.1 left intact
{"network-topology:net
 
 
It does not require authorization. The  issue seems to be recreated.
 
வியா., 28 ஜன., 2021, பிற்பகல் 11:46 அன்று, Daniel de la Rosa <ddelarosa0707@...> எழுதியது:
Thanks Oleksii... IMHO, this issue is not a show stopper for Aluminium SR2 but please confirm
 
On Thu, Jan 28, 2021 at 10:09 AM Oleksii Mozghovyi <Oleksii.Mozghovyi@...> wrote:
 
Hello everyone,
 
This issue is related only to the RFC8040 implementation of the RESTconf, so you have to use a proper endpoint for the testing, for example:
 
The thing is that {apiRoot}/restconf is managed by a different web initializer and doesn't have such an issue.
 

From: release@... <release@...> on behalf of Venkatrangan Govindarajan <gvrangan@...>
Sent: Thursday, January 28, 2021 8:01:59 PM
To: Luis Gomez
Cc: Daniel de la Rosa; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Subject: Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Just downloaded SR2 and installed some project that uses topology model and executed this...
 
******************
curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /restconf/operational/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: BASIC realm="application"
< Content-Length: 0
< 
* Connection #0 to host 127.0.0.1 left intact
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin;
> ^C
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> 
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}
************
 
The GET seems to require authorization. Also used wrong password which was also blocked.
 
 
 
 
 
வியா., 28 ஜன., 2021, பிற்பகல் 10:53 அன்று, Luis Gomez <ecelgp@...> எழுதியது:
It seems like we have to stop the Aluminium SR2 release after hearing the authentication issue from Robert.


On Jan 27, 2021, at 4:32 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:
 
Thank you all.. @Luis Gomez please proceed with distribution at your earliest convenience
 
On Mon, Jan 25, 2021 at 10:25 AM <gilles.thouenon@...> wrote:
Hello,
 
I’ve proceeded to the TransportPCE release merge job for Aluminium SR2 which is tagged with version 2.2.0.
Everything on our side seems ok.
Tell us if additional action is required from our side.
 
Best Regards,
 
Gilles Thouénon
 
De : release@... [mailto:release@...] De la part de Gilles Thouenon via lists.opendaylight.org
Envoyé : lundi 25 janvier 2021 08:31
À : Daniel de la Rosa <ddelarosa0707@...>; Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Thanks Daniel.
On TransportPCE side, our stable/aluminium branch is ready. We encountered the same issue as 
So, we are waiting for the resolution of Jenkins jobs failing issue.
Best Regards,
 
Gilles Thouenon
 
De : integration-dev@... [mailto:integration-dev@...] De la part de Daniel de la Rosa
Envoyé : lundi 25 janvier 2021 06:39
À : Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status
 
Thanks Anil. TransportPCE team, please proceed at your earliest convenience.
 
 
 
On Sun, Jan 24, 2021 at 7:43 PM Anil Belur <abelur@...> wrote:
Hello All,

OpenDaylight Aluminium SR2 version bump is complete and the staging repository is been promoted. The 'stable/aluminum' branch is unlocked and ready for development.

Pending activities that need to be completed for the release:
1. Self-managed projects release of Aluminum SR2.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [1.].

Thanks to everyone who contributed to the release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html
[1.] https://git.opendaylight.org/gerrit/c/docs/+/94758

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 

 
-- 
Venkatrangan Govindarajan
( When there is no wind...Row )

 
-- 
Venkatrangan Govindarajan
( When there is no wind...Row )
 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


shellcheck broken

Luis Gomez
 

FYI, not sure which jobs are impacted but shellcheck pre-commit is broken here:

https://jenkins.opendaylight.org/releng/job/builder-tox-verify-master/

BR/Luis


Re: [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

Guillaume Lambert
 

I  agree with the suggestion to skip Al SR2.

 

Best Regards

Guillaume

 

De : Luis Gomez [mailto:ecelgp@...]
Envoyé : jeudi 28 janvier 2021 22:11
À : Venkatrangan Govindarajan
Cc : Daniel de la Rosa; Oleksii Mozghovyi; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

 

Well, since the odl-restconf feature includes both draft and RFC8040 API, I believe this bug is effectively a security hole with a non trivial workaround even for the draft users (e.g. repack the restconf feature to skip RFC8040).

 

So my suggest is to skip Aluminium SR2 official release. Other TSC (or not TSC) opinions?

 

BR/Luis



On Jan 28, 2021, at 10:33 AM, Venkatrangan Govindarajan <gvrangan@...> wrote:

 

The problem occurs if the RFC8040 is used

 

curl http://127.0.0.1:8181/rests/data/network-topology:network-topology  -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /rests/data/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< ETag: "2013-10-21-network-topology"
< Last-Modified: 2021-Jan-28 18:31:25
< Content-Type: application/yang-data+json
< Content-Length: 133
<
* Connection #0 to host 127.0.0.1 left intact
{"network-topology:net

 

 

It does not require authorization. The  issue seems to be recreated.

 

வியா., 28 ஜன., 2021, பிற்பகல் 11:46 அன்று, Daniel de la Rosa <ddelarosa0707@...> எழுதியது:

Thanks Oleksii... IMHO, this issue is not a show stopper for Aluminium SR2 but please confirm

 

On Thu, Jan 28, 2021 at 10:09 AM Oleksii Mozghovyi <Oleksii.Mozghovyi@...> wrote:

 

Hello everyone,

 

This issue is related only to the RFC8040 implementation of the RESTconf, so you have to use a proper endpoint for the testing, for example:

 

The thing is that {apiRoot}/restconf is managed by a different web initializer and doesn't have such an issue.

 


From: release@... <release@...> on behalf of Venkatrangan Govindarajan <gvrangan@...>
Sent: Thursday, January 28, 2021 8:01:59 PM
To: Luis Gomez
Cc: Daniel de la Rosa; THOUENON Gilles TGI/OLN; integration-dev@...; Anil Belur; Casey Cain; Jordan Conway; LAMBERT Guillaume TGI/OLN; Release; Robert Varga; TSC; Transportpce-dev@...
Subject: Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

 

Just downloaded SR2 and installed some project that uses topology model and executed this...

 

******************

curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology -v
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8181 (#0)
> GET /restconf/operational/network-topology:network-topology HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: BASIC realm="application"
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin;
> ^C
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\>
gvrangan@gvrangan-Latitude-3490:~\> curl http://127.0.0.1:8181/restconf/operational/network-topology:network-topology --user 'admin:admin'
{"network-topology":{"topology":[{"topology-id":"hwvtep:1"},{"topology-id":"ovsdb:1"},{"topology-id":"netvirt:1"}]}}

************

 

The GET seems to require authorization. Also used wrong password which was also blocked.

 

 

 

 

 

வியா., 28 ஜன., 2021, பிற்பகல் 10:53 அன்று, Luis Gomez <ecelgp@...> எழுதியது:

It seems like we have to stop the Aluminium SR2 release after hearing the authentication issue from Robert.



On Jan 27, 2021, at 4:32 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:

 

Thank you all.. @Luis Gomez please proceed with distribution at your earliest convenience

 

On Mon, Jan 25, 2021 at 10:25 AM <gilles.thouenon@...> wrote:

Hello,

 

I’ve proceeded to the TransportPCE release merge job for Aluminium SR2 which is tagged with version 2.2.0.

https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge/lastBuild/

Everything on our side seems ok.

Tell us if additional action is required from our side.

 

Best Regards,

 

Gilles Thouénon

 

De : release@... [mailto:release@...] De la part de Gilles Thouenon via lists.opendaylight.org
Envoyé : lundi 25 janvier 2021 08:31
À : Daniel de la Rosa <ddelarosa0707@...>; Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

 

Thanks Daniel.

On TransportPCE side, our stable/aluminium branch is ready. We encountered the same issue as

https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21406
to stage the release.

So, we are waiting for the resolution of Jenkins jobs failing issue.

Best Regards,

 

Gilles Thouenon

 

De : integration-dev@... [mailto:integration-dev@...] De la part de Daniel de la Rosa
Envoyé : lundi 25 janvier 2021 06:39
À : Anil Belur <abelur@...>; Luis Gomez <ecelgp@...>; LAMBERT Guillaume TGI/OLN <guillaume.lambert@...>
Cc : 'integration-dev@...' (integration-dev@...) (integration-dev@...) <integration-dev@...>; Release <release@...>; TSC <tsc@...>; Jordan Conway <jconway@...>; Casey Cain <ccain@...>; Robert Varga <nite@...>; Venkatrangan Govindarajan <gvrangan@...>
Objet : Re: [integration-dev] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Aluminium SR2 release status

 

Thanks Anil. TransportPCE team, please proceed at your earliest convenience.

 

 

 

On Sun, Jan 24, 2021 at 7:43 PM Anil Belur <abelur@...> wrote:

Hello All,

OpenDaylight Aluminium SR2 version bump is complete and the staging repository is been promoted. The 'stable/aluminum' branch is unlocked and ready for development.


Pending activities that need to be completed for the release:
1. Self-managed projects release of Aluminum SR2.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [1.].

Thanks to everyone who contributed to the release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html
[1.] https://git.opendaylight.org/gerrit/c/docs/+/94758

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

 


 

--

Venkatrangan Govindarajan
( When there is no wind...Row )


 

--

Venkatrangan Govindarajan
( When there is no wind...Row )

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

261 - 280 of 14659