Merge "MC-capability improved error message"

MC-capability improved error message

A more descriptive error message when a node is found incompatible with
a certain service slot width.

New message
  ROADM-A1-SRG1 does not support a service slot width of 50GHz
  (ROADM-A1-SRG1 supports slot-width-granularity: 12.5GHz, and
  min-slots: 1, and max-slots 3, i.e. slot width: 12.5GHz to
  37.5GHz).

Old message
  Cannot fit a service with 50.0GHz on node ROADM-A1-SRG1, with
  slot width granularity 12.5000 min slots 1 and max slots 3

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

Allow project build for user settings

Script should permit user to input the settings file, especially working
in a proxy settings.

Signed-off-by: Balagangadhar (Bala) Bathula <bb4341@att.com>
Change-Id: I2592a64d42c256867ca4994f943b9e7354e0f6b6

Bump upstream dependencies to latest Sc-SR2

Adopt:
- odlparent-14.0.8
- yangtools-14.0.11
- mdsal-14.0.11
- netconf-8.0.7
- transportpce-models-21.2.2
- lighty-21.1.0

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

Merge changes I451d8447,I6dfb47b4,Ie770ef84,If08319dc,Iafae3d00, ...

* changes:
  Spectrum assignment fixgrid only for 1.2.1
  Service spectrum assignment uses MC-capabilities
  New package handling MC-capabilities
  Implement mc min/max slots in portmapping
  Add min/max slots to tpce portmapping yang model
  Implement center-freq-granularity in freq. select
  New packages aiding finding available frequencies
  New package for center frequency granularity LCM

Spectrum assignment fixgrid only for 1.2.1

During spectrum assignment, there is a boolean value
keeping track of fix- vs flex grid. The code only treat
the service as fix grid if a node is using OpenROADM
version 1.2.1.

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

Service spectrum assignment uses MC-capabilities

Service spectrum assignment uses slot width granularity and
min/max-slots to determine if a degree/srg is compatible
with the required service frequency slot width.

Example
-------

  min-slots: 1                       min-slots: 8
  max-slots: 16                      max-slots: 16
  slot-width-granularity: 12.5       slot-width-granularity: 6.25
    _____                              _____
   |     |                            |     |
   |  A  |_SRGa__________________SRGb_|  B  |
   |_____|                            |_____|

   SRGa: Possible service slots: 12.5, 25.0, ..., 200.0 (GHz)
   SRGb: Possible service slots: 50.0, 62.5, ..., 100.0 (GHz)

Given the above example a service with slot width 50GHz would work
while a service slot width of 37.5GHz will not (SRGb only supports
slot widths 50GHz and above).

Code summary
------------

- Class PostAlgoPathValidator, method getSpectrumAssignment(...)
    The method uses mc-capabilities when finding available frequencies.
    The information is obtained from the PceNode.

- Interface PceNode
    Two new methods getMinSlots and getMaxSlots.
    getSpectrumAssignment(...) takes advantage of them when finding
    available frequencies.

- Class PceOpticalNode
    Refactored the constructor to accept an instance of McCapability
    containing slotWidthGranularity, centralFreqGranularity, min and
    max slots.

- PostAlgoPathValidatorTest
    Uses the topology information in src/test/resources/topology to
    setup a fake topology while unit testing getSpectrumAssignment(...)

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

New package handling MC-capabilities

OVERVIEW

The class McCapabilityCollection simplifies finding out if a service
slot width is compatible with all nodes in the path.
MC capabilities such as slot width granularity and min/max slots are
taken into account.

The class NodeMcCapability is intended to simplify handling API input by
removing the need of extra null checks and implements yang default
values.

Example #1
----------

/**
 * Determine if a service with a slot width of 50GHz (i.e. 8 slots
 * of 6.25GHz) is compatible with the default MC capabilites of slot
 * width granularity 50GHz and min and max slots set to 1.
 */
boolean compatible() {

    CapabilityCollection collection = new McCapabilityCollection();
    collection.add(new InterfaceMcCapability("ROADM-A-SRG1", 50, 1, 1));

    //true
    return collection.isCompatibleService(6.25, 8);
}

Example #2 - Observer
---------------------

/**
 * There is an optional Observer interface. The implementing class
 * is notified about any errors when verifying if a MC interface
 * is not compatible with a service.
 * The class VoidObserver may be used if one whishes to ignore all
 * error messages.
 */
