Move openconfig functional test library to common

- update existing openconfig portmapping functional tests
- update the node name key in simulators module

JIRA: TRNSPRTPCE-839
Change-Id: I46661190ef1d5ca022969ecb4d9ea8306135586d
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Move JsonUtil to test-common

JsonUtil is a utility test class that is duplicated in several modules
and used to deserialize json string into DataObject.
Move it to test-common which is dedicated for this.

Change-Id: Ia233daf88cf055d4074dbaa547afdbff7975cbe0
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Remove unused properties from PCE test classes

Some PCE test classes declare the BindingDOMCodecServices as a property
but the latter is not used. Just delete it.

JIRA: TRNSPRTPCE-840
Change-Id: I495302488f1dd5c562db92a105ae35fa166d215e
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Load openroadm-operational-modes catalog at init

At servicehandler bundle initialization, load the openroadm operational
modes catalog in the datastore in order to make available for the PCE
computation openroadm transponder specifications.
- add a datastore initialization method in catalog impl
- update existing Junit tests
- update one GNPy functional test because now PCE has almost the same
  performances as GNPy
- develop Junit tests for CatalogDataStoreOperationsImpl class

JIRA: TRNSPRTPCE-714
Change-Id: Ia8fdf253b9daa7b4d75525f2fdb403736d64f57f
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Fix NPE in OCPortMapping

- Add protection to avoid a NPE when the open-terminal-meta-data is not
present
- review some log level to improve log readability
- optimize a litle bit the number of the datastore read access for the
  meta-data

JIRA: TRNSPRTPCE-844
Change-Id: I78bbfe5631895a8c4c1cbbe41307b16723e700a4
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Co-authored-by: Christophe Betoule <christophe.betoule@orange.com>

Add missing javadoc in networkmodel module

To fix most of javadoc compilation warnings.

JIRA: TRNSPRTPCE-841
Change-Id: Ie072b77ccad2abb3a9eb9e0ff69e6af3dc0f432e
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Remove NodeData class which is never used

JIRA: TRNSPRTPCE-840
Change-Id: I87ce57a335650dfdede2639985e44fb0b7f9c4b0
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Clean up the pom files

- remove unnecessary dependencies
- add undeclared dependencies

JIRA:TRNSPRTPCE-843
Change-Id: I32ec338120e3d4897d2174256e2408c4808b5dc0
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Migrate InstanceIdentifier on the rest of the code

Use DataObjectIdentifier instead of InstanceIdentifier in
transportpce-olm, pce, renderer, servicehandler and the rest of tapi
modules.

JIRA: TRNSPRTPCE-842
Change-Id: I856988a584f5bde7c1549dff032841441eb65ddd
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Migrate InstanceIdentifier of networkmodel module

Use DataObjectIdentifier instead of InstanceIdentifier in
transportpce-networkmodel module except in few classes where a specific
treatment is done with the deprecated InstanceIdentifier
(NetworkModelProvider, PortMappingListener and DeviceListener).

JIRA:TRNSPRTPCE-842
Change-Id: I8af232bce1c9d8adfcc45eae4df64a40c5c68a82
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Migrate InstanceIdentifier of common module

- use DataObjectIdentifier instead of InstanceIdentifier in
  transportpce-common module
- propagate the same migration in the impacted code of all downstream
  modules

JIRA: TRNSPRTPCE-842
Change-Id: I66a372df3ff43e702d872e4c248c6776a913cc16
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Migrate InstanceIdentifier of test-common module

- use DataObjectIdentifier instead of InstanceIdentifier which is
  deprecated in test-common module
- propagate the same migration in the impacted code of all downstream
  modules

JIRA: TRNSPRTPCE-842
Change-Id: I2848781d75f752a73a021eb59a7028ccd330ada9
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Migrate BindingCodecContext

Use DefaultBindingDOMCodecFactory instead of BindingCodexContext to
instantiate BindingDOMCodecServices.

Change-Id: Iff3213fe59947bde5163e6da340739b877230aa6
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Upgrade lightynode version

This new version of lightynode contains additional openconfig models
announcements used for openconfig portmapping implementation.

Change-Id: I14161a66bce8c0b59c71b822eed7b93c3cf1b81c
Signed-off-by: Christophe Betoule <christophe.betoule@orange.com>

Enhancements for discovering OpenConfig XPDRs

Joint development by Fujitsu/NTT/Orange.

Change-Id: I63efa83adf227fa0fe911271a1b392b3a75a1d33
Signed-off-by: Roshan Joyce <roshan.joyce@fujitsu.com>

Consistent cent. freq. width decimal precision

Corrects an issue where the nr of decimals for central frequency
was 4 in ZtoA direction and 5 in AtoZ direction.

Change-Id: I924273f1fff09870aff9e84042b5aac110a29fc8
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Implement client create service frequency choice

Implement the augmentations found in:
transportpce-service-spectrum-constraint@2023-09-07.yang.

APIImpact

The properties "frequency-range" and "frequency-slot" are implemented.
The properties "frequency-slot" is only valid when "service-format"
is set to "other".

Allowing the client to set frequency-slot using any other type of
service-format may cause unintended side effects such as the mc
interface (e.g. 37.5GHz) being smaller than the nmc
interface (e.g. 40GHz).

POST /rests/operations/org-openroadm-service:service-create
{
    "input": {
        ...
        "service-a-end": {
            ...
            "service-format": "other",
            "frequency-range": {
                "min-frequency": 191.4,
                "max-frequency": 191.5
            },
            "frequency-slot": {
                "center-frequency": 193.1,
                "slot-width": 37.5
            },
            ...
        },
        "service-z-end": {
            ...
            "service-format": "other",
            "frequency-range": {
                "min-frequency": 191.4,
                "max-frequency": 191.5
            },
            "frequency-slot": {
                "center-frequency": 193.1,
                "slot-width": 37.5
            },
            ...
        }
    }
}

Frequency Range
---------------

"frequency-range": {
    "min-frequency": 192.1,
    "max-frequency": 194.1
}

Allows the client to narrow down the frequency spectrum from
which TPCE chooses a range for the service. The values
are expected to be in THz (eg. 192.1).
If the client specifies a larger frequency range than
is needed for for the service, TPCE may choose a subset
of the range.

Frequency Slot
--------------

"frequency-slot": {
    "center-frequency": 193.2,
    "slot-width": 37.5
}

Allows the client to select a specific center frequency and slot width.
Should typically be used on its own without "frequency-range".
Valid values for slot-width are defined by 12.5 x m, where m is a
positive integer greater or equal to 1.
Omitting the property "slot-width" will cause TPCE to try to
select an appropriate range automatically using "center-frequency".

Combining frequency-range and frequency-slot
--------------------------------------------

Although there is no restriction preventing the client from using both
frequency-range and frequency-slot, doing so provides no real benefit.
The exception is this case where center-frequency is left out:

"frequency-range": {
    "min-frequency": 191.325,
    "max-frequency": 194.0
},
"frequency-slot": {
    "slot-width": 25
}

In this case, TPCE should select an available frequency range of 25GHz
within the range 191.325 - 194.0.

Code Changes
------------

The primary change is in the method getSpectrumAssignment in the class
PostAlgoPathValidator. The method implements the package in
org.opendaylight.transportpce.pce.frequency.

The secondary change is the class PceComplianceCheck. It has been
updated to also validate the new frequency related parameters
in the updated service-create API body.

The packages aside, the rest of the changes in the existing
classes is mostly a ripple effect due to the changes in the class
PostAlgoPathValidator. See the extracted code below added with
comments for further explanation.

public class PostAlgoPathValidator {
    ...
    private SpectrumAssignment getSpectrumAssignment(
            GraphPath<String, PceGraphEdge> path,
            Map<NodeId, PceNode> allPceNodes,
            int spectralWidthSlotNumber) {
        ...
        Select frequencySelectionFactory =
                new FrequencySelectionFactory();

        // Find the available frequencies based on available
        // frequencies on the nodes, client input and
        // the frequencies available to the customer.
        BitSet assignableBitset =
                frequencySelectionFactory.availableFrequencies(
                        clientInput,
                        spectrumConstraint,
                        result
                );

        LOG.debug("Assignable bitset: {}", assignableBitset);

        // Find a spectrum using the available spectrum and a
        // slot width. The slot width is either spectralWidthSlotNumber
        // or the slot width found in the slot-width property, i.e.
        // API input. slot-width property will overried
        // spectralWidthSlotNumber.
        return computeBestSpectrumAssignment(
            assignableBitset,
            clientInput.slots(spectralWidthSlotNumber),
            isFlexGrid
        );
    }
}

JIRA: TRNSPRTPCE-833
Change-Id: I3d8f73924a0bf192394e3f15f20330cef6edb699
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

New packages simplifying picking service frequency

The intention behind the packages is to simplify selecting
an available frequency range from which a subset may be setup
for a new service.

Choosing a frequency range depends on these criteria:

1) Is the "customer" limited to a certain range?
2) The available range on the nodes for the service.
3) The service format (type).
4) The requested frequency range presented in the service
   create request (i.e. API body).
5) The requested center frequency presented in the
   service create request (i.e. API body).

The class FrequencySelectionFactory in the 'frequency' package brings
all the pieces together solving the requirements above.

There is also a new package 'input' dealing with input validation.

Example #1: Determine the available spectrum for the new service
----------------------------------------------------------------

/**
 * Determine the available spectrum for the new service.
 * A frequence range from a service may be picked from
 * the output of this method.
 *
 * @param input API input.
 * @param availableSpectrumOnNodes
 *             The available spectrum on the nodes
 *             selected for the new service.
 * @param customerSpectrumConstraint
 *             The customer may be restricted to this
 *             spectrum.
 * @return The spectrum that is available for the new
 *         service.
 */
BitSet availableSpectrum(
        PathComputationRequestInput input,
        BitSet availableSpectrumOnNodes,
        BitSet customerSpectrumConstraint) {

    ClientInput clientInput = new ApiClientInput(
            input,
            new FrequencyIntervalFactory(768, 6.25),
            new FrequencySpectrum(
                    new SpectrumIndex(
                            191.325,
                            6.25,
                            768
                    )
            ),
            new ServiceFrequency(),
            6.25
    );

    Select frequencyFactory =
            new FrequencySelectionFactory(768);

    BitSet availableSpectrum =
            frequencyFactory.availableFrequencyRange(
                    clientInput,
                    customerSpectrumConstraint,
                    availableSpectrumOnNodes
    );

    return availableSpectrum;
}

Example #2:Validate PathComputationRequestInput
-----------------------------------------------
The intent with this example code is to validate this part of
the service-create api body:

