Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide clarification on the field component_name #162

Merged
merged 1 commit into from
Mar 6, 2024

Conversation

nmahabaleshwar
Copy link
Contributor

@nmahabaleshwar nmahabaleshwar commented Feb 23, 2024

Provide clarification on the field component_name.

Copy link
Contributor

@morrowc morrowc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might wait on heas@ to have a look at this.

@haussli
Copy link
Contributor

haussli commented Feb 24, 2024

LGTM. I would add another eg for clarity; eg: component_name: chassis0/linecard0

@nmahabaleshwar
Copy link
Contributor Author

LGTM. I would add another eg for clarity; eg: component_name: chassis0/linecard0

Added another example as suggested

@LimeHat
Copy link

LimeHat commented Feb 24, 2024

Can you elaborate a bit on how it is supposed to be used / what is the purpose of the field? In what cases, for example, linecard0 component is used?

I would imagine that in most cases, accounting records are generated by control modules (in chassis-based systems) or a control module equivalent in a fixed system. Does it mean that the chassis returns the name of the active control module (at the time when the record was created)?

@nmahabaleshwar
Copy link
Contributor Author

Can you elaborate a bit on how it is supposed to be used / what is the purpose of the field? In what cases, for example, linecard0 component is used?

I would imagine that in most cases, accounting records are generated by control modules (in chassis-based systems) or a control module equivalent in a fixed system. Does it mean that the chassis returns the name of the active control module (at the time when the record was created)?

This is field is useful in a system where multiple entities can generate accounting records. For example, modular systems where we can have multiple control modules, each in active/standby roles. An accounting event can happen on any component resulting in a RecordResponse message. This fields can identify from which component a RecordResponse originated from.

@LimeHat
Copy link

LimeHat commented Feb 24, 2024

Yeah, it is more or less clear with the control modules.
What would constitute an accounting event on a line card? Is it for systems that allow users to directly connect to each line card (e.g. the linecard has a management IP, etc)?

@haussli
Copy link
Contributor

haussli commented Feb 25, 2024

Some systems have redundant routing engines, multiple chassis with their own routing engines/control cards, and some have a linecards/cards in general that have a cli accessible in-line or from a serial port. It is reasonable to expect that these cards might log/account these activites. This field allows the origin or the records to be identified, which I would expect to be platform/vendor specific. eg: (WAGs)
fpc0
chassis1/fpc0
re0
re1
chassis1/re1
0/RP0/CPU0

acctz/acctz.proto Outdated Show resolved Hide resolved
@morrowc morrowc merged commit 0e73fed into openconfig:main Mar 6, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants