Date   

release name shift

Guillaume Lambert
 

Hello OpenDaylight Community,

Following our developper forum last week, the question of the release name has been raised by Robert.
I've set up for a small confluence survey  to get TSC opinion on the topic at https://wiki.opendaylight.org/x/QRkF.
We can of course pursue the discussion by email with the whole community here.

Hope this helps.

Best Regards
Guillaume


_________________________________________________________________________________________________________________________

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: [integration-dev] 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


TSC Special Election

Casey Cain
 

Hello, everyone. 

Prior to the recent TSC Election, the community elected to reform the TSC number of seats.  The TSC voted to initiate an election to add Active Community Members to the TSC.  The TSC defined activity as:
  • Active Community Members: Anyone from the OpenDaylight community with twenty (20) or more measurable contributions during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.

The TSC did not yet confirm the number of seats.  Please reference the TSC Election Process and the TSC Minutes.  I suggest that the TSC discuss proposals between now and February 18th, where the TSC can vote to confirm the available seats.  We can then initiate the TSC Special Election and candidates will be able to self-nominate.  

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC: CaseyLF
WeChat: okaru6
Voice: +1.408.641.0193


Re: [app-dev] CSIT for Akka uplift

Robert Varga
 

[+kernel-dev]

On 05/02/2021 18:35, Venkatrangan Govindarajan wrote:
Hi Robert,
Hey Venkat,

  Based on our discussion in the DDF, I reviewed the patch - [0]. It is
not used by any of the currently active 3-node jobs. The current silicon
3node jobs have classic.netty.tcp righly set in akka.conf -[1] (Please
search for the string 'Dump akka.conf')
Yeah... I wondered about that... see below.

I guess, no fix is needed. for netty.tcp. Please let me know if you have
some failing job link, so that we can check for other failures.
I suspected as much :) In that vein I went ahead and released both
controller-3.0.6 and aaa-0.13.1.

Given we are before branch cut, let's try to treat this as an MIR bump
and see what the fallout is,

We still have ~2 weeks until the checkpoint. If this does not pan out,
we will just revert and come back with lessons learnt :)

Regards,
Robert


