Date   

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: Silicon General Release CSIT check

Anil Belur
 


On Wed, Mar 24, 2021 at 6:08 AM Luis Gomez <ecelgp@...> wrote:
I think you patch [1] fixed the issue:


We can maybe pick next AR build to see all netconf tests passing.

Also we need another patch [2] to move aaa and netconf CSIT to MRI once this issue [3] gets addressed in global-jib.

BR/Luis





Hello team:

The change in [3.] is no longer required as it's already addressed in releng/global-jjb CR (https://gerrit.linuxfoundation.org/infra/c/releng/global-jjb/+/67014).
The CR was waiting on a review/merge on the CR 67014 before proceeding with the releng/global-jjb release. 

Now CR 67014 is merged and releng/global-jjb v0.62.0 is released. Please merge releng/builder CR for the global-jjb 

Cheers,
Anil

 
On Mar 23, 2021, at 12:03 AM, Robert Varga <nite@...> wrote:

On 19/03/2021 06:44, Daniel de la Rosa wrote:
Hello TSC

We have picked a Silicon AR #228 as release candidate. 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/>

Here is the CSIT checklist so please review it ASAP

https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing
<https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing>

It looks like the netconf test suite is busted:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netconf-csit-1node-scale-only-silicon/250/robot-plugin/log.html.gz

Suite setup failed:
Artifact "netconf-testtool" in component "netconf" could not be downloaded from https://nexus.opendaylight.org/content/repositories//autorelease-4768/org/opendaylight/netconf/netconf-testtool/1.13.1/netconf-testtool-1.13.1-rest-perf-client.jar

Also suite teardown failed:
Variable '${testtool}' not found.

Since NETCONF is an MRI project in Silicon, the testtool should not be
downloaded from autorelease staging repo but rather from normal release
repo.

I do not know how to achieve, can someone from int/test take a look?

Regards,
Robert










Re: [E] Re: Release Interview

Robert Varga
 

On 25/03/2021 17:18, navid.ghazisaidi@... wrote:
Thanks Robert!

I was using this page (https://docs.opendaylight.org/projects/integration-distribution/en/latest/platform-versions.html) which just shows the targeted release number but as you mentioned it didn't cover all previous versions.
Yes, because that page is end-user collateral for Simultaneous Release.
As such, it is updated during each MRI bump. For example in Silicon, the
first update was here:
https://git.opendaylight.org/gerrit/c/integration/distribution/+/92972/4/docs/platform-versions.rst
as part of https://git.opendaylight.org/gerrit/q/topic:"silicon-mri",
just as
https://git.opendaylight.org/gerrit/c/docs/+/92934/3/docs/release-notes/upgrade-process.rst
was.

This sort of thing happens in every release between "Release Integrated
Deadline" and "Version Bump Checkpoint".

How about other projects? If you agree we should start mapping them to
the main release version (in this case silicon)? I remember we discussed
this before but can you help me recall the reason why we can't use the
main release name for MRI projects?

Quick answer to that is: because MRI projects are released way before
Simultaneous Release. As an example: Silicon is not released yet, but
yangtools-6.0.0 was released on October 8th, 2020.

The entire idea of a monolithic autorelease-based Simultaneous Release
(where you build all the projects and release them at the same time)
does not actually have a basis in our governance and has been introduced
as a reaction to, and a stop-gap solution for, how badly our very first
release (Hydrogen) went. That in turn was a result of us having been
SNAPSHOT-integrated across all projects and our pom.xml being a horrible
mess. Neither of those is true anymore.

Regards,
Robert


Thanks,
Navid


On 3/25/21, 3:24 AM, "Robert Varga" <nite@...> wrote:

On 25/03/2021 06:14, navid.ghazisaidi@... wrote:
> All,
>
>
>
> I just updated the filters of
> https://wiki.opendaylight.org/display/ODL/Silicon+Release
> <https://wiki.opendaylight.org/display/ODL/Silicon+Release> to pick up
> other tickets for netconf, etc.

Thanks.

> Note that for some project (e.g., ODL parent, YANG tools, and
> infrautils) I don’t see any results, not sure if there is any jira
> ticket that I can’t capture it or there is nothing…

The reason for that is that the filter needs to include *all* versions
of MRI projects as integrated into int/dist at the time of release, i.e.
the filter for odlparent is not 'is 8.1.1', but rather (as of this
writing) 'in [8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.1.0, 8.1.1]'.

For obvious reasons I am not willing to maintain the list of versions
anywhere but a git repository.

Regards,
Robert



Re: [ODL Discuss] ODL Helm chart

Daniel de la Rosa
 

+ Jeff Hartley


On Thu, Mar 25, 2021 at 11:52 AM Luis Gomez <ecelgp@...> wrote:
As I brought in today's TSC meeting, any decent IT app nowadays has a helm chart to quickly install in K8s.

Looking at some open source example:

https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus

It seems like we need to hold some helm definitions in our code repo for folks to perform:

helm repo add odl https://opendaylight.github.io/helm-charts

Also we need to publish docker containers somewhere so they can be used in a K8s Deployment file like this:

    spec:
      containers:
      - name: odl
        image: quay.io/opendaylight/netconf:v0.13.0
...

I am not an expert in K8s so let me know if I miss anything.

Anil, do you see any problem in existing ODL infra to achieve the above?

BR/Luis



ODL Helm chart

Luis Gomez
 

As I brought in today's TSC meeting, any decent IT app nowadays has a helm chart to quickly install in K8s.

Looking at some open source example:

https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus

It seems like we need to hold some helm definitions in our code repo for folks to perform:

helm repo add odl https://opendaylight.github.io/helm-charts

Also we need to publish docker containers somewhere so they can be used in a K8s Deployment file like this:

spec:
containers:
- name: odl
image: quay.io/opendaylight/netconf:v0.13.0
...

I am not an expert in K8s so let me know if I miss anything.

Anil, do you see any problem in existing ODL infra to achieve the above?

BR/Luis


Re: Silicon General Release CSIT check

Luis Gomez
 

Anil, please let us know when global-jib patch is merged as this is blocking CSIT jobs update.

BR/Luis

On Mar 24, 2021, at 8:59 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:

Hello all.. Sounds like we need to wait for @Anil Belur  to work on [2] and [3] to pick the next Silicon AR?  or we can move forward with just the NETCONF fix

Thanks

On Tue, Mar 23, 2021 at 1:08 PM Luis Gomez <ecelgp@...> wrote:
I think you patch [1] fixed the issue:


We can maybe pick next AR build to see all netconf tests passing.

Also we need another patch [2] to move aaa and netconf CSIT to MRI once this issue [3] gets addressed in global-jib.

BR/Luis


On Mar 23, 2021, at 12:03 AM, Robert Varga <nite@...> wrote:

On 19/03/2021 06:44, Daniel de la Rosa wrote:
Hello TSC

We have picked a Silicon AR #228 as release candidate. 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/>

Here is the CSIT checklist so please review it ASAP

https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing
<https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing>

It looks like the netconf test suite is busted:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netconf-csit-1node-scale-only-silicon/250/robot-plugin/log.html.gz

Suite setup failed:
Artifact "netconf-testtool" in component "netconf" could not be downloaded from https://nexus.opendaylight.org/content/repositories//autorelease-4768/org/opendaylight/netconf/netconf-testtool/1.13.1/netconf-testtool-1.13.1-rest-perf-client.jar

Also suite teardown failed:
Variable '${testtool}' not found.

Since NETCONF is an MRI project in Silicon, the testtool should not be
downloaded from autorelease staging repo but rather from normal release
repo.

I do not know how to achieve, can someone from int/test take a look?

Regards,
Robert








Re: Release Interview

Robert Varga
 

Hello everyone,

I would also like to raise two concerns:

1) this particular conversation is point-to-point and not on mailing
list. I do not see *any* reason for it to be private, so can everyone
here *default* to mailing lists, please?