public boolean compatible() {
    CapabilityCollection collection =
            new McCapabilityCollection(new Observer() {
                @Override
                public void error(String message) {
                    System.out.println(message);
                }
            });
    collection.add(new InterfaceMcCapability("ROADM-A-SRG1", 50, 1, 1));

    return collection.isCompatibleService(6.25, 6);
}

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

Implement mc min/max slots in portmapping

Portmapping for v2.2.1 and 7.1 is updated with mc capabilities
min/max slots.

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

Add min/max slots to tpce portmapping yang model

Adding the leaves 'min-slots' and 'max-slots' to mc-capabilities
in the yang model 'transportpce-portmapping'.

They correspond to the leaves min-slots and max-slots in the openroadm
device model (org-openroadm-device):

  leaf min-slots {
    type uint32;
    default "1";
    config false;
    description
      "Minimum number of slots permitted to be joined together to form
       a media channel. Must be less than or equal to the max-slots";
  }
  leaf max-slots {
    type uint32;
    default "1";
    config false;
    description
      "Maximum number of slots permitted to be joined together
      to form a media channel. Must be greater than or equal to
      the min-slots";
  }

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

Implement center-freq-granularity in freq. select

When a frequency range is selected for a new service,
center-freq-granularity on the nodes are taken into account.

Since each node may have different center-freq-granularity values,
the least common multiplier is used to find a "common ground".

This commit also uses the "base frequency" 193.1 (G.694.1) as the
reference point, when finding possible center frequencies, as opposed
to the start/end of the range.

In short, this commit implements the leaf center-freq-granularity
defined in org-openroadm-device:

    leaf center-freq-granularity {
      type org-openroadm-common-optical-channel-types:frequency-GHz;
      default "50";
      config false;
      description
        "Granularity of allowed center frequencies.
         The base frequency for this computation is 193.1 THz (G.694.1)"
    }

Example
-------

In this example two nodes have these center-freq-granularity values:

    _____                      _____
   |     | 37.5GHz      75GHz |     |
   |  A  |____________________|  B  |
   |_____|                    |_____|

The center frequency granularity 75GHz is compatible with both
A and B above.

Given the scenario above, potential center frequencies are
193.1THz ± n x 75GHz, where n≥0 and will be used while searching for
an available service slot. To be more exact, this range will
be used: 191.325THz < 193.1THz ± n x 75GHz < 196.125THz.

In this example, the frequency 196.1THz is the first center frequency
tested for an available service slot while 196.025 is the second.

If the service slot requires more than a width of 50GHz (2 x 25GHz),
the first possible center frequency is instead 196.025THz.

                A,B         A         A,B         A         A,B
                 ↓          ↓          ↓          ↓          ↓
    ...--|--...--|----------|----------|----------|----------|------|
THz   193.1   195.95     195.9875   196.025    196.0625   196.1  196.125

GHz ...-> <-...-> <- 37.5 -> <- 37.5 -> <- 37.5 -> <- 37.5 -> < 25 >
GHz ...-> <-...-> <------ 75.0  ------> <------ 75.0  ------> < 25 >

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

New packages aiding finding available frequencies

OVERVIEW

The classes in this commit finds an available frequency range by
iterating through a BitSet representing available frequencies.

The iteration uses the base frequency (i.e. 193.1THz, G.694.1) index
location in the BitSet as the reference point (as opposed to the start
or end of the BitSet). In essence, an adaption to the
center-freq-granularity as specified in mc-capability-profile in
org-openroadm-device.yang.

Also, the iteration moves in "center frequency granularity" steps
through the BitSet. The intention is to use the frequency granularity
settings of all service path nodes to find a suitable available
frequency range.

EXAMPLE

/**
 * Find a frequency range for a new service
 *
 * @param pceNodes The nodes in the service
 * @param serviceFrequencySlotCount The nr of slots required for
 *                                  the new service
 * @param assignableBitset A bitset representing which slots
 *                         are available
 * @return A start and stop index nr forming a range of frequencies
 *         available for the service.
 */
