Adding upstream version 1.34.4.
Signed-off-by: Daniel Baumann <daniel@debian.org>
This commit is contained in:
parent
e393c3af3f
commit
4978089aab
4963 changed files with 677545 additions and 0 deletions
|
@ -0,0 +1,162 @@
|
|||
module openconfig-platform {
|
||||
|
||||
yang-version "1";
|
||||
|
||||
// namespace
|
||||
namespace "http://openconfig.net/yang/platform";
|
||||
|
||||
prefix "oc-platform";
|
||||
|
||||
import openconfig-platform-types { prefix oc-platform-types; }
|
||||
import openconfig-extensions { prefix oc-ext; }
|
||||
import openconfig-alarm-types { prefix oc-alarm-types; }
|
||||
|
||||
// meta
|
||||
organization "OpenConfig working group";
|
||||
|
||||
contact
|
||||
"OpenConfig working group
|
||||
www.openconfig.net";
|
||||
|
||||
description
|
||||
"This module defines a data model for representing a system
|
||||
component inventory, which can include hardware or software
|
||||
elements arranged in an arbitrary structure. The primary
|
||||
relationship supported by the model is containment, e.g.,
|
||||
components containing subcomponents.
|
||||
|
||||
It is expected that this model reflects every field replacable
|
||||
unit on the device at a minimum (i.e., additional information
|
||||
may be supplied about non-replacable components).
|
||||
|
||||
Every element in the inventory is termed a 'component' with each
|
||||
component expected to have a unique name and type, and optionally
|
||||
a unique system-assigned identifier and FRU number. The
|
||||
uniqueness is guaranteed by the system within the device.
|
||||
|
||||
Components may have properties defined by the system that are
|
||||
modeled as a list of key-value pairs. These may or may not be
|
||||
user-configurable. The model provides a flag for the system
|
||||
to optionally indicate which properties are user configurable.
|
||||
|
||||
Each component also has a list of 'subcomponents' which are
|
||||
references to other components. Appearance in a list of
|
||||
subcomponents indicates a containment relationship as described
|
||||
above. For example, a linecard component may have a list of
|
||||
references to port components that reside on the linecard.
|
||||
|
||||
This schema is generic to allow devices to express their own
|
||||
platform-specific structure. It may be augmented by additional
|
||||
component type-specific schemas that provide a common structure
|
||||
for well-known component types. In these cases, the system is
|
||||
expected to populate the common component schema, and may
|
||||
optionally also represent the component and its properties in the
|
||||
generic structure.
|
||||
|
||||
The properties for each component may include dynamic values,
|
||||
e.g., in the 'state' part of the schema. For example, a CPU
|
||||
component may report its utilization, temperature, or other
|
||||
physical properties. The intent is to capture all platform-
|
||||
specific physical data in one location, including inventory
|
||||
(presence or absence of a component) and state (physical
|
||||
attributes or status).";
|
||||
|
||||
oc-ext:openconfig-version "0.24.0";
|
||||
|
||||
// OpenConfig specific extensions for module metadata.
|
||||
oc-ext:regexp-posix;
|
||||
oc-ext:catalog-organization "openconfig";
|
||||
oc-ext:origin "openconfig";
|
||||
|
||||
// grouping statements
|
||||
|
||||
grouping platform-component-temp-alarm-state {
|
||||
description
|
||||
"Temperature alarm data for platform components";
|
||||
|
||||
// TODO(aashaikh): consider if these leaves could be in a
|
||||
// reusable grouping (not temperature-specific); threshold
|
||||
// may always need to be units specific.
|
||||
|
||||
leaf alarm-status {
|
||||
type boolean;
|
||||
description
|
||||
"A value of true indicates the alarm has been raised or
|
||||
asserted. The value should be false when the alarm is
|
||||
cleared.";
|
||||
}
|
||||
|
||||
leaf alarm-threshold {
|
||||
type uint32;
|
||||
description
|
||||
"The threshold value that was crossed for this alarm.";
|
||||
}
|
||||
|
||||
leaf alarm-severity {
|
||||
type identityref {
|
||||
base oc-alarm-types:OPENCONFIG_ALARM_SEVERITY;
|
||||
}
|
||||
description
|
||||
"The severity of the current alarm.";
|
||||
}
|
||||
}
|
||||
|
||||
grouping platform-component-temp-state {
|
||||
description
|
||||
"Temperature state data for device components";
|
||||
|
||||
container temperature {
|
||||
description
|
||||
"Temperature in degrees Celsius of the component. Values include
|
||||
the instantaneous, average, minimum, and maximum statistics. If
|
||||
avg/min/max statistics are not supported, the target is expected
|
||||
to just supply the instant value";
|
||||
|
||||
uses oc-platform-types:avg-min-max-instant-stats-precision1-celsius;
|
||||
uses platform-component-temp-alarm-state;
|
||||
}
|
||||
}
|
||||
|
||||
grouping platform-component-top {
|
||||
description
|
||||
"Top-level grouping for components in the device inventory";
|
||||
|
||||
container components {
|
||||
description
|
||||
"Enclosing container for the components in the system.";
|
||||
|
||||
list component {
|
||||
key "name";
|
||||
description
|
||||
"List of components, keyed by component name.";
|
||||
|
||||
leaf name {
|
||||
type leafref {
|
||||
path "../config/name";
|
||||
}
|
||||
description
|
||||
"References the component name";
|
||||
}
|
||||
|
||||
container state {
|
||||
config false;
|
||||
|
||||
description
|
||||
"Operational state data for each component";
|
||||
|
||||
uses platform-component-temp-state;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
// data definition statements
|
||||
|
||||
uses platform-component-top;
|
||||
|
||||
|
||||
// augments
|
||||
|
||||
|
||||
}
|
Loading…
Add table
Add a link
Reference in a new issue