"service-format": "other",
"frequency-slot": {
    "center-frequency": 193.1,
    "slot-width": 37.5
},

In short, slot-width need to be in 12.5 GHz increments and
center-frequency in 6.25 GHz increments. i.e. center-frequency
is expected to be 6.25 GHz increments from the anchor frequency
193.1 (e.g.  ..., 193.09375, 193.1, 193.10625, ...).

Also, frequency-slot is only valid together with service-format = other.

public void validateInput(PathComputationRequestInput input) {
    Factory inputValidationFactory = new ValidInputFactory();
    Valid validInput = inputValidationFactory.instantiate(
            191.325,
            193.1,
            6.25,
            12.5,
            768
    );

    if (!validInput.isValid(input)) {
        LOG.error(
                "PCEInput validation failed: {}",
                validInput.lastErrorMessage()
        );
    }
}

JIRA: TRNSPRTPCE-833
Change-Id: I565198a5906ac600ada204b100f41eb9fe7aeb82
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Implement service-format 'other'

Add "service-format": "other" to service-create api body.
The primary difference between this format and the others is that
"other" will set the nmc interface 8GHz narrower than the mc interface.

APIImpact

POST /rests/operations/org-openroadm-service:service-create
{
    "input": {
        ...
        "service-a-end": {
            ...
            "service-format": "other"
            ...
        },
        "service-z-end": {
            ...
            "service-format": "other"
            ...
        }
    }
}

Background

The justification for this change at this time, is to prepare for
adding frequency selection properties to the API body at a later commit.
i.e. we want to allow the client to choose a service center-frequency
and slot-width but only using the service-format "other". Setting
center-frequency and slot-width using any other type of service-format
may cause less desirable side effects.

The frequency selection code will follow in a separate commit. Splitting
them up makes it easier to distinguish one piece of functionality
from the other.

JIRA: TRNSPRTPCE-833
Change-Id: I82a130c0cac5647caf91f22c53825b3620e5c001
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Augment service-create adding frequency properties

This commit augments the OpenmROADM create-service API with
frequency related properties.
The intent is to provide a way for the client to influence/choose
the frequency range when setting up a service.

APIImpact

Modifies the service-create body with these new properties currently
not in the OpenRoadm standard:

* min-frequency     (THz)
* max-frequency     (THz)
* center-frequency  (THz)
* slot-width        (GHz)

Example:

POST /rests/operations/org-openroadm-service:service-create
{
    "input": {
        ...
        "service-a-end": {
            ...
            "frequency-range": {
                "min-frequency": 191.4,
                "max-frequency": 191.5
            },
            "frequency-slot": {
                "center-frequency": 193.1,
                "slot-width": 37.5
            },
            ...
        },
        "service-z-end": {
            ...
            "frequency-range": {
                "min-frequency": 191.4,
                "max-frequency": 191.5
            },
            "frequency-slot": {
                "center-frequency": 193.1,
                "slot-width": 37.5
            },
            ...
        }
    }
}

NOTE: While this commit augments the service-create API body, it does
not implement these properties in TPCE.

Intention
---------

The intention behind these properties to allow the client to
choose which frequency range is used for the service.
The intention is not to allow the client to choose a different
frequency range in A end vs Z end.

Frequency Range
---------------

"frequency-range": {
    "min-frequency": 192.1,
    "max-frequency": 194.1
}

Allows the client to narrow down the frequency spectrum from
which TPCE chooses a range for the service. The values
are expected to be in THz (eg. 192.1).
If the client specifies a larger frequency range than
is needed for for the service, TPCE may choose a subset
of the range.

Frequency Slot
--------------

"frequency-slot": {
    "center-frequency": 193.2,
    "slot-width": 37.5
}

Allows the client to select a specific center frequency and slot width.
Should typically be used on its own without "frequency-range".
Valid values for slot-width are defined by 12.5 x m, where m is a
positive integer greater or equal to 1.
Omitting the property "slot-width" will cause TPCE to try to
select an appropriate range automatically using "center-frequency".

Combining frequency-range and frequency-slot
--------------------------------------------

Although there is no restriction preventing the client from using both
frequency-range and frequency-slot, doing so provides no real benefit.
The exception is this case where center-frequency is left out:

"frequency-range": {
    "min-frequency": 191.325,
    "max-frequency": 194.0
},
"frequency-slot": {
    "slot-width": 25
}

In this case, TPCE should select an available frequency range of 25GHz
within the range 191.325 - 194.0.

JIRA: TRNSPRTPCE-833
Change-Id: I02c8db0d0a7beb0ff0a20334b2db192504c5e912
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Merge "Set serviceFeasibilityCheck to false for some RPCs"

Merge "Ignore end node without available TPs in PCE"

Merge "Check if SRG has available PPs before access"

Reimplement GnpyConsumer without jersey

- clean pce pom file to remove jakarta and jersey dependencies
- reimplement GnpyConsumer to use basic HttpClient
- adapt unit tests using wiremock

JIRA: TRNSPRTPCE-837
Change-Id: I463b91d305c87e266a43836db0e22535c3d032b2
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Co-authored-by: manuedelf <emmanuelle.delfour@orange.com>

Clean the odl-transportpce-dmaap-client feature

Use odl-jersey-2 feature to avoid packaging jakarta.inject and causing
possibly big trouble in karaf when installing the feature