private SpectrumAssignment availableFrequencyRange(
        Set<PceNode> pceNodes,
        int serviceFrequencySlotCount,
        BitSet assignableBitset) {

    //Create an empty collection of center frequency granularities.
    //An empty collection will use 50GHz as the default granularity.
    Collection centerFrequencyGranularityCollection =
        new CenterFrequencyGranularityCollection(50);

    //Iterate through the nodes in the path and add each
    //center frequency granularity to the collection.
    for (PceNode pceNode : pceNodes) {
        centerFrequencyGranularityCollection.add(
            pceNode.getCentralFreqGranularity()
        );
    }

    Base baseFrequency = new BaseFrequency();

    //Use the strategy of going from high frequencies to low
    //when finding an available range.
    Assign assignSpectrum =
            new AssignSpectrumHighToLow(new SpectrumIndex());

    //Find an available frequency range
    Range range = assignSpectrum.range(
            768,
            baseFrequency.referenceFrequencySpectrumIndex(
                    193.1,
                    191.325,
                    6.25
            ),
            assignableBitset,
            centerFrequencyGranularityCollection.slots(6.25),
            serviceFrequencySlotCount
    );

    //Return the available frequency range as a begin and stop index.
    return new SpectrumAssignmentBuilder()
            .setBeginIndex(Uint16.valueOf(range.lower()))
            .setStopIndex(Uint16.valueOf(range.upper()))
            .setFlexGrid(true)
            .build();

}

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

New package for center frequency granularity LCM

Introduces a new collection intended for storing center frequency
granularity values. The collection simplifies calculating
Least Common Multiple values for multiple nodes (e.g. SRGs) and
determine by how many slots each center frequency is
separated (e.g. on a 768 grid where each slot is 6.25GHz wide).

Example #1
----------

Consider this topology where the nodes A and B are connected using
SRGs with the given center frequency granularity:
      _____                      _____
     |     | 37.5GHz      75GHz |     |
     |  A  |____________________|  B  |
     |_____|                    |_____|

  Collection collection = new CenterFrequencyGranularityCollection(50);
  collection.add(37.5);
  collection.add(75);

  System.out.println(collection.leastCommonMultipleInGHz());
  \> 75

  // Given a slot width granularity of 6.25GHz, the center frequency
  // granularity of 75 GHz represents 12 slots.
  System.out.println(collection.slots(6.25));
  \> 12

Given the above scenario, and a base frequency of 193.1THz (G.694.1),
193.025 and 193.175 (THz) are examples of possible center frequencies
compatible with both A and B.

Illustrating the center frequency granularities for A and B:

      A,B            A            A,B            A            A,B
       ↓             ↓             ↓             ↓             ↓
  ...--|-------------|-------------|-------------|-------------|--...
    193.025       193.0625       193.1        193.1375      193.175

  ...-> <- 37.5GHz -> <- 37.5GHz -> <- 37.5GHz -> <- 37.5GHz -> <-...
  ...-> <-------   75GHz   -------> <-------   75GHz   -------> <-...

Example #2
----------

An empty collection will use the default center frequency granularity,
in this case 50GHz.

  Collection collection = new CenterFrequencyGranularityCollection(50);

  System.out.println(collection.leastCommonMultipleInGHz());
  \> 50

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

Complement converters tests with TAPI dataObject

- add TAPI 2.4 dataObject to test converters with Context based data
models.
- rename TapiStringConstants class to TapiConstants since it does not
  only contain string constants.
- add UT to write a TAPI context from a XML file into DS, read it from
TAPI topology and additionally store it in JSON file.

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

Clean up the code across the entire project

- clean up at the exceptions level (remove declaration of exceptions
  never thrown, log the exception when catched...)
- remove unused properties
- simplify few if-else structures
- remove few useless try-catch structures

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

fix some this-escape compilation warnings

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

Refactor RPC registration in TapiNetworkUtilsImpl

Change the way to instantiate the RPC implementations in order to remove
a "this-escape" warning raised by the JDK at the compilation.
Introduce an AbstractTapiNetworkUtil class to mutualize common code
between RPC implementations.

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

Add mising serialVersionUID

That removes some compilation warnings.

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

Fix javadoc compilation warnings

Mainly in networkmodel module. This removes a number of warnings.

JIRA: TRNSPRTPCE-854
Change-Id: I10deba2d5abbeec816d043f6cf4035f8d73e9360
Signed-off-by: Gilles Thouenon <gilles.thouenon@orange.com>
Fix javadoc compilation warnings

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

Migrate registration of some RPC implementations

Several TPCE modules still use an outdated method for registering RPC
implementations. Update the code to use the new registration methods
available in RpcProviderService.

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

Add missing type argument for generic class

Add a type argument to the generic
org.opendaylight.yangtools.binding.Notification interface in the
renderer to remove a compilation warning.

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

Clean up maven dependency declarations

Add missing dependencies and remove unnecessary ones to suppress Maven
compilation warnings

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

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