Change system process args from leaf-list to leaf value

[earies]

• (M) release/models/system/openconfig-procmon.yang
  • Type change for process args from leaf-list to leaf
  • Backwards incompatible minor version update to 0.5.0

Change Scope

During analysis of /system/processes/process/state/args it was observed that
implementation behaviors may not correspond to the definition of this leaf.

In the current published 0.4.0 version of openconfig-procmon.yang, args
is a leaf-list calling for implementations to parse the command line arguments
for every running process and pack each into precise elements of the leaf-list.
While this is entirely possible, there is the additional overhead associated
with parsing every PID and the overall usage of such data that should be
considered.

This proposal is for flattening the complexity and returning process cmdline
args as a single string as would be retreived by procfs (for Linux-based
systems)

NOTE: This change is backwards incompatible per YANG specifications however
this is about current shipping implemention behaviors and the usage around this
data

Platform Implementations

• JUNOS/EVO: Currently deviated not-supported
• Arista EOS: Returns single element of leaf-list unparsed as full string
• Nokia SRL: Not deviated, observation is not supported on SRL 25.7.2
• Nokia SROS: Deviated not-supported
• Cisco IOS-XR: Not deviated, unknown runtime behavior
• Cisco IOS-XE: Deviated not-supported

[earies]

@hellt @rgwilton @romeyod @jsterne for comment/review on their respective implementations

[earies]

@hellt @rgwilton @romeyod @jsterne for comment/review on their respective implementations

And to kick start some discussion on this

• If process args are encoded as a leaf-list, what use-cases and storage assumptions are there around the receiver side? Will these args merely be concatenated back to a single string? How does a leaf-list benefit in this case?
• For Linux based systems, this data is likely to come from /proc/pid/cmdline ref: https://man7.org/linux/man-pages/man5/proc_pid_cmdline.5.html. In any case, null byte handling is necessary.

Prior art reference from SYSAPPL-MIB:

   sysApplElmtRunParameters OBJECT-TYPE
       SYNTAX      Utf8String          
       MAX-ACCESS  read-only           
       STATUS      current
       DESCRIPTION
           "The starting parameters for the process."
   ::= { sysApplElmtRunEntry 8 }

[romeyod]

@hellt @rgwilton @romeyod @jsterne for comment/review on their respective implementations

And to kick start some discussion on this

• If process args are encoded as a leaf-list, what use-cases and storage assumptions are there around the receiver side? Will these args merely be concatenated back to a single string? How does a leaf-list benefit in this case?

I am not aware of use-case and storage assumptions from the receiver side.

Since Arista EOS returns single element of leaf-list unparsed as full string, it safe to assume some operator might be using this. From a backward compatibility perspective, can we make args a union though?

[earies]

I am not aware of use-case and storage assumptions from the receiver side.

Since Arista EOS returns single element of leaf-list unparsed as full string, it safe to assume some operator might be using this. From a backward compatibility perspective, can we make args a union though?

Well to be fair, you are complying to the data type, just not the description as it is defined today.

I don't think we need the complexity of a union at all here - esp. for a piece of data that is imo mostly going to take up resources w/ potentially not much usage.

If we update the description to comply to EOS current behavior, it negates the necessity of a leaf-list.

If we change this to a singleton leaf, it would be backwards incompatible but EOS could marshal the same as the leaf-list element today.

I'd be curious if there are any other current implementations out there and current behavior.

And is arg parsing really necessary here to be the responsibility of the element publishing the data?

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 4c888d1