Re: [ODL Discuss] [release] [OpenDaylight TSC] [TSC][Discuss] ODL Jira & Confluence Migration to Atlassian Cloud - Scheduled for August 26th

[Robert Varga]

On 23/08/2024 8.54 am, Anil Belur wrote:



On Fri, Aug 23, 2024 at 3:18 PM Michal Chochula 
 wrote:


Hello Anil, thank you for the update.
But it Seems like redirects still are not working. ODL team at
Pantheon is actively using and depending on content from ODL JIRA.
Redirects not working is kind of annoying. Can you please check?
Currently when I click for example
https://jira.opendaylight.org/browse/NETCONF-873
 It ends up with
404 not found.

Thank you
Michal


Hi Michal: I'll look into this and get back to you.


Hello Anil,

so the problem is that


https://jira.opendaylight.org/projects/ODLPARENT?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released


ends up being redirected to


https://lf-opendaylight.atlassian.net/jira/projects/ODLPARENT?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released


whereas the correct page is


https://lf-opendaylight.atlassian.net/projects/ODLPARENT?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released


i.e. *without* the '/jira' prefix.

As of now, all of my jira.opendaylight.org links I have remembered in my 
browser are unusable.


Can you expedite the fix, please?

Thanks,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9134): https://lists.opendaylight.org/g/Discuss/message/9134
Mute This Topic: https://lists.opendaylight.org/mt/108077505/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] [app-dev] Segment Routing + PCE + PCEP + BGP-LS support in ODL Carbon release

[Robert Varga]

On 04/08/2024 5.43 pm, kals wrote:

Hi Experts,


Hello "__kals__",


I would like to know whether *_Carbon _*release will support the following:


the relevant documentation is available at 
https://docs.opendaylight.org/en/stable-carbon/user-guide/bgp-user-guide.html 
and 
https://docs.opendaylight.org/en/stable-carbon/user-guide/pcep-user-guide.html




1) BGP-LS support :
    - BGP Link state protocol for learning the topology (links and nodes)


Yes.



2) PCE support :
    - Does ODL have the support of PCE to compute a path between two 
endpoints with the given constraints.


Yes.


    - ODL has PCE inbuilt support ?


Yes.



3) PCEP support:
     - ODL can create a PCEP session between ODL and the node after 
learning the topology ?


Yes.



4) Segment Routing support:
     - Does ODL have Segment Routing support also ?


Yes.

5) Is it possible for a user to create a static SR tunnel/ LSP through 
CLI commands ?


No. Pretty much all of of the corresponding configuration is done via 
RESTCONF, please refer to the documentation mentioned above.


Can I use the latest ODL version or any particular version of ODL will 
onlysupport it?


As such, BGP/PCEP features have been stable for a long time, but there 
have been some changes since 2017.03 Carbon SR3 (Apr 2018).


As per 
https://docs.opendaylight.org/en/stable-potassium/release-process/release-schedule.html, 
the community supports only 2023.09 Potassium, i.e SR3, or later.



Experts:
   Kindly clarify all my doubts. I am not using Calcium as it does 
not have GUI support hence I am using Carbon.


We do not support anything "GUI" for a long time, as it is not our core 
competency. We do provide API explorer-type thing via 
odl-restconf-openapi. That is as good as a GUI for vast majority of use 
cases, and certainly on part with what we have provided via GUI for 
BGP/PCEP in the past.


You essentially have two options:
1) upgrade to 2023.09 Potassium SR3 or laster
2) engage community-external professional services, such as those 
available at sa...@pantheon.tech


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9124): https://lists.opendaylight.org/g/Discuss/message/9124
Mute This Topic: https://lists.opendaylight.org/mt/107744523/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] Support of SFC from Opendaylight

[Robert Varga]

On 17/03/2024 07.51, Thomas Jonathan Jackson wrote:

Hello sir.


Hello,

I'd like to know why Opendaylight Stopped supporting SFC(Service 
Function Chaining) feature in new versions.


The reason was a lack of contributors willing to keep the project alive.

The project opted to not participate in the Simultaneous Release in 
October 2019: https://lists.opendaylight.org/g/TSC/message/12005


The project was then archived due to inactivity along with a slew of 
other projects in the April-August 2021 timeframe:

https://lists.opendaylight.org/g/TSC/message/13666
https://wiki.opendaylight.org/display/ODL/Bulk+Archive+Approval

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9087): https://lists.opendaylight.org/g/Discuss/message/9087
Mute This Topic: https://lists.opendaylight.org/mt/104979965/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Private: Re: [ODL Discuss] Is there no validation on leafrefs in opendaylight? #help

[Robert Varga]

On 22/02/2024 08.35, aronbergur...@gmail.com wrote:
Ah I see, I had already found this LeafRefValidation component. That is 
why I thought it was weird that there was no validation of the leafref 
in the example above.


I have been diving into ODL for the past weeks, and I am really 
intrigued. But the lack of documentation is however a bit saddening.  I 


Yeah, there are troves of documentation in the old wiki, 
https://wiki-archive.opendaylight.org/view/Main_Page, which is no longer 
indexed by search engines as most of it has gone stale.


The new wiki has very little of that, and I honestly do not even know 
how it is organized.


I would like to build up the documentation in more maintainable way, 
perhaps as markdown directly in the individual project repos, but have 
no idea where to start and what the overall goal should be.


What sort of documentation were you looking for?


would really like to get this LeafRefValidation integrated to the data tree.


Awesome, but see below.

Are there any useful guides for developers wanting to contribute to ODL 


There are some guides in 
https://docs.opendaylight.org/en/latest/contributor-guides/index.html 
... there was some other guide as well, but I don't have the link handy :(



and what are the other 3 big pieces missing to full yang validation?


The other three, in order of increasing difficulty are:

1) 'unique' constraints

There is already an implementation, but it does not scale to larger 
lists and hence it is disabled by default.


The scalability problem is that each time the list is validated, it is 
an O(N) operation where N is the number of items in the list. This needs 
to be reworked so that we maintain an index, so N becomes the number of 
modified items.


I have had some false starts in this area and I an not sure how far the 
last attempt got. Perhaps it was as far as having the TreeNode part 
semi-figured out and scratching my head on how to retrofit it into 
SchemaAwareApplyOperation, but memory is spotty.


2) 'must' constraints

No implementation and bare-bones idea on how to do this:
- essentially it boils down to maintaining indexes as in 1), but
- the index usually lives in an ancestor of the node which has the 
constraint
- we need to perform some amount of static analysis of the expression to 
determine where to place that index and how to maintain it


There are some JIRA issues filed for bits and pieces, but honestly, even 
I do not understand the descriptions I put in those :(


3) 'when' conditionals

The mother of them all. While everything else is a essentially 
postcondition check, these actually govern which postconditions to check 
based on data. I suspect these will build on the infra created for 2) 
plus some magic to govern the layout of the strategy tree. No idea how 
exactly, as we have not explored it at depth -- but it should become 
more apparent when 1) and 2) are implemented.



Now leafref validation lies somewhere between 1) and 2) in terms of 
complexity.


Current implementation, if I remember it correctly, works on the entire 
data tree candidate, i.e. it suffers from the same scalability problem 
as current unique constraints validation, just worse, as it evaluates 
all leafrefs everywhere, without paying attention to whether it was 
modified or not.


In order for proper integration, the validation piece needs to be 
triggered on modification -- of either the leaf using the reference or 
the referred-to object.


That probably boils down to:
- performing some static analysis on the leafref expression to figure 
out where an index should be maintained -- i.e. the closest common 
ancestor of the user and the referred-to object. This is simpler than 
the analysis in 2) simply because leafref expressions are simpler and we 
already have the tools to resolve them (SchemaInferenceStack)

- designing/writing the index maintenance code

At the end of the day, the data is organized as a tree, which is updated 
by applying modifications in a depth-first manner and performing partial 
validation of each subtree as we exit its corresponding node. In order 
to scale, each kind of validation needs to fit into this model -- so 
that it is only executed when needed. When it executes, it should also 
have as much information as we can reasonably maintain to execute quickly.


This is one of the places where we do some heavy lifting using 
"Algorithms and Data Structures" area of computer science, simply 
because this component is expected to cater to literally gigabytes of 
stored data built up and maintained through a lot of small incremental 
updates.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9085): https://lists.opendaylight.org/g/Discuss/message/9085
Mute This Topic: https://lists.opendaylight.org/mt/104506163/21656
Mute #help:https://lists.opendaylight.org/g/Discuss/mutehashtag/help
Group Owner: discuss+ow...@lists.opendaylight.org
Unsu

Re: [ODL Discuss] Is there no validation on leafrefs in opendaylight? #help

[Robert Varga]

On 21/02/2024 23.33, aronbergur...@gmail.com wrote:


For example when creating a topology you can add an underlay-topology 
item with topology-ref to non existing topology. And ODL responds with 
201 and if I fetch the topologies I can see that the topology was created
even though it is referencing non existing topology. Is this the 
intended behaviour in ODL?


Hello,

there is a leafref validation component here:

https://github.com/opendaylight/yangtools/blob/bd3f43b357bc9e1226501a283c2071f8ff5074c0/data/yang-data-tree-ri/src/main/java/org/opendaylight/yangtools/yang/data/tree/leafref/LeafRefValidation.java#L48

It was developed for FD.io long time ago, but was never properly 
integrated into data tree.


Unfortunately it is one of the four pieces missing to full YANG 
validation :(


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9084): https://lists.opendaylight.org/g/Discuss/message/9084
Mute This Topic: https://lists.opendaylight.org/mt/104504702/21656
Mute #help:https://lists.opendaylight.org/g/Discuss/mutehashtag/help
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] L2 switch project

[Robert Varga]

On 14/02/2024 16.08, David Arjona via lists.opendaylight.org wrote:

Hi Everybody,


Hello,

Robert has taken over the Aluminum-l2switch code and has successfully 
submitted the "Update to work with Aluminium GA" code change. Thanks Robert!


The code I am currently working on for Silicon-l2switch comes from the 
code I submitted as "Take over the original update to work on 
aluminium", which is now in Abandoned state. So my question is: Do I 
continue working on my Silicon code, even when it stems from an 
Abandoned Aluminum code-change, or do I create a new Silicon update that 
stems from Robert's newly submitted code?


As I noted when abandoning that change, I have integrated your changes 
into the original Al patch while completely reworking it (it was a 
horrible thing).


I have also fixed up and merged your Si patch and made a ton of further 
patches, the result of which is that the current origin/master works on 
Si SR4 -- hence there is nothing more to do on this step.



Which one is the most "correct" path?


The next step is to adopt Phosphorus, which is where the fun begins.

As can be seen in the message of 
https://git.opendaylight.org/gerrit/c/l2switch/+/110236 and the 
corresponding Jenkins build failure, there is preparatory work needed 
before that can happen.


I have provided links to the upgrade guide that point document the 
changes that are triggering the failure.


There are three separate steps that need to happen, not in order:

1) Stop using compatibility methods in everything *except* packethandler

These are clearly flagged by javac warnings like:


[WARNING] 
/w/workspace/l2switch-maven-merge-master/hosttracker/implementation/src/main/java/org/opendaylight/l2switch/hosttracker/plugin/inventory/Host.java:[107,79]
 
setTerminationPoint(java.util.List)
 in 
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.NodeBuilder
 has been deprecated and marked for removal
[WARNING] 
/w/workspace/l2switch-maven-merge-master/hosttracker/implementation/src/main/java/org/opendaylight/l2switch/hosttracker/plugin/internal/SimpleAddressObserver.java:[190,14]
 setId(java.math.BigInteger) in 
org.opendaylight.yang.gen.v1.urn.opendaylight.address.tracker.rev140617.address.node.connector.AddressesBuilder
 has been deprecated and marked for removal


The first one is a flag for List/Map conversion, the other is for the 
Uint (in this case Uint64) conversion.


I have merged multiple patches to fix occurrences of these, which you 
can find in git history. I suggest you review them and understand their 
effects, as that understanding is critical to not introducing regressions.



2) Reconcile base-packet.yang's definition of fields

Current definition is:


  grouping packet-fields {
leaf payload-offset {
  type int32;
}
leaf payload-length {
  type int32;
}
  }


which I think is wrong -- those should be uint32 as far as I understand, 
but that needs to be checked. Making that change will invariably break 
packethandler decoders around BitBufferHelper, giving an insight on how 
that needs to change.



3) Fix BitBufferHelper

Methods from this are used to both interact with OFP classes 
(highlighted by warnings like in 1)) and packethandler classes (not 
highlighted and broken by 2).


Hence BitBufferHelper needs to be adjusted to work with Uint{8,16,32,64} 
as appropriate, which should end up fixing the fallout from 2) and fix 
the remainder of warnings like 1).


Once all three are done, the aforementioned patch should verify without 
a glitch, paving the way for updates to subsequent releases.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9081): https://lists.opendaylight.org/g/Discuss/message/9081
Mute This Topic: https://lists.opendaylight.org/mt/99883508/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] L2 switch project

[Robert Varga]

On 13/02/2024 19.58, Jamie G. wrote:

Is it possible the container is looking for:
https://mvnrepository.com/artifact/com.google.guava/guava/29.0-jre

The bundle's manifest exports com.google.common.collect


Guava is our core dependency and as such a single version is pulled in 
by infrastructure components (i.e. as deep as yangtools.concepts and 
infrautils.ready-api). Outside of odlparent I think we have fewer than 5 
artifacts that are not exposed to that version transitively via their 
dependencies.


Therefore when this sort of thing happens, 99+% of the time the problem 
is version convergence, i.e. the set of  artifacts meeting at runtime do 
not match.


In this particular case the problem was pulling in Aluminium version of 
openflowplugin (0.11.x) while pulling in Silicon version of everything 
else (odlparent-8.1.x, mdsal-7.0.x, etc.).


Regards,
Robert



On Tue, Feb 13, 2024 at 3:23 PM David Arjona via
lists.opendaylight.org 
wrote:


Hi Everybody,

I have continued working in the l2switch code. Now I get an error message that I do not 
understand how to fix: It seems that the code versions at l2switch.packethandler do not 
match, but I do not know where and how to fix this problem. I am attaching the output of 
the "mvn clean install" command to this email.

Regards,

David










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9080): https://lists.opendaylight.org/g/Discuss/message/9080
Mute This Topic: https://lists.opendaylight.org/mt/99883508/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

[ODL Discuss] The road to Java 21

[Robert Varga]

Hello everyone,

we saw the release on a new Java LTS version in September, so it is high 
time we discuss its adoption.


As it currently stands (odlparent-13.0.10), we are targeting Java 17 and 
do not execute SFT when running with Java 21.


That will change with karaf-4.4.5, slated for odlparent-13.0.11, in that 
we do execute SFT with Java 21 and expect it to pass.a


Targeting maven.compiler.release=21 does not work, but that will be 
fixed in karaf-4.4.6. That is the only blocker I know of to have both 
YANG Tools and MD-SAL build passing when targeting Java 21.


From development environment perspective:
- Fedora 40 is expected to ship Java 21
- Ubuntu 2020.04 and 2022.04 both can support Java 21
- there is SDKMAN! allowing you to choose from any number of suppliers 
(https://sdkman.io/jdks) with very much up-to-date builds


With this perspective, I think our plan should be:
- support running on Java 21 from odlparent-13.0.11 onwards, i.e. 
2023.09 Potassium SR3 or later
- build with both Java 17 (for release) and Java 21 (for validation) on 
2024.03 Calcium SR1 or later, contingent on 
https://jira.linuxfoundation.org/plugins/servlet/desk/portal/2/IT-26285

- require Java 21 for 2024.09 Scandium onwards

Unless there are serious objections raised before March 15th 2024, this 
transition will be part of odlparent-14 integrated into 2024.09 Scandium.


Regards,
Robert[*]

[*] looking forward to all the Java 21 goodies we will be allowed to use :)


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9072): https://lists.opendaylight.org/g/Discuss/message/9072
Mute This Topic: https://lists.opendaylight.org/mt/103990064/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] Gerrit verify changes

[Robert Varga]

On 07/11/2023 15.45, Andrew Grimberg wrote:

Greetings folks,


Hello Andy,

TLDR; Changes now require 2 Verify+1 votes to be submittable. One of the 
votes must come from the 'ODL Required GHA' user.


okay, so here is a real-life problem: why doesn't the GHA action trigger 
for https://git.opendaylight.org/gerrit/c/aaa/+/109969 and how can I fix 
this?


Also, what is preventing 
https://git.opendaylight.org/gerrit/c/releng/builder/+/106213 from being 
submitted?


Thanks,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9065): https://lists.opendaylight.org/g/Discuss/message/9065
Mute This Topic: https://lists.opendaylight.org/mt/102443749/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] https://jira.opendaylight.org/browse/CONTROLLER-1911

[Robert Varga]

On 05/01/2024 05.27, Roshni k k wrote:

Hi Robert,


Hello Roshni,

We have started working on CONTROLLER-1911 - [CONTROLLER-1911] Consider 
using java.lang.ref.Cleaner for transactions and FileBackedOutputStreams 
- OpenDaylight JIRA 


The code changes are ready.  Shall we raise a review request?


Sure, thanks for the contribution!

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9059): https://lists.opendaylight.org/g/Discuss/message/9059
Mute This Topic: https://lists.opendaylight.org/mt/103537724/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [E] Re: [ODL Discuss] L2 switch project

[Robert Varga]

On 12/12/2023 15.43, Sangwook Ha via lists.opendaylight.org wrote:

The Maven build jobs for l2switch have been reverted to use Java 11:
https://git.opendaylight.org/gerrit/c/releng/builder/+/109134 



So now you can verify your change with OpenDaylight Gerrit & Jenkins:
https://git.opendaylight.org/gerrit/c/l2switch/+/108266 



The patches seem to need a rebase...

Regards,
Robert



Thanks,
Sangwook

On Thu, Dec 7, 2023 at 4:49 PM David Arjona via lists.opendaylight.org 
 
> wrote:


Hi Ivan,

If I am understanding correctly, I just need to continue modifying
the code in my computer, since I have the latest "aluminum" version,
and check that my code follows all the upgrades described at the
Silicon Platform Upgrade page
(https://docs.opendaylight.org/en/stable-silicon/release-notes/upgrade-process.html 
).
 Then I need to compile this code and submit it to Gerrit as the new update to Silicon.

Am I correct?

Thanks,

David





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9054): https://lists.opendaylight.org/g/Discuss/message/9054
Mute This Topic: https://lists.opendaylight.org/mt/103130614/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] Gerrit verify changes

[Robert Varga]

On 08/11/2023 14.53, Andrew Grimberg wrote:

Greetings Robert,

On 11/7/23 15:47, Robert Varga wrote:


[snip]


And I also have an issue to report: +2/Submit Gerrit shortcut is broken.

git.opendaylight.org/gerrit/c/netconf/+/108831 is fully verified and I 
do not have a '+2' button in top right corner.


That means I have to go through:
- "Reply"
- "+2"
- "Send"

This hurts A LOT on this side of the pond.