2) we are slipping more and more into *only* using meetings. There is
very little in terms of asynchronous (and public) communication going on
-- and very quickly 'on meetings' is becoming the only place where any
work is being done.

If you look at LFX, the second trend is clearly visible in graphs when
you look at on which days things tend to happen.

I am not sure what 'interview' is meant to mean here.

Honestly, as the guy who contributed 53% of changes in past 6 months and
83.5% of changes in last 90 days, I just do not have the cycles to
edit/maintain wiki pages -- this is effectively creating reports and as
such it *must* be automated. Any and all maintenance must be a natural
part of the development workflow -- i.e. things like 'which versions are
in Silicon MRI' absolutely must have a single place in Gerrit and that
place needs to be updated as part of the version bump process -- just
like
https://docs.opendaylight.org/projects/integration-distribution/en/latest/platform-versions.html
is.

I have raised the issue of our release notes templates being unusable to
pretty much everyone at least three times over the course of past three
years, yet nothing has changed.

They are useless to developers, simply because things are not tied to
anything developer-tangible. It is unusable to marketing, because it
deals with 'features' and similar technical constructs. It is useless to
our end users, as it is not tied to use cases.

Each and every single release we go through the same exercise and basics
do not change.

Per-project release notes should look something like:
https://www.eclipse.org/xtend/releasenotes.html#/releasenotes/2021/03/02/version-2-25-0
-- note how pretty much everything in that is easily scripted and automated.

The overall SimRel notes should look something like:
https://www.eclipse.org/eclipse/news/4.19/

Both of those should be created in a collaborative and open fashion and
ultimately hosted in a git repository (probably docs).

As for timing, please understand that these documents come to life at
SimRel start and *NOT* just before SimRel is released -- they need to be
*finalized* in the few weeks between code freeze and release
announcement. What that means in concrete terms is that for Silicon
these should have been started on 2020-09-17 at the latest -- and
preferably just after 2020-08-03.

Regards,
Robert

On 25/03/2021 12:04, guillaume.lambert@... wrote:
Hi all

 

Brandon, Casey, I’d be happy to give you my thought but if you really
need them by this Friday, the best I can do is Friday 10pm Paris Time (=
2pm  LA time).

If Robert wants to make the interview, I am also fine with that as long
as the whole TSC is OK.

 

