Migrate last remaining uses of InstanceIdentifier

In the TPCE code, calls to the toLegacy() method are hanging around
since the migration from InstanceIdentifier to DataObjectIdentifier,
because they were needed to use the firstKeyOf() method. Now that the
latter is available in DataObjectIdentifier, we can now remove calls to
toLegacy.
Also add few SuppressWarnings annotations to remove few unchecked casts.

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

Bump upstream dependencies to Sc-SR2

Adopt:
- odlparent-14.0.7
- yangtools-14.0.9
- mdsal-14.0.9
- netconf-8.0.5
- transportpce-models-21.2.0
- lighty-21.1.0

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

Generalize use of StandardCharsets constants

Replace everywhere in TPCE code Charset.forName() by StandardCharsets
constants.

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

Generalize use of Uint constant when available

Uint8, Uint16, Uint32, Uint64 classes have defined few constants.
Use them when possible.

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

Generalize the use of JUnit5 Assertions

Although TPCE has migrated to JUnit5, there are still some test classes
that still use JUnit4 assertions (org.junit.Assert).
Generalize JUnit5 assertions across all TPCE test classes.

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

Generalize static imports for Assertions

Most Junit test classes in TPCE use static imports for Assertions, which
provides better readability. Generalize this across all TPCE test
classes.

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

Generalize static imports for Mockito

Most of Junit test classes in TPCE uses static imports for Mockito which
brings better readibility. Generalize that through all TPCE test
classes.
Also, use the JUnit5 extension to initialize Mock instead of
MockitoAnnotations, which makes things simpler.

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

Use Awaitility in Junit tests requiring timeout

Some Junit tests require a timeout and use Thread.sleep which blocks the
main thread. Use the Awaitility library to time out tests more smoothly.

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

Use sft.skip in TPCE features pom files

Using skip.karaf.featureTest property in feature pom files generates a
compilation warning. Change it to the new one.

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

Remove some dead code lying around

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

Remove useless call to toIdentifier method

In the TPCE code, unnecessary calls to the toIdentifier() method are
hanging around since migrating InstanceIdentifiers objects to
DataObjectIdentifier. Just delete them to make things cleaner.

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

Merge changes I783b6f04,I6c110318,Iea039f8a

* changes:
  Correct CEP management at service creation
  Correct bugs in tapi conversion Factory
  Refactor tapi topo ConvertXXX Classes

Correct CEP management at service creation

- Create eODU Cep on client ports connected to a network port
  when the port is activated through a pht service creation.
- Create transportpce-tapi-connectivityutils.yang file to define
  a new connection-vs-service object used to store for services
  the list of associated connections.
- Create methods to populate this new object in ConnectivityUtils
  in order to better handle underlying connections.
- Modify the process of creation of top-connections.
- Add creation of I-OTU connections.

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

Correct bugs in tapi conversion Factory

- Correct some bugs in TapiConversionFactory adding some
  layer-protocol-qualifiers to interfaces and correcting
  frequency multipliers.
- Use UintX predefined constants notably in LPN Map

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

Refactor tapi topo ConvertXXX Classes

- Refactor the Classes used to convert OR to TAPI topology changing name
  of classes to a more comprehensive name, and adding java docs.
- Integrate modifications proposed in change #114944 that can be back-
  ported respecting expected behavior at the target.

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

Use java.nio to manage files

It remains several places (mainly in test-common module) where files are
handled with the java.io package.
Instead, use the more modern objects from java.nio.file.
Also, use Files.newBufferedReader() instead of FileReader.

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

Fix javadoc checkstyle issues

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

Migrate usage of Hamcrest test library to AssertJ

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

Correct bugs at tapi uninstall

- correct bug introduced deleting links during Tapi feature
  uninstallation
- adjust tox tests to uninstall tapi feature after all nodes have been
  disconnected

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

Changes to update nbl and add rate in portmapping

- non-blocking-list updated to have one nbl for each client port.
- rate is now populated for LCPs based on meta-data.
- client transceiver with supported-interface-capability is added in
  meta data.

JIRA: TRNSPRTPCE-855
Signed-off-by: Roshan Joyce <roshan.joyce@fujitsu.com>
Change-Id: I0d516e9bc524a0df78089dc835d8cd24571b0552

Merge "Fix ROADM provisioning for 7.1 models"

Complement new converters of test-common

- add new method to serialise in a Json/Xml output file
- complement Junit tests
- add missing declared dependencies in the pom.xml file

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

Remove JsonUtils from test-common

This code now becomes redundant with the code for the new
JsonDataConverter. Migrate its few uses to JsonDataConverter and delete
JsonUtils which is then no longer used.

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

Implement new converters in test-common

Usage of existing converters is difficult.
Implement more simple ones to serialize/deserialize DataObject to/from
String for Junit test purpose.
- implement new Json serializer/deserializer
- implement new Xml serializer/deserializer
- add Junit tests

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

Refactor some DataObjectIdentifier

- use some WithKey
- remove one usage of a deprecated InstanceIdentifier method

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

Move constants from NetworkUtils in common module

NetworkUtils class specifies few constants which are used almost
everywhere. Move them on the StringConstants class of common module
which is dedicated to centralize all constants.
Also rename a few of them to make them more explicit.

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

Refactor some uses of Map

When possible, use  utility means that makes Map handling easier.

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

Merge changes Ibae306ef,I52415c1b,I9210afca

* changes:
  Implement error message subscriber
  New result message builder (WeightedResultMessage)
  New observer package subscribing for error msg

Implement error message subscriber

APIImpact

Adds a more descriptive error message for the create service API,
providing more context in case the process fails.

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

New result message builder (WeightedResultMessage)

The new class WeightedResultMessage simplifies creating a resultmessage
based on a list of DeviceRenderingResult or OLMRenderingResult objects.

Useful when there is two parallell tasks running and none, one or both
result in an error. The WeightedResultMessage turns them into one
message (string) prioritizing error messages before successful messages.

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

New observer package subscribing for error msg

The EventSubscriber class is intended for tracking events of various
severity. The class provides a way of collecting error messages
for later use. The class contains convenient methods extracting the
first or last message from a given type (error, warning etc).

The class is particularly useful in the case of an iteration where it's
not uncommon for errors to occur during the iteration, although at some
point in the iteration at least one item should complete without error.

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

Adjust Xponder nrg/irg computation

- Correct irg and nrg computation for Xponder
- Adjust corresponding Juinit tests

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

Adjust ROADM IRG computation

Correct inter-rule-group computation for ROADM to build as many IRGs as
SRGs, including 2 associated-node-rule-groups (one for SRG, one for DEG)

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

Add CEPlist to OTS NEP at init

- add Cep list to owned-node-edge-point for Xponders at initialization
  corresponding to T0 configuration
- add OTS CEP creation at init for SRG PPs and Degrees TTPs
- modify CEP name to differentiate from NEP names adding "CEP+" at the
  begining of CEP Name

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

Fix ROADM provisioning for 7.1 models

Provision NMC, MC and ROADM cross-connects for a ROADM node with 7.1
OpenROADM MSA models.

JIRA: TRNSPRTPCE-834
Change-Id: I23b7de784745c9006aac202a8fea5487cd5d2c2a
Signed-off-by: Balagangadhar (Bala) Bathula <bb4341@att.com>

Replace use of deprecated methods in tapi module

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

Add openconfig node in openroadm network layers

- refactor NetworkModelServiceImpl to add and remove an openconfig node
  in openroadm network layers (clli, network, topology, otn)
- refactor switch case structure in TopologyUtils to update the
  operational and admin states with openconfig values
- add a new functional test suite to check this new feature

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

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>