Are these self-reviews? I only see that with self-reviews and it's a UI 
change in Gerrit itself that I have not found how to bring back. The 
Gerrit devs have basically hidden self-review on purpose to strongly 
discourage it as it is not a best practice.


Yes, these are self reviews, there are a number of projects where we are 
down to doing these.


It does seem to be related to the GHA change, as this earlier this week 
and we are still running the same Gerrit version (3.7.2)...


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9030): https://lists.opendaylight.org/g/Discuss/message/9030
Mute This Topic: https://lists.opendaylight.org/mt/102443749/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] Gerrit verify changes

[Robert Varga]

On 07/11/2023 19.48, Andrew Grimberg wrote:

Greetings Robert,


Hello Andy,

[snip]

So, if for some reason the GHA started failing this would require a 
Gerrit admin (LFRE) to disable the hard requirement that the 
odl.required.gha account has voted.


Please note, that LFRE gets every single failure or cancellation 
notification on the required job and we're well aware of the impact that 
that job has on our projects so we're paying attention to it!


Okay, but this makes it an SLA item, so I think we should have a 
dedicated issue type in servicedesk.


And I also have an issue to report: +2/Submit Gerrit shortcut is broken.

git.opendaylight.org/gerrit/c/netconf/+/108831 is fully verified and I 
do not have a '+2' button in top right corner.


That means I have to go through:
- "Reply"
- "+2"
- "Send"

This hurts A LOT on this side of the pond.

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9028): https://lists.opendaylight.org/g/Discuss/message/9028
Mute This Topic: https://lists.opendaylight.org/mt/102443749/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] Gerrit verify changes

[Robert Varga]

On 07/11/2023 18.23, Andrew Grimberg wrote:

Greetings Robert,


Hello Andy,


On 11/7/23 06:56, Robert Varga wrote:

Hello Andy,

On 07/11/2023 15.45, Andrew Grimberg wrote:
This job will vote Verified+/-1 depending on the status on all 
changes and the vote will come in as the 'ODL Required.GHA' account. 
Gerrit has been updated to _require_ that that user has voted +1 for 
a change to be submittable. It also requires that at least one other 
Verified+1 has happened. That other +1 can come from a committer (as 
can already happen, though this is not preferred) or from another CI 
system such as Jenkins or our GHA user for a GHA job validation.


I am reading this as 'committers no longer have the final say on what 
can and cannot be merged'.


Is my understanding correct?
Yes and no. Yes in that there is now a system level required job that is 
maintained by LFRE specifically related to INFO.yaml files.  No, in that 
outside of that specific job related to INFO.yaml files committers still 
have final arbitration of a job having to pass any _other_ CI or no 
other CI.


[snip] all the goodness, which is understood.

The job in question has been in use now for over 3+ months on both ONAP 
and ORAN (not an LFN project) with no issues (outside of when GHA itself 
is having issues). Having it as a mechanical bar in this way allows us 
to be assured that all projects are properly handling their INFO.yaml 
files. This also allows us to remove a job from Jenkins that does this 
INFO.yaml validation presently for all projects.


My primary concern lies exactly here: what is the recovery path if that 
job starts failing?


If you would like to inspect what is happening this new global 
requirement is done by way of a new CI management repository in Gerrit. 
This repository is the `.github` repository (yes, the magic GitHub 
repo). The workflow in question is available here [0] for inspection. It 
consumes a reusable workflow which comes from here [1]. Committers to 
this new repository are the same committer set as have rights against 
the releng/builder repo which drives Jenkins, this means that you have 
committer rights on the repo as well.


As I understand it, the recovery path requires at least two persons:
- one who would submit a disable-this-requirement patch to this magic repo
- a releng/builder committer to approve it

Is my understanding correct?

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9026): https://lists.opendaylight.org/g/Discuss/message/9026
Mute This Topic: https://lists.opendaylight.org/mt/102443749/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] Gerrit verify changes

[Robert Varga]

Hello Andy,

On 07/11/2023 15.45, Andrew Grimberg wrote:
This job will vote Verified+/-1 depending on the status on all changes 
and the vote will come in as the 'ODL Required.GHA' account. Gerrit has 
been updated to _require_ that that user has voted +1 for a change to be 
submittable. It also requires that at least one other Verified+1 has 
happened. That other +1 can come from a committer (as can already 
happen, though this is not preferred) or from another CI system such as 
Jenkins or our GHA user for a GHA job validation.


I am reading this as 'committers no longer have the final say on what 
can and cannot be merged'.


Is my understanding correct?

Thanks,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9024): https://lists.opendaylight.org/g/Discuss/message/9024
Mute This Topic: https://lists.opendaylight.org/mt/102443749/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [ODL Discuss] ODL HA feature contribution: Requesting your view on outstanding HA defects for upcoming release.

[Robert Varga]

On 21/08/2023 09.18, Roshni k k via lists.opendaylight.org wrote:

Hello Robert and All,


Hello Roshni,

welcome in our little community :)


 1. I recently started joining ODL Linux Networking Community along with
my colleagues @Saravanan Shanmuga Sundaram
 and @Rohini Ambika
 .
 2. We have experience in Java and SDN Technologies and we are
interested in contributing to ODL in high availability/clustering area.


Cool, glad to meet you.


 3. In this regard I have pulled  JIRA issues related to clustering.
Some of these tickets are bit older  I would like to get your
opinion/review on these tickets so that I can start working on them.


Yeah, we have all sorts of these. Unfortunately there is some disrepair, 
as we do not have full-time contributors in this area, I am afraid.



 4. Meanwhile we have setup a local ODL environment with 3 node cluster
with Chlorine SR1. My plan is to validate the older defects if they
still exists in the latest release.


Awesome, this is very welcome work!


 5. Please let us know if you have any recommended tickets that can be
picked up under the clustering area for the upcoming release.


I am not tracking anything overly critical. Everything in CONTROLLER is 
up for grabs, most notably the things we do not have steps to reproduce 
or have not been confirmed.


In clustering, the usual thing after having steps to reproduce was to 
create a reproducer unit test first and then zero in on the fix. Tom 
Pantelis used to use this approach to shake out some really terrifying 
things :)


Also, we have a weekly call which noone is using, where we discuss 
things that need doing in kernel projects. If you have details to 
discuss, we can just up that...


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9011): https://lists.opendaylight.org/g/Discuss/message/9011
Mute This Topic: https://lists.opendaylight.org/mt/100868720/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] ODL yang-tools help

[Robert Varga]

sssn 17/07/2023 15.14, Paolo Pino wrote:
Hi, I'm Paolo Pino, I took the liberty of contacting you via email 
that I retrieved on https://git.opendaylight.org/gerrit.


Hello Paolo,

I'm trying to use yang-maven-plugin generated classes in a vanilla 
java project but i can't find documentation or other resource on how 
to use mdsal in this context so i've opened this issue on 
stackoverflow 
https://stackoverflow.com/questions/76665089/opendaylight-odl-java-json-xml-binding-problem. 
You are probably the most knowledgeable person on the problem so I 
would be very grateful if you had the patience to help me.

Thanks a lot for your help and have a nice day.


Sorry to have missed your email, but I was on vacation and things get 
lost -- interacting lists.opendaylight.org, such as 
https://lists.opendaylight.org/g/Discuss, is your best bet.


Anyway, this looks resoundingly similar to 
https://lists.opendaylight.org/g/kernel-dev/message/1003, so I would 
suggest following on that topic.


Regards,

Robert





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9000): https://lists.opendaylight.org/g/Discuss/message/9000
Mute This Topic: https://lists.opendaylight.org/mt/100635572/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] L2 switch project

[Robert Varga]

On 03/07/2023 17.59, David Arjona via lists.opendaylight.org wrote:

Hi Daniel,

Thanks for the info. I have taken a look at it and at the 
opendaylight/l2switch code in Github. Obviously, I don't understand a 
lot of it. However, I would like to start testing it, to have a better 
idea of how it works.


One thing to note here is that there are some forks containing work that 
has not been upstreamed: 
https://github.com/opendaylight/l2switch/forks?include=active%2Cinactive&page=1&period=&sort_by=last_updated. 
I think the first step is to evaluate those changes for integration -- 
which needs some paperwork -- Casey is the point contact to get anything 
of that kind sorted out.


What do you think it would be the best way to start testing the l2switch 
code? Should I use ODL's most recent code version (Argon) or the latest 
ODL version that offered support for this feature (Oxygen: 
https://stackoverflow.com/questions/61396128/what-releases-of-odl-have-l2switch-working )? What else do I need to consider when testing this feature?


In order to get l2switch into the baseline int/dist, it needs to be 
caught up with Argon at the very least. Given the current codebase is at 
Oxygen, that is quite bit of work. My suggestion is to spin separate 
patches for each major release. The documentation of major changes in 
release is at:


https://docs.opendaylight.org/en/stable-sodium/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-magnesium/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-aluminium/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-silicon/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-phosphorus/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-sulfur/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-chlorine/release-notes/upgrade-process.html
https://docs.opendaylight.org/en/stable-argon/release-notes/upgrade-process.html

Target versions documented therein point to GA release -- and hence need 
to be updated to last SR, see below.


I very much advise against attempting against taking shortcuts here -- 
it certainly is possible, but making sense of the overall delta is not 
for the faint of the heart.


IIRC one of those steps requires working around a controller API which 
has no replacement (see https://jira.opendaylight.org/browse/MDSAL-555).


BTW, Does anybody have a table linking ODL release names to software 
version number? For example: Boron, 0.5; Carbon, 0.6; ...


Not for all the projects, for the platform there is 
https://docs.opendaylight.org/projects/integration-distribution/en/latest/platform-versions.html


We have these for each release train, for example:
https://docs.opendaylight.org/projects/integration-distribution/en/stable-sodium/platform-versions.html

MSI projects bump X in 0.X.Y in their version, so it's rather simple to 
calculate.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8990): https://lists.opendaylight.org/g/Discuss/message/8990
Mute This Topic: https://lists.opendaylight.org/mt/99883508/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Opendaylight Argon: How can I manage an L2 network? #help #opendaylight-help-openflow

[Robert Varga]

On 19/04/2023 08.40, ulo...@indra.es wrote:

Hi David,

Thanks for your help, I think it's a good start to work with ODL by 
defining flows, so I can tell the switch to work normal. However, I 
don't understand how to define a learning switch, where it is the 
controller or the application that learns the relationship between the 
MACs and the in-port.


A learning switch example is here: 
https://github.com/opendaylight/openflowplugin/tree/master/samples/learning-switch


There is a more complete switch in a separate project here: 
https://github.com/opendaylight/l2switch/ but it has been long out of 
maintenance.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8967): https://lists.opendaylight.org/g/Discuss/message/8967
Mute This Topic: https://lists.opendaylight.org/mt/98314434/21656
Mute #help:https://lists.opendaylight.org/g/Discuss/mutehashtag/help
Mute 
#opendaylight-help-openflow:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight-help-openflow
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

[ODL Discuss] Java 11 support sunset

[Robert Varga]

Hello everyone,

As 2023.03 Argon is nearing its release, we are also nearing the End of 
Life date for 2022.03 Sulfur: as per the community support rules, as 
soon as Argon is out, Sulfur is no longer supported.


Sulfur is an important milestone, as it is our JDK transition release, 
which supports both Java 11 and Java 17. Its nominal End of Life date is 
March 16th, 2023, which is tomorrow (depending on your timezone and when 
you are reading this).


There have not been any security issues which would warrant a 
Simultaneous Release since December 5th, 2022 (the regularly scheduled 
release of Sulfur SR3) and as such, we will not be making a Sulfur SR4.


With these facts on the table, OpenDaylight kernel projects will each be 
making a last Sulfur-train release as a courtesy to downstreams 
interested enough to pick these up simply because there is a significant 
number of important backported bug fixes.


This process is already underway, with the previously-announced release 
of odlparent-10.0.6 and will be concluded with the release of 
bgpcep-0.17.9 (or transportpce-5.x.x if the TPCE team chooses to follow 
suit). It notably excludes Managed Snapshot Integrated projects, like 
openflowplugin, daexim, jsonrpc, ovsdb and others.


The releases provided through this effort are quite incompatible with 
Sulfur SR3 (through adoption of karaf-4.3.9 at the very least) and are 
the last releases we will issue for the 2022.03 release train. Anyone 
adopting them needs to be cognizant of the fact we will not be issuing 
any releases to fix anything that might go wrong with them -- they are a 
courtesy after all.


This corpus also is the last we expect to support Java 11. All 
subsequent releases are expected to come from 2022.09 Chlorine or later, 
which in turn requires Java 17 or later.


If you are in a position where you require more than the regular 
community-promised support, PANTHEON.tech has got you covered, as we 
have a number of flexible support solutions, currently stretching as far 
back as 2018.03 Oxygen. Please contact sa...@pantheon.tech for more 
information on available options.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8956): https://lists.opendaylight.org/g/Discuss/message/8956
Mute This Topic: https://lists.opendaylight.org/mt/97638419/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: 
https://lists.opendaylight.org/g/Discuss/leave/4219721/21656/1056093597/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] Jetty version

[Robert Varga]

On 07/11/2022 10:02, Michael D?rre wrote:

Hi @all,

we - as part of the ONAP project - are trying to migrate our code to odl 
chlorine-SR0 and getting some issues. The biggest one at the moment is, 
that by trying to register a websocket servlet we are provocating this 
bug here.


https://github.com/eclipse/jetty.project/issues/7835

So my question is if there are any plans to migrate to jetty 10 in the 
nearer future? I mean I am still trying to work around this bug but just 
for information in case we do not get this to work.


We are picking up Jetty from Karaf, which in turn picks it up from Pax Web.

There is a Pax Web version using Jetty-10 (v9.0.1), but that has not yet 
been integrated into Karaf.


So I guess, the better forum for this question is d...@karaf.apache.org, 
as we will pick it up once there is a Karaf release with Pax Web 9.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8935): https://lists.opendaylight.org/g/Discuss/message/8935
Mute This Topic: https://lists.opendaylight.org/mt/94862318/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] ONAP/ODL Integration Sync

[Robert Varga]

On 19/09/2022 20:55, dmcbr...@linuxfoundation.org wrote:

ONAP/ODL Integration Sync

Team,

At tomorrow's meeting, I'd like to discuss ODL integration with the ONAP 
London release in 1Q23. This will be similar to what we did for the ONAP 
Kohn release, which successfully enabled a smooth integration effort by 
Dan T and his tea

I am sorry but I could not join due to personal circumstances.

You may find the schedule proposal for the London release here: 
https://wiki.onap.org/x/fwDiC . Note that 
this proposal has not yet been reviewed or approved by the ONAP TSC.


Quoteth:

M0: Oct 10th, 2022: Kick Off
M1: Dec 1st, 2022: GlobalReq Approved
M2: Jan 19th, 2022: Spec Freeze

ODL does not have an Argon plan up (sorry, formals are quite lacking in 
the past few weeks). The dates look something line the following: 
https://git.opendaylight.org/gerrit/c/docs/+/102518/1/docs/release-process/release-schedule.rst, 
subject to ODL TSC approval (yeah, we are behing, but the dates will not 
move significantly).


We certainly are aiming to have 2022.09 Chlorine out before London M1 -- 
which means all projects interesting for ONAP released except the 
ONAP-specific distribution.


Furthermore, a mid-release review of ODL is expected to be available by 
Londong M2, providing a natural go/no-go ONAP decision to adopt either 
one of:

1) 2023.09 Argon
2) 2022.09 Chlorine SR1
3) 2022.03 Sulfur SR3 (with option for late-coming SR4 by London M4)

Note that:
- 3) means signing off ONAP London with a no-longer-supported version of 
OpenDaylight

- 2) means about 4 months of support after  London Sign-off date
- 1) means just under 10 months of the same.

As for the delta between 1) and 2), I expect it to be minor, but we will 
not really know for sure before Oct 10th.


I think this is dominated by Sulfur->Chlorine migration on ONAP side 
(incl. bierman02 woes).


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8923): https://lists.opendaylight.org/g/Discuss/message/8923
Mute This Topic: https://lists.opendaylight.org/mt/93788342/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] [tsc] Proposal to archive inactive projects.

[Robert Varga]

On 30/09/2022 04:34, Anil Belur wrote:

Hello TSC:

The list of $projects (and last activity on the repo) are inactive for 
the last ~2 release cycles and good candidates for project archival.


- l2switch: Apr, 2021


-1, this is a very useful downstream of OFP. Perhaps we may merge it 
with it.



- dlux: Sept, 2020


+1


- dluxapps: Oct, 2020


+1


- netvirt: June, 2021


+1


- odlguice: Oct, 2020


+1


- odlmicro: Dec, 2020


+1


- odlsaf: Dec, 2020


+1


- odltools: Oct, 2020


+1


- p4plugin: Oct, 2020


+1


- plastic: Oct, 2020


+1


- unimgr: Sept, 2021


Not sure, this project was in some sort of a handover last time I checked...

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8922): https://lists.opendaylight.org/g/Discuss/message/8922
Mute This Topic: https://lists.opendaylight.org/mt/94009246/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] [OpenDaylight TSC] Relevancy of branch locks during the release process

[Robert Varga]

On 09/08/2022 15:44, Guillaume Lambert via lists.opendaylight.org wrote:

Hello


As discussed during the TSC meeting of 7th July 
,
I'd like to challenge the relevancy of branch locks during releases 
processes.

In my opinion they have more cons than pros today.

I agree they used to be meaningful in the past to avoid potential 
overlaps and incoherence.


But it was a time when many active projects and committers were taking 
part to the release.


I am not convinced the size of the community still justifies such a 
process today.

And since most active projects and their committers are quite experienced,
I am quite convinced that branch locks more brake the release than they 
help.
I think especially of repeated situations such as when downstream 
projects face
bugs in their upstream dependencies and have to wait for the branch to 
be unlocked

to update their poms and trigger stage-releases jobs.

But I might have missed some aspects.
So I would like to have other community members'opinion on the topic.


I tend to agree. The branch lock is relevant only to MSI projects at 
this point. Those projects do not even have what I would call active 
committers (with the notable exception on OFP).


Meanwhile the way branch-lock works is quite wrong, as it should only be 
affecting MSI projects (e.g. those in autorelease.git), but affects 
everyone (who happens to match their branch naming).


Ditch it for all I care.

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8914): https://lists.opendaylight.org/g/Discuss/message/8914
Mute This Topic: https://lists.opendaylight.org/mt/92924121/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] The road to Java 17

[Robert Varga]

On 25/04/2022 16:42, Robert Varga wrote:

On 25/09/2021 00:00, Robert Varga wrote:


Hello yet again,

with not may replies in this thread, here is an update on where we are.

With all this in picture, I believe the proper course in OpenDaylight 
is to have:
- Sulfur (22.03) supporting both JDK11 and JDK17 at compile-time, with 
artifacts compatible with JDK11+

- All of Sulfur being validated with JDK17


Both these items are delivered, all projects participating on Sulfur GA 
verify each patch with both JDK11 and JDK17.


As it stands 2022.03 Sulfur SR1 works just fine with Java 17. Please 
share your experience, as I am currently tracking no outstanding issues 
at this time.



