1. Topics
  2. MandatoryLeafEnforcer check for config true leaf - nodes

MandatoryLeafEnforcer check for config true leaf - nodes

Vikram
 

Hi Team

 

Using Neon-SR1

 

Model is as below:

Container A {

      leaf B{

            type string;

            config true;

           mandatory true;

      }

      leaf C{

            type string;

            config false;

      }

}

 

Creating Dataobject in ODS:

ABuilder().setC(“C”).build() object is been stored in Operational Datastore  -> MandatoryLeafEnforcer kicks in and throwed below exception:

 

java.lang.IllegalArgumentException: Node XXX  is missing mandatory descendant /(http://www.advaoptical.com/A?revision=2016-09-16)B

 

As leaf node B is config attribute, our understanding is mandatory check should not be performed on this leaf node when the data object is stored in Operation DS.

 

Thanks in advance for your support.

 

Regards

Vikram

 
Robert Varga
 

On 30/07/2019 16:02, Vikram Darsi wrote:
Hi Team

 

*Using Neon-SR1*

 

*Model is as below:*

Container A {

      leaf B{

            type string;

            config true;

           mandatory true;

      }

      leaf C{

            type string;

            config false;

      }

}

 

*Creating Dataobject in ODS:*

ABuilder().setC(“C”).build() object is been stored in Operational
Datastore  -> MandatoryLeafEnforcer kicks in and throwed below exception:

 

java.lang.IllegalArgumentException: Node XXX  is missing mandatory
descendant /(http://www.advaoptical.com/A?revision=2016-09-16)B

 

As leaf node B is config attribute, our understanding is mandatory check
should not be performed on this leaf node when the data object is stored
in Operation DS.
OpenDaylight has always followed a 'fused' Operational datastore model,
which is now documented here:
https://tools.ietf.org/html/rfc8342#section-5.3

Assuming conventional datastore model, based on your reasoning, would
not work either: 'container A' lacks a 'config' statement, which means
it defaults to 'config true', which means it is *not* part of
Operational datastore (same as 'leaf B') -- which leaves 'leaf C' in a
vacuum.

Regards,
Robert

?
signature.asc

Vikram
 

Hi Robert,

Thanks for the reply. Apologies, If I did not convey the query properly.

Query is about the 'mandatory' statement not 'config' statement.

Say, A container node has both config and state data, certain config information from the user is mandatory hence they are defined as mandatory. Say, in the DTCL triggered, based on the mandatory information provided , we derive state information and store in ODS. With the " MandatoryLeafEnforcer" in place, we force to set the other fields as well in ODS (It leads to duplicate information in ODS)

Is it a good idea to relax 'mandatory' check only for config true attributes when they are stored in ODS?

Thanks
Vikram

-----Original Message-----
From: Robert Varga <nite@...>
Sent: Tuesday, July 30, 2019 8:44 PM
To: Vikram Darsi <VDarsi@...>; yangtools-users@...
Subject: Re: [yangtools-users] MandatoryLeafEnforcer check for config true leaf - nodes

External email: [nite@...]

......................................................................
On 30/07/2019 16:02, Vikram Darsi wrote:
Hi Team

 

*Using Neon-SR1*

 

*Model is as below:*

Container A {

      leaf B{

            type string;

            config true;

           mandatory true;

      }

      leaf C{

            type string;

            config false;

      }

}

 

*Creating Dataobject in ODS:*

ABuilder().setC("C").build() object is been stored in Operational
Datastore  -> MandatoryLeafEnforcer kicks in and throwed below exception:

 

java.lang.IllegalArgumentException: Node XXX  is missing mandatory
descendant /(http://www.advaoptical.com/A?revision=2016-09-16)B

 

As leaf node B is config attribute, our understanding is mandatory
check should not be performed on this leaf node when the data object
is stored in Operation DS.
OpenDaylight has always followed a 'fused' Operational datastore model, which is now documented here:
https://tools.ietf.org/html/rfc8342#section-5.3

Assuming conventional datastore model, based on your reasoning, would not work either: 'container A' lacks a 'config' statement, which means it defaults to 'config true', which means it is *not* part of Operational datastore (same as 'leaf B') -- which leaves 'leaf C' in a vacuum.

Regards,
Robert
Robert Varga
 

On 30/07/2019 17:44, Vikram Darsi wrote:
Hi Robert,

Thanks for the reply. Apologies, If I did not convey the query properly.

Query is about the 'mandatory' statement not 'config' statement.

Say, A container node has both config and state data, certain config information from the user is mandatory hence they are defined as mandatory. Say, in the DTCL triggered, based on the mandatory information provided , we derive state information and store in ODS. With the " MandatoryLeafEnforcer" in place, we force to set the other fields as well in ODS (It leads to duplicate information in ODS)
Right -- and since you have the mandatory leaf readily available, why
not just propagate it as-is to operational?

Is it a good idea to relax 'mandatory' check only for config true attributes when they are stored in ODS?
That very much depends.

As noted below, config=true and config=false are equal members of the
operational datastore, why would one be treated differently?

If such a reason exists, is it good enough to justify the added semantic
complexity people have to bear in mind?

Regards,
Robert

?
signature.asc

1 - 4 of 4