Dear all,

The problem has been identified and report in the documentation: bgpcep/docs/pcep/pcep-user-guide-path-computation.rst

"Known Bug
^^^^^^^^^

When using BGP-LS for automatic Graph topology acquisition, for an undetermined
reason, karaf is unable to start properly the *bgp-topology-provider* bundle.
This is due to karaf that doesn't properly manage blueprint dependencies. Thus,
BGP Topology Provider class is initialized with a wrong reference to the Graph
Topology Service: a null pointer is provided instead. However, it is easy to
overcome this issue by simply restarting the *bgp-topology-provider* bundle.

First identify the bundle number of *bgp-topology-provider* and check the
status.

.. code-block:: console

    opendaylight-user@karaf>bundle:list | grep bgp-topology-provider
    232 │ Failure  │  80 │ 0.14.0          │ bgp-topology-provider


Then restart the bundle if status is *Failure*

.. code-block:: console

    opendaylight-user@karaf>bundle:restart 232

And finaly, verify that the bundle is active

.. code-block:: console

    opendaylight-user@root>bundle:list 232
    START LEVEL 100 , List Threshold: 50
     ID │ State  │ Lvl │ Version         │ Name
    ────┼────────┼─────┼─────────────────┼───────────────────────
    232 │ Active │  80 │ 0.14.0          │ bgp-topology-provider


Looking to the log, you will normally see that a new Graph has been created and
fulfil with your network topology element. Using Graph Rest API *Get Operational
Graph* will also validate that all is running correctly.
"

The main problem does not come from the code itself, but rather than on karaf which is unable to correctly schedule the blueprint.

bgp-topology-provider is launch with a null pointer as reference to the GraphServiceProvider while GraphServiceProvder is available or available latter.

It is why a simple bundle:restart is sufficient to overcome the issue.

What I could do, is to remove the assert on null value for GraphServiceProvider and replace it by a if() to launch or not the LinkstateGraphBuilder(). Of course, it will failed, but again a bundle:restart will solve the issue.

I will propose the change in 2 hours

Regards

Olivier

Thanks for letting us know.

On Mon, Mar 9, 2020 at 9:35 PM JamO Luhrsen <jluhrsen@...> wrote:

Hi all,

A new regression was discovered in BGPCEP CSIT that is now blocking the
release:

https://jira.opendaylight.org/browse/BGPCEP-898

Once we get a handle on that, we will probably have some change(s) to merge
and wait for the normal process of autorelease to finish and then we'll check
on CSIT results after that.

Thanks,
JamO

--

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@...

_________________________________________________________________________________________________________________________

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.