- Chlorine (22.09) to require JDK17+


This is now slated for delivery: odlparent/master and yangtools/master 
both require JDK17 and are taking advantage of JDK17 features. More 
projects are slated to follow.


2022.09 Chlorine platform components (e.g. MRI projects up to and 
including NETCONF) now require Java 17 on their master branch. I have 
done some amount of exploration in other support projects and it seems 
there are no blockers to adoption.


As such, I believe(*) we are committed to Java 17 for 2022.09 Chlorine 
Simultaneous Release.


Regards,
Robert

(*) Please switch to Java 17 now and report any issues you find. At this 
point we are very much committed to Java 17 and the sooner you test, the 
better experience of this switch all of us will have.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8911): https://lists.opendaylight.org/g/Discuss/message/8911
Mute This Topic: https://lists.opendaylight.org/mt/85850198/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Old RESTCONF northbound scheduled for removal

[Robert Varga]

On 15/03/2022 18:44, Robert Varga wrote:

On 01/12/2021 11:14, Robert Varga wrote:


The tracker issue for the removal is 
https://jira.opendaylight.org/browse/NETCONF-837 and the plan of 
action is as follows:


[snip]

4. 2022.09 Chlorine, due out in September 2022, will not include the 
old implementation.


The old implementation is no longer present in netconf/master, hence 
this item is slated for delivery in 2022.09 Chlorine.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8886): https://lists.opendaylight.org/g/Discuss/message/8886
Mute This Topic: https://lists.opendaylight.org/mt/87424268/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] The road to Java 17

[Robert Varga]

On 25/09/2021 00:00, Robert Varga wrote:

Hello everyone,


Hello again,

as you might have noticed, Java 17 has been released: 
https://jdk.java.net/17/ with reference implementation here: 
https://jdk.java.net/java-se-ri/17


[snip]

IIUC, there are only a few issues which prevents us from adopting JDK 17 
as a requirement:
- maven-xtend-plugin compatibility (due to Guice, what a surprise), 
which should be solved in 2.26.0, whenever that is available

- SpotBugs compatibility, which should be addressed in 4.4.x series


These issues have been addressed.

With all this in picture, I believe the proper course in OpenDaylight is 
to have:
- Sulfur (22.03) supporting both JDK11 and JDK17 at compile-time, with 
artifacts compatible with JDK11+

- All of Sulfur being validated with JDK17


Both these items are delivered, all projects participating on Sulfur GA 
verify each patch with both JDK11 and JDK17.



- Chlorine (22.09) to require JDK17+


This is now slated for delivery: odlparent/master and yangtools/master 
both require JDK17 and are taking advantage of JDK17 features. More 
projects are slated to follow.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8885): https://lists.opendaylight.org/g/Discuss/message/8885
Mute This Topic: https://lists.opendaylight.org/mt/85850198/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Old RESTCONF northbound scheduled for removal

[Robert Varga]

On 01/12/2021 11:14, Robert Varga wrote:


The tracker issue for the removal is 
https://jira.opendaylight.org/browse/NETCONF-837 and the plan of action 
is as follows:


1. Phosphorus SR2, due out 2022-01-27, will issue a single (mild) 
warning on startup. We will continue to install the implementation as 
part of the 'odl-restconf' feature.


2. 2022.03 Sulfur, due out 2022-03-17, will not install the old 
implementation by default. Users will be required to explicitly install 
the 'odl-restconf-nb-bierman02' feature. The warning introduced in step 
1. will be updated to warn about the fact the feature is no longer 
supported and scheduled for removal in the next major release.


3. Old implementation will be removed from the netconf git repository's 
master branch as soon as the 3.0.x stability branch for Sulfur is 
created -- i.e. March/April 2022.


4. 2022.09 Chlorine, due out in September 2022, will not include the old 
implementation.


Unless serious objections to this are raised by 2022-01-10 we will 
execute it exactly as outlined above.


No objections received up until now (~2 months after the dealine), this 
is the official plan of action.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8877): https://lists.opendaylight.org/g/Discuss/message/8877
Mute This Topic: https://lists.opendaylight.org/mt/87424268/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] [kernel-dev] ONAP/ODL Integration Sync

[Robert Varga]

On 15/03/2022 18:06, David McBride wrote:

We're on the bridge now...


So essentially we have agreed that ONAP/ccsdk should be taking ownership 
of the distribution ODL is providing.


Barring the daexim dependency, which is an ODL MSI project due to the 
committers to making it MRI, that will allow  ONAP/ccsdk to pick up ODL 
artifacts no later than our Version Bump Checkpoint, which happens 
~5months before the SimRel release date.


Aside from solving the release alignment issue, it will also allow ONAP 
to provide useful feedback while ODL is still building up its SimRel -- 
which is obviously beneficial to both projects.


A pointer I failed to provide in the meeting due to technical issues: 
https://github.com/opendaylight/integration-distribution/blob/master/onap-karaf/pom.xml 
is the XML that would have to be rehosted to ccsdk.


One notable outlier for Kohn is the use of Sulfur or Chlorine -- 
Chlorine would technically be better, as it would give ~12 months of 
supported ODL to ONAP and their downstreams, but Chlorine *will not* 
include the old RESTCONF interface, only RFC8040, as per 
https://lists.opendaylight.org/g/Discuss/message/8843


Regards,
Robert




On Mon, Mar 14, 2022 at 8:36 AM <mailto:dmcbr...@linuxfoundation.org>> wrote:


Team,

Just as a reminder, we will be using the ODL/ONAP Integration Sync
meeting tomorrow to coordinate the ONAP Kohn release with ODL
releases, such that we have an ODL release available approximately 1
month prior to ONAP M3.

For the discussion, I have put together a draft schedule for the
ONAP Kohn release: https://wiki.onap.org/x/2gWsBw
<https://wiki.onap.org/x/2gWsBw>. Important note: this schedule has
not been reviewed or approved by the ONAP TSC, so it should be
considered speculative. As such, our schedule coordination with ODL
will need to be iterative.

Looking forward to seeing all of you on the call on Tuesday.

David


  ONAP/ODL Integration Sync

/When/
Tue Mar 15, 2022 10am – 11am Pacific Time - Los Angeles
/Where/
https://zoom.us/j/91654497219?pwd=SGZpNGRGV2tzejRIS1Mrb21kYXh3Zz09
<https://zoom.us/j/91654497219?pwd=SGZpNGRGV2tzejRIS1Mrb21kYXh3Zz09>(map

<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F91654497219%3Fpwd%3DSGZpNGRGV2tzejRIS1Mrb21kYXh3Zz09&sa=D&ust=1647704179911000&usg=AOvVaw2Ci-n1LJS55PyEZlrKvFIe>)
/Who/

•   
Casey Cain- organizer
•   
jluhr...@gmail.com <mailto:jluhr...@gmail.com>
•   
ece...@gmail.com <mailto:ece...@gmail.com>
•   
kp...@linuxfoundation.org <mailto:kp...@linuxfoundation.org>
•   
abhijitk...@gmail.com <mailto:abhijitk...@gmail.com>
•   
ddelar...@luminanetworks.com <mailto:ddelar...@luminanetworks.com>
•   
Jill Lovato
•   
sandeeplinux1...@gmail.com <mailto:sandeeplinux1...@gmail.com>
•   
Joe Malcolm (jomalcol)
•   
hari.kris...@luminanetworks.com <mailto:hari.kris...@luminanetworks.com>
•   
Robert Crowe (rocrowe)
•   
tejas.nevre...@gmail.com <mailto:tejas.nevre...@gmail.com>
•   
ddelarosa0...@gmail.com <mailto:ddelarosa0...@gmail.com>
•   
dmcbr...@linuxfoundation.org <mailto:dmcbr...@linuxfoundation.org>
•   
Kuangching Wang
•   
Robert Varga
•   
onap-s...@lists.onap.org <mailto:onap-s...@lists.onap.org>
•   
kernel-...@lists.opendaylight.org
<mailto:kernel-...@lists.opendaylight.org>
•   
discuss@lists.opendaylight.org <mailto:discuss@lists.opendaylight.org>
•   
dt5...@att.com <mailto:dt5...@att.com>
•   
TABEDZKI, RICHARD
•   
xin.m...@fujitsu.com <mailto:xin.m...@fujitsu.com>
•   
Ramey, Daniel
•   
d.arunprak...@ericsson.com <mailto:d.arunprak...@ericsson.com>
•   
faseel...@ericsson.com <mailto:faseel...@ericsson.com>
•   
hema.gopalkrish...@ericsson.com <mailto:hema.gopalkrish...@ericsson.com>
•   
gvran...@yahoo.co.in <mailto:gvran...@yahoo.co.in>
•   
guillaume.lamb...@orange.com <mailto:guillaume.lamb...@orange.com>

__Topic: ONAP/ODL Integration Sync
Time: This is a recurring meeting Meet anytime

Join Zoom Meeting
https://zoom.us/j/91654497219?pwd=SGZpNGRGV2tzejRIS1Mrb21kYXh3Zz09

<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F91654497219%3Fpwd%3DSGZpNGRGV2tzejRIS1Mrb21kYXh3Zz09&sa=D&ust=1647704179907000&usg=AOvVaw1ls0Ad5S74ig1r0iB0-MBA>

Meeting ID: 916 5449 7219
Passcode: 789726
One tap mobile
+12532158782,,91654497219# US (Tacoma)
+13462487799,,91654497219# US (Houston)

Dial by your location
 +1 253 215 8782 US (Tacoma)
 +1 346 248 7799 US (Houston)
 +1 669 900 6833 

Re: [ODL Discuss] ONAP/ODL Integration Sync

[Robert Varga]

On 08/03/2022 20:14, David McBride wrote:

Hi Robert,


Hey David,

 From the TSC call yesterday, my understanding was that the sync call 
was next week.  Sorry if I misunderstood.


Yeah, it may very much be my misunderstanding, it would not be the first 
nor the last time that happened.


Nevertheless the content below is something to mull over before we meet 
next week :) I do believe it provides a very clear solution (and 
challenges thereto) the problem at hand...


Regards,
Robert



David

On Tue, Mar 8, 2022 at 11:07 AM Robert Varga <mailto:n...@hq.sk>> wrote:


So nobody attented this call today.

This question raised yesterday on ONAP PTL call was the one of release
timing and streamlining alignment with ODL.

The one thing I failed to realize is that ODL release cycle is
off-the-wack due to the major changes happening to yangtools/mdsal
integration.

Judging from the contents of our ONAP-specific distribution (which
really should live in CCSDK or thereabout), ONAP depends on the
following ODL projects:

odlparent
infrautils
yangtools
mdsal
controller
aaa
netconf
daexim

All of these, with the notable exception of DAEXIM, are ODL MRI
projects, subject to having a stable release available at ODL's "MRI
Version Bump Checkpoint".

According to ODL SimRel schedule

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

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

this checkpoint occurs *way* ahead of the official release.

I'll take the blame for Phosphorus and Sulfur completely missing the
deadline, but I fully expect to restore normal service for Chlorine.

What that means in practical terms is that Chlorine (due out
~16.9.2022), the release artifacts for ODL Platform are expected to be
available on or about 15.4.2022 (my favorite day), e.g. full 5 months
ahead of the SimRel release date.

The associated first health checkpoint is on or about 29.4.2022 (aka
Version Bump Checkpoint). ODL release health is further evaluated at
CSIT Checkpoint (on or about 13.5.2022) for a decision to press
ahead or
roll back. A further heal check is evaluated by ODL TSC at "Middle
Checkpoint", e.g. on or about 8.7.2022, which essentially requires all
of CSIT to be healthy or a very good prognosis to be present (otherwise
postponing the SimRel is on the table).

With that, I think the path forward is for ONAP's CCSDK to begin
integration as soon as the MRI Version Bump or CSIT checkpoint, giving
plenty of runway for integration and working out kinks.

DAEXIM is an outlier, we need to come to an agreement around it.

Regards,
Robert



--
*David McBride *(pronounce <https://nmdrp.me/davidmcbride>)
Senior Technical Community Architect
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018 
Email: dmcbr...@linuxfoundation.org <mailto:dmcbr...@linuxfoundation.org>



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8870): https://lists.opendaylight.org/g/Discuss/message/8870
Mute This Topic: https://lists.opendaylight.org/mt/89645033/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

[ODL Discuss] ONAP/ODL Integration Sync

[Robert Varga]

So nobody attented this call today.

This question raised yesterday on ONAP PTL call was the one of release 
timing and streamlining alignment with ODL.


The one thing I failed to realize is that ODL release cycle is 
off-the-wack due to the major changes happening to yangtools/mdsal 
integration.


Judging from the contents of our ONAP-specific distribution (which 
really should live in CCSDK or thereabout), ONAP depends on the 
following ODL projects:


odlparent
infrautils
yangtools
mdsal
controller
aaa
netconf
daexim

All of these, with the notable exception of DAEXIM, are ODL MRI 
projects, subject to having a stable release available at ODL's "MRI 
Version Bump Checkpoint".


According to ODL SimRel schedule 
(https://docs.opendaylight.org/en/latest/release-process/release-schedule.html), 
this checkpoint occurs *way* ahead of the official release.


I'll take the blame for Phosphorus and Sulfur completely missing the 
deadline, but I fully expect to restore normal service for Chlorine.


What that means in practical terms is that Chlorine (due out 
~16.9.2022), the release artifacts for ODL Platform are expected to be 
available on or about 15.4.2022 (my favorite day), e.g. full 5 months 
ahead of the SimRel release date.


The associated first health checkpoint is on or about 29.4.2022 (aka 
Version Bump Checkpoint). ODL release health is further evaluated at 
CSIT Checkpoint (on or about 13.5.2022) for a decision to press ahead or 
roll back. A further heal check is evaluated by ODL TSC at "Middle 
Checkpoint", e.g. on or about 8.7.2022, which essentially requires all 
of CSIT to be healthy or a very good prognosis to be present (otherwise 
postponing the SimRel is on the table).


With that, I think the path forward is for ONAP's CCSDK to begin 
integration as soon as the MRI Version Bump or CSIT checkpoint, giving 
plenty of runway for integration and working out kinks.


DAEXIM is an outlier, we need to come to an agreement around it.

Regards,
Robert



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8869): https://lists.opendaylight.org/g/Discuss/message/8869
Mute This Topic: https://lists.opendaylight.org/mt/89645033/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Multiple mount points for the same device

[Robert Varga]

On 15/12/2021 19:34, Yevgeny Shakhnovich wrote:

Hi Robert,
We allow our customers to use Restconf directly. Using Restconf, they can
create multiple netconf mount points for the same device. Unfortunately,
they consider it not as an option but as a defect.
This is a problem.


Right, but given the deployment flexibility where (for example) the same 
device can be mounted with different credentials, we cannot really make 
a blanket restriction on a TCP N-tuple here.


This is a use-case/deployment-specific restriction. There are a number 
of ways to place a policy enforcement point here, and if we are to 
provide a default here, we really need a complete use case description.


Can you supply it, please?

Once we have it, we can play a number of deployment-level tricks and 
make sure things work the way you expect them to.


Alternatively, contributions containing proper reasoning/mitigation are 
always welcome.


Regards,
Robert




Thanks,
Yevgeny

-Original Message-
From: Robert Varga 
Sent: Wednesday, December 15, 2021 7:58 AM
To: Yevgeny Shakhnovich ; Miroslav
Mikluš 
Cc: Discuss@lists.opendaylight.org
Subject: Re: [ODL Discuss] Multiple mount points for the same device

On 13/12/2021 16:05, Yevgeny Shakhnovich wrote:

Hi Miroslav,

Thank you for your prompt response but I am slightly disappointed by it.
I hoped that I overlooked something.  A user can create a mount point
using Restconf and can modify this mount point using the same Restconf.
Our application cannot control it. Do you provide any interceptor that
we can use to enforce the uniqueness? I am not aware of it.


I am not sure what exactly is the use case you are asking for. You certainly
do not have to use the stock netconf-topology component, or can filter
access to the network topology through usual API gw methods.

As for uniqueness -- we are giving people flexibility to do what they
need -- and that includes having netconf topology nodes which connect to the
same device.

Regards,
Robert





Thanks,

Yevgeny

*From:* Miroslav Mikluš 
*Sent:* Monday, December 13, 2021 12:46 AM
*To:* Yevgeny Shakhnovich mailto:yevgeny.shakhnov...@ipinfusion.com>>
*Cc:* Discuss@lists.opendaylight.org
<mailto:Discuss@lists.opendaylight.org>
*Subject:* RE: [ODL Discuss] Multiple mount points for the same device

Dear Yevgeny,

You can implement uniqueness of host, port or credentials in your own
controller application,

but I think that OpenDaylight should not assume that any of those
mount-point attributes are

fixed and user / client application should be able to change them.

Cheers,

Miroslav

*From:* Discuss@lists.opendaylight.org
<mailto:Discuss@lists.opendaylight.org>
mailto:Discuss@lists.opendaylight.org>> *On Behalf Of *Yevgeny
Shakhnovich
*Sent:* Thursday, December 9, 2021 5:47 PM
*To:* Discuss@lists.opendaylight.org
<mailto:Discuss@lists.opendaylight.org>
*Subject:* [ODL Discuss] Multiple mount points for the same device

Hi ODL,

We found that we can create a few Netconf mount points for the same
device by using different node-ids. So, the host, the port, the
credentials are the same. Only the node-id is different for each mount
point.  ODL does not check for uniqueness of the host/port combination.

Is it intentional? I cannot imagine a use case justifying it.

Is it possible to exclude such duplication?

We use Silicon release of ODL.

Thanks,

Yevgeny


.






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8860): https://lists.opendaylight.org/g/Discuss/message/8860
Mute This Topic: https://lists.opendaylight.org/mt/87615798/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Mount Point Schema

[Robert Varga]

On 12/01/2022 19:48, Ronald Hoang wrote:

Hi,

When mounting a netconf device initially there is an option to have a 
custom distinct schema cache for that node that is separate from the 
default cache/schema. You can also have multiple nodes using your 
distinct cache if they use the same yang modules so you may allocate 
them accordingly.


When doing your initial put request for your netconf mount you can add 
the following option: xmlns="urn:opendaylight:netconf-node-topology">custom_cache_name_here


This should create a separate schema cache that can be found under 
/cache/custom_cache_name


Hope this helps!


Yup. If you have a network of devices which have inconsistent models, 
this is the only way forward -- i.e. configure devices sharing the same 
view of a model to share a particular schema directory.


At the end of the day, you can go as far as having each device have its 
own cache directory (although I would not call that kind of setup 
efficient).


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8859): https://lists.opendaylight.org/g/Discuss/message/8859
Mute This Topic: https://lists.opendaylight.org/mt/88328929/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] OpenDaylight having trouble parsing schema list reported by netconf get request because of augmented leaf nodes

[Robert Varga]

Hello Roland,