I share Casey’s concern that this topic risks to absorb the whole TSC
meeting.

Daniel, is that fine if we limit this talk to 10 to review the deadlines
and organize ourselves ?.

 

If we did talk about this marketing message a fortnight ago, some
projects did only have one meeting to react since then.

And we have still pending technical issues to fix before broadcasting
any marketing message.

Silicon Managed projects have not been released or approved yet. SM
projects are still working hard to wrap up.

So I can understand some of them have not filled the wiki yet.

 

As a PTL, I’ve raised the topics several times to the TransportPCE
contributors during our syncs but they are all pretty busy.

AT&T contributors were struggling with a bug to prepare their demo for
the OFC conference and Orange was preparing another demo for MDONS.

During this release, Nokia and Eurecom also proposed additional
interesting contributions that were not planned initially and that we
just integrated.

Thus, we have to rework our message and if it is now ready from the
Orange side,  we are still validating its contents with the other
companies at that moment.

I don’t think it would be fair to not include everyone.

 

Also let’s not mistake haste for speed.

In the past, these people noticed their message was modified by the
marketing and they didn’t have a chance to react to these modifications.
For example in Neon, they told me that they would have liked to change
the term “degree” which has a different meaning in WDM.

If the message was really OK for non-optical expert, it was really
confusing for the optical professionals.

I’d really like that we take the time to talk on how we can avoid this
kind of situation for future releases.

 

Best Regards

Guillaume

 

 

*De :*Daniel de la Rosa [mailto:ddelarosa0707@...]
*Envoyé :* jeudi 25 mars 2021 05:36
*À :* Casey Cain; Robert Varga; Luis Gomez; navid.ghazisaidi@...
*Cc :* LAMBERT Guillaume TGI/OLN; Brandon Wick
*Objet :* Re: Release Interview

 

Indeed we talked about it so let me add Robert so he can let us know why
this wiki page doesn't include NETCONF and other of his projects. Let me
also add Navid and Luis since we all talked about this during a TSC
meeting. 

 

On Wed, Mar 24, 2021 at 11:55 AM Casey Cain <ccain@...
<mailto:ccain@...>> wrote:

We discussed this at the last 2 TSC meetings and even mentioned it a
few times before.  We have an outstanding action item for the
Release Manager and the PTLs to ensure that the information on this
wiki page <https://wiki.opendaylight.org/x/GRsF> is accurate and
complete prior to March 24th.

The purpose of the Interview is to give a chance for the face of the
community, the TSC chair to provide their thoughts on the release
and to highlight important changes.

 

In the past when we tried to have the "Release Interview" with the
entire TSC we have had issues with staying on topic and developing
relevant marketing messaging.  If you think it would be best to
approach Robert to do the release interview, please let me know.

 

Best,

Casey Cain

Technical Program Manager / Community Architect

Linux Foundation

_________________

IRC: CaseyLF

WeChat: okaru6

Voice: +1.408.641.0193

Book a Meeting w/ Casey <http://calendly.com/caseylf>

 

 

On Wed, Mar 24, 2021 at 11:34 AM <guillaume.lambert@...
<mailto:guillaume.lambert@...>> wrote:

No objection.

I let you propose it at the meeting start.

 

*De :*Daniel de la Rosa [mailto:ddelarosa0707@...
<mailto:ddelarosa0707@...>]
*Envoyé :* mercredi 24 mars 2021 15:06
*À :* LAMBERT Guillaume TGI/OLN
*Cc :* Casey Cain; Brandon Wick
*Objet :* Re: Release Interview

 

Hello all. I'm not available either but also, we are going to
need Robert and potentially others since they are more fully
aware of what's new in Silicon. Maybe we can just use the whole
TSC meeting to review this?

 

Thanks

 

On Wed, Mar 24, 2021 at 1:23 AM <guillaume.lambert@...
<mailto:guillaume.lambert@...>> wrote:

Hi all

 

My agenda is already full this Friday afternoon ( 7am PST is
3pm Paris Time this week)

Can it wait for Monday ? Potentially anytime at your
convenience.

 

Best Regards

Guillaume

 

------------------------------------------------------------------------

*De :*Casey Cain [ccain@...
<mailto:ccain@...>]
*Envoyé :* mardi 23 mars 2021 21:32
*À :* LAMBERT Guillaume TGI/OLN; Daniel de la Rosa
*Cc :* Brandon Wick
*Objet :* Release Interview

Hi, Guillaume and Daniel.

 

As we discussed previously there is a need to confirm the
release features of Silicon and set up an interview with
yourself for marketing purposes.  Can we schedule this
interview for this Friday at 7 am PST?

I will also confirm with you on this week's TSC call that
the necessary information has already been collected and
posted to the wiki.

 

Thanks!!

Casey Cain

Technical Program Manager / Community Architect

Linux Foundation

_________________

IRC: CaseyLF

WeChat: okaru6

Voice: +1.408.641.0193

Book a Meeting w/ Casey <http://calendly.com/caseylf>

_________________________________________________________________________________________________________________________

 

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.

_________________________________________________________________________________________________________________________

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 General Release CSIT check