Change-Id: I1947bd8e86f86204ec015d0591dd503f9f119927
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Clean JsonStringConverter

Remove a duplicated line

Change-Id: I850b2d84483e543f97e5854731071aa1be70f30f
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

clean the odl-transportpce feature

- remove from the odl-transportpce feature packaging the jakarta.inject
  dependency
- replace some jersey dependencies by the odl-jersey-2

JIRA: TRNSPRTPCE-837
Change-Id: If6b167e0a395bc5d3998a72c7c2b49c298ca1a4c
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Close properly the GnpyConsumer component

Change-Id: Ie519e98d9eb228089f24b172723b921deef88b36
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Add Func Test for Topology extension

JIRA: TRNSPRTPCE-828
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: Ibc714402e4ae2a5bbd2e8fe79bd3dd53903fcb4c

Add Tapi Abstracted Node to OR Topo

- Add in networkModelServiceImpl a method to create
  a TAPI-SBI-ABS-NODE node at each level of the OR
  topology.
- Call this method at controller initialization if
  the tapi feature is activated from TapiProvider.
- Adjust tapi functional test considering that a new
  node TAPI-SBI-ABS-NODE is added at tapi feature
  initialization.
- Add in NetworkModelServiceImpl a method to delete
  The node and associated links (linkClass =  Inter-
  domain or alienToTapi) at tapi feature desinstal-
  lation.
- Add unsintall_karaf_features to test_utils
- Unsinstall tapi feature at the end of each tapi
  functional test.

JIRA: TRNSPRTPCE-827
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: Iebe33624e1a71f595aef515e705f41941ab64a1e

Create topo Context at Init for Alien & SBI

JIRA: TRNSPRTPCE-830
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: Ib4ffcf68cd26841aaf430738f348317f55bb203c

Handle modifications in existing RPCs and new RPCs

-Handle new RPC init-interdomain-links
-Handle new parameters related to T-API and OpenConfig
 added in existing RPC.

JIRA: TRNSPRTPCE-824
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: Ib3d351b660dcc975b5c68e43b39952d1dfea1d1f

Check if SRG has available PPs before access

If all PPs are used for any SRG, node validation will crash in
getRdmSrgClient because it tries to access the first element of
the empty available PP set, causing path computation to fail even
if there are other SRGs with available PPs.

This fixes the issue by moving the existing check for empty
available SRG PPs to before trying to access the first element.

JIRA: TRNSPRTPCE-835
Change-Id: I499f84b22f709504f3c67269ed4491ca7ed4246d
Signed-off-by: Jonas Mårtensson <jonas.martensson@smartoptics.com>

Ignore end node without available TPs in PCE

When PCE validates a node, if it is an end node (SRG or XPONDER) it
initializes TPs and if there are no available TPs, it sets valid to
false. This should result in the node being ignored by path
computation but currently it does not.

This fixes node validation so that such a node is ignored.

JIRA: TRNSPRTPCE-836
Change-Id: I7d133cf2009280b60cc5dd3b728c4b4229a518e7
Signed-off-by: Jonas Mårtensson <jonas.martensson@smartoptics.com>

networkutils RPCs adjusted for topo extension

JIRA: TRNSPRTPCE-823
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: I633a78177e76bf2e1a1f63222bf48b116b4bbaec

Yang file to augment OR topology

JIRA: TRNSPRTPCE-822
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: I93584290543f9e6898a9979f9d6124051362f4a6

Adjust tox ini tests sequencing

Change sequencing to perform tapi func tests after testsPCE
which makes all tests sequential, to check if func test run
better.

Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: I9a1508848f9885ce3a3421e6c272525b4feedac3

Merge changes I5958bef2,Icbca02a2

* changes:
  Fix a few bugs processing Topo
  Populate OM in portMapping and Topo

Set serviceFeasibilityCheck to false for some RPCs

Requesting a service feasibility check sets the related variable to
true in PCE listener. Other service RPCs did not set it back to false
when requested, which resulted in service handling exiting after path
computation was completed and did not continue with service rendering
and OLM setup. This change sets service feasibility to false for other
service RPCs.

JIRA: TRNSPRTPCE-831

Change-Id: I6a9f3d00c908ecf82b19ba55ee4afd13b19822d3
Signed-off-by: Jonas Mårtensson <jonas.martensson@smartoptics.com>

Fix a few bugs processing Topo

Second implementation without changing supporting-odu4
to a leaflist

JIRA: TRNSPRTPCE-759
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: I5958bef26014f31e08bf8000447028896b6d3c8c

Populate OM in portMapping and Topo

- Populate Operational mode in Port Mapping from profile
  (for device R7.1)