On 19/01/2022 22:05, Ronald Hoang wrote:
Looking further into the source code, I found in XmlParserStream.java in 
yangtools to throw the exception that is causing my issue on line 566. 
There is a comment at the conditional statement noting that the node is 
unhandled and it is still undecided what to do with the node. I see 
online that people have made test cases setting this boolean value 
"strictParsing" to false, which would solve my issue, however I have not 
seen a method from the current distribution that would allow me to set 
this setting to false when mounting a new NetConf device to the ODL 
controller so it can still automatically create the schema context. Is 
there a way to do this? Would one have to go through the process of 
adding to an existing feature in the open source project to achieve this 
goal?


This (with the previous email) sounds like a problem with schema 
information/interpretation of a particular details.


Can you provide further details around the device and/or the steps to 
reproduce? Otherwise we are talking about (very difficult to bracket) 
theoretical scenarios, which are rather difficult to diagnose through 
emails...


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8858): https://lists.opendaylight.org/g/Discuss/message/8858
Mute This Topic: https://lists.opendaylight.org/mt/88395416/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] #opendaylight #help Update archetype based project from AL SR4 to Phosphorus latest

[Robert Varga]

On 11/01/2022 11:12, Zsolt Krenak wrote:

Hi Robert,


Hello Zsolt, everyone,

Sorry, if this is a duplicate, I sent this in the morning, but I cannot 
see it sent so I send it again.


So, the AAA version is the latest released: 0.14.7 which is most 
probably the problem, as this version is still referencing odlparent 
9.0.8 and mdsal 8.0.7. If we downgrade to the released versions of 
Phosphorus SR1 based on these versions (Platform versions — 
integration/distribution master documentation (opendaylight.org) 
) 
then everything seems to work. So I figure the problem is that the log4j 
fix is not yet released "officially". Right now went for SR1 which was 
probably the harder part and now wait for a new release that contains 
log4j fix (probably SR2?). Is there maybe a timeline for this? Thanks is 
advance.


Right. As per our community support, Phosphorus SR2 will have Log4Shell 
resolved in the timelines documented in the release plan (sorry, I don't 
have the link readily available, I am sure Daniel, CCd, does).


As per our governance, a number of MRI projects have releases unaffected 
by Log4Shell available, but those are not completely integrated. If 
memory serves right, we are now blocked by CONTROLLER-2025, which we 
want to have fixed in Phosphorus SR2 as well.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8857): https://lists.opendaylight.org/g/Discuss/message/8857
Mute This Topic: https://lists.opendaylight.org/mt/88187032/21656
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Mute #help:https://lists.opendaylight.org/g/Discuss/mutehashtag/help
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] OPNFLWPLUG-1121: Log4J Bug

[Robert Varga]

Hello,

as a community we generally frown on private emails where general 
concerns are involved. I suggest you engage with (at least) 
discuss@lists.opendaylight.org and/or d...@lists.opendaylight.org.


In relation with Log4Shell set of vulnerabilities, I have sent a few 
emails as to how the situation is going to be handled by the security 
team and the wider community (e.g. what I am going to do).


I suggest reviewing these mailing lists and engaging either the 
community (on said mailing lists) or your commercial support provider to 
get the answers you seek.


Regards,
Robert

On 17/01/2022 14:44, Rohini Unni wrote:

Thanks Arun.

Regards,
Rohini

On Mon, Jan 17, 2022 at 11:30 AM D Arunprakash 
mailto:d.arunprak...@ericsson.com>> wrote:


+++
Adding current contributors of Openflowplugin.

__ __

Regards,

Arun

__ __

*From:* Rohini Unni mailto:rohini...@gmail.com>>
*Sent:* Monday, January 17, 2022 11:24 AM
*To:* D Arunprakash mailto:d.arunprak...@ericsson.com>>
*Subject:* Re: OPNFLWPLUG-1121: Log4J Bug

__ __

Hi ,

__ __

Could you please update on this request?

__ __

Regards,

Rohini.

__ __

On Thu, Jan 13, 2022 at 4:37 PM Rohini Unni mailto:rohini...@gmail.com>> wrote:

Hi ,

__ __

This is regarding the Log4J vulnerability reported in ODL .


https://jira.opendaylight.org/projects/OPNFLWPLUG/issues/OPNFLWPLUG-1121?filter=allopenissues




Could you please let us know when this issue will be fixed and
released?

Currently, we are working on an ODL project(Silicon) where this
vulnerability has been reported.

__ __

Regards,

Rohini.




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8856): https://lists.opendaylight.org/g/Discuss/message/8856
Mute This Topic: https://lists.opendaylight.org/mt/88549920/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] #opendaylight #help Update archetype based project from AL SR4 to Phosphorus latest

[Robert Varga]

On 04/01/2022 10:17, Zsolt Krenak wrote:

Hi Everyone,


Hey Zsolt,

I'm trying to bump our ODL version from Aluminium SR4 to Phosphorus 
latest due to the log4j vulnerability. Our repo is based on the 
generated archetype repo. I bumped all parent adn dependency versions I 
could find in poms to the following:


odlparent 9.0.9
controller 4.0.7
netconf 2.0.11
mdsal 8.0.8

I fixed the compiliation errors in our plugin and odl compiles fine. On 
the other hand when karaf is started the follwing exception happens:


/Apache Karaf starting up. Press Enter to open the shell now.../

/ 99% 
[===>]org.apache.karaf.features.internal.util.MultiException: 
Error restarting bundles:/


/        Exception in 
org.ops4j.pax.web.extender.war.internal.Activator.start() of bundle 
org.ops4j.pax.web.pax-web-extender-war./


[snip]

/I also cloned the archetypes project and bump the versions there to 
have a reference. When I run mvn clean install, the Opendaylight Rest 
single feature test dies for the exact same reason. Probably something 
is missing because this is a big jump in versions, could someone give me 
a hint what is missing or what changed since aluminium that could cause 
this problem? Thanks is advance!


It seems *something* is off, but you do not mention the AAA version. Can 
you perhaps post full karaf.log, so I can see what bundles are being 
installed?


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8850): https://lists.opendaylight.org/g/Discuss/message/8850
Mute This Topic: https://lists.opendaylight.org/mt/88187032/21656
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Mute #help:https://lists.opendaylight.org/g/Discuss/mutehashtag/help
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Multiple mount points for the same device

[Robert Varga]

On 13/12/2021 16:05, Yevgeny Shakhnovich wrote:

Hi Miroslav,

Thank you for your prompt response but I am slightly disappointed by it. 
I hoped that I overlooked something.  A user can create a mount point 
using Restconf and can modify this mount point using the same Restconf. 
Our application cannot control it. Do you provide any interceptor that 
we can use to enforce the uniqueness? I am not aware of it.


I am not sure what exactly is the use case you are asking for. You 
certainly do not have to use the stock netconf-topology component, or 
can filter access to the network topology through usual API gw methods.


As for uniqueness -- we are giving people flexibility to do what they 
need -- and that includes having netconf topology nodes which connect to 
the same device.


Regards,
Robert





Thanks,

Yevgeny

*From:* Miroslav Mikluš 
*Sent:* Monday, December 13, 2021 12:46 AM
*To:* Yevgeny Shakhnovich >

*Cc:* Discuss@lists.opendaylight.org 
*Subject:* RE: [ODL Discuss] Multiple mount points for the same device

Dear Yevgeny,

You can implement uniqueness of host, port or credentials in your own 
controller application,


but I think that OpenDaylight should not assume that any of those 
mount-point attributes are


fixed and user / client application should be able to change them.

Cheers,

Miroslav

*From:* Discuss@lists.opendaylight.org 
 > *On Behalf Of *Yevgeny Shakhnovich

*Sent:* Thursday, December 9, 2021 5:47 PM
*To:* Discuss@lists.opendaylight.org 
*Subject:* [ODL Discuss] Multiple mount points for the same device

Hi ODL,

We found that we can create a few Netconf mount points for the same 
device by using different node-ids. So, the host, the port, the 
credentials are the same. Only the node-id is different for each mount 
point.  ODL does not check for uniqueness of the host/port combination.


Is it intentional? I cannot imagine a use case justifying it.

Is it possible to exclude such duplication?

We use Silicon release of ODL.

Thanks,

Yevgeny


.




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8847): https://lists.opendaylight.org/g/Discuss/message/8847
Mute This Topic: https://lists.opendaylight.org/mt/87615798/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

[ODL Discuss] Old RESTCONF northbound scheduled for removal

[Robert Varga]

Hello everyone,

as you might be aware, OpenDaylight ships two versions of RESTCONF 
northbound.


The first is the all-familiar implementation of 
draft-bierman-netconf-restconf-02, available at localhost:8181/restconf.


The second is the implementation of RFC8040, available at 
localhost:8181/rests.


TL;DR of this email is that we plan to completely remove the first 
implementation in our 2022.09 Chlorine release. If it is a problem for 
you, please speak out now.



There are multiple reasons driving this decision:

1. The old interface does not (and cannot) support YANG 1.1 action 
statements, i.e. there is no way to invoke them.


2. RFC8040 implementation is considered now considered a 
fully-maintained and production-ready equivalent.


3. The implementation is effectively frozen, receiving only minimal 
updates required for it to remain working in face of upstream API changes.


4. Bringing the implementation into a shape which is maintainable in the 
long term requires a large-scale refactor with the associated risk of 
introducing regressions.


5. The implementation is the only user of a number of pieces of upstream 
code, preventing that code from being removed.



The tracker issue for the removal is 
https://jira.opendaylight.org/browse/NETCONF-837 and the plan of action 
is as follows:


1. Phosphorus SR2, due out 2022-01-27, will issue a single (mild) 
warning on startup. We will continue to install the implementation as 
part of the 'odl-restconf' feature.


2. 2022.03 Sulfur, due out 2022-03-17, will not install the old 
implementation by default. Users will be required to explicitly install 
the 'odl-restconf-nb-bierman02' feature. The warning introduced in step 
1. will be updated to warn about the fact the feature is no longer 
supported and scheduled for removal in the next major release.


3. Old implementation will be removed from the netconf git repository's 
master branch as soon as the 3.0.x stability branch for Sulfur is 
created -- i.e. March/April 2022.


4. 2022.09 Chlorine, due out in September 2022, will not include the old 
implementation.


Unless serious objections to this are raised by 2022-01-10 we will 
execute it exactly as outlined above.


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8843): https://lists.opendaylight.org/g/Discuss/message/8843
Mute This Topic: https://lists.opendaylight.org/mt/87424268/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Remove www-authenticate from response header. #help #opendaylight

[Robert Varga]

On 29/09/2021 07:38, sachin.gu...@hsc.com wrote:
Calling any RESTConf API with invalid credentials, the response returned 
is HTTP Status code 401 with header field "WWW-Authenticate".


Consequently chrome browser displays a pop up to enter credentials. In 
order to avoid that pop-up, Response should not include 
"WWW-Authenticate" header.


Please suggest ways to remove the header "WWW-Authenticate"?


I am not aware of us explicitly doing this, so I suspect this is 
something Jetty does, so look at its configuration?


From usability perspective, that does make sense, though, as serving a 
plain "401" does not really tell you much...


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8837): https://lists.opendaylight.org/g/Discuss/message/8837
Mute This Topic: https://lists.opendaylight.org/mt/85942529/21656
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Mute #help:https://lists.opendaylight.org/g/Discuss/mutehashtag/help
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Netconf configuration storage #opendaylight

[Robert Varga]

On 10/11/2021 21:52, makuz...@gmail.com wrote:

Hi All,


Hello Maciej,

I'm trying to build a device configuration management application using 
OpenDaylight and lighty.io.
When I'm adding Netconf connector to the network topology I'm able 
(after device is succesfully connected) to read and modify device's 
configuration through the data broker taken from the mount point.
 From what I've learned (and please correct me if I'm wrong) mount 
point's data broker delegate all Netconf operations directly to the 
device so device configuration is kept only inside the device itself - 
in particular configuration is not available if the device is not connected.


Yes, netconf mountpoints are completely stateless.

There is a need to store configurations from multiple devices in 
distributed store for high availability.

My question is:
Is there a way to keep devices' configurations inside controller's 
MD-SAL storage?


Not out of the box, no.

I would like to store, read and modify device configuration even if the 
device itself is not connected and then e.g. synchronize it later.


All the building blocks are present, AFAICT, it is just a matter of 
putting some engineering into getting it off the ground.


Note though, what you are looking for is essentially a cache -- and you 
get into https://martinfowler.com/bliki/TwoHardThings.html area -- hence 
there are number of questions, all starting with "what should happen if":


- what should happen if the datastore accepts something the device does not?
- what should happen if both the cached view and the device's 
configuration changes?
- what should happen if the device changes while it's not connected? 
(think firmware upgrades)


And then it's just a matter of getting to code written and contributed :)

Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8835): https://lists.opendaylight.org/g/Discuss/message/8835
Mute This Topic: https://lists.opendaylight.org/mt/86971241/21656
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] [integration-dev] [opendaylight-dev][release] OpenDaylight - Silicon SR3 release status

[Robert Varga]

On 10/11/2021 04:12, Luis Gomez wrote:
The release actually happened before the other projects because TPCE 
does not depend anymore on MSI projects. For future, I would still 
recommend TPCE to wait for the TSC release approval, otherwise there is 
risk of having to repeat the release if for a example a bug in the 
kernel is found.


Well, that's true, but then spinning a new release of a single project 
is quite straightforward, so TPCE can run as fast as kernel projects are 
integrated into int/dist -- it even could become an MRI project, if they 
so choose.


Regards,
Robert





BR/Luis


On Nov 9, 2021, at 5:47 PM, Daniel de la Rosa > wrote:


HI Gilles,

This is from the other email thread The logs you show below are 
for a normal merge job that does not publish release artifacts but 
SNAPSHOT. So in short, you have bumped TPCE to use Silicon SR3 but the 
actual TPCE Silicon SR3 release does not happen until 1) Silicon SR3 
release artifacts for all managed projects are published in nexus and 
2) you execute this release merge job: 
https://jenkins.opendaylight.org/releng/view/transportpce/job/transportpce-release-merge 



thanks

On Tue, Nov 9, 2021 at 7:09 AM > wrote:


Hi Daniel,

__ __

Shweta released TransportPCE SR3 last week. 

Please see the following log :

https://s3-logs.opendaylight.org/logs/releng/vex-yul-odl-jenkins-1/transportpce-release-merge/23/



At first sight it seems OK.

Please tell us if there is any other action required from our side
(still the release note to update)

__ __

Gilles

__ __

__ __

*De :*integration-...@lists.opendaylight.org

[mailto:integration-...@lists.opendaylight.org
] *De la part de*
Daniel de la Rosa
*Envoyé :* mardi 9 novembre 2021 15:53
*À :* Anil Belur mailto:abe...@linuxfoundation.org>>; LAMBERT Guillaume INNOV/NET
mailto:guillaume.lamb...@orange.com>>; VACHHANI, SHWETA
(sv1...@att.com ) mailto:sv1...@att.com>>
*Cc :* 'integration-...@lists.opendaylight.org
'
(integration-...@lists.opendaylight.org
)
(integration-...@lists.opendaylight.org
)
mailto:integration-...@lists.opendaylight.org>>; Andrew Grimberg
mailto:agrimb...@linuxfoundation.org>>; Casey Cain
mailto:cc...@linuxfoundation.org>>;
OpenDaylight Discuss mailto:discuss@lists.opendaylight.org>>; Release
mailto:rele...@lists.opendaylight.org>>;
navid.ghazisa...@verizon.com 
*Objet :* Re: [integration-dev] [opendaylight-dev][release]
OpenDaylight - Silicon SR3 release status

__ __

Thank you for the update. Guillaume and/or Shweta, please proceed
at your earliest convenience

__ __

On Sun, Nov 7, 2021 at 4:09 PM Anil Belur
mailto:abe...@linuxfoundation.org>>
wrote:

Hello All,

OpenDaylight Silicon SR3 version bump is complete and the
staging repository is being promoted. The 'stable/silicon'
branch is unlocked.

Pending activities required to be complete for the release:
1. Self-managed projects to release artifacts for Silicon SR3.
2. Release Distribution once step 1. is complete.
3. Release notes merge CR.
https://git.opendaylight.org/gerrit/c/docs/+/98347

4. Update ODL downloads page [1.].

Thanks to everyone who contributed to the Silicon SR3 release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html

[1.]
https://wiki.opendaylight.org/display/ODL/Silicon+SR3+Release+Approval



-- 

Daniel de la Rosa

ODL Release Manager

__ __


_

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

Re: [ODL Discuss] Question: Opendaylight Callhome / Keepalive

[Robert Varga]

On 04/11/2021 10:45, Lena Peuker wrote:

Hi together,


Hello Lena,

actually we try to integrate a specific network-function via callhome 
with opendaylight, but we struggle with a specific issue.


 1. The NF triggers callhome (TCP) towards SDNC, capabilities are
loaded, netconf-session is established and NF is automatically
mounted in ODL.
 2. NF sends periodically keep-alive messages and expects a response. ->
  SSH_MSG_GLOBAL_REQUEST keepal...@example.com
 want-reply=true
 3. ODL receives the keep-alive messages but it seems as it is not
supported. ->  SSH_MSG_REQUEST_FAILURE
 4. NF drops the connection to ODL (NF is unmounted and ssh connection
is dropped).


Can you provide details on the NF? Strictly speaking it should interpret 
any reply to the keepalive as okay and not tear the session down...


We also thought that these keep-alive messages are something unspecific 
and is not related to callhome, but it is also described in the RFC 8071 
  (https://datatracker.ietf.org/doc/html/rfc8071#section-4.1 
 – s. S7) to 
establish a persistent Netconf-session through SSH.


Now the question is:

  * Does a specific version of ODL supports these keep-alive mechanisms?
  * Is it possible to handle these keep-alive messages to establish a
persistent Netconf-session through SSH? 


I am pretty sure we solved this issue many moons ago, to the point I 
don't remember when.



I also dropped a snippet of karaf.log which gives some more details.


Looking at this, it seems the software stack is using Aluminium, either 
SR2 or SR3 -- which is not the latest release in Aluminium stream.


It would be very helpful for us to get some support or just a note if 
  ODL in general supports this mechanisms.


So Aluminium is no longer supported by the community. You will need to 
upgrade to at least Silicon for us here to be able to help. If you 
cannot, there are multiple commercial support options available from 
https://pantheon.tech .


Regards,
Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8826): https://lists.opendaylight.org/g/Discuss/message/8826
Mute This Topic: https://lists.opendaylight.org/mt/86812631/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] [E] [OpenDaylight TSC] Moderating mailinglists

[Robert Varga]

Hey Casey, everyone,
On 28/10/2021 20:03, Casey Cain wrote:
Ok.  Sorry for the slow reply.  I've spent a big chunk of time going 
through the Groups.io settings changing things up a bit to hopefully 
reduce the spam.  Unfortunately there is no way to bulk apply settings.
I have removed the ability for non-members to post to our mailing list.  
They must at least be a member of annou...@lists.opendaylight.org 
<mailto:annou...@lists.opendaylight.org> to post (other than Security).  
New members will have their first message moderated and then they should 
be automatically unmoderated after that.  I've also added Navid as a 
moderator.


Let's trial this for a bit and see what happens.  Hopefully we'll see a 
reduction in spam.  If there are any other community volunteers that 
wish to act as moderators, please let me know.


