►
From YouTube: SONiC DASH Workgroup Community Meeting Mar 1 2023
Description
Nvidia (Oleksandr Ivanstiv aka Sasha) would like to present HLD:
SONiC Repo PR1265 CRM HLD Add DASH Resources - https://github.com/sonic-net/SONiC/pull/1265
PR289 - Still needs volunteer - Dockerfile.saithrift-client has a static tag in the FROM instruction
Please see full notes in email
A
A
Last
week
on
the
22nd,
we
had
a
PR
336,
332,
333,
296
and
341,
and
this
one
in
particular
Prince
was
talking
about
service
tunnel,
private
link
and
these
examples
he
had
put
into
the
Sonic
hld
I
sent
these
out
in
the
meeting
notes,
and
it's
also
in
the
document,
and
then
we
also
had
346
supply
of
Vladimir
and
then
this
week,
I
understood
from
Prince
that
Nvidia
wanted
to
present
1265
from
the
Sonic
repo.
Is
that
correct,
Prince.
B
A
A
D
B
So
this
is
actually
the
update
of
the
existing
documents
that
we
have
in
Sonic,
because
the
feature
itself
is
already
implemented
in
Sonic
and
it
is
used
for
the
let's
say,
getting
information
about
the
Legacy
Sonic
resources
and
we
are
going
to
add
that
specific
objects
to
the
existing
implementation.
But
what
is
worth
noting
that
we
are
not
changing
any
flows,
so
the
exist.
The
implementation
and
all
the
flows
of
the
CRM
will
remain
the
same
as
it
is
right
now
in
Sonic,
so
yeah.
B
A
C
B
If
there
are
any
of
resources
that
exceed
defined
in
the
threshold
and
CLI
comma,
we
should
have
a
CLI
command
that
allows
us
to
check
the
current
user
user
usage
of
the
available
of
and
availability
of
the
monitored
resources
so
basically
feature
allow
us
to
get
the
available
resources
from
the
PSI
and
from
the
hardware,
and
it
also
is
responsible
for
counting
the
used
resources
inside
the
Sonic.
So
the
PSI
itself
provides
only
the
number
of
available
resources
and
it
is
not
responsible
for
like
accounting
of
the
used
resources.
B
So
this
is
responsibility
of
the
Sonic.
So
in
a
legacy
Sonic
we
have
different
different
type
of
resources.
It's
like
routes
next
up,
Neighbors
next
hope,
group
members,
alcohols,
FDB
and
I
think
that
there
are
a
couple
of
more
resources
that
we
are
monitoring
in
Sonic,
but
they
are
not
part
of
this
document,
so
the
document
wasn't
updated
and
for
the
dash
we
are
going
to
add
Vienna
v-net
eni
eni,
as
our
net
address
inbound
routes,
outbound
routes,
c2b,
APA
validation,
SL
groups
and
ICL
rules.
B
Let's
go
quickly
over
the
monitoring
process
requirements,
so
the
monitoring
process
should
periodically
pulsai
counters
for
all
required
resources.
Then
it
should
check
whether
a
retrieved
values
exceeds
the
defined
thresholds
and
log
appropriate
slot
message.
The
user
should
be
able
to
configure
low
and
high
thresholds.
The
user
should
be
able
to
configure
thresholds
in
the
form
of
following
formats,
so
we
can
configure
the
percentage
or
actual
used
account
or
actual
free
counts,
and
by
default
the
thresholds
are
configurating
percentage.
B
Serum
feature
should
lock
the
slog
message.
If
there
are
any
resources
that
exceeds
lower
high
thresholds,
ceram
should
support
two
type
of
slog
messages.
The
first
one
is
exceeded
for
the
high
threshold
and
the
second
one
is
clear
for
the
love
potential.
So
slot
messages
should
be
in
the
following
format,
so
the
format
we
have
warning
threshold
exceeded
for
the
high
threshold
threshold,
type
use
count
and
free
count
and
the
same
Porsche,
clear,
threshold
threshold
type
is
just
count
and
three
count
and
the
good
threshold
type
can
be
in
percentage
used
or
free.
B
The
default
polling
interval
should
be
set
to
five
minutes
default.
High
threshold
should
be
set
to
85
percent
and
default.
Low
threshold
should
be
set
to
80
70.
So
it's
the
same
for
dash
CRM
features
should
suppress
the
slot
message
after
printing
them
10
times
up
to
not
like
overflow
of
this
log
was
the
same
messages,
so
it
will
stop
printing
ten
times.
C
Yeah
I
think,
basically,
this
is
a
feature
already
there
in
Sonic,
and
it
is
this
frequent
monitoring
of
these
resources
and
also
throwing
these
alert
messages
with
which
we
can
identify
if
any
resources
exceeding
some
thresholds
and
those
things
so
so,
I
think
this
is
basically
adding
on
top
of
the
existing
feature.
The
new
objects
right,
like
the
new
Dash
yeah.
B
B
They
are,
they
are
configurable.
They,
the
default
values,
are
set
to
85
and
70
percentage,
but
there
is
a
CLI.
It
is
possible
to
configure
it
through
directly
with
sort
of
Json
file
through
config
DB,
or
there
is
a
CLI
that
allows
to
configure
the
polling
interval,
the
threshold,
the
threshold
types
for
each
individual
resource
or
for
all
resources.
B
Okay,
so
let's
let's
go
over
what
we
are
adding
here
for
the
dash,
so
we
have
a
configuration
DB
and
in
configuration
DB,
we
have
a
CRM
table.
This
table
contains
nipple
link
interval
and
the
configuration
for
the
each
resource,
the
configuration
of
the
threshold
type,
the
configuration
of
load
threshold
and
the
configuration
of
high
threshold,
and
basically,
we
have
the
exactly
the
same
for
the
dash.
So
we
have
for
each
Dash
object
that
we
support.
B
C
C
B
B
We
have
a
statistic
for
the
dash
we
have
the
v-net
used
available,
so
basically
each
gun
each
counter
for
each
object.
We
have
three
counters,
we
have
available.
We
have
two
countries
available
and
used
and
for
each
Dash
object.
We
have
two
of
those
counters
I
think
the
same
way
as
we
have
for
for
the
Legacy
objects
so,
and
we
have
additional
table
that
contains
Dash
ICL
group
stats
and
in
this
Dash
SL
group
Stars.
We
have
the
rules
used
and
available
per
each
Dash
SL
group
and
brings
regarding
the.
B
C
B
Okay,
so
the
orchestration
agent
implementation,
so
we
basically
just
went
over
the
requirements
of
inside
the
occasions.
We
have
serum
or
class
that
implements
all
the
logic
and
it
is
responsible
for
querying
the
resources,
accounting,
the
used
resources
and
for
the
like,
sending
messages
to
this
lock
when
the
threshold
is
exceeded.
B
Of
you,
we
have
the
following
mapping
from
the
CRM
resources
to
design
objects.
We
have
dark
green
it
and
we
have
dachi
and
I.
We
have
as
an
Ethernet
address
inbound
routes,
IPA
validation,
outbound,
c2p,
ICL
group
and
I
sell
rules
from
sell
I
point
of
view
from
select
point
of
view.
So
we
are
going
to
reuse
the
same
utility
for
the
dash.
We
are
not
going
to
implement
new
ones,
so
everything
will
be
in
one
place,
so
we
can
configure
the
pollen
interval.
B
We
can
configure
threshold
for
a
type
and
pile
of
value
for
all
resources
at
once
and
we
can
configure
the
thresholds
per
individual
resource
so
and
we
have
also
show
a
command
shop
utility
and
this
utility
can
print
the
summary
in
which
it
will
display
the
polling
interval
and
it's
going
to
show
information
about
resources.
It
will.
This
comment
will
print
the
information
about
used
and
available
resources
and
it
can
bring
the
configured
thresholds
and
in
context
of
Dash,
so
we
are
going
to
extend
the
utility
with
the
following
commands
for
each
Dash
object.
B
We
are
going
to
implement,
take
the
command
that
will
allow
us
to
configure
the
threshold
like
the
type
and
low
and
high
value,
and
also
we
are
going
to
implement
the
stove,
extend
the
Shelf
utility
and
we
will
be
able
to
print
the
information
about
Dash
resources
about
and
about
the
configured
thresholds.
What
is
worth
noting
here
that,
at
the
dash
commands,
I
will
be
available
only
on
the
devices
with
switch
type
GPU
yeah.
B
So
we
are
not
going
to
confuse
the
switch
Sonic
users
and
we
are
not
going
to
show
the
those
commands
there,
so
they
will
be
available
only
under
the
dpu
and
regarding
the
Legacy
resources
configuration
in
the
dpu,
so
they
they
are
not
required
so
for
the
vendors
are
not
required
to
implement
the
PSI
API
for
all
those
objects,
so
the
CRM
or
agent.
On
the
start,
we'll
ask
the
site
about
supported.
B
C
B
C
B
Are
not
going
to
block
the
CRM,
will
query
the
resource
at
the
initialization
and,
if
say,
returns,
not
supported
for
some
of
the
resources
one
or
more.
It
will
not
try
to
query
it
in
the
runtime,
so
there
is
no
point
to
query
the
resources
that
are
not
supported,
yeah,
so
yeah.
This
is
completely
up
to
the
vendor
implementation
and
which
resource
should
be
supported
and
visual.
B
Config
utility
Syntax
for
dash,
API
and
dash
attributes,
we
have
show
utility
syntax
and
here
and
what
is
also
we
are
going
to
extend,
is
Young
model,
as
of
in
general,
though,
or
the
CRM
in
the
Sonic
is
the
following.
So
we
have
the
definition
of
the
types.
So
we
have
threshold
type
for
the
threshold.
We
have
a
type
for
the
pulling
interval
and
for
each
Legacy
resource
that
we
have
in
the
Sonic.
We
have
the
following
as
schemas
so
for
each
resource.
B
We
have
the
threshold
type,
we
have
by
threshold
and
load
threshold,
and
this
is
going
to
be
remaining
without
changes.
So
what
we
are
going
to
do
for
the
dash
so
for
the
dash
threshold
for
the
dash
resources.
We
all
also
want
to
like
allow
to
get
the
art
model
to
pass
the
thresholds
only
if
the
Sonic
is
running
on
the
dpu.
B
So
in
the
young
model
we
are
going
to
check
the
switch
type
on
which
we
are
running
and
if
the
switch
type
is
not
dpu,
so
we
are
not
going
to
allow
to
configure
the
thresholds
for
the
for
the
dash.
So
this
is
the
the
main
difference
yeah,
and
this
is
basically
it.
So
we
have
a
float
definition
here.
B
If
you
want,
we
can
go
overflows
that
we
have
in
Sonic,
but
in
general
we
already
discussed
it
this.
So
we
have
the
configuration
DB
and
we
have
the
sum
of
the
resource,
so
we
can
take
as
an
example.
The
vnis
of
the
vni
is
created
in
with
the
dash.
It
will
be,
not
the
configuration
DB,
it
will
be
application
to
be,
but
the
logic
inside
the
application
is
the
same.
So
we
have
configurations
that
is
pushed
into
the
database.
We
are
going
to
receive
the
notification
inside
that
work.
B
B
If,
yes,
then
we
will
send
a
clear
message
into
syslog
check
if
the
use
counter
exceed
exceeds
a
high
threshold,
and
then
we
will
send
the
log
message
to
syslog,
but
we
will
increase
a
counter
of
logging
message
to
track
if
we
are
less
as
we
printed
less
than
that,
10
messages
into
says.
Log
and
I
will
basically
sleep
for
the
polling
interval
them
out
to
before
the
next
iteration.
B
Okay,
so
we
can
go
over
quickly
over
the
CRM
select
config,
so
we
have
a
user
as
an
actor
user
is
going
to
implement
this
Li
command
and
we
will
call
appropriate
a
Sonic
utilities
script
from
the
Sonic
utility
script.
We
will
parse
the
the
command.
We
will
process
the
data
and
modify
appropriate
attribute
in
the
config
DB
and
will
modify
work
agent
about
the
change
and
work
agent
will
consume
the
change
at
configuration
and
updates
it.
Instead,
it
into
its
internal
state
yeah
and
we
have-
and
we
have
a
serum
SLI
show.
B
So
again,
the
user
is
as
an
actor
executes.
The
show
command
select
is
calling
appropriate
some
utilities
script
and
from
this
script
we
are
going
to
get
the
thresholds
configuration
if
it
is
needed
and
or
we
are
going
to
get
the
counters
from
the
counters
database
if
it
is
needed,
format
an
output
and
displays
this
output
to
the
user
from
the
testing
requirements.
Point
of
view.
B
E
B
So
token,
in
general,
so
this
will
be
to
verify
serum
config
config
commands
per
each
config
comment
that
we
have
to
verify
the
that
we
can
change
the
type
low
and
high
thresholds
and
verify
that
show.
Commands
displayed
the
correct
values
for
the
threshold
and
for
the
resources,
and
we
also
going
to
extend
virtual
switch
tests.
B
So
far
on
top
of
the
existing
test,
we
will
implement
the
new
test
for
the
Dasher
sources
and
again
we
are
going
to
reuse
the
the
same
test
cases
that
are
implemented
for
the
existing
Legacy
resources.
So
in
general
the
Tesla
will
be
the
following
to
configure
the
threshold
to
create
Dash
entries
in
the
application
DB
to
exceed
the
high
threshold
verifies
that
the
threshold
exceeded
message
is
written
to
syslog
verifies
that
threshold
used
counter
from
this
slot
message
matches
the
created
entries
a
remote
Dash
entries
to
follow
both
the
load
threshold
verifies
that
threshold.
B
Clear
message
is
written
into
syslog
and
verifies
that
the
used
counter
from
this
slot
message
matches
the
created
entries
and
from
system.
In
this
case.
This
case
is
points
of
you
from
Sonic
management
test
point
of
view.
We
again
going
to
extend
the
existing
test
cases.
We
are
going
to
reduce
the
existing
test
cases
and
extend
them
to
cover
the
dash
resources,
but
the
same
methodology
will
be
used
for
the
Dutch
resources,
as
we
have
for
the
Legacy
objects
director.
F
Also
I
have
one
general
question:
is
it
common
to
use
Dash
work
for
Dodge
specific
commands
in
Sonic
I
mean
for
all
stuff
that
we
had
add
for
dash,
because
don't
you
understand
I'm
guessing
that
some
CRM
resources,
which
is
valid
for
Asic
I,
mean
for
switching
silicon,
will
be
valid
for
dash
case
as
well?
No.
B
So
we
are
trying
to
group
all
of
them,
so
all
the
resources
that
are
coming
from
Dash
extension
hidraphile
inside
I
will
be
covered
under
dash
subgroup
inside
the
CLI
utilities
inside
the
config
and
show
utilities
and
I.
Don't
think
that
those
resources
might
be
reused
in
the
switch
in
some
way.
So
they
are
only
dpu
specific.
F
B
So,
first
of
all,
all
these
resources,
all
the
Legacy
resources
are,
let's
say
optional
for
INS
in
the
dpu,
because
so
we
are
not
going
to
configure,
for
example,
the
Legacy
resources,
and
this
is
what
the
Legacy
ICL
resources,
and
this
is
why
we
separated
them
into
two
different
groups.
So
we
have
like
the
Legacy
ICL
that
we
use
in
the
switch,
and
here
we
have
Dash
ICL,
which
are
completely
different.
Icl
resources
and
completely
different
apps
ICL
objects.
B
So
we
intentionally
intentionally
moved
them
into
a
separate
group
and
for
example,
if
we
take
from
the
let's
say
road
or
neighbor
point
of
view,
there
is
no
no
real
need
to
monitor
this
those
resources
inside
the
GPU
because
from
the
requirements,
what
I
understand
we
are
going
to
have
only
a
couple
of
routes.
It's
like
one
of
two
routes
and
up
to
two
neighbors
inside
the
dpu,
and
we
are
not
going
to
have
like
a
high
usage
of
those
resources.
So
they
are
here.
B
We
still
can
configure
them
if
they
are
supported
by
the
PSI
implementation
of
the
particular
vendor,
but
they
are
not
very
meaningful,
but
still
the
approach
to
configure
them
is
the
same
as
it
was
before.
So,
if
you
can
configure
any
of
these
resources
of
those
resources,
if
they
are
supported
by
the
vendor
or
you
can
still
configure
all
the
resources
at
once
on
the
dpu
and
having
all
command-
and
it
will
be,
it
will
configure
the
thresholds
for
all
the
resources
that
are
available
in
the
dpu.
D
B
E
I
I
have
a
question:
I
joined
a
little
bit
later
apologize
Alexandra.
The
question
is:
is
it
fair
to
say,
based
on
the
question,
the
previous
scholar
had
write
about
common
thresholds
versus
Dash
specific
data
types
or
object
types
thresholds
right?
Is
it
fair
to
say
over
time?
If
we
want
to
establish
more
Dash
specific
thresholds,
we
will
extend
the
the
the
CLI
to
include
Dash
and
whenever
it's
in
common
it
will
be
in
common
or
will
break
apart
or
we
will
straddle
both
I
was
I,
wasn't
very
clear
about
the
answer
we
gave.
B
B
E
B
Basically,
this
CRM
is
is
the
only
feature
right
now
that
has
some
connection
to
the
existing
Utilities
in
the
Sonic,
because
all
the
rest
functionalities
that
we
have
right
now
is
not
going
through
configuration
DB.
It
is
going
through
application,
DB
and
it
will
be
configured
by
gnmi,
and
so
the
CRM
right
now
is
the
only
feature
and
I
don't
see
any
new
features
in
the
near
future.
That
will
be
sitting
inside
the
config
DB
and
that
will
require
the
modification
of
the
existing
commands
in
the
Sonic.
G
B
So
I
I'm
going
to
paste
investing
the
link
to
the
pull
request
here
in
the
chat.
So
far
as
an
action
item,
I
have
the
question
from
Prince
about
the
alcohol
group
per
Enis,
so
I
will
check
this
question
and
I
will
update
document
if,
if
needed
so
I
think
basically
that
it
should
be
covered
and
we
should
be
able
to
provide
the
statistic
per
eni,
but
I
will
double
check
and
I
think
the
next
week
we
can
merge
this
document
and
I
also
going
to
start
working
on
the
implementation.
Swss.
D
B
Of
from
the
top
of
my
memory,
I
remember
that
we
have
the
alcohol
groups,
we
have
alcohol
rules
that
are
going
to
be
displayed
per
our
account
group.
So
because
we
we
can,
we
have
some
certain
limitation
of
how
many
rules
we
can
create
in
each
group
and
all
the
other
are
global
resources.
So
they
are
not
tied
to
anything
else.
B
B
B
G
G
There
is
a
case
where
someone
implements
routes
in
multiple
tables
where
he
and
I
actually.
So
there
is
actually
a
limit
to
to
where
you
can
add
a
route
for
one
E9,
but
you
cannot
add
a
route
for
another
dni
which
is
not
how
generally
the
stable
is
defined
and
is
supposed
to
behave
so
it
will
be
displayed
as
long
back
table.
D
So
definitely
we
don't
want
to
carve
out
the
route
table
per
eni
and
keep
that
Dynamic
for
sure.
So
what
you're
saying
is
that
if
there
is
a
when
we
cross
the
threshold
value,
it
is
the
resource
that
is
lacking
in
the
overall
table.
So
it's
okay
to
just
display
it
globally,
rather
than
Berlin
uni
yeah
I.
Think
that
sounds
okay.