Re: [integration-dev] [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: [integration-dev] 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: [integration-dev] 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: [integration-dev] [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: [integration-dev] [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: Silicon code freeze...

Daniel de la Rosa
 

Great, thanks.... I have adjusted Silicon Checklist accordingly


Thanks

On Mon, Feb 1, 2021 at 7:02 AM Robert Varga <nite@...> wrote:
On 30/01/2021 20:06, Robert Varga wrote:
> Hey everyone,
>
> On 30/01/2021 08:47, Robert Varga wrote:
>> On 28/01/2021 19:28, Daniel de la Rosa wrote:
>>> Hello TSC members and all
>
> [snip]
>
>>> I think we can wait a week since have plenty of time to release Silicon
>>> by March 17th but please let me know if you have any objections
>>
>> +1 we still have a lot of global activities to execute:
>>
>> - odlparent-8.1 (ongoing)
>
> This is done.
>
>> - aaa removal (becomes MRI, the vote is just in)

This is now done...

>> - genius removal (becomes MSI, we want to keep it in good shape)
>

... and this item is up next.

>> - akka-2.6 integration (pending CSIT testing)

This item is getting ready and should land this week.

>> - (maybe) netconf removal (becomes MRI, still need a vote)

The vote is out, I expect it to conclude this week.

Regards,
Robert


Re: [release] Silicon: next steps for Genius

Robert Varga
 

Hello,

the patches to take Genius to self-managed mode in Silicon live here:
https://git.opendaylight.org/gerrit/q/topic:genius-sm

There are three patches now, which need to go in order:
- int/dist
- releng/builder
- releng/autorelease

The last one will trigger Jenkins proposing a patch to releng/builder,
which will finalize the transaction.

Regards,
Robert

On 29/01/2021 23:38, Robert Varga wrote:
Thanks, we will proceed then with this plan.

Regards,
Robert


On 29/01/2021 07:56, Hema Gopalakrishnan via lists.opendaylight.org wrote:
Hi Robert,

The steps that you have mentioned below is fine with us. Please go ahead.

Thanks,
Hema

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Tuesday, January 26, 2021 2:01 PM
To: tsc@...; release@...
Cc: Hema Gopalkrishnan <hema.gopalkrishnan@...>; Faseela K <k.faseela@...>; Chetan Arakere Gowdru <chetan.arakere@...>
Subject: Silicon: next steps for Genius

Hello everyone,

as you may be aware, Genius has decided not to participate in Silicon release as a managed project.

As it currently stands it would be subject to branching and version-bumping at the Silicon branch and release points.

We do not want that to happen, as would result in genius.git/master to become eventually unbuildable -- raising a high barrier of entry if someone were to want give it a try. This has happened to each and every ex-MSI project. We need and can do better.

What we want to achieve is that as soon as Silicon releases, genius.git/master will be bumped to Silicon GA artifacts of its upstreams. That way its build will not get broken once Silicon SNAPSHOT artifacts expire and will remain buildable for pretty much eternity.

To get to that point, we need to remove Genius from autorelease and int/dist before the Silicon branch point.

Any objections to doing that this or next week?

Regards,
Robert





Technical debt report for January 2021

Robert Varga
 

Hello everyone,

this is a quick summary of current outstanding technical debt, as
reported by the autorelease build. I missed sending out the report for
November, sorry about that.

1.2.2021 4.1.2021 delta
Deprecated 1593 1623 -30
Deprecated for removal 841 1448 -607
Modernizer 109 196 -87

The second line is more critical, as those are things that either we or
our upstreams *will* remove. That number breaks down like this:

1.2.2021 4.1.2021 delta
Uint{8,16,32,64} (Mg) 250 407 -157
setFoo(List) (Al) 150 404 -254
isFoo() (Si) 76 342 -266
other 365 295 +70

The vast majority of migration method use is in Genius (340 out of 476),
leaving ~140 items to be resolved -- which is very much manageable.

MD-SAL will therefore remove codegen for these methods as part of the
Phosphorus MRI window.

Regards,
Robert


Re: Silicon code freeze...

Robert Varga
 

On 30/01/2021 20:06, Robert Varga wrote:
Hey everyone,

On 30/01/2021 08:47, Robert Varga wrote:
On 28/01/2021 19:28, Daniel de la Rosa wrote:
Hello TSC members and all
[snip]

I think we can wait a week since have plenty of time to release Silicon
by March 17th but please let me know if you have any objections
+1 we still have a lot of global activities to execute:

- odlparent-8.1 (ongoing)
This is done.

- aaa removal (becomes MRI, the vote is just in)
This is now done...

- genius removal (becomes MSI, we want to keep it in good shape)
... and this item is up next.

- akka-2.6 integration (pending CSIT testing)
This item is getting ready and should land this week.

- (maybe) netconf removal (becomes MRI, still need a vote)
The vote is out, I expect it to conclude this week.

Regards,
Robert


Re: Turning AAA into a Release-Integrated project

Robert Varga
 

On 30/01/2021 21:30, Robert Varga wrote:
On 29/01/2021 23:45, Robert Varga wrote:
On 25/01/2021 11:49, Robert Varga wrote:

This makes it two out of four in favor with no objections.

I will work with autorelease and int/dist to make this happen next week.
This is now being integrated.
This work has now completed. The branch should stabilize in about 30
minutes.

Regards,
Robert


Re: Turning AAA into a Release-Integrated project

Robert Varga
 

On 29/01/2021 23:45, Robert Varga wrote:
On 25/01/2021 11:49, Robert Varga wrote:
Hello everyone,

as I've been mentioning for past couple of releases, it is my intention
to peel the AAA project from autorelease and make it a Managed Release
Integrated project before Silicon branching occurs. This means AAA will
be in charge of producing its release artifacts and generally fall in
integration workflows designed for MRI projects.

The justification is three-fold:
- all of AAA's dependencies are release-integrated-
- the project is essentially dormant with the rate of change
well-controlled and mostly reacting to upstreams
- AAA is the last non-MRI dependency of NETCONF

As a AAA committer, do you have any objection to this change?
+1 from me.

If I don't hear any objections this week, I will default to pushing this
change through.
This makes it two out of four in favor with no objections.

I will work with autorelease and int/dist to make this happen next week.
This is now being integrated.

Regards,
Robert


Re: Silicon code freeze...

Robert Varga
 

Hey everyone,

On 30/01/2021 08:47, Robert Varga wrote:
On 28/01/2021 19:28, Daniel de la Rosa wrote:
Hello TSC members and all
[snip]

I think we can wait a week since have plenty of time to release Silicon
by March 17th but please let me know if you have any objections
+1 we still have a lot of global activities to execute:

- odlparent-8.1 (ongoing)
This is done.

- aaa removal (becomes MRI, the vote is just in)
While I have the superpowers, I'll take care of this now...

- genius removal (becomes MSI, we want to keep it in good shape)
... and then this.

- akka-2.6 integration (pending CSIT testing)
- (maybe) netconf removal (becomes MRI, still need a vote)
We'll see how these two go next week.

Regards,
Robert


Re: Silicon code freeze...

Robert Varga
 

On 28/01/2021 19:28, Daniel de la Rosa wrote:
Hello TSC members and all

According to our release schedule 

https://docs.opendaylight.org/en/latest/release-process/release-schedule.html
<https://docs.opendaylight.org/en/latest/release-process/release-schedule.html>

Silicon code freeze is scheduled to happen on Feb 4th... but as you can
see from the checklist

https://wiki.opendaylight.org/display/ODL/Silicon+Formal+Release+Checklist
<https://wiki.opendaylight.org/display/ODL/Silicon+Formal+Release+Checklist>

I think we can wait a week since have plenty of time to release Silicon
by March 17th but please let me know if you have any objections
+1 we still have a lot of global activities to execute:

- odlparent-8.1 (ongoing)
- aaa removal (becomes MRI, the vote is just in)
- akka-2.6 integration (pending CSIT testing)
- genius removal (becomes MSI, we want to keep it in good shape)
- (maybe) netconf removal (becomes MRI, still need a vote)

Regards,
Robert


Re: [ODL Discuss] old wiki down

Casey Cain
 

Thanks for flagging this, Luis!

I'll follow-up when we know more.

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC: CaseyLF
WeChat: okaru6
Voice: +1.408.641.0193


On Fri, Jan 29, 2021 at 3:25 PM Luis Gomez <ecelgp@...> wrote:
FYI the old ODL wiki is down:

https://wiki-archive.opendaylight.org/

I opened ticket here:

https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21459

BR/Luis





old wiki down

Luis Gomez
 


Re: Turning AAA into a Release-Integrated project

Robert Varga
 

On 25/01/2021 11:49, Robert Varga wrote:
Hello everyone,

as I've been mentioning for past couple of releases, it is my intention
to peel the AAA project from autorelease and make it a Managed Release
Integrated project before Silicon branching occurs. This means AAA will
be in charge of producing its release artifacts and generally fall in
integration workflows designed for MRI projects.

The justification is three-fold:
- all of AAA's dependencies are release-integrated-
- the project is essentially dormant with the rate of change
well-controlled and mostly reacting to upstreams
- AAA is the last non-MRI dependency of NETCONF

As a AAA committer, do you have any objection to this change?
+1 from me.

If I don't hear any objections this week, I will default to pushing this
change through.
This makes it two out of four in favor with no objections.

I will work with autorelease and int/dist to make this happen next week.

Regards,
Robert

821 - 840 of 14317