Ah, this sounds like something really workable. Can we get this into 
today's TSC notes, so we can find the policy in future?


Thanks to much,
Robert



Best,
Casey Cain
Senior Technical Community Architect
Linux Foundation
_
WeChat: okaru6
WhatsApp: +1.503.779.4519
Book a Meeting w/ Casey <http://calendly.com/caseylf>


On Thu, Oct 21, 2021 at 10:50 AM Robert Varga <mailto:n...@hq.sk>> wrote:


On 21/10/2021 19:48, Ghazisaidi, Navid wrote:
 > Hi Robert,
 >
 > I'll take care of it. Can you send me the credentials and links
to the
 > mailbox(es)?

The way this works is you get those emails to a mailbox of your
choosing. How to set it up -- I have no idea, but I bet Casey does know
exactly what to do :)

Thanks so very much,
Robert

 >
 > Thanks,
     > Navid
 >
 > On Thu, Oct 21, 2021 at 10:26 AM Robert Varga mailto:n...@hq.sk>
 > <mailto:n...@hq.sk <mailto:n...@hq.sk>>> wrote:
 >
 >     Hello everyone,
 >
 >     we sorely need people moderating our mailing lists.
 >
 >     The jobs description is simple:
 >
 >     1) setup filters to redirect approvals to a separate folder
 >     2) look at that folder at least once a day, doing:
 >     2a) delete spam
 >     2b) send an empty reply to valid emails
 >
 >     Step 1) is required because groups.io <http://groups.io>
<http://groups.io <http://groups.io>> just does
 >     not have any spam
 >     filter, so you get all sorts of offers. S2N is probably
around 0.05.
 >     The
 >     good thing about is you know how most favorite spams on the
internet
 >     look like.
 >
 >     This is a critical job, as it makes our conversations with
potential
 >     new
 >     members fluid, as oftentimes they do not subscribe and ignore the
 >     message groups.io <http://groups.io> <http://groups.io
<http://groups.io>> sends them.
 >
 >     Any immediate takers or persons willing to find volunteers,
please?
 >
 >     Thanks,
 >     Robert
 >
 >     P.S.: Just a data point: in last 8 hours I got one new subscriber
 >     notification and 7 spam messages in that folder.
 >
 >     
 >




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8823): https://lists.opendaylight.org/g/Discuss/message/8823
Mute This Topic: https://lists.opendaylight.org/mt/86495960/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




OpenPGP_signature
Description: OpenPGP digital signature

Re: [ODL Discuss] Opendaylight Netconf configuration

[Robert Varga]

On 22/10/2021 17:35, arne.chres...@telekom.de wrote:

Hi Robert,


Hello Arne,

Apologies for my unsolicited message - I found your email address on the 
Opendaylight Netconf project page in jira. I am addressing you directly 
because I couldn’t find information on a mailing list or slack channel I 
could use. If that exists, I’m happy to use it in future. Please let me 
know.


No worries. For future reference, these queries are best addressed to 
discuss@lists.opendaylight.org, which has an audience of both devs and 
users.


My question is: How can I change the Netconf Call-Home port in ODL? I 
found the following in 
https://docs.opendaylight.org/projects/netconf/en/v1.13.1/user-guide.html#netconf-call-home 
 
: /The server uses port  by default and this can be configured via a 
blueprint configuration file./


However, I could not find any information where this blueprint file is 
located and what’s the file name. Optimally, I would like to adjust the 
setting already in my dockerfile when building the odl image.


This is the file 
https://github.com/opendaylight/netconf/blob/master/netconf/callhome-provider/src/main/resources/OSGI-INF/blueprint/callhome-topology.xml#L41-L47 
.


It should be possible to change it without editing files, but I am not 
sure about that.


It would be great if you could give me a hint or point me to the 
adequate forum for my question. Thanks a lot!


You're very welcome,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8818): https://lists.opendaylight.org/g/Discuss/message/8818
Mute This Topic: https://lists.opendaylight.org/mt/86572258/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] Reg: Dynamic registration of Yang Models #opendaylight

[Robert Varga]

On 20/10/2021 17:00, ravic...@gmail.com wrote:

Hello All,


Hello Ravi,

We are building a domain manager product in order to provision network 
devices in the PON and DOCSIS domains for which
we are using lighty.io as the core framework. We have quite a few YANG 
models which serve as the core models and these

models get registered with lighty as part of the lighty initialization.


Right, in either case of ODL or lighty.io, there is a set of 
pre-packaged models. Packaging for both also has Java Binding classes 
generated.


We also expose few RPC API s that enable writing of data into the MDSAL 
operational data store corresponding to the above models.
There is a requirement to support introduction of new YANG models into 
the system and as part of the process, these models need to be
stored into the MDSAL data tree and also dynamically registered with 
lighty.  Once these models are registered  the expectation is to be able

to write data into the MDSAL data tree for these models.

Currently, we have run into an issue where the dynamic registration of 
new YANG models is not working as expected and write is not happening
into MDSAL since MDSAL cannot recognize these models .Analysis of the 
lighty framework code revealed that upfront the lighty framework builds 
the schema context with the initial set of YANG models that are packaged 
with the application. This initial schema context is passed down to the 
RESTCONF module and assigned to some of the objects that are used

during write/read operations to/from MDSAL.
Any new model that gets introduced into the system post startup needs to 
go into the schema context.
The issue that we are facing is that lighty.io does not offer any API 
that facilitates addition of new models into the existing schema context 
and the schema

context needs to be rebuilt and updated wherever required.


Right, and this is boils down to default packaging and use-cases 
required. OpenDaylight components allow for this amount of flexibility, 
but not with the constraints you seem to be implying.


This is a use-case trade-off, which has essentially three competing 
requirements:


1. static component and model wiring (lighty)
2. access through binding APIs (default assumption)
3. runtime introduction of models (mechanism is critical)

In this model you can pick any two and there is a way to wire the 
components to do the right thing.


You are further constraining 3) by only talking about YANG models 
themselves. That automatically implies you are willing to forgo 2). Is 
that correct?


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8816): https://lists.opendaylight.org/g/Discuss/message/8816
Mute This Topic: https://lists.opendaylight.org/mt/86466972/21656
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [E] [OpenDaylight TSC] Moderating mailinglists

[Robert Varga]

On 21/10/2021 19:48, Ghazisaidi, Navid wrote:

Hi Robert,

I'll take care of it. Can you send me the credentials and links to the 
mailbox(es)?


The way this works is you get those emails to a mailbox of your 
choosing. How to set it up -- I have no idea, but I bet Casey does know 
exactly what to do :)


Thanks so very much,
Robert



Thanks,
Navid

On Thu, Oct 21, 2021 at 10:26 AM Robert Varga <mailto:n...@hq.sk>> wrote:


Hello everyone,

we sorely need people moderating our mailing lists.

The jobs description is simple:

1) setup filters to redirect approvals to a separate folder
2) look at that folder at least once a day, doing:
2a) delete spam
2b) send an empty reply to valid emails

Step 1) is required because groups.io <http://groups.io> just does
not have any spam
filter, so you get all sorts of offers. S2N is probably around 0.05.
The
good thing about is you know how most favorite spams on the internet
look like.

This is a critical job, as it makes our conversations with potential
new
members fluid, as oftentimes they do not subscribe and ignore the
message groups.io <http://groups.io> sends them.

Any immediate takers or persons willing to find volunteers, please?

Thanks,
Robert

P.S.: Just a data point: in last 8 hours I got one new subscriber
notification and 7 spam messages in that folder.





OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8815): https://lists.opendaylight.org/g/Discuss/message/8815
Mute This Topic: https://lists.opendaylight.org/mt/86495960/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[ODL Discuss] Moderating mailinglists

[Robert Varga]

Hello everyone,

we sorely need people moderating our mailing lists.

The jobs description is simple:

1) setup filters to redirect approvals to a separate folder
2) look at that folder at least once a day, doing:
2a) delete spam
2b) send an empty reply to valid emails

Step 1) is required because groups.io just does not have any spam 
filter, so you get all sorts of offers. S2N is probably around 0.05. The 
good thing about is you know how most favorite spams on the internet 
look like.


This is a critical job, as it makes our conversations with potential new 
members fluid, as oftentimes they do not subscribe and ignore the 
message groups.io sends them.


Any immediate takers or persons willing to find volunteers, please?

Thanks,
Robert

P.S.: Just a data point: in last 8 hours I got one new subscriber 
notification and 7 spam messages in that folder.


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8813): https://lists.opendaylight.org/g/Discuss/message/8813
Mute This Topic: https://lists.opendaylight.org/mt/86495420/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [OpenDaylight TSC] [opendaylight-dev][release] OpenDaylight - Phosphorus release status

[Robert Varga]

On 07/10/2021 14:47, Guillaume Lambert via lists.opendaylight.org wrote:

Hello

I confirm  we are in the process of releasing with Gilles at the wheel.
Though, jenkins outtage are braking us.

After a succesfull build, the stage release job failed this morning with 
a weird message


ERROR: I/O error: NSPR connection reset


Argh, Sigul is broken, hence the job cannot sign the artifacts. Please 
retry and if it's still broken file an LF IT ticket. 
status.linuxfoundation.org is not reporting any issues, so this should 
Just Work(tm).


Regards,
Robert



https://jenkins.opendaylight.org/releng/job/transportpce-maven-stage-phosphorus/1/console 



BR
Guillaume


*De :* Daniel de la Rosa [ddelarosa0...@gmail.com]
*Envoyé :* jeudi 7 octobre 2021 00:08
*À :* Anil Belur; LAMBERT Guillaume INNOV/NET
*Cc :* Andrew Grimberg; Casey Cain; OpenDaylight Discuss; Release; TSC; 
integration-...@lists.opendaylight.org; navid.ghazisa...@verizon.com
*Objet :* Re: [opendaylight-dev][release] OpenDaylight - Phosphorus 
release status


Thanks for the update. I believe TransportPCE is in the process of 
releasing in phosphorus  but I’m going to let Guillaume confirm this.


On Mon, Oct 4, 2021 at 4:40 PM Anil Belur > wrote:


Hello All,

OpenDaylight Phosphorus version bump is complete and the staging
repository has been promoted. The 'stable/phosphorus' branch is
unlocked and ready for development.

Pending activities required to be complete for the release:
1. Self-managed projects to release artifacts for Phosphorus.
2. Release Distribution once the 1. is complete.
3. Release notes - $Project PTL's to submit release notes to
Opendaylight docs.
4. Update ODL downloads page [1.].

Many thanks to everyone who contributed to the Phosphorus release.

Regards,
Anil Belur

[0.] https://docs.opendaylight.org/en/latest/downloads.html


--
Daniel de la Rosa
ODL Release Manager

_

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.







OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8800): https://lists.opendaylight.org/g/Discuss/message/8800
Mute This Topic: https://lists.opendaylight.org/mt/86246459/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] working simultaneously on new features and with upstream dependencies bug fixes

[Robert Varga]

On 06/10/2021 16:39, guillaume.lamb...@orange.com wrote:

Hello


Hello again,


Thanks for your feedback Robert.
You're apologized for the late reply. My mailbox is also pretty full.

I agree with you. Release should be preferred to SNAPSHOT.
There is a lot of things that evolved since then and TPCE can certainly do that 
now.
It is much more easier. Just to mention it, having Netconf in MRI helped us a 
lot.
Thanks again to you and the netconf team for this hard work.
We should probably advertize that to ONAP people who bumped into similar issues.
They might be interested in using a closer version of Opendaylight.


Right, although I do not know how it aligns with their plans :)

My take on that is that the onap distro thing we build in int/dist needs 
to be rehosted into ccsdk (or wherever). Unfortunately they do not trust 
our SRs and as I understand it they are not quite there in terms of what 
they'll need to do for closer tracking.


I hope to get that conversation started, but it looks as though that's 
going to be a 2022 thing.



Yes local maven repo is not so pretty but usually works.
Rebuilding jars takes times on bigger projects and  is a bit hard for maven 
beginners.
Though, it is not always feasible just after a release bump.

Daily builds would be the holy grail but 3 weeks average is already a good 
start.
If we can live with that today, it can be certainly improved.


It is a start, but is a ton of error-prone, repetitive manual work. Next 
step is to get the automation in place and once we have it, we'll see if 
we can crank it up to 11.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8796): https://lists.opendaylight.org/g/Discuss/message/8796
Mute This Topic: https://lists.opendaylight.org/mt/77657975/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] working simultaneously on new features and with upstream dependencies bug fixes

[Robert Varga]

On 19/10/2020 15:34, guillaume.lamb...@orange.com wrote:

Hi all


Hello,

We started an interesting discussion during our DDF last week with 
Robert who proposed to keep on talking by email.


Sorry this was stuck way down on the to-reply list.


Here is a quick sum-up.

During the release cycle, old –SNAPSHOT dependencies are regularly 
deleted from Nexus.


And they might be replaced by new ones with a bug that prevent from 
keeping on developing a new feature.


( For example YANG deviations not well supported in Netconf 
https://jira.opendaylight.org/browse/NETCONF-637 
)


The question is “how in that case keep on working on the new features 
development and parallel with the integration of new dependencies?”


There might be possibilities to use stable dependencies version in 
Jenkins by keeping on using –SNAPSHOT dependencies in the master branch.


Or should we wait for the dependencies bugs to be fixed ?


This is one of the reasons to not work on snapshots, but releases. So 
for normal operations, just use everything released -- transportpce can 
certainly do that today.


Now, receiving a fix, that should be possible if upstream codebase has 
not divereged much (usually does not) by:
- checkout upstream project's tag you have integrated (i.e. git checkout 
v2.0.5 for current netconf)

- cherry-pick required fixes
- rebuild changed artifacts

Your local maven repo now has the fixes working in those versions. Might 
not be the prettiest, but works.


Now the second thing is -- we want to have project releases done 
periodically. My running average is a release every ~3 weeks, but we can 
do much better.


I really want to see automatically-working as-needed daily releases, but 
that is a long journey -- the MRI testing rework being the prerequisite 
(releases must be gated and for that CSIT must be stable). Then we'll 
get into properly managing repository releases and propagating version 
bump patches, etc.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8793): https://lists.opendaylight.org/g/Discuss/message/8793
Mute This Topic: https://lists.opendaylight.org/mt/77657975/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[ODL Discuss] Heads up: odlparent-10 to use Guava-31

[Robert Varga]

Hellow everyone,

this is a courtesy call to inform you that odlparent-10 will be adopting 
Guava-31.x.x as its baseline.


Most of the users should not be affected, but there are a number of 
incompatibilities listed here: 
https://github.com/google/guava/releases/tag/v31.0


Please object now it this does not suite you.

Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8789): https://lists.opendaylight.org/g/Discuss/message/8789
Mute This Topic: https://lists.opendaylight.org/mt/85850290/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[ODL Discuss] The road to Java 17

[Robert Varga]

Hello everyone,

as you might have noticed, Java 17 has been released: 
https://jdk.java.net/17/ with reference implementation here: 
https://jdk.java.net/java-se-ri/17


OpenDaylight currently requires Java 11 at compile-time and *should* be 
able to run on everything up to Java 17. This *should* is currently not 
enforced by our CI, but I am not aware of any reasons this would not be 
the case.


Java 17 is the next LTS release, which there are multiple support 
options available, with at least 8 years of support being available.


As per our usual OpenDaylight support policy, we are currently 
supporting Java 17 runtime on a best-effort policy: any issues found 
will be dealt with to the extent considered feasible.


Going forward, though, we will require Java 17 as both compile-time and 
runtime very soon, simply because of the language feature options 
becoming available:

- https://openjdk.java.net/jeps/361 (switch expressions)
- https://openjdk.java.net/jeps/371 (hidden classes)
- https://openjdk.java.net/jeps/378 (text blocks)
- https://openjdk.java.net/jeps/394 (instanceof pattern matching)
- https://openjdk.java.net/jeps/395 (records)
- https://openjdk.java.net/jeps/409 (sealed classes)
- https://openjdk.java.net/jeps/415 (deserialization filters)
- https://jdk.java.net/17/release-notes#JDK-8251989 (improved CHA)

Furthermore, there are a ton of runtime improvements, which we can take 
into implementation considerations, like 
https://bugs.openjdk.java.net/browse/JDK-8266074. We want to take 
advantage to these ASAP.


IIUC, there are only a few issues which prevents us from adopting JDK 17 
as a requirement:
- maven-xtend-plugin compatibility (due to Guice, what a surprise), 
which should be solved in 2.26.0, whenever that is available

- SpotBugs compatibility, which should be addressed in 4.4.x series


With all this in picture, I believe the proper course in OpenDaylight is 
to have:
- Sulfur (22.03) supporting both JDK11 and JDK17 at compile-time, with 
artifacts compatible with JDK11+

- All of Sulfur being validated with JDK17
- Chlorine (22.09) to require JDK17+

Unless there are any objections, this is the current plan of record. If 
you disagree, please holler now.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8788): https://lists.opendaylight.org/g/Discuss/message/8788
Mute This Topic: https://lists.opendaylight.org/mt/85850198/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[ODL Discuss] Heads up: Sulfur will require maven-3.8.2+

[Robert Varga]

Hello everyone,

this is a heads-up notification that we will be implementing 
https://jira.opendaylight.org/browse/ODLPARENT-260 for Sulfur SimRel.


This is an upgrade from our current requirement of maven-3.5.x, but 
honestly if you do not have maven-3.6.x, you are wasting CPU cycles.


This version is widely available in Linux distributions by default, 
hence I do not see any reason to hold off. If you disagree, please 
holler now.


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8787): https://lists.opendaylight.org/g/Discuss/message/8787
Mute This Topic: https://lists.opendaylight.org/mt/85849634/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] yang tool failing to compile juniper yang with odl aluminium release #opendaylight

[Robert Varga]

On 20/05/2021 11:17, mohit1992gu...@gmail.com wrote:
> I am using the old aluminium version. I have connect the juniper SRX320
> device having junos verison 19.4R3-S1.3. 
> 

[snip]

> These following exception i am getting:
> ==
> *[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project sample-api: Compilation failure:
> Compilation failure:*
> *[ERROR]
> /home/hscuser/zeetta_work/netos/sample/api/target/generated-sources/mdsal-binding/org/opendaylight/yang/gen/v1/http/yang/juniper/net/junos/es/conf/root/rev190101/juniper/tenant/security/dynamic/address/address/name/profile/category/property/property/value/case_1/StringBuilder.java:[160,33]
> cannot find symbol*
> *[ERROR]   symbol:   method length()*
> *[ERROR]   location: variable value of type
> org.opendaylight.yang.gen.v1.http.yang.juniper.net.junos.es.conf.root.rev190101.juniper.tenant.security.dynamic.address.address.name.profile.category.property.property.value.case_1.String*
> *[ERROR]
> /home/hscuser/zeetta_work/netos/sample/api/target/generated-sources/mdsal-binding/org/opendaylight/yang/gen/v1/http/yang/juniper/net/junos/es/conf/root/rev190101/juniper/tenant/security/dynamic/address/address/name/profile/category/property/property/value/case_1/StringBuilder.java:[169,30]
> incompatible types: java.lang.String cannot be converted to
> org.opendaylight.yang.gen.v1.http.yang.juniper.net.junos.es.conf.root.rev190101.juniper.tenant.security.dynamic.address.address.name.profile.category.property.property.value.case_1.String*
> *[ERROR] -> [Help 1]*

Looks like a bug, please file an issue with MD-SAL project in
jira.opendaylight.org.

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8739): https://lists.opendaylight.org/g/Discuss/message/8739
Mute This Topic: https://lists.opendaylight.org/mt/82957680/21656
Mute 
#opendaylight:https://lists.opendaylight.org/g/Discuss/mutehashtag/opendaylight
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] ODL Issue For Ietf-alarm yang with key as identity