Daniel de la Rosa
 

Hello all.. Sounds like we need to wait for @Anil Belur  to work on [2] and [3] to pick the next Silicon AR?  or we can move forward with just the NETCONF fix

Thanks

On Tue, Mar 23, 2021 at 1:08 PM Luis Gomez <ecelgp@...> wrote:
I think you patch [1] fixed the issue:


We can maybe pick next AR build to see all netconf tests passing.

Also we need another patch [2] to move aaa and netconf CSIT to MRI once this issue [3] gets addressed in global-jib.

BR/Luis


On Mar 23, 2021, at 12:03 AM, Robert Varga <nite@...> wrote:

On 19/03/2021 06:44, Daniel de la Rosa wrote:
Hello TSC

We have picked a Silicon AR #228 as release candidate. 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/>

Here is the CSIT checklist so please review it ASAP

https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing
<https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing>

It looks like the netconf test suite is busted:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netconf-csit-1node-scale-only-silicon/250/robot-plugin/log.html.gz

Suite setup failed:
Artifact "netconf-testtool" in component "netconf" could not be downloaded from https://nexus.opendaylight.org/content/repositories//autorelease-4768/org/opendaylight/netconf/netconf-testtool/1.13.1/netconf-testtool-1.13.1-rest-perf-client.jar

Also suite teardown failed:
Variable '${testtool}' not found.

Since NETCONF is an MRI project in Silicon, the testtool should not be
downloaded from autorelease staging repo but rather from normal release
repo.

I do not know how to achieve, can someone from int/test take a look?

Regards,
Robert







Re: [E] RE: Jira tickets fields

Guillaume Lambert
 

You’re welcome.

It’s up to you where you want to put it.

You can use newcomers guide but you can also create a dedicated page since  this mostly concerns PTL and committers.

 

Guillaume

 

De : navid.ghazisaidi@... [mailto:navid.ghazisaidi@...]
Envoyé : mercredi 24 mars 2021 17:09
À : LAMBERT Guillaume TGI/OLN; ODL Docs (documentation@...); TSC@...
Cc : Casey Cain (ccain@...); Daniel de la Rosa
Objet : Re: [E] RE: Jira tickets fields

 

I forgot that, thanks for reminding me, Guillaume!

 

Should we put it under https://docs.opendaylight.org/en/latest/contributor-guides/newcomers-guide.html ?

 

Thanks,

Navid

 

 

From: "guillaume.lambert@..." <guillaume.lambert@...>
Date: Wednesday, March 24, 2021 at 3:28 AM
To: Navid <navid.ghazisaidi@...>, "ODL Docs (documentation@...)" <documentation@...>, "TSC@..." <TSC@...>
Cc: "Casey Cain (ccain@...)" <ccain@...>, Daniel de la Rosa <ddelarosa0707@...>
Subject: [E] RE: Jira tickets fields

 

Thanks Navid

 

For information, most of best practices have now been migrated to the documentation contributor guides

at https://docs.opendaylight.org/en/latest/contributor-guides/index.html

 

Guillaume

 

 

 

De : TSC@... [mailto:TSC@...] De la part de navid.ghazisaidi via lists.opendaylight.org
Envoyé : mardi 23 mars 2021 21:08
À : ODL Docs (documentation@...); TSC@...
Cc : Casey Cain (ccain@...); Daniel de la Rosa
Objet : [OpenDaylight TSC] Jira tickets fields

 

Hi All,

 

Here is the list of fields I believe we should make them mandatory in any jira ticket. I have added description with some example values for each field. As mentioned in our last TSC call, this may help automating the project release tracking and release notes publication.

 

please let me know what your thoughts are.

 