- Populate rate in PortMapping from supported Interface
  capabilities (All device versions
  & supported Operational mode (device R7.1)
- Propagate Operational mode from PortMapping to topology.
- Adjust tox-ini to have tests121 performed sequentially
  after tests221 to avoid failures on the gate.

JIRA: TRNSPRTPCE-708
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: Icbca02a277d60b340963b3932fec90dc02ece3f0

Make lighty build voting in the CI

Change-Id: I5498b693b138a74e9c3da826e5a393631076ec1b
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Fix bad import in lighty module

Change-Id: I2f8fe3080b3b21c6fe5581e3b3890efc4e12e62f
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Bump transportpce-models to 21.1.0

Adopt the released version

Change-Id: I672d1c552e8defd9a76e62025450f8ff45400bad
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Bump upstream dependencies to Scandium-SR1

Adopt:
- odlparent-14.0.4
- yangtools-14.0.5
- mdsal-14.0.4
- netconf-8.0.3
- lighty-21.0.0
- transportpce-models-21.1.0-SNAPSHOT

Also update netconf.device package revision.

Change-Id: Iece3f0dfff17f15c188c021e829e8a20fa4d1d73
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Bump netconf to 8.0.2

Pick up bugfixes from upstream.
Also
- update code since NetconfNode has moved to the NetconfNodeAugment
object
- adapt functional tests library

Change-Id: I9b9bd25b85da8be4dcdfbf10ccc3b91af7fe27fd
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Co-authored-by: Gilles Thouenon <gilles.thouenon@orange.com>

Bump transportpce-models version to 21.0.0

Change-Id: Idbb3e0630195abf5d9d986ae3b702c95595140d6
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Fixup javadoc checkstyle issues

Change-Id: I175f14bbd99fc9ae1a4284ebcb74c32cd96ae3c8
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Refactor test_utils lib to improve the Reg search

Adapt the wait_until_log_contains method in order to be able to detect
different Regex, depending on the context of use.

JIRA: TRNSPRTPCE-820
Change-Id: I516d4a23b052c30c219150a6b6ecee73ebbc3ecf
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Update netconf node mount settings in func. tests

Many NETCONF session reconnection issues are observed when running
functional tests on the CI. Update some settings.

Change-Id: I56f8edad2e83a7973b271f5840f936cc924f407b
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Bump project version to 11.0.0-SNAPSHOT

Start next Titanium development iteration

Change-Id: I087100311ec6fc7f9a921fb77c95ed21968b156b
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Merge "Fix grid spectrum computation (reversed logic)"

Fix grid spectrum computation (reversed logic)

Corrects an issue where flexgrid spectrum assignment
searches for available frequencies in 50GHz steps and
fixgrid searches in 6.25GHz steps. The reverse makes more sense.

Consider the for-loop in the method computeBestSpectrumAssignment
in the class PostAlgoPathValidator.

    for (int i=spectrumOccupation.size(); i >= spectralWidthSlotNumber;
            i -= isFlexGrid ? spectralWidthSlotNumber : 1) {
        ...
    }

* If isFlexGrid = true and spectralWidthSlotNumber = 8, then this loop
  subtracts 8 from i each iteration.
* If isFlexGrid = false, this loop subtracts 1 from i each iteration.

Changes
===============

In essence, fixGrid behaves as flexGrid and vice versa. This commit
inverts the logic. As an example, the bug affects scenarios where
part of a 50GHz range is available. See the examples below.

The method computeBestSpectrumAssignment is changed from private
to public access to allow unit testing. Two unit tests are also
added in the new class PostAlgoPathValidatorTest.

Examples
===============

Assuming the available frequency range can be represented
by this BitSet (1=available, 0=used):

                      |         50GHz         |         50GHz         |
SLOT:       0 1 ... 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
AVAILABLE:  0 0      0  1  1  1  1  1  1  1  1  1  1  1  1  0  0  0  0

Example FixGrid
===============

Compute spectrumassignment:

    BitSet available = new BitSet(768);
    available.set(16, 28);
    postAlgoPathValidator.computeBestSpectrumAssignment(
            available,
            8,
            false
    )

The above example will produce this result:

    SpectrumAssignment{beginIndex=20, flexGrid=false, stopIndex=27}

This may be illustrated as:
                      |         50GHz         |         50GHz         |
SLOT:       0 1 ... 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
ASSIGNED:   0 0      0  0  0  0  0  1  1  1  1  1  1  1  1  0  0  0  0

FIX
------------

After this commit, the above example will produce this result:

    SpectrumAssignment{beginIndex=16, flexGrid=false, stopIndex=23}

This may be illustrated as:
                      |         50GHz         |         50GHz         |
SLOT:       0 1 ... 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
ASSIGNED:   0 0      0  1  1  1  1  1  1  1  1  0  0  0  0  0  0  0  0

EXAMPLE FlexGrid
================

Compute spectrumassignment:

    BitSet available = new BitSet(768);
    available.set(16, 28);
    postAlgoPathValidator.computeBestSpectrumAssignment(
            available,
            8,
            true
    )

The above example will produce this result:

    SpectrumAssignment{beginIndex=16, flexGrid=true, stopIndex=23}

This may be illustrated as:
                      |         50GHz         |         50GHz         |
SLOT:       0 1 ... 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
ASSIGNED:   0 0      0  1  1  1  1  1  1  1  1  0  0  0  0  0  0  0  0

FIX
------------

After this commit, the above example will produce this result:

    SpectrumAssignment{beginIndex=20, flexGrid=false, stopIndex=27}

This may be illustrated as:
                      |         50GHz         |         50GHz         |
SLOT:       0 1 ... 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
ASSIGNED:   0 0      0  0  0  0  0  1  1  1  1  1  1  1  1  0  0  0  0

JIRA: TRNSPRTPCE-821
Change-Id: Idb4e7509a9575775846f6d3f0dab63a9ba2ea927
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Link node id to node name conversion in TAPI

Corrects an issue where a value such as ROADM-A-xxxxx
would not return the node name ROADM-A.

JIRA: TRNSPRTPCE-818
Change-Id: Ib6f73bc9eafa39cead5d29d312cd8f8b660cb116
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Upgrade lightynode to Ca-SR1

This new version of Lightynode is aligned with lighty-core-20.1.0
dependancy.

JIRA: TRNSPRTPCE-800
Change-Id: Ib7485690249ce011e0e851bebb6ee2cb8f6867b2
Signed-off-by: Christophe Betoule <christophe.betoule@orange.com>

Error due to empty list of XPDR in TAPI

When an OpenROADM service is converted to TAPI, an exception
(NoSuchElementException) is thrown.

JIRA: TRNSPRTPCE-804
Change-Id: I29ac92817050b4e2cbad73c752442874bbf2a9df
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Error due to duplicate roadm node id key in TAPI

Resolves an issue where an IllegalArgumentException was thrown
due to duplicate node id keys for ROADMs. A node id such as
ROADM-B-SRG1 was transformed into ROADM, instead of ROADM-B.

JIRA: TRNSPRTPCE-803
Change-Id: I1198454b3749dbfeaa1329b3efc94e28c3f6ddd2
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Error in TAPI creating frequency ranges

When an OpenROADM service is converted to TAPI, an exception
(ArrayIndexOutOfBoundsException) is thrown.
A byte array (size 96) was used when the code was actually expecting
size 768 (i.e. 96 x 8), when trying to create a Map<Double, Double>
with frequency ranges.

The use of method getFreqMapFromBitSet in ConvertORToTapiTopology
has been replaced with the package
org.opendaylight.transportpce.tapi.frequency.

A refactored version of getFreqMapFromBitSet can be found in the class
org.opendaylight.transportpce.tapi.frequency.NumericFrequency.

JIRA: TRNSPRTPCE-802
Change-Id: I423507decaae38b44d9f6968882179c3ec1b11d4
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

New Tapi package dealing with frequency BitSets

Refactored code creating classes capable of converting
byte to BitSet to numeric frequency ranges.

e.g. byte[] = {-1} -> 191.325:191.375 THz

Each byte in an array is treated as 8 bits. Meaning an array
of 96 bytes is treated as a BitSet of 768 bits. The bits may
subsequently be converted to a map where the key is the
lower frequency and the value is the upper frequency in a range.

The package treats each signed byte at "face value". FlexGrid
or FixGrid data are treated equally.

Examples
byte[] = {1}       -> BitSet: {0}               -> 191.325:191.33125
byte[] = {15}      -> Bitset: {0,1,2,3}         -> 191.325:191.35
byte[] = {-16}     -> BitSet: {4,5,6,7}         -> 191.35:191.375
byte[] = {-1}      -> BitSet: {0,1,2,3,4,5,6,7} -> 191.325:191.375
byte[] = {-128}    -> BitSet: {7}               -> 191.36875:191.375
byte[] = {-128, 1} -> BitSet: {7,8}             -> 191.36875:191.38125

Package Overview

The main parts of this package are the classes AvailableGrid and
NumericFrequency. AvailableGrid is used to ease converting
a byte array to either assigned (used) or available frequencies
represented by a BitSet.

AvailableGridFactory provides a way to instantiate an AvailableGrid
object using either available or used frequency grid byte data.

The method getFreqMapFromBitSet in ConvertORToTapiTopology has
been modified and copied to NumericFrequency and is used to
convert a bitset to a Map<Double, Double> (numeric frequency range).

The interface Math is intended to make it easier to unit test the code.
The implementation of Math (i.e. FrequencyMath) simply wraps calls to
GridUtils.getStartFrequencyFromIndex(...) and
GridUtils.getStopFrequencyFromIndex(...).
Since GridUtils depends on global constants, any changes to those
constants may result in unit tests failing. The interface 'Math'
provides a way to test the code using predictable data.

Example usage:

/**
 * This method converts a byte array (e.g. 96 elements) representing
 * frequency ranges into a BitSet (i.e. 768 bits), and finally into
 * a Map<Double, Double> where the key represents the start frequency
 * and the value the end frequency in a range.
 *
 * In short, this example will convert...
 *     byte[] = {-1}
 * ...into...
 *      Map<Double, Double> = 191.325:191.375
 */
public Map<Double, Double> availableMap(byte[] availableByteMap) {

    Available available = new AvailableGrid(availableByteMap);

    // This object will help us convert an instance of 'Available'
    // into a numeric frequency range.
    Numeric numericFrequency = new NumericFrequency(
            GridConstant.START_EDGE_FREQUENCY,
            GridConstant.EFFECTIVE_BITS,
            new FrequencyMath()
    );

    // Convert BitSet data contained in the bitMap object
    // into a frequency range map.
    // Note: If instead we want the assigned frequencies
    //       we could execute:
    //       numericFrequency.assignedFrequency(available):
    return numericFrequency.availableFrequency(available);
}

JIRA: TRNSPRTPCE-802
Change-Id: I578abad37351eb4ead5e8907207f1384df27f09a
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Frequency rounding error in GridUtils

There is a frequency rounding error in the class GridUtils, methods
 - getStartFrequencyFromIndex(int index)
 - getStopFrequencyFromIndex(int index)

As an example, GridUtils.getStartFrequencyFromIndex(1) will return
191.33124999999998 instead of 191.33125.

HOW TO REPRODUCE

@Test
void testStartEnd() {

    System.out.println(" Index |        Start       |      End ");
    System.out.println(
        " ----- |--------------------|--------------------");

    for (int i = 0; i < 8; i++) {
        BigDecimal start = GridUtils.getStartFrequencyFromIndex(i);
        BigDecimal end = GridUtils.getStopFrequencyFromIndex(i);

        String message =
            String.format(" %5d | %18s | %18s ", i, start, end);

        System.out.println(message);
    }
}

The above code will output (note index 1 and 6 in the table):

 Index |        Start       |      End
 ----- |--------------------|--------------------
     0 |            191.325 |          191.33125
     1 | 191.33124999999998 | 191.33749999999998
     2 |           191.3375 |          191.34375
     3 |          191.34375 |          191.35000
     4 |             191.35 |          191.35625
     5 |          191.35625 |          191.36250
     6 | 191.36249999999998 | 191.36874999999998
     7 |          191.36875 |          191.37500

After this commit the same code above will produce:

 Index |        Start       |      End
 ----- |--------------------|--------------------
     0 |            191.325 |          191.33125
     1 |          191.33125 |          191.33750
     2 |           191.3375 |          191.34375
     3 |          191.34375 |          191.35000
     4 |             191.35 |          191.35625
     5 |          191.35625 |          191.36250
     6 |           191.3625 |          191.36875
     7 |          191.36875 |          191.37500

JIRA: TRNSPRTPCE-812
Change-Id: Idcc40d2c1aca2bd18ac0fcc5daed26c004ed7a58
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Bump upstream dependencies for 2024.09 Scandium

Adopt:
- odlparent-14.0.3
- yangtools-14.0.4
- mdsal-14.0.2
- netconf-8.0.1
- transportpce-models-21.0.0-SNAPSHOT

Also,
- update dependencies in pom.xml files due to package rename and
  associated imports
- adapt the implementation of DeviceListeners
- disable the tox buildlighty's vote in the CI

JIRA: TRNSPRTPCE-815
Change-Id: Id31ee13f052c4d8718a9553fed82abb9386d831e
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Improve lightynode installation process

The same version of lightynode simulator is used for all functional
tests. We no longer need to install it several times before each test
series.
- improve lightynode installation process
- adapt also tox.ini

JIRA: TRNSPRTPCE-813
Change-Id: I380fa9bb2a876e2b3ed083ee335bf004926b262c
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Increase the kafka producer reconnect backoff time

Configure the kafka producer with a reconnection time at 10min (instead
of 500ms) to avoid polluting the logs with too many warnings messages.

JIRA: TRNSPRTPCE-807
Change-Id: Ie48800105bdeed8e3525d693cda1fc8e22c9bd24
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Search available frequencies in TAPI cause error

Resolves an issue causing a NoSuchElementException when
TAPI is activated and an OpenROADM service is copied to TAPI.

The exception was thrown during an iteration while attempting
to filter out available bitsets by using string comparison
that would never be true:

"AvailFreqMapsKey{mapName=cband}" != "cband"

JIRA: TRNSPRTPCE-801
Change-Id: I507c0e602fdee92df39e75ef0f9af2d2f23739e9
Signed-off-by: Joakim Törnqvist <joakim.tornqvist@smartoptics.com>

Fix shellcheck in installMavenUbuntu script

Change-Id: Ifdf2d839674f63018682ea0c45c84c468b099722
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Merge "Bump CI scripts to Ubuntu 20.04"

Bump CI scripts to Ubuntu 20.04

Build node on the CI have migrated from CentOS to Ubuntu-2004 which
already supports different versions of java.
- remove old installMavenCentOS.sh script which is now obsolete
- replace it with installMavenUbuntu.sh which configures java-21 and
  install maven 3.9.8

Change-Id: I50c29126cb2797d1ba4c386284c4015f8079f6df
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Merge "Debug tool for openconfig proprietary extensions"

Bump few upstream dependencies for Ca-SR1

Adopt:
- netconf-7.0.7 (critical fix)
- transportpce-models-20.1.2

JIRA: TRNSPRTPCE-799
Change-Id: I57a8efa611f9e7d9f80ecf2905ed22bf3b1cec29
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Debug tool for openconfig proprietary extensions

Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I61e21b88029961186308a6a5373f562b6991c8a2

Fix CI Cent OS 8 configuration issue (workaround)

- reverts commit 94578ec62abf23679af8557bde48e26e1b7bc7d7
  to reenable voting for checkbashisms and pre-commit

Mirrorlist URLs have been archived and moved to Cent OS vault.
https://forums.centos.org/viewtopic.php?t=78708&start=30
https://forums.centos.org/viewtopic.php?t=80698
This impacts Jenkins minions configuration.

- force vault use in yum repos config till this is fixed upstream

Change-Id: I87831c5fe4cb81031f75d42762e1ad16e296a3e5
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>

Consolidate ConnectivityUtils

- Add spectrum information to Cep
- Centralize Topological_mode & TopoUUID handling in TapiProvider
- Refactor ConnectivityUtils adding CreateRoadmCepAndClientNeps to
factorize & backporting createCepRoadm and createRoadmNep into
ConvertORToTapiTopology to call it from Tapilink
- Move method to calculate fiber parameters from PceLink to NetworkUtils
to call them in TapiLink
- Add methods to create OTS & OMS Cep in TapiLinkImpl at init
- Add method to build OTS-Cep-Spec from OR OMS
- Add Test for OTS & OMS cep
- Refactor TapiLinkImpl & TapiORListener
- AddTest for PhotonicMediaNodeEdgePointSpec in Test of
convertORTopoToFullTapiTopoTest
- adapt tapi constructors in lighty build

JIRA: TRNSPRTPCE-759
Signed-off-by: orenais <olivier.renais@orange.com>
Change-Id: I2a1aeb3c413b315c46c66723342888c497365b6f

Fix common GridUtils comments

Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: Ia6b3813507337844e257ad5b7d9dd1b4cd971a4e

refactoTapi2.4 Final touch

Backport commit b6c6d93979d076cf5dac84f18df3b15c312961c1 from
stable/calcium branch.
Fix a commit handling error during the development...

Change-Id: I603aa131ace9f23ee364eca86943c330405134bb
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Co-authored-by: orenais <olivier.renais@orange.com>

Fix frequencies in TAPI ConvertORToTapiTopology

JIRA: TRNSPRTPCE-764
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: Ie6c070aa718b4561f3ad73676f8eb3f49ca64034

Bump upstream dependencies to Ca-SR1

Adopt:
- odlparent-13.1.3
- yangtools-13.0.6
- mdsal-13.0.4
- netconf-7.0.6
- transportpce-models-20.1.1

Aslo adapt lighty build to tapi code evolution.

JIRA: TRNSPRTPCE-799
Change-Id: If1a2e0f19b7dd2885dd952b271090dc46df44edd
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Fix floating equality bug in tapi module

Change-Id: Ied1dba218056fec63044055b94886c81009b12ae
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Make lighty build voting in the CI

Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Change-Id: I728a72a4f92626f52b07346544fe4bfca79092ab

Fix tpce-lighty build

- get the RpcService from LightyServices
- change urn of yang modules instances

FIRA: TRNSPRTPCE-799
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Change-Id: I60abe1130a2136a740f041364742342e85d109cc

Fixup checkstyle issues

Move some variables.

JIRA: TRNSPRTPCE-799
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Change-Id: I143fdb8ece7b7d77892c960819d88da168df6b81

Bump lighty to 20.0.0

Change-Id: I94a321d5a38e11b93bd76bc5b9437ef7c2d81c49
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Make tox pre-commit and checkbashism non voting

These two tox test environments are systematically failing on the CI.
- checkbashisms can't be installed.
- idem with pre-commit?
Disable them for now while waiting to understand what is going on.

Change-Id: I9a1c946d922cfa821a7d77ae791bb2c6b3358a7f
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>

Merge "Refactor ConvertORTopoToTapiTopoTest"

Update release in docs/conf.yaml

Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I15c62732e9e3519d43922fc59853ca0c2a897660

Merge "Power setup  gainloss failure Junit test"

Merge "Refactor TAPI utils TapiContext"

Refactor ConvertORTopoToTapiTopoTest

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I012fda1c98ddfe812872dddb85489cda1192455a

Merge changes I04980c0b,Ib74e699a,I6ca86692,Ida6061da,Iea661424, ...

* changes:
  Refactor ConvertORTopoToFullTapiTopoTest step 7
  Refactor ConvertORTopoToFullTapiTopoTest step 6
  Refactor ConvertORTopoToFullTapiTopoTest step 5
  Refactor ConvertORTopoToFullTapiTopoTest step 4
  Refactor ConvertORTopoToFullTapiTopoTest step 3
  Refactor ConvertORTopoToFullTapiTopoTest step 2
  Refactor ConvertORTopoToFullTapiTopoTest step 1

Refactor TAPI utils TapiContext

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: Ica321417d3ff7ac23a345b1e182ad940cc1058c8

Power setup  gainloss failure Junit test

JIRA: TRNSPRTPCE-798
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I12e34d532c84ab4c0590981090f1f290d6a45938

Abort power setup if setting gainloss fails

Currently, if changing control mode from power to gainloss fails on a
device, e.g. because it becomes disconnected, power setup just
continues with the next node.

This changes behaviour so that power setup is aborted instead and
service creation is rolled back.

JIRA: TRNSPRTPCE-798
Change-Id: I85f03f318c66a524ac91d62cf7459d01e9a5d021
Signed-off-by: Jonas Mårtensson <jonas.martensson@smartoptics.com>

Refactor ConvertORTopoToFullTapiTopoTest step 7

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I04980c0b032546765bcc9010f83d9a253fa95617

Refactor ConvertORTopoToFullTapiTopoTest step 6

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: Ib74e699af595515a536a963eec2ed5cd612a86f4

Refactor ConvertORTopoToFullTapiTopoTest step 5

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I6ca8669229c45f7fb660beb559b7469df601b803

Refactor ConvertORTopoToFullTapiTopoTest step 4

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: Ida6061daf919a37c033fbe23c5ec7af36e47205f

Refactor ConvertORTopoToFullTapiTopoTest step 3

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: Iea661424d133995b3413ca98e127808e4c775090

Refactor ConvertORTopoToFullTapiTopoTest step 2

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I79e404cfec8a033698695b5ec348a4e09e2c66d2

Refactor ConvertORTopoToFullTapiTopoTest step 1

JIRA: TRNSPRTPCE-735
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I5bef988d4582652ca02e30699cb303600656911f

Merge "Bump transportpce-models upstream dependency"

Merge changes I1e9ed1dd,I86ae4ee0

* changes:
  Refactor TAPI TapiNetworkModelServiceImpl
  Rework TAPI TapiNetworkModelServiceImpl code style