[Robert Varga]

On 22/04/2021 14:41, Anshul Agrawal wrote:
> Hi,

Hello,

> I am working for Netconf protocol for ietf-alarm yang.
> 
>  
> 
> https://tools.ietf.org/html/rfc8632 
> 
>  
> 
> Ietf-alarm yang has 3 keys for /alarms/alarm-list/alarm list, where
> alarm-type-id is key of  IdentityRef type.
> 
>  
> 
> typedef alarm-type-id {
> 
>   type identityref {
> 
>     base alarm-type-id;
> 
>   }
> 
>   description
> 
>     "Identifies an alarm type.  The description of the alarm type
> 
>  id MUST indicate whether or not the alarm type is abstract.
> 
>  An abstract alarm type is used as a base for other alarm type
> 
>  ids and will not be used as a value for an alarm or be present
> 
>  in the alarm inventory.";
> 
>     }
> 
>  
> 
>  
> 
> While performing get-config operation, via Postman, I am forming all 3
> keys where one of key is of type identityref.
> 
>  
> 
> alarm-type-id  à this key is provided using
> 
>  : 
> 
> test-openconfig-extensions:ABCD
> 
>  
> 
> But ODL is sending this request in following format :-

Can you specify the version you are using, please?

> 
> http://openconfig.net/yang/test/yang/extensions
> >x:ABCD
> 
>  
> 
> Question here is why ODL is sending this request as “x= or “x:  at place
> of original module name.

Northbound interface is RESTCONF, which is using module names for
namespace specification (see RFC8040, section 3.5.3)

Southbound interface is NETCONF, which in turn means XML encoding --
which is using XML's built-in facilities for namespace specification
(see RFC6020 section 9.10.3), which are completely independent of YANG
module names.

We are using a strategy which is consistent with examples in RFC6020
section 9.10.5.

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8732): https://lists.opendaylight.org/g/Discuss/message/8732
Mute This Topic: https://lists.opendaylight.org/mt/82286191/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] Removal of opendaylight-topology.yang

[Robert Varga]

On 28/03/2021 21:57, Luis Gomez wrote:
> I think OFP still uses these models:
> 
> https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=applications/topology-manager/pom.xml;h=d7e0d2151ea6e35955651195373439409e146651;hb=refs/heads/master#l42
> <https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=applications/topology-manager/pom.xml;h=d7e0d2151ea6e35955651195373439409e146651;hb=refs/heads/master#l42>

Ah, yes, thanks for pointing that out. I wonder how I missed those.

> Maybe we should move them to OFP project.

Yes, that would be the plan for opendaylight-inventory anyway (used only
by OFP last time I checked). I will re-check and send out a follow up
about those.

Thanks,
Robert


> 
> BR/Luis
> 
> 
>> On Mar 26, 2021, at 4:06 AM, Robert Varga > <mailto:n...@hq.sk>> wrote:
>>
>> Hello everyone,
>>
>> as we are ramping out changes which will go into the Phosphorus MRI
>> window (and thus be part of Phosphorus Simultaneous Release ~6 months
>> from now), there is one major removal.
>>
>> It concerns OpenDaylight-specific models:
>> - opendaylight-topology.yang
>> - opendaylight-topology-inventory.yang
>> - opendaylight-topology-view.yang
>>
>> These models go back to 2013 and are the first cut at modeling a network
>> of devices and interacting with it in the context of a model-driven
>> controller.
>>
>> The concepts introduced here have been gradually superseded by RFC7950's
>> (YANG 1.1) introduction of 'action' as well as the work done under the
>> auspices of IETF's I2RS Working Group
>> (https://datatracker.ietf.org/wg/i2rs/documents/
>> <https://datatracker.ietf.org/wg/i2rs/documents/>).
>>
>> Since the last user of these models, controller's equally-obsolete
>> 'messagebus', is going away in this release, so are these models. This
>> work item is tracked here:
>> https://jira.opendaylight.org/browse/CONTROLLER-1978
>> <https://jira.opendaylight.org/browse/CONTROLLER-1978>.
>>
>> Regards,
>> Robert
>>
>>
>> 
>>
> 



OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8703): https://lists.opendaylight.org/g/Discuss/message/8703
Mute This Topic: https://lists.opendaylight.org/mt/81625190/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[ODL Discuss] Removal of opendaylight-topology.yang

[Robert Varga]

Hello everyone,

as we are ramping out changes which will go into the Phosphorus MRI
window (and thus be part of Phosphorus Simultaneous Release ~6 months
from now), there is one major removal.

It concerns OpenDaylight-specific models:
- opendaylight-topology.yang
- opendaylight-topology-inventory.yang
- opendaylight-topology-view.yang

These models go back to 2013 and are the first cut at modeling a network
of devices and interacting with it in the context of a model-driven
controller.

The concepts introduced here have been gradually superseded by RFC7950's
(YANG 1.1) introduction of 'action' as well as the work done under the
auspices of IETF's I2RS Working Group
(https://datatracker.ietf.org/wg/i2rs/documents/).

Since the last user of these models, controller's equally-obsolete
'messagebus', is going away in this release, so are these models. This
work item is tracked here:
https://jira.opendaylight.org/browse/CONTROLLER-1978.

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8700): https://lists.opendaylight.org/g/Discuss/message/8700
Mute This Topic: https://lists.opendaylight.org/mt/81625190/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [opendaylight-dev] opendaylight关于dlux的问题

[Robert Varga]

Hello,

dlux has not been updated in quite a while due to no web developer being
interested enough. You can try your hand with self-building it from the
dlux.git master (which is setup to point ot Magnesium SR2), but I think
it does not really work yet.

Patches are, as always, welcome.

Regards,
Robert


On 28/09/2020 04:42, weiyueqi...@p5w.net wrote:
> 你好，
> 我现在安装的是opendaylight0.12.2版本。
> 以前的版本是用OpenDaylight User Experience (DLUX)展示网络拓扑 network
> topology.
> 现在0.12.2版本没有DLUX，那用什么来展示网络拓扑network topology ？
> 
> best wishes~
> 
> 如有问题及时联系，谢谢！
> 
> 韦跃强
> 深圳市全景网络有限公司
> 地址：深圳市福田区皇岗路5001号深业上城T2大楼49层
> 邮编：518028
> 邮件：weiyueqi...@p5w.net
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8656): https://lists.opendaylight.org/g/Discuss/message/8656
Mute This Topic: https://lists.opendaylight.org/mt/77203107/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [OpenDaylight TSC] ODL deployment survey

[Robert Varga]

On 28/08/2020 01:37, JamO Luhrsen wrote:
>>   * Will Operators be willing to have DevOps teams contribute to the
>> upstream community?
>>
> Just DevOps? I think other contributions are sorely missing as well.
> Dev, Test, release engineering...

Not only. My primary thought was "at least devops should participate
upstream", as that would be the core benefit of devops in my mind, but
certainly others should as well.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8629): https://lists.opendaylight.org/g/Discuss/message/8629
Mute This Topic: https://lists.opendaylight.org/mt/76464043/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] How can I change my topology using RESTCONF commands?

[Robert Varga]

On 23/07/2020 20:21, Luis Gomez wrote:
> I am not sure what is the purpose of reading/writting in the config
> topology:
> /restconf/configuration/network-topology:network-topology/topology/flow:1,
> but whatever it is, it is not implemented in ODL.

If I were to venture a guess, the intent *might* be to populate flows
via FRM, but if memory serves that part is being done via inventory ...
(and I am out of my depth here).

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8619): https://lists.opendaylight.org/g/Discuss/message/8619
Mute This Topic: https://lists.opendaylight.org/mt/75740317/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [opendaylight-dev] [release] Action for PTLs & projects: Project Wiki Pages

[Robert Varga]

On 03/07/2020 02:03, Luis Gomez wrote:
> As I said in this morning TSC, we have ODL interns helping moving
> content from old wiki to new wiki. If PTLs just fix the project landing
> page links to point to the right old wiki links, the interns can easily
> pick up and move old wiki links content to confluence.

Alright, I do have some high-priority items:

1)
https://wiki-archive.opendaylight.org/view/TSC:Procedures_and_Processes
is not replicated
https://wiki.opendaylight.org/pages/viewpage.action?pageId=329148

All of that content needs to be migrated.

2) Old TSC meeting minutes need to be migrated

Before we had meetbot, we used to prepare manual meeting minutes. There
is at the very least
https://wiki-archive.opendaylight.org/images/f/fb/TSC_2013-07-18_Minutes.pdf.
I know of this link because of Yang Tools Graduation Review -- but all
of these need to be hunted down and migrated to under TSC meetings.

3) Meetbot TSC meeting minutes are not replicated
https://wiki-archive.opendaylight.org/view/TSC:Meeting#Meeting_Minutes
lists a bunch of pointers to meeting minutes, but those links do not
work -- LF needs to be bugged about this, we have to have those meetings
in browsable form


These are TSC and governance resources, and they need to be readily
accessible (as Anil found during the INFO.yaml effort).


4) Archived meetings need to be migrated over:
https://wiki-archive.opendaylight.org/view/Archivedmeetings

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8602): https://lists.opendaylight.org/g/Discuss/message/8602
Mute This Topic: https://lists.opendaylight.org/mt/75465580/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] We can't edit wiki/confluence pages anymore

[Robert Varga]

On 26/05/2020 16:41, Guillaume Lambert via lists.opendaylight.org wrote:
> It’s true we received some pieces of information on the mailing-list but
> I would have appreciated a clear explanation about the strategy here if
> there is one.
> I am sorry but I didn’t catch by which fancy those domains migrations
> and unavailability appear, and also why they can’t be better
> synchronized with (at least major) release schedules.
> 
> Can we try to think about it next time, if there is one ?

I completely agree with the points raised.

As such, I think documentation is best kept in project's docs/**.rst and
hence have pointers to docs.opendaylight.org.

Having said that, I have done zero work towards that in the project I am
stewarding, sorry.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8588): https://lists.opendaylight.org/g/Discuss/message/8588
Mute This Topic: https://lists.opendaylight.org/mt/74352680/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [kernel-dev] How to avoid maven version check?

[Robert Varga]

On 16/04/2020 15:22, Wang senxiao wrote:
> 
> Hi all,
> 
>     *I compile my project use the command mvn clean install, but get an
> error:*
> 
>         [WARNING] Rule 1:
> org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message:
> 
>        Detected Maven Version: 3.3.9 is not in the allowed range [3.5.0,).
> 
> 
>     *my maven version is 3.3.9, and my project depends odlparent-lite
> 5.0.2, then I inside it and find the*

The enforcer rule is there for a reason, and that reason is that
odlparent-4.0.0+ is supported only with maven-3.5+, as noted here:
https://github.com/opendaylight/odlparent/blob/master/docs/NEWS.rst#version-400

maven-3.5.0 was released more than 3 years ago and is trivial to deploy
in any environment, just upgrade your installation.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8562): https://lists.opendaylight.org/g/Discuss/message/8562
Mute This Topic: https://lists.opendaylight.org/mt/73059725/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [OpenDaylight Discuss] ODL Got Link/Nodes information updated in real time

[Robert Varga]

On 25/03/2020 04:55, Daniel de la Rosa wrote:
> Thank you for the clarification. I thought that openflow stats included
> delay and jitter, and those were available via dlux..: but just checked
> and it is not the case 

Yeah, an OFP limitation. I do believe BGP/LS does include this TE
information, hence if you attach OpenDaylight to a BGP/LS feed from your
network you should be able to see that information and in real-time.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8558): https://lists.opendaylight.org/g/Discuss/message/8558
Mute This Topic: https://lists.opendaylight.org/mt/72534347/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [ODL Discuss] [Aaa-dev] [OpenDaylight Discuss] sodium restconf auth method

[Robert Varga]

On 24/03/2020 21:54, Luis Gomez wrote:
> Hi Michael,
> 
> I do not think there is any plan for replacing the removed oauth/token
> interface. Please feel free to contribute this to ODL.

Correct.

The initial announcement about this feature going away was here:
https://lists.opendaylight.org/g/aaa-dev/message/1607

As noone reacted to that, the feature was removed and that has been
properly announced (for example) here:
https://lists.opendaylight.org/g/Discuss/message/8282

Our stance has not changed since that message went out.

Regards,
Robert

> 
> BR/Luis
> 
> 
>> On Mar 23, 2020, at 9:44 AM, Michael Dürre
>> > > wrote:
>>
>> Hi,
>>
>> I already ask to aaa-...@lists.opendaylight.org but without any response.
>>
>> I'm trying to find out which new interfaces for login are available
>> since sodium release, because I see you removed the oauth/token
>> interface. 
>> https://jira.opendaylight.org/browse/AAA-173 but it is still part of
>> the documentation
>> (https://docs.opendaylight.org/projects/aaa/en/latest/user-guide.html). 
>> Because
>> we do not want to use basicAuth for our GUI. Is there maybe planned to
>> have or even already implemented JWT (jsonwebtoken) or something else?
>> I already tried to implemented this into neon-SR1 but with medium
>> success. That means it worked (so login and verify) but at the same
>> time disabled basicAuth.
>>
>> I'm thankful for every hint I can get.
>> Thanks in advance.
>>
>> Kind regards,
>> Michael
>> -- 
>> *Michael Dürre*
>> Software Engineer
>>  
>> highstreet technologies GmbH
>> Hähnelstraße 6
>> 12159 Berlin
>> Skype: michael.due...@highstreet-technologies.com
>> E-Mail: michael.due...@highstreet-technologies.com
>> 
>> Web: http://www.highstreet-technologies.com
>> 
>>  
>> Geschäftsführer: Dipl.-Ing. (FH) Alfons Mittermaier
>> Handelsregister: Amtsgericht Charlottenburg, HRB 114905 B
>> Firmensitz: Berlin
>> USt-IdNr.: DE261090513
>>  
>>  
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8557): https://lists.opendaylight.org/g/Discuss/message/8557
Mute This Topic: https://lists.opendaylight.org/mt/72537810/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OpenDaylight Discuss] DLUX is not available in Open Daylight- Sodium

[Robert Varga]

On 18/03/2020 05:59, Laxman Bhandari wrote:
> Hi,
> 
> I have installed new ODL (Sodium) and tried to add dlux features but it
> is not listed in karaf feature. Just wondering what could be the reason.

1) it is not part of Sodium release (SR2+ only)
2) it is not part of the base distribution (karaf-XYZ), only the full
distribution (opendaylight-XYZ).

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8545): https://lists.opendaylight.org/g/Discuss/message/8545
Mute This Topic: https://lists.opendaylight.org/mt/72071565/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OpenDaylight Discuss] [OpenDaylight TSC] TWS Today

[Robert Varga]

On 06/01/2020 17:55, Tejas Nevrekar wrote:
> Hi all,
> 
> The agenda for today's TWS was for getting together to complete the
> lighty project proposal.
> 
> Not sure if the lighty team is ok for that today.
> 
> Robert, can you please confirm?

Sorry, there's a public holiday in Slovakia, so everyone's off...

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8500): https://lists.opendaylight.org/g/Discuss/message/8500
Mute This Topic: https://lists.opendaylight.org/mt/69469682/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OpenDaylight Discuss] [opendaylight-dev] How to develop Netconf application with Sodium release?

[Robert Varga]

On 05/11/2019 11:36, Dudek, Michal (Nokia - PL/Krakow) wrote:
> Hello,
> 
> I would like to create Opendaylight application which manages devices
> connected via NETCONF interface.
> 
> Unfortunately, existing examples are outdated and are not supported with
> the latest SODIUM release of Opendaylight.
> 
> It includes basing RPC example
> 

The code snippets are a stale a bit there, plus the archetypes pointers
were wrong -- should work much better now.

> with RPC and nc-mount
> .

Ah, nc-mount is part of coretutorials, which is a rather dormant
project. I have hacked it up to at least compile against Neon, but
reviving it fully will take a couple of weeks more (and then all the
tutorials will need to be checked).

Regards,
Robert


> 
>  
> 
> I would appreciate for any up-to-date example how to create Netconf
> application or link do the documentation which specifies how to
> implement application with current Opendaylight version.
> 
>  
> 
> Best Regards,
> 
> Michal.
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#5674): https://lists.opendaylight.org/g/dev/message/5674
> Mute This Topic: https://lists.opendaylight.org/mt/42212055/1320659
> Group Owner: dev+ow...@lists.opendaylight.org
> Unsubscribe: https://lists.opendaylight.org/g/dev/unsub  [n...@hq.sk]
> -=-=-=-=-=-=-=-=-=-=-=-
> 



signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8477): https://lists.opendaylight.org/g/Discuss/message/8477
Mute This Topic: https://lists.opendaylight.org/mt/44298645/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OpenDaylight Discuss] l2switch flow removal

[Robert Varga]

On 18/10/2019 03:26, Luis Gomez wrote:

It is mostly a matter of bandwidth, expertise is not that important here. If 
you think you can spare some time in the ODL community, first updating the code 
to recent release (e.g. sodium), and second adding some features and fixing 
some bugs at your discretion, I would really encourage you to do so. When you 
are decided, please send a mail to the ODL TSC mail list 
(t...@lists.opendaylight.org) describing your plans for the project and asking 
how to proceed. AFAIR there is no established process to revive a project in 
OpenDaylight but the TSC should be able to come up with one.


I was just thinking about this some three days ago.

Migrating to Sodium GA is surprisingly easy -- 
https://git.opendaylight.org/gerrit/c/l2switch/+/85209.


If someone can fixup the UTs (see FIXME), we can have a self-released 
Sodium L2 Switch...


Regards,
Robert
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8456): https://lists.opendaylight.org/g/Discuss/message/8456
Mute This Topic: https://lists.opendaylight.org/mt/34547216/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OpenDaylight Discuss] unusual snapshots

[Robert Varga]

On 15/10/2019 22:11, Yevgeny wrote:

Hi,

Analyzing a problem on our customer site, we found an unusual for us 
content of snapshots folder:


-rw-rw-r-- 588369268 10 14 17:30 
snapshot-member-1-shard-default-operational-*40001*-1571041824314


-rw-rw-r    725285773 10 14 19:26 
snapshot-member-1-shard-default-operational-*80001*-1571048746771


-rw-rw-r-- 1393540512 10 14 20:54 
snapshot-member-1-shard-default-operational-*120002*-1571054003364


-rw-rw-r-- 248338135 10 14 21:03 
snapshot-member-1-shard-default-config-40001-1571054631140


