►
From YouTube: SIG Node Sidecar WG 2023-09-05
Description
Meeting notes and agenda: https://docs.google.com/document/d/1E1guvFJ5KBQIGcjCrQqFywU9_cBQHRtHvjuqcVbCXvU/edit#heading=h.m8xoiv5t6qma
GMT20230905-160425_Recording_1920x1018.mp4
B
Oh,
it's
signal
outside
car
working
group
today
is
September
5th
2023
welcome
everybody,
so
we
have.
A
B
A
Well,
if
you
you
can
you
can
present
it's
just
I
took
notes
last
week
and
when
I
read
them
this
morning,
I
said:
oh,
my
God.
What
did
we
say
again?
A
It
was
a
bit
confusing,
so
I
I've
wrote
something
in
the
cap,
but
before
showing
it
to
to
Joe
I
I
wanted
just
to
discuss
between
us
to
make
sure
that
I
I,
understood
and
then
Todd
kindly
made
a
drawing
to
explain
because
it's
probably
easier
than
words.
So
thank
you.
Ted.
A
So
yeah,
so
do
you
remember
so?
Last
week
we
spoke
about
termination
and
how
to
ensure
we,
we
give
a
little
bit
more
time
for
the
the
logging
sidecars
to
flush
and
everything.
So
it
was
about
how
to
signal
that
we
are
going
to
exit
and
how,
when
everything.
A
Yes,
so
the
first
drawing
is
the
first
option
that
I
think
we
we
said
last
week.
Is
we
don't
change
anything
regarding
the
pre-stop
hooks?
B
A
So
here
what
we
said
is
that
it's
pretty
intuitive,
but
there
is
like
one
drawback,
is
that
if
SC1
or
SC2
is
a
login
container,
they
will
have
like
less
time
to
to
flush
the
the
buffers
because
and
and
they
cannot
really
rely
on
the
pre-stop
hook,
because
the
free
stop
hook
means
everybody
got
a
crystal
book.
We
don't
know
when
the
containers
actually
got
their
sick
terms
to
stop
logging.
A
So
that's
the
main
difference
with
the
second
option
is
where
we
we
keep
the
seek
terms,
as
as
it
is
it's
just
that
we
start
the
pre-stop
books
when
the
containers
got
their
symptoms
and
and
I'm
not
sure.
If
this
is
what
we
said
last
time.
B
B
It
was
my
understanding
that,
like
if
you
implement
pre-stop,
you
don't
need
to
react
on
sick
term
any
longer.
Unless
you
want
to
work
past
the
pre-stop
hook.
D
D
B
D
C
So
I'm
hacking
on
this
diagram
one
more
time,
because
you
sort
of
realize
that,
like
all
these
are
at
least
the
two
that
I
drew
were
sort
of,
assuming
that
the
container
works
well
and
basically
that
it
does
get
the
Sig
like
I,
wasn't
I
didn't
draw
something
assuming
that
the
container
required
a
sick
kill.
Basically
a
Sig
term
container
ignores
it
just
keeps
going
on
right
and
I
think
there
was
a
big
difference
in
that
case,
when
the
second
one,
obviously.
A
I,
don't
think
it
does
I
I
think
when
I
remember
what
we
said
last
week,
it
was
like,
but
oh
yeah,
it's
only
in
my
my
brain,
so
I'm
not
even
sure
that
that's
what
we
said
is
do
we
want
to
to
to
to
modify
the
pre-stop
hook
for
the
sidecars
or
do
we
keep
it
as
it
is
today,
and
the
reasoning
was
to
give
a
little
bit
more
time
for
the
login
containers
but
yeah
then.
B
Yeah
I
do
think
we
tried
optimize
for
is
first,
is
to
start
determinating
as
soon
as
possible,
and
second
is
make
sure
that
we
have
a
signal
when
all
the
containers
are
done,
so
we
can
terminate
no
longer
than
all
other
containers
so
like
for
something
else.
You
need
to
do
as
soon
as
possible.
For
others,
you
need
to
do
no
longer
than
other
containers
so
to
satisfy
both
I.
Think
first
picture
was
oh
okay.
Let's.
B
Yeah,
okay,
so
first
picture
it
was
better
well
first,
so
you
can
have
more
time
to
clear
your
previous
buffers
and
such
and
second
is
better.
Like
and
yeah.
You
still
get
a
sick
term
whenever
are
done
in
this
case,
you
may
have
very
little
time
to
you
know,
clears
up
woofers.
A
Yes,
but
but
the
the
thing
that
we
had
with
the
first
one,
the
issue
is
that
if,
if
we
just
put
the
pre-stop
as
it
is
today,
that's
what
we
said,
we
are
not
sure
that
the
other
containers
will
stop
logging
when
the
Free
Stuff
book
starts
so
I
mean,
but
maybe
I'm
wrong.
Maybe
the
the
first
one
is
the
one
we
want
and
it's
easier
and.
A
Go
so
that
so
that's
the
fourth
option:
that's
the
the
the
bottom
one
right,
so
the
containers
get
the
sick
term
and
and
at
the
same,
just
after
that,
we
start
the
free
stock
book.
D
C
The
second
diagram
I
just
drew
that,
assuming
that,
like
assume,
you
see
one
of
your
C2
just
ignore
the
Sig
term
and
everything
gets
killed
at
the
very
end
of
the
grace
period.
And
I
wanted
to
look
at
that
see
if
there's
like.
C
Is
there
really
a
difference
in
that
case,
because
the
other
one,
a
diagram,
assumes
that
everyone
behaves
nicely
gets
a
Sig
term
shuts
down
quickly
like
this
one
assumes
that
your
main
containers
just
ignore
the
sick
term
and
always
get
killed
with
a
grace
period
and
I,
don't
know
if
there's
you
get
slightly
more
time
to
flush
logs,
but
there's
really
like
it.
Just
sort
of
doesn't
behave
super
well,
but
there's
nothing.
You
can
do
really
unless
you
have
like
a
separate
grace
period.
I
think.
C
A
I
I
agree.
Also,
the
the
easiest
to
to
explain
to
people
is
that
if
you
have
a
pre-stop
book,
every
branding
container
in
the
Pod
will
will
get
it.
It's
pretty
stuff
executed
at
the
same
time,
so
now
free
step
and
then,
if,
when
C1
and
and
C2
I,
don't
know
the
last
one
that
finishes
finishes,
then
we
send
a
sick
term
to
the
last
site
card,
then
to
the
I
mean
in
reverse
order.
A
C
B
A
Wait
another
10
seconds
and
be
killed
by
basically.
C
If
you
know
you've
been
success
like
so
as
soon
as
you
get
a
pre-stop
start,
trying
to
get
everything
off
the
node
and
as
soon
as
you've
got
a
sick
term,
you
know
that
you're
not
going
to
get
any
more
logs
basically,
and
you
can
assume
that
I've
got
to
get
whatever
the
current
logs
are
off
and
I'm
good
to
go.
Then
I
can
shut
down.
B
And
for
shadow
smash,
but
he
might
just
say
any
Commendation
I
mean
ignore.
Please
stop
and
then
one
six
term
hits
just
stop
it.
A
I
think
it's
just
it's
just
for
the
logging,
one
that
you
implement
a
pre-stop
and
it
should
not
return
right,
because
if
it
returns,
we
might
get
a
sick
term,
but
that
we
could
ignore
anyway,.
B
D
A
One
and
three
here,
yeah,
okay,
so
I
will
I
will
modify
the
the
pr
for
the
enhancement
just
to
have
like
this
option
explained,
try
to
explain
it
better
and
once
I
have
something
I
will
just
ping
we'll
correct
my
English.
C
I
think
the
examples
you
gave
of
a
logging
container
and
like
a
network
proxy
of
some
sort.
Let
me
be
health
help
people
really
understand
like
how
you
could
actually
use
this
Implement
free
stuff.
I,
get
lots
of
notes
to
try
to
hurry
up
and
get
things
off
disk
or
off.
The
node
term
means
I
can
assume.
Nothing
else
is
going
to
log.
That
was
in
front
of
me
basically
and
for
networks
you
just
don't
care
whatever.
C
D
A
Yeah,
I
I,
don't
think
it's
an
issue
frankly,
because
if,
if
you
wanted
to
get
notified,
you
have
the
pre-stop
hook
and
then.
D
A
C
D
A
A
Okay,
that's
why
we
we
try
to
find
ways
around
it
with
the
existing.
C
You
think
we're
worried
about
the
basically
trying
to
get
another
API
change.
Yeah.
B
A
But
again
again,
if,
if
during
the
pr
review,
that's
what
Joe
wants,
because
he
wrote
the
document
like
suggesting
an
API
change,
we
will
see
and
also
if
we
get
to
Beta,
it
can
still
change
before
we
go
to
GA
right.
B
And
it's
really
an
interesting
question:
what
like,
if
you
introduce
any
side
of
ordering
or
extended
grace
period,
how
much
it
matter
for
customers
like
how
much
it
matter
for
customers
what
they
will
prioritize
like
faster
determination
with
a
little
bit
of
lost
traffic
or
a
longer
termination
with
more
reliability,
guarantee
I.
Think
more
people
will
be
fine
to
poseid
cars,
not
to
terminating
orders
and
extend
every
determination
to
like
10
more
seconds
or
like
20
more
seconds.
D
D
A
Okay,
I
will
probably
tomorrow
morning,
I
will
like
write
it
when
just
after
coffee
and
then
like.
A
A
A
feedback
from
from
you
and
then
I
will
tag
Joe
in
the
pr.
B
Thanks:
okay,
don't
talk
about
regression.
B
Off
no
it's
on
Friday
right
passion
is
on
Friday,
but
we
really
need
to
get
it
soon.
Okay,.
B
So
this
is
a
default
here
that
the
initial
PR
right-
what
are
you
doing.
B
B
A
D
Actually,
it
doesn't
because
the
first
PR
is
just
wrapping
the
the
cycle
container
logic
with
feature
gate,
so
we
don't
need
that
E3
test
phosphorus
cycle
container
need
to
test.
We
need
that.
B
Wait
so
this
one
is
what
actual
fix
right.
Yes,
this.
A
A
Yeah,
that's
that's
a
different
discussion,
it's
something
that
was
an
expected
Behavior
long
time
ago
and
then,
like
a
team,
brought
it
again
like
at
the
beginning
of
the
week.
No
during
the
weekend
and
say:
okay,
it's
some
refactoring,
maybe
I
don't
know
if
we
can
do
this
one
before
or
after
the
site
card
yeah,
but
we
can
discuss
this
later.
Can
you
just
check
the
the
one
that
I
sent
in
the
chat
yeah
in
the
zoom
chat
or
I
can
send
in
our
chat?
B
D
D
A
Yeah
and
since
Sergey
has
a
full.
A
D
A
D
B
Okay,
yeah,
have
anybody
reviewed
this
fix,
I
think
I'm?
Okay,
with
that
I
just
want
to
make
sure
anybody
else
has
opinion.
B
B
B
But
he
needs
some
like
push.
Okay,
we
need
to
tell
him
that
this
is
fine
and
very
good,
and
thank
you
very
much
for
posting
this
comparison
with
127..
It's
really
a
couple
okay,
so
this
is
I
just
you
posted
it
here
because
of
a
started
field,
moving
to
different
place
right.
A
It's
much
like
it's
more
like
a
discussion
with
you.
Do
we
want
to
change
this
as
well,
while
going
beta
and
or
are
we
just
like,
take
an
excuse
and
and
push
it
back
to
130
or.
B
No
there
is,
there
is
many
fix.
Many
things
that
want
this
changed
like
sidecar
is
only
related
to
that
because
of
same
logic
that
it
touches
in
in
terms
of
Readiness
probes.
We
also
have
a
new
API,
like
local
API
for
Google,
that
somebody
wants
to
implement
that
will
report
Readiness
locally,
and
it
also
wants
to
change
this
logic
to
like
clean
up
this
logic.
B
A
little
bit
otherwise
like
local
API,
will
also
return
some
inconsistent
data
and
we
want
some
consistency,
so
yeah
I,
don't
think
it's
strictly
related
and
I
think
it
can
be
done
with
smaller,
like
it
doesn't
require
all
the
refactoring.
Maybe
it
will
require
a
little
bit
of
change.
B
B
Let's
see
how
it
goes,
you
know
I
also
forgot
to
add
to
agenda
I
looked
at
what
is
HPA
like
scalar
and
VP
last
week,
I
was
having
some
customer
issues,
and
this
HPI
has
a
logic
that
excludes
all
the
unique
containers
from
calculations.
B
So
when
we
calculate
like
it,
has
its
own
for
Loop
to
understand
how
much
container
it
takes
and
it
they
takes
from
container
status,
not
from
like
regular
containers,
so
that
may
need
testing
at
least
and
I'm,
not
sure
if
it
will
need
a
change
as
well.
C
Yeah
I
thought
I
saw
an
issue
that
someone
wrote
against
the
auto
scaler
for
it
like
they're
the
same
problem,
I'm
guessing
with
vertical
Auto
scale
or
vertical
pause
they're
in
place.
Yeah.
B
And
I
think
they
calculate
usage
rather
than
requests,
so
they
they
need
to
know
you
actual
usage
and
usage,
is
calculated
through
a
c
advisor
then
go
through
the
status
like
start
summary,
or
maybe
some
some
other
endpoint,
but
that's
basically
a
problem
like
we.
This
Loop
is
different
because
it
looks
at
usage
rather
than
on
actual
requests
and
image
that
we
changed.
It's
quite
like.
B
B
B
Okay,
anything
else
for
today.