►
From YouTube: SIG Node Sidecar WG 2023-01-17
Description
Meeting notes and agenda: https://docs.google.com/document/d/1E1guvFJ5KBQIGcjCrQqFywU9_cBQHRtHvjuqcVbCXvU/edit#heading=h.m8xoiv5t6qma
GMT20230117-170624_Recording_1302x1120
A
Hello,
hello,
it's
January,
17
2023,
it's
a
signaled,
sidecar
working
group
meeting.
Welcome
everybody
I
think
today's
agenda
will
be
quite
short
unless
we'll
stumble
across
some
discussions.
A
So
I
wanted
to
start
discussing
like
we
have
a
cap
document.
I
think
it's
almost
complete.
The
only
questionable
part
at
this
moment
is
whether
we
support
other
types
of
restart
policies
on
containers.
So
there
are
basically
two
questions.
First
question
is
whether
we
support
restart
policy
on
regular
containers,
not
just
init
containers
and
because
container
definition
is
currently
shared.
A
So
if
you
add
restart
policy
for
each
containers,
they
will
almost
automatically
be
on
regular
containers
as
well,
unless
we
do
some
magic
or
some
like
big
refactoring,
yeah
and
second
question
is:
if
you
reduce
the
restart
policy,
always
for
any
containers,
do
we
need
to
restart
to
introduce
any
other
restart
policies,
or
we
just
private
people
specifying
those
and
yeah?
There
is
some
discussion
in
the
comments
on
this
document.
A
Unfortunately,
like
I
only
added
my
comments
yesterday,
I
was
thinking
about
it
for
a
long
time
and
I
was
trying
to
wrap
my
head
around
like
how
much
we
need
to
invest
into
that
now,
how
much
it
will
be
future
proof
and
whether
you'll
need
it
to
whether
we
need
to
have
it
in
the
future.
So
let's
have
a
discussion
open.
A
First,
let's
maybe
discuss
start
with
restart
policy,
never
in
on
failure
for
unit
containers,
so
today's
behavior
is
yeah.
I
put
it
here,
you
need
containers
will
inherit
a
restart
policy
of
pod,
but
for
always
there
will
be
on
failure
instead
of
always
because
it
is
not
always
for
any
containers.
I
mean
it's
kind
of
yeah.
So
when
both
when
there
is
a
job
like
Port,
is
a
job
that
has
a
result
policy,
never
the
failure
of
a
new
container
he'll
fail
the
entire
port.
A
If
container
reports
which
fires
that
it's
always
running
so
it's
always,
then
we
will
keep
retrying
the
need
containers
forever.
Unless
it
will
succeed,
that's
the
current
behavior
and
it's
introducing
of
always.
We
have.
We
stumble
into
the
citizen
situation
this.
All
this
behavior
is
not
inherited
from
always
of
Port,
so
when
Port
is
defined
as
always,
standard
in
your
containers
are
still
defined
as
on
failure.
So
it's
not
it's.
It's
different
behaviors
and
regular
pods
and
regular
containers.
A
Those
some
incompatibility
so
like
I,
think
Joe.
Roses
are
here
so
that
semantic
differences
between
always
and
always
for
regular
containers
and
always
for
init
containers.
They're
not
inheritable
from
Port
restart
policy
and,
secondly,
yeah
so
there's
a
difference,
and
then
there
is
a
difference.
What
does
never
a
non-failor
mean
in
in
terms
of
the
containers
like?
Do
we
ever
want?
Never,
for
always
odd,
so
do
you
all?
Do
we
ever
want
to
pause
that
was
designed
to
be
always
running
so
once
scheduled?
A
It
will
keep
retrying
and
keep
trying
to
run,
and
if
you
apply
never
to
some
init
container,
does
it
mean
that
this
internet
will
be
skipped
or
doesn't
mean
that
we
change
the
semantic
of
port
with
restart
policy,
always
meaning
that
if
pod
has
a
startup
policy,
always
you
still
have
a
failure,
condition
when
Port
will
not
will
stop
being
retried,
which
is
complicated,
I
know
how
many
of
you
followed
the
discussion
any
idea,
any
any
thoughts.
B
A
D
Right,
yeah,
the
only
I
think
this
is
a
really
good
topic.
D
It
gets
even
more
complicated
by
the
fact
that
deployments
when
layered
on
top
of
PODS
have
things
like
imposing
and
always
policy
on
the
pod,
and
so,
if
you
had
individual
containers
taking
effects
Not
only
would
you
have
to
think
about
all
the
impacts
on
pods
we'd
have
to
think
about
all
the
impacts
on
deployments,
which
is
like
I
kind
of
almost
makes
my
head
explode,
I'm
tempted
to
say
like
for
a
very
first
Alpha.
D
We
should.
We
should
commit
to
looking
at
all
these
things
if
the
if
the
enhancement
is
useful
but
I'm
really
hesitant
to
like
start
investing
in
figuring
all
this
out
when
we're
just
trying
to
like
prove
a
core
idea.
I,
don't
know
if
that
makes
sense
to
other
people,
but
that's
kind
of
how
I've
been
thinking
about
it.
A
Yeah
and
I
put
it
in
name
and
consideration
like
new
addition.
Here
we
really
I
mean
the
reason
we
started
using.
The
restart
policy
always
is
first,
it
kind
of
fits
a
definition,
kind
of
fits,
the
intent
of
this
policy
and
also
it
opens
the
door
for
this.
Futures
scenarios
like
there
are
something
else
that's
important.
A
Not
all
of
them
are
important,
but
some
like
let's
say
you
want
to
restart
the
initialization
for
jobs
that
has
a
restart
policy.
Never
so
it's
fine
to
restart
it
in
Civilization
for
the
sports,
maybe
and
expressions
that
may
be
interesting
concept,
but
so
we
opened
this
door,
but
then
the
question
is:
do
we
really
have
to
open
this
door
and
like
do
you
want
to
open
this
door,
and
is
it
future
proof,
like
other
scenarios,
will
be
really
interesting
and
important?
A
So
alternative
is
to
have
some
other
property,
like
let's
say
like
ambient
through
or
like
something
like
that.
That
will
change,
I
mean
it's
going
to
be
applied
to
both
sides
like
you
need
containers
in
regular
containers,
and
it
will
be
only
about
making
it
run
forever
and
restart
always,
but
then
don't
touch
it.
Don't
block
pod
completion,
so
just
just
Express
this
thought
with
this
new
property
and
don't
open
the
door
for
those
new
scenarios
so
well
I.
B
So
my
my
feeling
is
that
we
should
reuse
the
the
restart
policy
and
I,
don't
like
the
other
ones,
but,
as
you
said,
maybe
we
can
just
go
with
that
in
the
alpha
and
then,
if
we
have
blockers,
then
we
can
invest
more
time
in
trying
the
alternatives.
D
Yeah
I
think
there's
a
lot
of
value
in
the
cup
to
keeping
the
Alternatives
that
we
thought
of
either
in
like
an
Alternatives,
considered
section
or
somewhere
just
so
people
that
ask
this
question
again.
We
can
just
kind
of
Point
them
to
and
be
like
yeah.
No,
we
actually
didn't
think
about
that.
Here's,
the
pros
and
cons
we
listed
if
you
have
other
pros
and
cons
or
other
thoughts,
we're
happy
to
add
them
to
the
cap
and
that
kind
of
stuff,
I
think
that's
really
valuable.
D
I
feel
like
that
kind
of
keeps
us
out
of
Double
Jeopardy
for
a
lot
of
things,
but
I
I,
yeah,
I,
think
I.
Think
I'm
in
line
with
everybody
else,
I
I
realize
that
there
are.
It
does
kind
of
open
the
door
to
like
well
shouldn't
it
be
possible
for
all
containers
to
have
all
options
and
right
now
they
have
none
and
we're
gonna
make
one
and
there
might
be
others
so
I'll
probably
have
to
like
put
in
the
like
to
Beta
sections,
some
kind
of
clarity
on
like
what
we're
committing
to
add.
D
If
we
go
all
the
way,
are
we
are,
we
only
committing
to
having
always
on
a
knit
containers
and
that's
it
for
all
the
way
to
GA
for
our
feature,
or
would
we
go
a
little
bit
further?
Would
we
touch
the
main
containers,
I
kind
of
want
to
stay
away
from
the
main
containers
entirely
on
this
feature,
but
we
probably
have
to
make
some
kind
of
statement
there
on
like
if
we're
in
our
first
Alpha,
if
we're
only
going
to
support
one
value
on
one
flag
like
are
we
gonna?
A
And
you're
in
favor
of
this
property,
because
it's
easier
to
explain
or
Authority
is
there.
D
A
I
think
just
to
be
I
and
I
will
say
later,
but
this
field
can
be
applied
to
both
sides
of
containers.
It
can
be
both.
You
need
containers
than
regular
containers,
and
the
idea
would
be
that
any
container
may
be
a
sidecar
if
you
want
to
order
it
with
emit
containers,
you
put
it
there.
If
you
want
to
have
it
among
all
the
containers,
you
just
keep
it
in
regular
container
section
interesting.
D
A
This
case
yeah
they're,
saying
that
if
you
don't
I
think
if
we
have
strong
concerns
that
those
scenarios
is
restarted,
policy
per
container
are
really
hard
to
implement
in
the
future,
and
you
may
not
need
it
ever
then.
The
question
will
be
like.
If
we
will
introduce
new
field,
is
it
better
option
or
what's
the
downside
of
international
new
fields.
D
If
we
introduce
a
field
just
for
one
type
of
container,
then
I
feel
that
causes
Divergence.
Where,
like
at
that
point
like
it's
hard
to
argue
to
anybody,
that
you
can't
just
have
like
completely
different
sets
of
fields
on
all
the
different
kinds
of
containers
and
there's
no
relationship
between
them.
D
A
Yeah
I'm
with
you
on
that
aspect,
I
just
like
did
I.
You
did
a
good
job
of
leaving
this
properties
like
what
it
will
mean
for
any
containers
to
have
all
this,
but
then
I
started
thinking
about
scenarios.
What
you
can
support
and
in
reality
is
only
I
think
that
makes
sense
is
on
failure
for
never
port.
A
So
this
is
the
only
scenario
that
makes
sense.
Other
scenarios
would
be
really
hard
to
First
Implement
and
reconcile
with
existing
Behavior
yeah.
D
Yeah,
so
we
would
basically
have
to
put
a
validator,
and
it
says
that
you
can.
If
you
set
this
field
on
a
knit
containers,
you
can
only
set
it
to
always,
even
though
the
underlying
enum
might
have
other
values,
you
just
can't
use
them.
A
Yeah
and
foreign.
A
Okay,
yeah
I,
don't
know
I
I
kind
of
struggle.
Writing
any
cons
for
this
option
for
a
new
field
ambient
through
for
all
containers.
I
struggled
to
put
like
why
it's
not
that
except
we
open
new
scenarios
of
this
restart
policy
that
people
may
benefit
from,
but
you
not
implementing
the
scenarios
and
don't
even
know
how
to
implement
us.
D
Yeah
I,
don't
I'd
have
to
think
more
about
that
one
I
I'm
with
you
I,
don't
see
as
many
cons
to
it.
I'm
not
stupid
anybody
else's
thoughts.
A
And
the
only
difference
is
for
initials
will
wait
for
Readiness
on
for
regular
containers.
We
wouldn't.
A
D
I
I
think
it
is
a
real
con
like
potential
for
confusion.
People
like
they
see
the
ambient
thing.
The
first
thing
they
do.
If
they
haven't
read
all
the
fine
print
is
just
go
out
of
container
of
the
tambian
and
then
later
they
realized.
Oh,
if
I
just
put
it
in
the
init
containers.
I
wouldn't
I
wouldn't
have
had
all
these
weird
startup
problems.
B
A
A
A
A
It's
really
hard
to
explain
why
my
login
containers
they
need
container,
so
I
was
thinking,
I
mean,
but
you
really
want
ordering
with
other
init
containers,
so
one
option
would
be
to
introduce
a
new
collection
that
will
supersede
you
need
containers,
something
like
infrastructure
containers
or
something
like
that,
and
an
idea
would
be
that.
Let's
say
you
need
continues
around
first
and
all
the
like.
Maybe
second,
like
infrastructure
containers
going
first,
then
all
we
need
contents
run,
but
the
recommendation
is
only
use
infrastructure,
container
collection,
but
I.
D
Yeah
I
think
there's
a
lot
of
value
to
just
getting
something
out
there
for
people
to
use,
and
some
of
these
things
like
honestly,
there's
the
apis
have
been
accumulating
craft
for
a
while
and
if
there
is
ever
a
V2.
We
would
probably
clean
up
all
of
this,
but
it
might
be
better
to
just
minimize
the
amount
of
complexity
we
add
now,
even
if
it
has
some
warts
and
just
kind
of
keep
going.
D
D
A
A
Okay,
so,
okay,
if
nobody
has
problems,
you
need
containers,
it's
fine.
At
least
we
can
explain
why.
D
Yeah
yeah
I
think
it's
really
good
to
have
these
discussions
and
put
the
rationale
down
because
I
guarantee
you
like
every
different
way.
You
could
do
this
somebody's
going
to
come.
Ask
us
why
we
didn't
do
it
that
way.
A
Okay,
yeah
and
I
see
termination
stages
described
now,
and
we
have
cap
PR
also
filled
out
so
I
think
you're
in
a
good
shape
on
a
cap.
D
A
Okay
and
I
also
looked
at
the
all
the
open
questions.
Let's
move
it
here.
B
Joe
I
think
Tim
put
some
questions
on
Saturday
night
yeah.
D
Friday
night
yeah,
Iowa
I
know
oh
a
pass.
I'm
gonna
do
that
today.
I
think
most
of
it
is
just
like
me
agreeing
on
like
what
we
might
do
when
we
get
to
Beta,
hopefully
with
them.
So
I,
don't
think
it's
blocker,
but
I
will
do
a
pass
on
that
today
and
try
and
clear
it.
A
Up,
okay,
so
naming
which
I
discussed
it
I
think
we
closed
on
it
mostly
I
mean
yeah.
Let's
see
what
feedback
we'll
get
from
other
people
termination
ordering.
We
have
have
a
discussed,
we
don't
do
ordering
now
yeah.
D
I'm
gonna
I'll
try
and
give
a
little
more
explanation
to
what
that
would
look
like
if
we
did
do
real
ordering
so
that
we
can
people
ask
will
be
like
yeah
we're
not
going
to
do
anything
in
Alpha,
but
in
beta
if
we
get
there.
These
are
some
of
the
options
we
have
and
all
the
options
are
backwards
compatible,
so
we'll
be
able
to
add
them.
D
C
D
A
Okay,
I
think
we
discussed
it
already
so
I'm,
not
sure
who
yeah
I
think
I
yeah
I
put
the
section
about
background
possibilities
there,
so
that
should
be
good.
D
A
I
went
to
PR
meeting
last
Thursday.
They
I
mean
it's
good
to
promote
that.
What
we
about
to
do
that
and
also
they
said
that
they
don't
see
all
those
questions
I
raised
as
blockers
for
Alpha.
So
we
should
be
good
to
go
from
that
perspective,
but
it's
something
that
we
need
to
answer
when
we
go
to
Baton
so
forth,
and
they
also
said
that
likely
it
will
be
a
long
way
forward
like
it
will
be
many.
D
A
Yeah,
so
this
is
still
not
done.
I
I
will
be
in
Francesca
and
Swati
if
they
can
help
us
complicated
CPU
manager
and
resource
manager.
You're
an
apology
manager
like
how
do
we
allocate
resources
and
whether
sidecars
introduce
any
new
problems
that
we
didn't
anticipate.
A
A
And
users
can
cause
troubles,
we
have
a
section
in
cap.
A
And
by
the
way,
I
added
another
travel
scenario
there.
A
C
A
Oh
yeah,
this
one
so
something
that
we
haven't
considered
before,
but
some
of
the
people
may
start
using.
So
imagine
you
have
two
initialization
tasks
today,
like
people
has
like
maybe
downloading
some
big
file
to
use
and
also
installing
some
certificates
we
can
open
gates
for
people
start
using
initialization,
like
sidecar
containers
to
do
initialization
in
parallel.
So
today
the
only
option
you
have
is
to
do
a
sequencing
causes,
synthesization
stages.
A
People
might
start
saying
like
I,
want
to
do
faster
startups,
so
I
want
to
initialization
task
to
run
in
parallel
and
they
will
start
abusing
sidecars
by
running
a
lot
of
them.
Basically,
everything
like,
what's
the
downside
for
user
to
do
in
Salvation
stage
in
parallel
as
a
sidecar,
they
typically
wouldn't
exceed
resources
of
main
containers,
so
they
can
use
a
lot
of
resources
and.
A
Yeah,
so
they
can
like
have
some
balloon
in
it
containers
or
something
like
that
and
then
start
doing
some
synchronization
on
all
the
sensation.
Tasks
are
complete,
so,
instead
of
synchronizing
today
on
termination
they
will
start
synchronizing
on
initialization
just
to
make
continuous
start
faster.
A
I
don't
know,
I
mean
this
is
definitely
an
abuse,
not
some
of
the
intent
people
to
to
do.
Yeah
I,
don't
know
how
bad
it
will
be
and
how
much
of
a
headache
we'll
have
with
people
start
asking
us
to
do.
Synchronization
natively
supported
in
kublet,
so
you
have
to
go
back
when
all
incisation
completed
or
something
like
that.
Yeah.
D
I
think
it's
a
good
one
to
call
out
I
think
we
mitigated
a
little
bit
by
the
fact
that,
like
you're,
going
to
get
billed
in
your
resource,
consumption
for
side
cars
differently
than
a
normal
in
the
container,
so
you're
going
to
get
charged
more,
basically
because
it's
going
to
run
the
whole
time
or
it's
assumed
to
run
the
whole
time.
D
So
that's
a
little
bit
of
an
incentive
for
people
to
be
at
least
people
that
are
cost
sensitive
to
not
like
do
this
unnecessarily
yeah
the
I,
don't
know
what
to
say
about
the
the
built-in
synchronization
Primitives
yeah
people
might
start
asking
for
stuff,
like
that.
A
C
Circle
I
got
a
question
about
the
overall
direction
I'm
seeing
here
since
this
is
my
first
attention
meeting,
it
seems
odd
to
me
that
we're
discussing
in
knit
containers
and
like
redoing
in
it
containers
when
I
it
seems
it
would
be
more
effective
to
have
a
project
to
fix
in
it
containers
and
do
sidecars
without
lumping
them
all
into
one
project.
It
just
seems
so
complicated.
The
discussions
we've
been
having
here
today
are
confusing
and
complicated.
A
Yeah,
the
main
motivation
here
is
I
mean,
of
course,
we
want
the
easy
way
to
inject
containers
into
any
port.
So
we
want
to.
There
are
many
patterns
where,
like
metrics
or
proxy
containers
being
injected
from
with
web
hooks,
so
we
need
to
have
an
easy
way
to
inject
them
and
that's
what
we
started
with
like.
Let's
say:
let's
have
another
collection
of
containers
that
will
be
sidecars
and
this
collection
will
be
easy
to
inject.
But
then
many
people
have
concerns
with
initialization
stage
versus
sidecars.
So
this
is
a
pattern
that
some
containers
use.
A
They
need
a
certificate
to
be
downloaded
first
and
they
have
special
providers
for
that,
and
then
they
want
to
run
proxy.
A
So
they
need
proxy
to
run
before
all
other
init
containers,
because
they
will
provide
the
mtls
version
of
security,
secure
communication,
but
also
they
can't
run
it
before
this
container
because
they
don't
have
a
certificate
yet
so
yeah.
We
want
to
solve
the
scenario
and
they
need
to
solve.
The
scenario
led
us
to
this
complicated
Road.
D
Yeah
and
another
way
that
I
think
about
I,
don't
know
if
this
helps
Brian
is
that
the
API
is
already
complicated
and
I.
Think
there's
been
likes
upwards
of
like
four
or
five
I,
don't
know,
Sergey
might
even
have
a
count
of
different
Alternatives
have
been
a
proposed
to
do
this,
all
of
which
change
the
API
in
some
way
and
they've
all
had
just
like
these
long
laundry
lists
of
problems
that
they
cause
for
the
API,
so
the
one
attractive
property
this
design
has.
D
Is
that
it's
because
it's
less
invasive
to
the
API?
It
circumvents
a
lot
of
those
problems.
It
is
a
little
less
obvious
than
some
of
the
other
Solutions,
but
it
kind
of
has
that
nice,
property
of
being
kind
of
like
uninvasive
to
the
API.
D
Yeah,
the
history
here
the
history
here
is
kind
of
like
it's.
It's
a
lot
to
get
through
and
I
I
was
I
was
pretty
surprised
at
some
of
the
solutions
being
proposed
and
then,
when
you
once
you
read
the
history
you're
starting
to
like
maybe
and
I,
would
love
to
hear
your
thoughts
on
like,
if
you
think
of
something
else,
because
there
are
a
lot
of
ways
to
come
at
this
one.
But
this
one
at
least
seems
to,
like
checks,
check
a
bunch
of
boxes
that
are
hard
to
check.
D
C
C
A
Foreign
yeah,
we
tried
like
when
I
joined
kubernetes
three
years
back.
The
first
cap
explain
like
trying
to
enter
this
side.
Characters
were
rejected
and
it
was
rejected
specifically
for
this
reason
that
you
outlined
just
now
so
saying:
can
we
get
to
the
more
tactical
first
step
in
towards
sidecar
containers,
and
then
we
have
like
last
release?
We
have
a
very
small
change
that
we
want
thought
it's
a
tactical
and
easy
to
implement
and
it
was
rejected
for
the
reason
that
we
need.
A
We
need
to
think
about
things
holistically,
so
we're
thinking
holistically
now
and
since
we
went
through
whole
Loop
from
full
cycle.
I
think
most
of
people
who
are
making
decisions
will
be
fine
with
that
and
from
code
perspective,
I'm
scared,
myself,
so
I
I
frightened
how
my
many
changes
you'll
need
to
make
in
so
many
places,
so
I
think
the
biggest
question
will
be.
A
D
Yeah,
the
the
rollouts
are
really
difficult
on
these
things.
We're
now
at
a
point
in
kubernetes,
where,
like
we
release
three
times
a
year,
and
we
support
three
releases
back
so
anything
that
we
roll
out
that
impacts
node
we're
basically
at
more
than
a
year.
It
doesn't
even
matter
like
what
design
we
pick
like.
If,
if
we
do
anything
that
changes
node,
it's
going
to
be
more
than
a
year
before,
you
have
any
hope
of
getting
into
ga.
D
D
But
it's
it's
going
to
be
a
weight.
Unfortunately,.
D
D
The
actual
core
feature
itself
is
one
of
the
simpler
like
you
have
you
have
an
existing
flag,
but
now
it's
on
containers,
if
you
set
it
to
always,
the
thing
just
keeps
running
instead
of
terminating,
so
the
logic
is
actually
pretty
simple
at
like
if
you
explain
it
to
a
user,
but
then
it's
just
like
reasoning
through
all
the
interactions
with
all
the
other
parts
of
the
system
is
where
the
complexity
happens.
D
I'm
worried
that,
like
the
system's
just
big
enough
that
you
can't
like
totally
avoid
that,
but
hopefully
that's
like
the
design
matures
we'll
figure
out
that
a
bunch
of
this
doesn't
actually
matter
as
much
and
kind
of
put
it
off
to
the
side
and
have
like
a
core
idea.
That
makes
sense,
but
it
takes
time
to
get
there.