-rw-rw-r-- 132 10 15 02:57 
snapshot-member-1-frontend-datastore-config-0-1571075868937


-rw-rw-r    137 10 15 02:58 
snapshot-member-1-frontend-datastore-operational-0-1571075900271


-rw-rw-r-- 158 10 15 02:59 
snapshot-member-1-frontend-datastore-Shard-prefix-configuration-shard-0-1571075991376


-rw-rw-r    139 10 15 02:59 
snapshot-member-1-frontend-datastore-Shard-default-0-1571075991541


-rw-rw-r--  81 10 15 02:59 snapshot-remote-rpc-registry-0-1571075991695

In our environment we have not seen a few files for the same shard. What 
are they for? Also, these numbers 40001, 80001, 120002, what do they mean?


I think those numbers are journal index numbers.

As for multiple snapshots being in existence -- there have been some 
patches in the are 
(https://git.opendaylight.org/gerrit/c/controller/+/82380 is what I 
remember, but there's probably more).


Regards,
Robert



We use Nitrogen-SR3, no cluster.

Thanks,

Yevgeny


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8447): https://lists.opendaylight.org/g/Discuss/message/8447
Mute This Topic: https://lists.opendaylight.org/mt/34550012/1320659
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  [n...@hq.sk]
-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8448): https://lists.opendaylight.org/g/Discuss/message/8448
Mute This Topic: https://lists.opendaylight.org/mt/34550012/21656
Group Owner: discuss+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OpenDaylight Discuss] Is it possible to delete snapshot and journal on Follower?

[Robert Varga]

On 22/08/2019 16:56, yevgeny.shakhnov...@us.fujitsu.com wrote:
> Hi,
> 
> We frequently have problems with synchronization between Leader and
> Follower that was just brought up. Follower may have very old state and
> synchronization fails because of time-out.
> 
> Is it possible to start the Follower without Snapshot and Journal
> folders? I believe it may reduce the time for synchronization.

It should, though there is
https://jira.opendaylight.org/browse/CONTROLLER-1626 which may affect
such a move.

I think the leader should be sending a full snapshot if it deems the
follower to be far enough behind, though memory of details is sketchy.

There are also some outstanding patches to handle those timeouts (but I
am still to review them).

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] ODL Sodium Java 8 or Java 11

[Robert Varga]

On 26/08/2019 11:52, Stephen Kitt wrote:
> Hi,
> 
> On Sun, Aug 25, 2019 at 12:32:11PM +, Paul Dennehy P wrote:
>> I am just curious to know if the Sodium release will be on Java 8 or 11?
>> I can see some of the master branches have moved to Java 11.
> 
> Sodium builds on Java 8. The next release, Magnesium, will build on
> Java 11; the master branches now correspond to that release, and
> Sodium is on stable/sodium.

Furthermore Sodium is expected to run fine on both Java 8 and Java 11.
Magnesium will run only on Java 11+.

MSI projects on Magnesium will switch to JDK11 during the Magnesium MRI
Integration Window.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [controller-dev] Migrating inventory/topology models

[Robert Varga]

[+ discuss, mdsal-dev]

On 05/09/2019 19:24, Anil Vishnoi wrote:
> As for the next steps, I think we need to migrate these models to
> openflowplugin, where they can be maintained, as that world is the only
> place that really uses them.
> 
> As far as upstream OpenDaylight is concern this make sense to me, but we
> need to be careful about the downstream consumer. Downstream user who
> just use core ODL projects (Controller, yangtools, mdsal,aaa) to develop
> their standalone application might be using these models, so this
> movement will break them and to solve this they will have to put
> dependency on openflowpluing, which they might not want. 

That is a valid concern, yes.

The answer really lies in packaging, as if you are using karaf, you will
have openflowplugin-features added to you distribution. Those would not
be installed, but will bloat the distro & confuse the users.

On the other hand, every feature we build is a separate repository, so
while you'd depend on openflowplugin-artifacts, you do not have to
depend on openflowplugin-features -- I think.

Without Karaf, you depend on whatever you like, so yeah, you get tied up
with OFP release cycle, but other than that there should not be a problem.

As far as those models are concerned, platform (mdsal/controller/netc)
position on them can be summed up as:

Migrate to using ietf-network(-topology), which are shipped from MD-SAL
for a year now. There are RFC8345 standard and are not expected to make
in the foreseeable future.
As a further note, while performing that migration, also move away from
using yang-ext.yang routed RPCs by switching to YANG 1.1 actions. Such
models are not supported by legacy RESTCONF (which itself is
deprecated), but are fully supported by RFC8040 RESTCONF (which is the
only actively supported version).

On a related note, this discussion will also be coming up with relation to:

ietf-packet-fields
ietf-access-control-list
ietf-lisp-address-types
ietf-ted
ietf-topology
ietf-topology-isis
ietf-topology-l3-unicast-igp
ietf-topology-ospf

as MD-SAL will be gradually dropping at least those, which have been
superseded by RFCs.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [controller-dev] Guava-28 removed CheckedFuture

[Robert Varga]

On 01/07/2019 10:28, Faseela K wrote:
>I will try to take it up for genius, netvirt and serviceutils.

Hello Faseela,

based on the direction taken in
https://git.opendaylight.org/gerrit/82889, I think the best approach for
genius/netvirt would be:

1) eliminate netvirt's use of non-Typed*Transaction interfaces from
genius and those @Deprecated genius methods

2) deprecate genius.infra.Typed*Transaction, as it has an MD-SAL
counterpart in mdsal.binding.util

3) mass-migrate all users

This way we would end up with:
1) immediate performance gains (fewer DS transactions)
2) users concentrated on a well-known API
3) a simple flag day merge

Regards,
Robert

P.S.: controller deprecations are already in place and I am seeing all
yellow, this will make the code *way* more maintainable



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [controller-dev] Guava-28 removed CheckedFuture

[Robert Varga]

On 01/07/2019 11:08, Robert Varga wrote:
> 
> On 01/07/2019 10:28, Faseela K wrote:
>> Robert,
>>Can you create a JIRA with the plan for deprecation and removal of 
>> controller APIs?
> Sure.
> 
> https://jira.opendaylight.org/browse/CONTROLLER-1902 tracks complete
> deprecation.

This has now been merged.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] OPERATIONAL datastore change listen

[Robert Varga]

On 01/07/2019 13:22, 王森枭 wrote:
> Hello guys, I have one question to consult you. I have write code to
> monitor OPERATIONAL datastore, but when I send message to trigger it
> according to postman, it can not enter listening process, is the
> OPERATIONAL datastore not supporting writing in this way? I hope to hear
> from you.

Not sure -- got a pointer to the postman stuff and the logs produced?

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] help

[Robert Varga]

On 02/07/2019 11:49, Lori Jakab wrote:
> On Mon, Jul 1, 2019 at 7:59 PM Asnake Ayele M.  > wrote:
> 
> is there any alternative to l2sitch and dlux in opendaylight.?
> 
> 
> I don't know about l2switch, but there haven't been any new/alternative
> GUI proposed for ODL.

There is an intern project to at least issue a point release of DLUX
here: https://wiki.opendaylight.org/view/Interns/Projects#Revive_DLUX

An alternative stack was discussed briefly, but nothing came out of it...

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [controller-dev] Guava-28 removed CheckedFuture

[Robert Varga]

On 01/07/2019 10:28, Faseela K wrote:
> Robert,
>Can you create a JIRA with the plan for deprecation and removal of 
> controller APIs?

Sure.

https://jira.opendaylight.org/browse/CONTROLLER-1902 tracks complete
deprecation.

https://jira.opendaylight.org/browse/CONTROLLER-1903 tracks removal.

>I will try to take it up for genius, netvirt and serviceutils.

Awesome, thanks!

Regards,
Robert

> Thanks,
> Faseela
> 
> -Original Message-----
> From: Robert Varga  
> Sent: Monday, July 1, 2019 1:56 PM
> To: Faseela K ; rele...@lists.opendaylight.org; 
> odlparent-...@lists.opendaylight.org; controller-...@lists.opendaylight.org
> Cc: discuss@lists.opendaylight.org; t...@lists.opendaylight.org
> Subject: Re: [controller-dev] Guava-28 removed CheckedFuture
> 
> On 01/07/2019 10:13, Faseela K wrote:
>> Robert,
> 
> Hey Faseela,
> 
>>What is the timeline for finishing this migration?
> 
> I do not have a specific timeline and certainly I cannot commit to finishing 
> up all the patches.
> 
> As for controller API removal, I do want to completely deprecate them (i.e. 
> all interfaces/classes) in Sodium and remove them in Aluminium (specifically, 
> during its MRI window in April 2020).
> 
>>I hope this is the corresponding neutron patch?
>>  
>> https://protect2.fireeye.com/url?k=b90d94dd-e5844e9a-b90dd446-0cc47ad9
>> 3c18-4e437efcd33c907d&q=1&u=https%3A%2F%2Fgit.opendaylight.org%2Fgerri
>> t%2F%23%2Fc%2F82802%2F
> 
> This one: 
> https://protect2.fireeye.com/url?k=4729bdb2-1ba067f5-4729fd29-0cc47ad93c18-0a9c7e3316fc2735&q=1&u=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2F80860
> 
> Regards,
> Robert
> 
>> Thanks,
>> Faseela
>>
>> -Original Message-
>> From: controller-dev-boun...@lists.opendaylight.org 
>>  On Behalf Of Robert 
>> Varga
>> Sent: Monday, July 1, 2019 1:36 PM
>> To: rele...@lists.opendaylight.org; 
>> odlparent-...@lists.opendaylight.org; 
>> controller-...@lists.opendaylight.org
>> Cc: discuss@lists.opendaylight.org; t...@lists.opendaylight.org
>> Subject: [controller-dev] Guava-28 removed CheckedFuture
>>
>> Hello everyone,
>>
>> this is just a heads up that Guava 28 removed CheckedFuture:
>>
>> https://protect2.fireeye.com/url?k=b8e15d45-e435574c-b8e11dde-86740465
>> fc08-65a26a6532eb57e6&q=1&u=https%3A%2F%2Fgithub.com%2Fgoogle%2Fguava%
>> 2Freleases%2Ftag%2Fv28.0
>>
>> This means that controller-based MD-SAL APIs are now officially dead weight.
>>
>> While there is no immediate need to upgrade Guava in Magnesium, there is now 
>> a real need to get off of controller/sal-*-api -- most projects are already 
>> done, but there are still some left:
>>
>> - serviceutils
>> - bgpcep
>> - ovsdb
>> - neutron
>> - genius
>> - sfc
>> - netvirt
>>
>> neutron already has a proposed patch, bgpcep has a patch in progress, the 
>> rest seem to be subtly intertwined and will need some effort to migrate.
>>
>> Regards,
>> Robert
>>
> 



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [controller-dev] Guava-28 removed CheckedFuture

[Robert Varga]

On 01/07/2019 10:13, Faseela K wrote:
> Robert,

Hey Faseela,

>What is the timeline for finishing this migration?

I do not have a specific timeline and certainly I cannot commit to
finishing up all the patches.

As for controller API removal, I do want to completely deprecate them
(i.e. all interfaces/classes) in Sodium and remove them in Aluminium
(specifically, during its MRI window in April 2020).

>I hope this is the corresponding neutron patch?
>  https://git.opendaylight.org/gerrit/#/c/82802/

This one: https://git.opendaylight.org/gerrit/80860

Regards,
Robert

> Thanks,
> Faseela
> 
> -Original Message-
> From: controller-dev-boun...@lists.opendaylight.org 
>  On Behalf Of Robert Varga
> Sent: Monday, July 1, 2019 1:36 PM
> To: rele...@lists.opendaylight.org; odlparent-...@lists.opendaylight.org; 
> controller-...@lists.opendaylight.org
> Cc: discuss@lists.opendaylight.org; t...@lists.opendaylight.org
> Subject: [controller-dev] Guava-28 removed CheckedFuture
> 
> Hello everyone,
> 
> this is just a heads up that Guava 28 removed CheckedFuture:
> 
> https://protect2.fireeye.com/url?k=b8e15d45-e435574c-b8e11dde-86740465fc08-65a26a6532eb57e6&q=1&u=https%3A%2F%2Fgithub.com%2Fgoogle%2Fguava%2Freleases%2Ftag%2Fv28.0
> 
> This means that controller-based MD-SAL APIs are now officially dead weight.
> 
> While there is no immediate need to upgrade Guava in Magnesium, there is now 
> a real need to get off of controller/sal-*-api -- most projects are already 
> done, but there are still some left:
> 
> - serviceutils
> - bgpcep
> - ovsdb
> - neutron
> - genius
> - sfc
> - netvirt
> 
> neutron already has a proposed patch, bgpcep has a patch in progress, the 
> rest seem to be subtly intertwined and will need some effort to migrate.
> 
> Regards,
> Robert
> 



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

[OpenDaylight Discuss] Guava-28 removed CheckedFuture

[Robert Varga]

Hello everyone,

this is just a heads up that Guava 28 removed CheckedFuture:

https://github.com/google/guava/releases/tag/v28.0

This means that controller-based MD-SAL APIs are now officially dead weight.

While there is no immediate need to upgrade Guava in Magnesium, there is
now a real need to get off of controller/sal-*-api -- most projects are
already done, but there are still some left:

- serviceutils
- bgpcep
- ovsdb
- neutron
- genius
- sfc
- netvirt

neutron already has a proposed patch, bgpcep has a patch in progress,
the rest seem to be subtly intertwined and will need some effort to migrate.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [OpenDaylight TSC] TSC Meeting minutes for June 20, 2019

[Robert Varga]

On 20/06/2019 20:10, Abhijit Kumbhare wrote:
> Hi TSC,
> 
> Please find & review the TSC meeting minutes below:
> 
> https://meetings.opendaylight.org/opendaylight-meeting/2019/tsc/opendaylight-meeting-tsc.2019-06-20-16.09.html

My AIs:

1) archetype follow-up:
   https://lists.opendaylight.org/pipermail/release/2019-June/017732.html

2) Java 11:
   https://lists.opendaylight.org/pipermail/release/2019-June/017699.html

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [controller-dev] 答复: Problem: ODL Neon archetype repo missing?

[Robert Varga]

On 20/06/2019 18:41, Robert Varga wrote:
> 
> Okay, with Stephen's help I was able to get the project into a
> semi-reasonable state -- i.e. you can currently use 1.1.0-SNAPSHOT to
> target Neon GA and 1.2.0-SNAPSHOT to target current Sodium.
> 
> There are a couple more patches to completely catch up to Fluorine
> SR2/SR3 and Neon SR1/current, which we will continue to work on, issuing
> proper releases for that.
> 
> Going forward, though, we need a caretaker committer, who will keep an
> eye on version bumps and releases, to produce the equivalent of these
> patches:
> 
> https://git.opendaylight.org/gerrit/82593 (i.e. archetypes version bump)
> https://git.opendaylight.org/gerrit/82594 (i.e. post-SR bump)
> https://git.opendaylight.org/gerrit/82599 (i.e. documentation update)
> 
> and spin standalone releases.
> 
> Any takers?

[+ release, discuss, as per my AI]

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [OpenDaylight TSC] TSC Meeting minutes for June 20, 2019

[Robert Varga]

On 20/06/2019 22:08, Casey Cain wrote:
> Hi, Michael.
> 
> In the last few DDFs I have brought up the idea of migrating to a
> Confluence wiki.  There are several reasons why I've been encouraging this.
> Internally at the LF we have been building a set of tools and automation
> over the last several years to help better suit our community needs. 
> Some of the  these systems tie into Salesforce, Atlassian tools (JIRA,
> Confluence) and Groups.io.
> 
> At the last DDF, those present agreed that we should look at migrating
> to a new wiki as long as the relevant information is captured and migrated.
> I agreed to do the bulk of the migration efforts myself.  While I am
> confident that I will grab all of the necessary information and move it
> over to the new wiki, I'm asking the community to grab the URL of any
> page they believe to be important to migrate and put it
> on https://wiki.lfnetworking.org/display/ODL/Migration+Sites just to be
> sure that I don't forget anything.
> You can help migrate those pages as well if you'd like.  But as promised
> I will do the bulk of the migration.
> 
> The current wiki will not be going anywhere until the community confirms
> that the necessary data has indeed been migrated and that we are
> satisfied with the new solution.

Yes, because we have a ton of historical data, but little of it seems
maintained or overly-accurate these days.

The idea here is at that any page on the old wiki marked for migration
would be replaced with a redirect to the new page.

Also note: if we have a docs person coming, a chunk of the wiki content
should be turned into .rst and committed to the project which owns it.

That way we always keep track of what's relevant and it is up to the
particular project to keep the information updated.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Future OpenDaylight Developer Forms

[Robert Varga]

Both, each with different primary focus (given the timeframe rel. SR):

- ONS EU: Magnesium deliverables, project-wide activities syncup
- other: Feb 2020 Magnesium final push/post-mortem, Aluminium project
planning

I would also like to see if we can get hackathons during these...

Regards,
Robert


On 20/06/2019 18:32, Casey Cain wrote:
> Hello, everyone.
> 
> OpenDaylight is trying to finalize our plans for the next Developer
> Design Forum.  We are currently faced with 3 options.
> 
>  1. At ONS EU
>  1. Antwerp, Belgium 
>  2. 26th - 27th (Thrus/Fri), September 2019.
>  2. Jointly with ONAP/OPNFV
>  1. Currently unknown location
>  2. January / February 2020 time frame
>  3. Both.
> 
> We need to urgently come to a decision so that organizations can plan
> their travel budgets.  Please reply with your comments and vote as soon
> as possible.
> 
> Best, 
> Casey Cain
> Technical Program Manager
> Linux Foundation
> _
> IRC - CaseyLF
> WeChat - okaru6
> 
> ___
> Discuss mailing list
> Discuss@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/discuss
> 



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [release] [OpenDaylight TSC] Magnesium supporting Java 11+ only

[Robert Varga]

On 21/06/2019 07:18, Faseela K wrote:
> Robert,
> 
>    +1 for moving to Java 11 for Magnesium.
> 
>  
> 
>    Do you have any study already done, on the impacts of the migration?
> 
>    Basically want to estimate how easy it will be for genius/netvirt to
> move to java 11.
> 
>    If there is a need for code changes, need to plan for the resources.

https://jenkins.opendaylight.org/releng/job/autorelease-release-sodium-mvn35-openjdk11/
is passing rather consistently, I suspect there will be little to do
aside from flipping the switch in odlparent -- unless I am missing
something.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

[OpenDaylight Discuss] Magnesium supporting Java 11+ only

[Robert Varga]

Hello,

as noted in
https://meetings.opendaylight.org/opendaylight-meeting/2019/tsc/opendaylight-meeting-tsc.2019-03-07-17.00.html,
we have made Sodium a combined Java 8/11 release.

With Magnesium starting in about three months, there is a need for
Offset-0 projects to know what the target release is going to be.

Based on past discussions and today's TSC call, the general sentiment is
that the ecosystem has moved to a place where requiring Java 11 is a
serious option, with the anticipation it will be a very reasonable
requirement ~9 months from now, when Magnesium GA is expected to land.