We should also find a good place in wiki to publish it. Maybe under Best Practices (https://wiki-archive.opendaylight.org/view/BestPractices)?

 

Thanks,

Navid

 

 

Project:

description: project name

values: aaa/bgpcep/controller/daexim/distribution/infrautils/jsonrpc/lispflowmapping/netconf/netvirt/openflowplugin/ovsdb/serviceutils/tpce

 

Priority:

description: the importance of ticket

values: Highest, High, Medium, Low, Lowest

 

Type:

description: issue type

values: Bug/New Feature/Task/Improvement/Deprecate

 

Status:

description: the status of ticket

values: Open/In Progress/In Review/Confirmed/Verified/Resolved/Closed/Done/Open

 

affectedVersion:

description: the version that the issue was seen (it’s only applicable to bugs)

values: aluminum/silicon/etc.; “None” to be used for anything other than “Bug”

 

fixVersion:

description: the version that includes the bug fix, new feature, behavior/feature change (improvement), or deprecated feature (the first time that the feature is being disappeared)

values: aluminum/silicon/etc.

 

 

_________________________________________________________________________________________________________________________
 
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.


Re: [E] RE: Jira tickets fields

Ghazisaidi, Navid
 

I forgot that, thanks for reminding me, Guillaume!

 

Should we put it under https://docs.opendaylight.org/en/latest/contributor-guides/newcomers-guide.html ?

 

Thanks,

Navid

 

 

From: "guillaume.lambert@..." <guillaume.lambert@...>
Date: Wednesday, March 24, 2021 at 3:28 AM
To: Navid <navid.ghazisaidi@...>, "ODL Docs (documentation@...)" <documentation@...>, "TSC@..." <TSC@...>
Cc: "Casey Cain (ccain@...)" <ccain@...>, Daniel de la Rosa <ddelarosa0707@...>
Subject: [E] RE: Jira tickets fields

 

Thanks Navid

 

For information, most of best practices have now been migrated to the documentation contributor guides

at https://docs.opendaylight.org/en/latest/contributor-guides/index.html

 

Guillaume

 

 

 

De : TSC@... [mailto:TSC@...] De la part de navid.ghazisaidi via lists.opendaylight.org
Envoyé : mardi 23 mars 2021 21:08
À : ODL Docs (documentation@...); TSC@...
Cc : Casey Cain (ccain@...); Daniel de la Rosa
Objet : [OpenDaylight TSC] Jira tickets fields

 

Hi All,

 

Here is the list of fields I believe we should make them mandatory in any jira ticket. I have added description with some example values for each field. As mentioned in our last TSC call, this may help automating the project release tracking and release notes publication.

 

please let me know what your thoughts are.

 

We should also find a good place in wiki to publish it. Maybe under Best Practices (https://wiki-archive.opendaylight.org/view/BestPractices)?

 

Thanks,

Navid

 

 

Project:

description: project name

values: aaa/bgpcep/controller/daexim/distribution/infrautils/jsonrpc/lispflowmapping/netconf/netvirt/openflowplugin/ovsdb/serviceutils/tpce

 

Priority:

description: the importance of ticket

values: Highest, High, Medium, Low, Lowest

 

Type:

description: issue type

values: Bug/New Feature/Task/Improvement/Deprecate

 

Status:

description: the status of ticket

values: Open/In Progress/In Review/Confirmed/Verified/Resolved/Closed/Done/Open

 

affectedVersion:

description: the version that the issue was seen (it’s only applicable to bugs)

values: aluminum/silicon/etc.; “None” to be used for anything other than “Bug”

 

fixVersion:

description: the version that includes the bug fix, new feature, behavior/feature change (improvement), or deprecated feature (the first time that the feature is being disappeared)

values: aluminum/silicon/etc.

 

 

_________________________________________________________________________________________________________________________
 
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.


TSC Meeting for March 25, 2021 at 9 am Pacific

Guillaume Lambert
 

Hello OpenDaylight Community,

 

Next TSC meeting is March 25, 2021 at 9 am Pacific Time.
The agenda proposal and the connection details for this meeting are available at the following URL:

https://wiki.opendaylight.org/x/zxsF

 

If you need to add anything, please let me know or add it there.
The meeting minutes will be at the same location after the meeting is over.

 

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: Jira tickets fields

Guillaume Lambert
 

Thanks Navid

 

For information, most of best practices have now been migrated to the documentation contributor guides

at https://docs.opendaylight.org/en/latest/contributor-guides/index.html

 

Guillaume

 

 

 

De : TSC@... [mailto:TSC@...] De la part de navid.ghazisaidi via lists.opendaylight.org
Envoyé : mardi 23 mars 2021 21:08
À : ODL Docs (documentation@...); TSC@...
Cc : Casey Cain (ccain@...); Daniel de la Rosa
Objet : [OpenDaylight TSC] Jira tickets fields

 

Hi All,

 

Here is the list of fields I believe we should make them mandatory in any jira ticket. I have added description with some example values for each field. As mentioned in our last TSC call, this may help automating the project release tracking and release notes publication.

 

please let me know what your thoughts are.

 

We should also find a good place in wiki to publish it. Maybe under Best Practices (https://wiki-archive.opendaylight.org/view/BestPractices)?

 

Thanks,

Navid

 

 

Project:

description: project name

values: aaa/bgpcep/controller/daexim/distribution/infrautils/jsonrpc/lispflowmapping/netconf/netvirt/openflowplugin/ovsdb/serviceutils/tpce

 

Priority:

description: the importance of ticket

values: Highest, High, Medium, Low, Lowest

 

Type:

description: issue type

values: Bug/New Feature/Task/Improvement/Deprecate

 

Status:

description: the status of ticket

values: Open/In Progress/In Review/Confirmed/Verified/Resolved/Closed/Done/Open

 

affectedVersion:

description: the version that the issue was seen (it’s only applicable to bugs)

values: aluminum/silicon/etc.; “None” to be used for anything other than “Bug”

 

fixVersion:

description: the version that includes the bug fix, new feature, behavior/feature change (improvement), or deprecated feature (the first time that the feature is being disappeared)

values: aluminum/silicon/etc.

 

 

_________________________________________________________________________________________________________________________

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 General Release CSIT check

Luis Gomez
 

I think you patch [1] fixed the issue:


We can maybe pick next AR build to see all netconf tests passing.

Also we need another patch [2] to move aaa and netconf CSIT to MRI once this issue [3] gets addressed in global-jib.

BR/Luis


On Mar 23, 2021, at 12:03 AM, Robert Varga <nite@...> wrote:

On 19/03/2021 06:44, Daniel de la Rosa wrote:
Hello TSC

We have picked a Silicon AR #228 as release candidate. 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/>

Here is the CSIT checklist so please review it ASAP

https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing
<https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing>

It looks like the netconf test suite is busted:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netconf-csit-1node-scale-only-silicon/250/robot-plugin/log.html.gz

Suite setup failed:
Artifact "netconf-testtool" in component "netconf" could not be downloaded from https://nexus.opendaylight.org/content/repositories//autorelease-4768/org/opendaylight/netconf/netconf-testtool/1.13.1/netconf-testtool-1.13.1-rest-perf-client.jar

Also suite teardown failed:
Variable '${testtool}' not found.

Since NETCONF is an MRI project in Silicon, the testtool should not be
downloaded from autorelease staging repo but rather from normal release
repo.

I do not know how to achieve, can someone from int/test take a look?

Regards,
Robert







Jira tickets fields

Ghazisaidi, Navid
 

Hi All,

 

Here is the list of fields I believe we should make them mandatory in any jira ticket. I have added description with some example values for each field. As mentioned in our last TSC call, this may help automating the project release tracking and release notes publication.

 

please let me know what your thoughts are.

 

We should also find a good place in wiki to publish it. Maybe under Best Practices (https://wiki-archive.opendaylight.org/view/BestPractices)?

 

Thanks,

Navid

 

 

Project:

description: project name

values: aaa/bgpcep/controller/daexim/distribution/infrautils/jsonrpc/lispflowmapping/netconf/netvirt/openflowplugin/ovsdb/serviceutils/tpce

 

Priority:

description: the importance of ticket

values: Highest, High, Medium, Low, Lowest

 

Type:

description: issue type

values: Bug/New Feature/Task/Improvement/Deprecate

 

Status:

description: the status of ticket

values: Open/In Progress/In Review/Confirmed/Verified/Resolved/Closed/Done/Open

 

affectedVersion:

description: the version that the issue was seen (it’s only applicable to bugs)

values: aluminum/silicon/etc.; “None” to be used for anything other than “Bug”

 

fixVersion:

description: the version that includes the bug fix, new feature, behavior/feature change (improvement), or deprecated feature (the first time that the feature is being disappeared)

values: aluminum/silicon/etc.

 

 


Re: Silicon General Release CSIT check

Robert Varga
 

On 19/03/2021 06:44, Daniel de la Rosa wrote:
Hello TSC

We have picked a Silicon AR #228 as release candidate. 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/
<https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-silicon-mvn35-openjdk11/228/>

Here is the CSIT checklist so please review it ASAP

https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing
<https://docs.google.com/spreadsheets/d/1zvD4xgiMlWCgg5ZBvxSRONY_LtLtzzNUeuA06-i7ukc/edit?usp=sharing>
It looks like the netconf test suite is busted:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netconf-csit-1node-scale-only-silicon/250/robot-plugin/log.html.gz

Suite setup failed:
Artifact "netconf-testtool" in component "netconf" could not be downloaded from https://nexus.opendaylight.org/content/repositories//autorelease-4768/org/opendaylight/netconf/netconf-testtool/1.13.1/netconf-testtool-1.13.1-rest-perf-client.jar

Also suite teardown failed:
Variable '${testtool}' not found.
Since NETCONF is an MRI project in Silicon, the testtool should not be
downloaded from autorelease staging repo but rather from normal release
repo.

I do not know how to achieve, can someone from int/test take a look?

Regards,
Robert


Silicon General Release CSIT check

Daniel de la Rosa
 


Re: [release] Silicon: next steps for Genius

Daniel de la Rosa
 

Robert and team

I'm still seeing Genius in AR... this is from the logs


Is this expected?

On Mon, Feb 1, 2021 at 2:43 PM Robert Varga <nite@...> wrote:
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
>>
>>
>>
>>
>>
>





Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

Luis Gomez
 

On Mar 18, 2021, at 6:02 PM, Luis Gomez via lists.opendaylight.org <ecelgp=gmail.com@...> wrote:

Yep, SNAPSHOT artifacts used in the common distribution have expired and got deleted because we let long time between Managed distribution release and Common distribution release.

This is the first time that this happens and has exposed some issues in the distribution repo. I will have to craft something in Jenkins to make this work, more info in tonight's meeting.

BR/Luis


On Mar 18, 2021, at 5:48 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:

Ok now that TransportPCE is done, @Luis Gomez  will move forward with distribution once he fixes some issues with the snapshots artifacts. 

Thanks




On Fri, Mar 12, 2021 at 6:33 AM <guillaume.lambert@...> wrote:

Hello

 

Thanks Anil.  I just released TransportPCE v 2.3.0 for Al SR3.

Let me know if there is any issue with it.

 

Though I didn’t need to merge anything for Al SR3, it seems that tpce stable/aluminium branch still appears locked.

 

Best Regards

Guillaume

 

 

De : Anil Belur [mailto:abelur@...]
Envoyé : vendredi 12 mars 20
21 03:49
À : Daniel de la Rosa
Cc : Casey Cain; LAMBERT Guillaume TGI/OLN; Luis Gomez; Release; Robert Varga; TSC
Objet : Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

 

Hello All,

OpenDaylight Aluminium SR3 version bump is complete and the staging repository has 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 SR3.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [0.].

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/+/95492

 

On Fri, Mar 12, 2021 at 10:07 AM Daniel de la Rosa <ddelarosa0707@...> wrote:

Anil and all. It was decided today to move forward with AR #370 as Aluminium SR3

 

Thanks 

 

On Wed, Mar 10, 2021 at 6:38 PM Anil Belur <abelur@...> wrote:

Hi Guillaume, 

 

+1, we can proceed with AR #370. Waiting on the other TSC members to weigh in.

 

Regards,

Anil

 

On Wed, Mar 10, 2021 at 8:49 PM <guillaume.lambert@...> wrote:

Hi Anil

 

Both options are fine in my opinion. What’s yours ?

With Silicon deadline coming soon, maybe AR #370 will be more straightforward.

 

Best regards

Guillaume

 

De : release@... [mailto:release@...] De la part de Anil Belur
Envoyé : mercredi 10 mars 2021 01:34
À : Daniel de la Rosa; TSC; Release
Cc : Luis Gomez; Robert Varga; Casey Cain
Objet : Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

 

 

 

On Mon, Mar 8, 2021 at 1:28 PM Anil Belur <abelur@...> wrote:

Greetings Team:

The version bump job for the Aluminimum SR3 release is failing, therefore we are blocked on the release till the outstanding issue with AR builds is resolved.

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-version-bump-aluminium-mvn35-openjdk11/11/consoleFull

After digging around I have noticed that we have gone ahead with voting on the release without putting the code freeze in place beforehand. To proceed with the SR3 release, firstly we have to code freeze the Aluminium branch (which has been done now), resolve the outstanding issues with the AR builds #394 is failing.

[1.] https://jira.linuxfoundation.org/browse/IT-21671

Thanks,
Anil 

 

Hello TSC members:

 

The version bump issue has been resolved now with the below CR's. the version bump job is going through now in #12:

 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-version-bump-aluminium-mvn35-openjdk11/12/

https://git.opendaylight.org/gerrit/c/releng/builder/+/95455        
https://git.opendaylight.org/gerrit/c/releng/builder/+/95456

 

The question is if we can we proceed with releasing the existing AR #370 (as per vote: https://wiki.opendaylight.org/display/ODL/Aluminum+SR3+Release+Approval), since the staging repo has been promoted or do we need to go with a new AR, then we need to take the new AR build #395 and proceed with the CSIT checklist for #374.

 

 

Regards,

Anil 

_________________________________________________________________________________________________________________________
 
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.






Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

Luis Gomez
 

Yep, SNAPSHOT artifacts used in the common distribution have expired and got deleted because we let long time between Managed distribution release and Common distribution release.

This is the first time that this happens and has exposed some issues in the distribution repo. I will have to craft something in Jenkins to make this work, more info in tonight's meeting.

BR/Luis


On Mar 18, 2021, at 5:48 PM, Daniel de la Rosa <ddelarosa0707@...> wrote:

Ok now that TransportPCE is done, @Luis Gomez  will move forward with distribution once he fixes some issues with the snapshots artifacts. 

Thanks




On Fri, Mar 12, 2021 at 6:33 AM <guillaume.lambert@...> wrote:

Hello

 

Thanks Anil.  I just released TransportPCE v 2.3.0 for Al SR3.

Let me know if there is any issue with it.

 

Though I didn’t need to merge anything for Al SR3, it seems that tpce stable/aluminium branch still appears locked.

 

Best Regards

Guillaume

 

 

De : Anil Belur [mailto:abelur@...]
Envoyé : vendredi 12 mars 20
21 03:49
À : Daniel de la Rosa
Cc : Casey Cain; LAMBERT Guillaume TGI/OLN; Luis Gomez; Release; Robert Varga; TSC
Objet : Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

 

Hello All,

OpenDaylight Aluminium SR3 version bump is complete and the staging repository has 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 SR3.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [0.].

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/+/95492

 

On Fri, Mar 12, 2021 at 10:07 AM Daniel de la Rosa <ddelarosa0707@...> wrote:

Anil and all. It was decided today to move forward with AR #370 as Aluminium SR3

 

Thanks 

 

On Wed, Mar 10, 2021 at 6:38 PM Anil Belur <abelur@...> wrote:

Hi Guillaume, 

 

+1, we can proceed with AR #370. Waiting on the other TSC members to weigh in.

 

Regards,

Anil

 

On Wed, Mar 10, 2021 at 8:49 PM <guillaume.lambert@...> wrote:

Hi Anil

 

Both options are fine in my opinion. What’s yours ?

With Silicon deadline coming soon, maybe AR #370 will be more straightforward.

 

Best regards

Guillaume

 

De : release@... [mailto:release@...] De la part de Anil Belur
Envoyé : mercredi 10 mars 2021 01:34
À : Daniel de la Rosa; TSC; Release
Cc : Luis Gomez; Robert Varga; Casey Cain
Objet : Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

 

 

 

On Mon, Mar 8, 2021 at 1:28 PM Anil Belur <abelur@...> wrote:

Greetings Team:

The version bump job for the Aluminimum SR3 release is failing, therefore we are blocked on the release till the outstanding issue with AR builds is resolved.

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-version-bump-aluminium-mvn35-openjdk11/11/consoleFull

After digging around I have noticed that we have gone ahead with voting on the release without putting the code freeze in place beforehand. To proceed with the SR3 release, firstly we have to code freeze the Aluminium branch (which has been done now), resolve the outstanding issues with the AR builds #394 is failing.

[1.] https://jira.linuxfoundation.org/browse/IT-21671

Thanks,
Anil 

 

Hello TSC members:

 

The version bump issue has been resolved now with the below CR's. the version bump job is going through now in #12:

 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-version-bump-aluminium-mvn35-openjdk11/12/

https://git.opendaylight.org/gerrit/c/releng/builder/+/95455        
https://git.opendaylight.org/gerrit/c/releng/builder/+/95456

 

The question is if we can we proceed with releasing the existing AR #370 (as per vote: https://wiki.opendaylight.org/display/ODL/Aluminum+SR3+Release+Approval), since the staging repo has been promoted or do we need to go with a new AR, then we need to take the new AR build #395 and proceed with the CSIT checklist for #374.

 

 

Regards,

Anil 

_________________________________________________________________________________________________________________________
 
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.


Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

Daniel de la Rosa
 

Ok now that TransportPCE is done, @Luis Gomez  will move forward with distribution once he fixes some issues with the snapshots artifacts. 

Thanks




On Fri, Mar 12, 2021 at 6:33 AM <guillaume.lambert@...> wrote:

Hello

 

Thanks Anil.  I just released TransportPCE v 2.3.0 for Al SR3.

Let me know if there is any issue with it.

 

Though I didn’t need to merge anything for Al SR3, it seems that tpce stable/aluminium branch still appears locked.

 

Best Regards

Guillaume

 

 

De : Anil Belur [mailto:abelur@...]
Envoyé : vendredi 12 mars 20
21 03:49
À : Daniel de la Rosa
Cc : Casey Cain; LAMBERT Guillaume TGI/OLN; Luis Gomez; Release; Robert Varga; TSC
Objet : Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

 

Hello All,

OpenDaylight Aluminium SR3 version bump is complete and the staging repository has 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 SR3.
2. Release Distribution once the 1. is complete.
3. Release notes - to be merged CR [1.]
4. Update ODL downloads page [0.].

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/+/95492

 

On Fri, Mar 12, 2021 at 10:07 AM Daniel de la Rosa <ddelarosa0707@...> wrote:

Anil and all. It was decided today to move forward with AR #370 as Aluminium SR3

 

Thanks 

 

On Wed, Mar 10, 2021 at 6:38 PM Anil Belur <abelur@...> wrote:

Hi Guillaume, 

 

+1, we can proceed with AR #370. Waiting on the other TSC members to weigh in.

 

Regards,

Anil

 

On Wed, Mar 10, 2021 at 8:49 PM <guillaume.lambert@...> wrote:

Hi Anil

 

Both options are fine in my opinion. What’s yours ?

With Silicon deadline coming soon, maybe AR #370 will be more straightforward.

 

Best regards

Guillaume

 

De : release@... [mailto:release@...] De la part de Anil Belur
Envoyé : mercredi 10 mars 2021 01:34
À : Daniel de la Rosa; TSC; Release
Cc : Luis Gomez; Robert Varga; Casey Cain
Objet : Re: [opendaylight-dev][release] OpenDaylight - Aluminium SR3 release status

 

 

 

On Mon, Mar 8, 2021 at 1:28 PM Anil Belur <abelur@...> wrote:

Greetings Team:

The version bump job for the Aluminimum SR3 release is failing, therefore we are blocked on the release till the outstanding issue with AR builds is resolved.

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-version-bump-aluminium-mvn35-openjdk11/11/consoleFull

After digging around I have noticed that we have gone ahead with voting on the release without putting the code freeze in place beforehand. To proceed with the SR3 release, firstly we have to code freeze the Aluminium branch (which has been done now), resolve the outstanding issues with the AR builds #394 is failing.

[1.] https://jira.linuxfoundation.org/browse/IT-21671

Thanks,
Anil 

 

Hello TSC members:

 

The version bump issue has been resolved now with the below CR's. the version bump job is going through now in #12:

 

https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-version-bump-aluminium-mvn35-openjdk11/12/

https://git.opendaylight.org/gerrit/c/releng/builder/+/95455        
https://git.opendaylight.org/gerrit/c/releng/builder/+/95456

 

The question is if we can we proceed with releasing the existing AR #370 (as per vote: https://wiki.opendaylight.org/display/ODL/Aluminum+SR3+Release+Approval), since the staging repo has been promoted or do we need to go with a new AR, then we need to take the new AR build #395 and proceed with the CSIT checklist for #374.

 

 

Regards,

Anil 

_________________________________________________________________________________________________________________________
 
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.

781 - 800 of 14351