As per my action item from today's TSC call, I am therefore soliciting
any dissent to adopting Java 11 as the minimum run-time environment for
OpenDaylight Magnesium Simultaneous Release.

Unless an objection is raised to this thread, the TSC will have a formal
vote on making Java 11 the required release next week, i.e. in the
meeting of June 27th.

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [OpenDaylight TSC] Service Desk Migration

[Robert Varga]

On 17/06/2019 21:23, Casey Cain wrote:
> The new service desk will become available to you starting Monday, June
> 17, 2019.
> 
> Any support requests that are already open in RT will be preserved and
> completed there, so there is no need to re-submit them again using the
> Jira Service Desk. Any new tickets created in RT will be automatically
> closed with a suggestion and instructions to use the new service desk
> procedure.
> 
> Starting Monday, June 17, please use the procedure described in the
> attached “Getting LF IT Help” document.

This seems to be missing an attachment. At any rate, the documentation
is available here:
https://docs.releng.linuxfoundation.org/en/latest/helpdesk.html

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [release] [Aaa-dev] Removal of IdP component from AAA

[Robert Varga]

On 22/03/2019 22:30, Daniel De La Rosa wrote:
> Robert, thank you for the details. Abhijit, i think we still need to
> discuss the details during our next TSC meeting since it sounds like
> there will be major impact for our customers

Hello Daniel,

any update on the impact for your customers?

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Runtime load of YANG file

[Robert Varga]

On 25/04/2019 23:04, Alexis de Talhouët wrote:
> Greeting folks,

Hello Alexis,

> I know this is not a new topic, but I’d like to have a fresh view on this: Is 
> it technically possible to load yang at runtime?
> If so, is it possible out-of-the-box, else could you share some leads on how 
> to implement this.

It is not a new topic, and I do not believe there is a ready-to-go
capability to do this.

> Use case is to use ODL to be a YANG datastore, and to manage YANG lifecycle 
> along with it’s underlying data through
> external system.

Can you file an issue in MD-SAL project and flesh out the use case?

Key questions:
- how does that external system interact with ODL-as-a-YANG-datastore?
- are there any Binding-aware applications loaded?

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [Aaa-dev] Removal of IdP component from AAA

[Robert Varga]

On 21/03/2019 18:07, Luis Gomez wrote:
> Hi Robert,
> 
> Can you please explain the impact of this? e.g. can we for instance change 
> the default user admin/admin or use token authentication after this change?

Well, I am just a caretaker trying to get things moving forward.

From what I remember, user credentials should not be affected, as that
goes through Shiro, which is a separate thing.

I would suspect that token authentication would be affected, but I do
not know the deployment details.

Please note this not something new, Ryan has made a call out here:
https://lists.opendaylight.org/pipermail/aaa-dev/2018-February/001606.html
and there is a tracker to replace Oltu here:
https://jira.opendaylight.org/browse/AAA-162. Based on the conversation
we have had on this when he was still around, his assessment was that
the feature is not useful in practice.

I do not claim authority over this matter, nor do I claim Ryan's
assessment is correct. Unfortunately, status quo in this project is
simply untenable for the following reasons:

1) JIRA has not been scrubbed for a year. When I scrubbed it, we
immediately got a fix from Richard Kosegi for AAA-174. That issue has
been sitting there for 10 months and it was fixed in about 24 hours.

2) there are a few long-standing issues filed, which require fixing in
Oltu. That is just not going to happen in upstream.

3) it is a core project, on which we rely for our security. We just
cannot afford it being a security hazard.

4) org.json/json dependency, which is coming from Oltu is a real
licensing concern, from what I understood from the conversations we had
(even at the TSC call) around
https://jira.opendaylight.org/browse/ODLPARENT-36

That is why I merged the change early in the dev cycle and announced it
very widely, so that there is plenty of time to determine impacts and
discuss alternatives.

The simplest way to determine it is, and I am kindly asking you to, grab
the latest Karaf distro and test out the functionality you expect to work.

If it turns out that there are stakeholders who are affected, I think
the proper course is for them (or their proxies) to come forward and
take ownership of the feature:
- it is mere 800LOC of code that got removed
- there are at least 3 bugs filed against token auth
- there are alternative libraries: https://oauth.net/code/java/

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

[OpenDaylight Discuss] Removal of IdP component from AAA

[Robert Varga]

Hello everyone,

as part of keeping OpenDaylight infrastructure secure and relevant, we
will be removing OAuth2 Identity Provider component from the AAA project.

There are three technical drivers behind this decision:

1) current implementation is based on Apache Oltu, which has been
terminated on March 21st, 2018 and moved to Attic:
https://attic.apache.org/projects/oltu.html

2) Oltu depends on org.json/json, which has a problematic license
(https://www.json.org/license.html)

3) we do not strive to be an IdP, as there are plenty solutions
available out there.

The details are in the tracker issue,
https://jira.opendaylight.org/browse/AAA-173, and in the removal patch,
https://git.opendaylight.org/gerrit/72022.

Should there be interest in having this functionality present, we will
gladly accept an alternative implementation, provided it comes with at
least a minimal commitment to support it.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Fwd: Delivery Status Notification (Failure)

[Robert Varga]

On 15/03/2019 03:38, Parul Agrawal wrote:
> Hi,
> 
> Thanks for your reply. As suggested  I tried to compile dluxapp for
> fluorine by updating the version of odlparent to 4.0.9 in all pom files.
> But I am getting the below error on compilation .Can you please help me
> in this regard?. Thank you for all your support so far.
> 
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 57.653 s <<< FAILURE! - in
> org.opendaylight.odlparent.featuretest.SingleFeatureTest
> [ERROR]
> installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl:
> file:/root/dluxapps/features/odl-dluxapps-topology/target/feature/f
> eature.xml, Feature: odl-dluxapps-topology 0.7.5.SNAPSHOT]  Time
> elapsed: 54.809 s  <<< ERROR!
> org.apache.karaf.features.internal.util.MultiException:
> Error restarting bundles:
>         Exception in org.jolokia.osgi.JolokiaActivator.start() of bundle
> org.jolokia.osgi.

Hmm... dluxapps' stable/oxygen branch with odlparent-4.0.9? I do not
believe that is going to fly.

You'll need to pick up the master branch, 0.8.0-SNAPSHOT, and fix
dlux.git first (as dluxapps depends on it).

You need to make sure all of platform versions are bumped, based on:
https://docs.opendaylight.org/projects/integration-distribution/en/stable-fluorine/platform-versions.html?highlight=platform%20versions

Note that the versions are slightly outdated,
https://git.opendaylight.org/gerrit/#/c/80874/ fixes that.

I suggest targeting Fluorine SR2 release versions first, so that you get
a stable baseline without flux, and then proceeding to pre-SR3.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Java 11 adoption

[Robert Varga]

On 07/03/2019 19:23, Robert Varga wrote:
> 
> To re-iterate the requirements, they are only four points:
> 
>> 2) All participating projects are required to built with JDK 11 no later
>> than the midway checkpoint. This requirement is checked by the
>> autorelease-sodium-openjdk11 job, which will remain in place for
>> duration of Sodium release. Current state is that the build fails on
>> ovsdb, but that is only a matter of removing tests (AI: me, already
>> agreed with OVSDB committers).

autorelease/jdk11 is stabilized as of
https://jenkins.opendaylight.org/releng/job/autorelease-release-sodium-mvn35-openjdk11/40.

This requirement has now been met and any subsequent build failures need
to be treated as regressions from the baseline, i.e. the same way as
JDK8 failures are.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Java 11 adoption

[Robert Varga]

Hello everyone,

On 22/02/2019 00:28, Robert Varga wrote:
> On 10/01/2019 19:30, Robert Varga wrote:
>> As an alternative we could skip the combined Java 8/Java 11 release,
>> going directly to a Java 11-only release -- either with Sodium or with
>> Magnesium.
>>
>> I would like to start the discussion around the options we have and
>> preferences of both OpenDaylight projects and our downstreams.
> 
> Based on the feedback on this thread and the feedback I received from
> users, it is clear that making a direct jump to Java 11 in Sodium would
> be problematic to at least one of our open-source downstreams.
> 
> In face of that, I propose we execute as follows:
> 
> - have concurrent autorelease-openjdk8 and autorelease-openjdk11 builds
> - do not have separate openjdk11 verify jobs
> - stabilize autorelease-openjdk11 by the midway checkpoint
> - Sodium release artifacts are still built with autorelease-openjdk8
> - evaluate feasibility of switching CSIT to Java 11
> 
> I am not sure about the last point -- we need to decide which JRE is
> primary for Sodium. I would like to push for Java 11 being the primary,
> and switching CSIT to it by midway checkpoint, but I am not sure if that
> is feasible.
> 
> Based on that, we would have:
> 
> - Sodium compatible with Java 8 and Java 11, with recommended runtime
> being either 8 or 11 (based on the CSIT question above).

the exact proposal lives here:
https://lists.opendaylight.org/pipermail/tsc/2019-February/011134.html

Proposed requirements on participation, as proposed there, have been
adopted as Requirements for Participation in the Sodium Simultaneous
Release on today's TSC call:
https://meetings.opendaylight.org/opendaylight-meeting/2019/tsc/opendaylight-meeting-tsc.2019-03-07-17.00.html

To re-iterate the requirements, they are only four points:

> 1) Target Java platform remains Java 8. This means we build run
> merge/autorelease jobs with Java 8. The artifacts that we produce as
> Sodium will be built with Java 8.
> 
> 2) All participating projects are required to built with JDK 11 no later
> than the midway checkpoint. This requirement is checked by the
> autorelease-sodium-openjdk11 job, which will remain in place for
> duration of Sodium release. Current state is that the build fails on
> ovsdb, but that is only a matter of removing tests (AI: me, already
> agreed with OVSDB committers).
> 
> 3) All participating project commit to support Java 11 as the run-time
> environment and are required to run at least one sanity test with Java
> 11 to ensure no obvious breakages are present by code freeze.
> 
> 4) At the time of release both autorelease-openjdk8 and
> autorelease-openjdk11 builds must be passing.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] ONAP's ODL distro

[Robert Varga]

On 25/02/2019 13:17, Alexis de Talhouët wrote:
> Greetings all,

Hello Alexis,

> Following a call last week, I started creating a specific ODL distro for
> ONAP’s need.
> Here is the current draft: https://gerrit.onap.org/r/#/c/79075/
> 
> Question is: when creating the ODL distro, a few files get added under
> src/main/assembly: 
> https://github.com/opendaylight/integration-distribution/tree/master/karaf/src/main/assembly
> I was wondering if these files could be moved to karaf4-parent or a
> place where I could simple
> inherit them without having to fork them.

looks good. karaf4-parent is not the right place, as they are inherently
CDS-aware. I think the best option would be to provide them through a
separate artifact from int/dist.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Java 11 adoption

[Robert Varga]

On 10/01/2019 19:30, Robert Varga wrote:
> Hello everyone,
> 
> as I noted in previous updates, our Neon release stream looks rather
> good where JDK11 compatibility is concerned, with my local builds with
> JDK11 passing with minor fixes (submitted) up to and including
> openflowplugin.
> 
> With the three version bumps tracked at TSC-186, TSC-187 and TSC-188,
> this should be readily reproducible without resorting to my local hacks.

This activity has been concluded and furthermore we have an Java 11
autorelease build for the Sodium release train.

> I would like to ask individual projects to do some build testing to
> ensure they work with JDK11 in the time we have left before Neon code
> freeze sets in (1/24/2019), but as this was never a requirement to
> participate nor a TSC-mandated goal, it really is up to them.
> 
> The big question is how are we going to go about adopting Java 11 from
> the point of:
> - it being a fully supported runtime
> - it being the minimum required runtime
> 

[snip]

> As an alternative we could skip the combined Java 8/Java 11 release,
> going directly to a Java 11-only release -- either with Sodium or with
> Magnesium.
> 
> I would like to start the discussion around the options we have and
> preferences of both OpenDaylight projects and our downstreams.

Based on the feedback on this thread and the feedback I received from
users, it is clear that making a direct jump to Java 11 in Sodium would
be problematic to at least one of our open-source downstreams.

In face of that, I propose we execute as follows:

- have concurrent autorelease-openjdk8 and autorelease-openjdk11 builds
- do not have separate openjdk11 verify jobs
- stabilize autorelease-openjdk11 by the midway checkpoint
- Sodium release artifacts are still built with autorelease-openjdk8
- evaluate feasibility of switching CSIT to Java 11

I am not sure about the last point -- we need to decide which JRE is
primary for Sodium. I would like to push for Java 11 being the primary,
and switching CSIT to it by midway checkpoint, but I am not sure if that
is feasible.

Based on that, we would have:

- Sodium compatible with Java 8 and Java 11, with recommended runtime
being either 8 or 11 (based on the CSIT question above).

- Magnesium being a Java 11-only release.

Abhijit, can you schedule this topic for the next week's TSC, please?

Thanks,
Robert

P.S.: JDK12 has entered RDP-2 phase and we will need to keep an eye out
for it during Sodium because it brings interesting runtime improvements.
Also JDK13 planning has started and there are few juicy bits on the
candidate list -- hence our adoption of JDK14 should be speedier than 11 :)



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [release] Can't do merge in snmp4sdn stable/neon branch

[Robert Varga]

On 20/02/2019 14:17, guillaume.lamb...@orange.com wrote:
> Hi all
> 
>  
> 
> Than Ha, I got the same question on another thread so thank you for the
> clarifications.
> 
>  
> 
> Here is my feedback.
> 
> If SM projects are affected by the branch lock of Managed projects
> because of Gerrit limitations, I think this is problematic, not only
> from a schedule standpoint.
> 
> If I am not mistaken, Jenkins releng macros are only available on
> predefined branches. This means Neon CI/CD can only be installed there
> and new changes can really be tested in the stable/neon branch.
> 
> This really complicates the integration work.
> 
> I noticed also that target dependencies versions are stabilized 1 or 2
> days just before the branch lock. Afterwards, there are a couple of
> weeks where SNAPSHOT and non-SNAPSHOT versions continue to coexist.

Snapshot artifacts are pruned if they are not refreshed in three weeks.
I think snapshot versions of artifacts should be pruned when
corresponding release artifacts are promoted, but I don't know whether
that is technically possible.

> I perfectly understand that not all project and subproject versions can
> be documented. But since the release target doc includes non-snapshot
> and snapshot versions, even with nexus,
> 
> it is complicated in such conditions to know which subproject (e.g.
> mdsal.binding.model = 1.2.6) version must be used when its version is
> non-aligned with the parent project version (e.g. mdsal.binding-parent
> =3.0.6).

I disagree. The only versions you need to care about are the versions of:
- ${project}-artifacts
- any parent poms produced by a project

All of these are version-aligned in mdsal, currently at 3.0.6.
Individual versions of artifacts are communicated through
mdsal-artifacts-3.0.6 and you should be getting them by:


 
 
 org.opendaylight.mdsal
 mdsal-artifacts
 3.0.6
 pom
 import
 
 


This is documented in
https://wiki.opendaylight.org/view/CrossProject:HouseKeeping_Best_Practices_Group:Project_layout
and has been the recommended way of consuming artifacts downstream for
more than 3 years.

If there is an artifact produced by a project and it is not part of
${project}-artifacts, that needs to be reported to upstream, as it
either is a bug, or that artifact is not meant for downstream consumption.

If you are not using the above to get version declarations, then yes, it
is complicated, but that is a complication you are inflicting on yourself.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [OpenDaylight TSC] Stable branches etc.

[Robert Varga]

On 11/02/2019 15:01, Sam Hague wrote:
> We really need to address the 'wild west' aspect here -- and we need
> concrete examples from past two releases.
> 
> Possible example, the sodium branch is broken for NetVirt because of the
> karaf.shell missing. [1] was pushed to add the pom dependency. Possible
> it was something else that caused the issue, but the point is that when
> things go unstable and not fixed you get days or weeks of things leaking in.
> [1] https://git.opendaylight.org/gerrit/#/c/80253/

Alright, this is a transitive dependency not being declared at point of
use and yeah, broken by genius correcting their use (moving out of API,
using scope=provided).

We explicitly do not guard against this kind of breakage, because that
would require a full autorelease build on each verify. It is caught by
autorelease, though.

What you can do on netvirt side is to clean up your build system to not
rely on transitives, like what bgpcep does:

https://github.com/opendaylight/bgpcep/blob/master/binding-parent/pom.xml#L60

It is by no means perfect and subject to breakage when things change
upstream, but I think that occurs only in case of what would be
considered an API change...

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [OpenDaylight TSC] Stable branches etc.

[Robert Varga]

On 30/01/2019 15:30, Sam Hague wrote:
> 
> 
> On Wed, Jan 30, 2019 at 5:03 AM  > wrote:
> 
> Hi Stephen
> 
> I am sharing your feedback and thinks it would make a lot of sense.
> Many linux distros use something similar to deal with staging
> packages in their repo, e.g. Fedora with stable/branched/rawhide
> repos or Debian with stable/testing/unstable repos.
> With only one (master) branch, it is difficult for downstream
> projects to deal with both the new features to develop and needed
> migrations for the next release at the same time.
> An intermediate branch may allow a better synchronization with the
> upstream projects as long as ongoing evolution are made available
> through nexus.
> 
> This is a good point and was a similar reason for needing a branch. This
> has hit us every release where the stable branch is pulled and master
> goes forward, but downstreams still want to continue working. They can't
> since the stable branch is locked and master becomes the wild west.

We really need to address the 'wild west' aspect here -- and we need
concrete examples from past two releases.

Based on the release schedule, the next release is not open, which
certainly is not a wild card to wreak havoc on downstreams -- so who and
why is causing it?!

> Some
> of this could be alleviated with more reliable planning - getting code
> in earlier and tested - but that is hard with limited resources. An
> intermediate branch would provide a place to keep working to finish
> things and make it into the sr1 and not try to cram something in at the
> last minute on the stable branch.

Well, I take the position that limited resources dictate limited code
churn and more incremental feature delivery. This includes the hard task
of culling deliverables early.

The additional branch really works in exactly the opposite direction:
rather than the features being postponed to the next GA release, they
are pushed out to SR1 (and SR2, etc.). That breaks the strong reading of
the SimRel schedule, really.

What I mean is that in the past the GA release was postponed by up to
three months to cope with "things just happening", with the hope being
that such events would become ever rarer. That has not generally
happened and today we have SimRel which is not time-flexible.

That time-flexibility meant that feature delivery problems would get
masked (i.e. you'd get 8-12 weeks more time in a particular cycle).

With that flexibility gone, though, there are only two options I can see:

1) the SimRel schedule works for a particular project
2) the SimRel schedule does not work for a particular project

I think we are dealing with a case of 2) here, and the question is whether:

a) SimRel schedule needs to be fixed
b) the project's upstreams need to be fixed
c) the project needs to be fixed

One final note: unlike MRI and self-managed projects, projects in
autorelease build have no control over how/when they consume upstream
changes nor when they release. I believe this is a major component of
the pain here.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss