►
From YouTube: Kubernetes SIG Node 20221004
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20221004-170504_Recording_1920x1026
A
Thanks
Manuel
good
morning,
everyone
and
today
is
the
October
1st
2013
and
our
regular
weekly
signaled
meeting.
Let's
start
next
yoyo
next
circuit,
do
you
want
to
update
our
PR
and
the
issue
board
status
for
last
week.
B
Yeah
sure,
thank
you
Don.
We
did
some
effort
and
clean
up
the
board,
since
we
also
have
cap
reviewers
right
now.
It
doesn't
go
very
fast,
all
the
triage
and
PR
reviews,
but
nevertheless
we
made
some
cleanup
and
Ronaldo.
Thank
you
for
approving
everything.
I
closed
a
bunch,
so
we
minus
22
since
last
week
and
it's
we
also
created
11.
So
it's
a
good
progress.
B
C
Yeah
so
I
put
a
link
there.
So
that's
the
dashboard,
that's
that
tracks
all
of
the
caps
for
126.
So
please
just
take
a
look
at
the
board
to
make
sure
that
the
cap
you
are
going
to
work
on
is
already
tracked
there.
If
not
just
you
need
to
add
the
lead,
opt-in
label
and
the
126
Milestone
to
your
cap
issue,
and
then
your
cap
will
be
automatically
tracked
there.
If
somehow,
you
still
didn't
work
just
reach
out
to
me
over
slack.
C
I
can
probably
help
you
on
that
yeah
and
also
just
a
reminder
that
the
cap
phrase
is
on
October
6,
6,
PM,
PDT,.
A
B
Want
to
say
a
big
thanks
to
Mark,
who
was
helping
us
to
apply
labels
I.
Think
since,
since
not
many
people
in
this
group
right
now
have
this
permissions.
Thank
you.
Mark!
No.
D
Problem-
and
we
should
work
with
I-
think
there's
some
context
to
get
more
people
to
have
these
permissions
but
happy
to
help
foreign.
B
Okay,
last
time,
I
already
started
talking
about
sidecar
containers.
I
just
wanted
to
update
people
on
status
of
this
cap,
and
it's
a
very
long
and
actually
discussed
cap
before
we
start
I
want
to
tell
about
you
by
the
way.
Do
you
see
my
screen
well
or
should
I
make
it
smaller.
D
B
B
Yeah,
user
storage
for
sidecar
containers-
typically,
you
either
have
some
something
that
you
heavily
configured
for
your
payload,
like
some
metrics
reporter
containers
that
will
run
and
react
on
specific
configuration
of
your
main
container
to
some
genetic
containers
like
local
uploader
that
can
take
any
log
and
it
may
or
may
not
require
or
like
desire
to
get
logs
from
init
containers
as
well.
So
it's
a
second
scenario
that
typically
comes
up
with
sidecar
containers.
B
Then
there
is
a
advanced
scenario
of
istio
Android
proxy
when
we
inject
proxy
into
container
configure
all
the
communication
to
go
through
this
proxy
and
this
proxy
will
need
to
leave
through
throughout
the
container
life
cycle
and
if
istio
is
not
ready
and
not
functioning,
then
you
may
not
have
communication
outside.
So
Readiness
of
your
containers
may
depend
on
Readiness
of
istio
and
liveliness
as
well.
B
So
this
is
a
kind
of
a
very
Advanced
sidecar
container,
and
there
is
also
very
interesting
scenario
that
is
business
cases,
for
instance,
job
orchestration,
I,
don't
remember
who
suggests
this
scenario,
but
it's
very
interesting
when
you
have
jobs
that
is
running,
that
is
doing
heavy
calculations,
but
you
also
have
sidecar
that
is
orchestration
sidecar
that
may
be
reporting
status
of
your
job,
but
also
when
it
exits.
It
signals
the
main
job
to
terminate,
because
this
means
that
this
job
is
no
longer
needed.
B
So
we
have
some
sidecars
that
runs
almost
like.
It
runs
in
the
background,
but
if
it
wants
to
terminate
the
port
it
can
so
this
for
scenarios
are
typically
what
we're
talking
about
user
storage
for
sidecars
and
we
can
list
all
the
features
of
sidecar
containers
like
they
need
to
shut
down
when
some
when
only
sidecar
continues
running
or
when
only
specific
containers
are
not
running.
That
also
need
to
shut
down
the
dependent
scenario
you
need
to
like
it
may
be
one
or
another.
B
They
need
to
stay
alive
while
important
things
are
staying
alive,
so
they
like
reference
for
jobs.
You
want
to
upload
logs
all
the
time,
so
if
your
lock
uploader
was
killed,
you
want
to
restart
it
anyway.
Even
though,
like
a
port,
a
restart
policy
was
never
and
it
will
not
be
started
today.
B
Then
sometimes
you
want
to
start
it
before
you
need
containers.
Sometimes
you
don't.
It
really
depends
on
scenario.
Sometimes
you
want
to
start
before
specific
containers,
sometimes
before
everything
there
is
also
a
scenario
of
being
able
to
inject
generally,
so
you
given
a
port,
you
want
to
inject
sidecar
without
thinking
about
it.
So
yeah
I
just
mark
my
things
that
I'm
injecting
a
sidecar
and
I
can
inject
anywhere,
and
it
will
behave
nicely
today.
You
need
to
really
think
about
like
where
you
inject.
B
What's
the
restart
policy,
how
to
react
on
it
and
stuff
like
that,
and
also
more
advanced
scenarios
when
residential
and
liveness
have
interdependencies,
so
you
may
depend
on
other
containers.
Readiness
or
other
containers
may
depend
on
your
agency
and
liveness
this
Advanced
use
case
and
we've
been
discussing
in
the
past
when
we
started
sidecar
container
two
years
back.
B
We
had
this
conversation
and
we
this
conversation,
hit
a
wall
of
misunderstanding
where
we're
going
as
a
signal,
so
we
couldn't
decide
what
is
Ultimate
flexibility
solution
will
be
so
original
proposal
was
copying
it
a
little
bit
and
then
we
said
that
we
cannot
decide
whether
this
scorpion
is
fine,
because
we
kind
of
I
decided
was
the
ultimate
flexibility
solution
will
be
then
alternate
flexibility
to
satisfy
all
these
features
will
be
abused
to
set
interdependencies
between
any
two
containers,
to
start
them
in
very
different
sequence,
and
to
have
some
as
well
I.
B
Don't
have
clear
understanding
that
this
is
Ultimate
flexibility
that
we
need,
but
it's
the
ultimate
flexibility
to
satisfy
any
scenario
ever
so.
If
we
have
that,
then
there
will
be
no
questions
to
ask
any
longer
about
code
lifecycle,
but
it's
not
clear
whether
you
want
to
get
that,
because
we
ultimately
design
kubernetes
and
kubernetes,
where
a
port
will
manage
the
like,
have
scheduling
inside
the
port
for
other
containers
and
like
a
very
Advanced
use
cases
there.
B
So
again
talking
about
copying
problems
as
I
said.
First
attempt
to
scope:
the
problem
was
two
years
back.
It
was
proposal
to
create
this
class
of
containers
called
Sidecar,
and
this
containers
will
will
be
easy
to
inject.
B
So
it
will
justify
this
scenario,
because
we
just
inject
container
with
a
specific
property,
and
it
will
be
you
don't
need
to
think
about
what
other
contents
are
defined
here
proposal
was
to
shut
down
this
container
when
main
containers
are
shut
down,
and
also
it
will
be
restarted
whenever,
while
main
container
is
still
running
so
I
restart
policy
will
be
either
written
anyway.
B
This
again,
this
can
this
discussion
of
this
scenario
hit
the
wall,
because
we
wasn't
sure
whether
we
want
to
get
whether
we
want
to
get
more
see
my
like
more
properties
for
the
semantic.
So
once
we
introduce
a
class
of
sidecar,
we,
like
some
people,
suggestion
like
well
this
site.
Cars
should
also
change
the
startup
ordering
do
they
need
to
start
before
all
other
containers
and
other
people
saying
this
content
should
start
before
you
need
containers,
so
we
hit
the
wall
like
again
like
we
don't
know
what
the
ultimate
solution
is.
B
If
you
introduce
this
class
today,
then
next
at
least
we
may
need
to
have
sidecar
before
you
need
side
car,
and
then
we
need
to
have
a
next
class
of
containers
called
sidecars
like
I
know
start
later,
so
we
didn't
want
to
get
onto
that,
and
we
said
that
we
will
try
to
come
up
with
a
design
with
different
type
of
designer
for
ultimate
solution.
B
So
there
was
a
two
document
floating
around
one
about
layers
approach
from
Team
Hawken
and
another
idea
wasn't
ever
documented
about
the
system
D
like
binds
to
approach
anyway,
but
again
this
ultimate
flexibility
solution.
It
was
hard
to
discuss
because
there
were
not
too
much
interest
in
like
designing
that
to
the
end
or
like
not
enough
time
from
key
players.
I
would
say
anyway.
B
Next
was
in
this
release.
I,
don't
remember
who
suggested
that
we
wanted
to
limit
scope
even
further,
so
instead
of
defining
sidecar
contents,
he
said:
can
you
just
Define
keystone
containers?
If
you
cannot
agree
on
Startup
ordering,
let's
Define
something
that
doesn't
mean
startup
ordering?
Let's
define
containers
that
will
upon
termination,
kill
the
entire
Port
like
once
this
container
is
terminated,
we'll
terminate
everything
else,
so
we
solve
one
problem
out
of
it.
So
we
still
have
this
easy
to
inject
property.
B
But
we
also
have
this
shutdown
everything
when
this
main
kind
of
stopped
running-
and
this
idea
was
like
idea-
was
to
minimize
the
scope
and
don't
pay
attention
on
the
startup
sequence
problem.
But
this
proposal
was
quickly
pivoted
towards
Keystone
being
a
boss
of
sidecar
and,
let's
just
decide,
decide
what
sidecar
containers
needs
to
behave
like
and
we
hit
this
sequencing
of
startup
problem
again.
B
So
next
proposal
was
even
further
boiling
it
down
and
like
changing
the
kind
of
way
to
do
that
it
was
pure
content,
restart
policy
and
introducing
new
type
of
containers
that
will
terminate
the
entire
pod
or
yeah.
B
So
the
idea
was
that
you
may
Mark
specific
containers
with
the
terminate
port
and
this
container
will
terminate
Port
upon
exit
and
also
in
Tradition,
the
restart
policy
per
container.
So
you
can
have
a
job
and
inside
this
job,
you'll
have
something
that
can
restart
all
the
time.
So
it's
kind
of
sidecar
style.
The
difference
of
this
proposal
was
that,
instead
of
defining
class
of
containers,
we'll
justify
properties
that
this
container,
like
some
containers,
May
exhibit,
and
these
properties
are
easier
to
maybe
easier
to
grasp.
B
So
and
again,
this
I
think
this
proposal
hit
a
wall
of
not
being
like
not
always
just
easy
to
inject
property,
and
is
it's
a
P
with
the
different
directions?
Pivot
of
from
lots
of
set
car
container
problem
to
Let's
so
like?
Let's
introduce
some
properties
for
some
containers
that
may
solve
the
sidecar
problem,
but
it
doesn't
solve
sidecar
problem
in
general.
B
So
it's
it's
a
pivot
like
big
keywords
that
maybe
May
so
may
have
to
solve
the
problem,
but
it's
little
different
so
and
finally
binds
to
semantic
that
we
discussed
before
so
binds
to
it's
kind
of
a
systemd
type
of
communication.
When
you
define
that
one
candidate
depends
on
another
container
and
if
one
can
terminate
and
you
will
terminate
as
well.
But
if
that
container
is
still
running,
you
will
be
restarted
no
matter
what
this
was.
B
This
also
hit
the
wall
of
not
solving
this
in
you
like
genetically
injecting
property
of
sidecar
containers,
plus
it
has
some
other
concerns
about
being
useful
for
very
simple
use.
Cases
and
Tim
Hawkins
creates
a
slide
deck
explaining
how
binds
to
May
leave
together
with
sidecar
equal
True
by
saying
binds
2
has
like
star
or
notion
support.
B
So
star
containers
has
like,
like
maybe
selector,
of
containers
that
applies
to
some
conditions,
doesn't
apply
to
other
containers,
but
it's
not
systemd
style,
so
we
kind
of
Pew
it
in
off
systemd
and
that
may
be
problematic.
So
anyway,
I
combine
this
list
of
questions
that
we
need
to
solve
before
Precision
on
sidecar
containers
and
I
wanted
to
understand.
B
If
there
are
like,
maybe
we
need
to
have
some
working
group
on
like
sidecar
accounts
for
127
and
I
also
wanted
to
understand
how
much
hunger
we
have
in
126
to
implement
something
I
think
Team
advocating
for
making
sidecar
container
the
implementing
this?
Oh,
no.
None
of
this
implementing
this
sidecar
class
containers
as
a
first
step
saying
like
Okay.
Let's
declare
that
these
properties
are
important.
We
will
solve
this
problem.
If
later
we
need
to
change
it,
we
will
suffer
the
consequences.
B
I
like
this
idea,
because
it
solves
a
lot
of
use
cases.
I,
think
that
is
reasonable,
but
I
understand
how
it's
How
It
may
affect
our
seek,
because
we
we
will
suffer
all
the
consequences
later.
There
may
not
be
any
consists
if
everybody
will
be
satisfied.
So
I
like
my
proposal,
because
it's
I
mean
I
I
kind
of
connected
to
it,
but
I
I,
don't
have
I
mean
if
sidecar
contains
will
be
implemented.
It's
the
best.
B
We
can
do
I
think,
but
if
we
still
have
reservations
about
our
future
and
we
cannot
decide
on
it,
maybe
we
can
go
with
this
proposal
and
yeah.
B
So
I
think
we
need
to
decide
what
scenarios
you
want
to
support
close
term
I'll
be
ready
to
suffer
consequences.
If
you
pick
one
of
the
size
for
126
and
if
not,
then
we
need
to
perform
the
work
group
and
finally
like
put
this
into
motion
and
like
at
least
in
127,
have
a
clear
plan.
What
we're
doing.
E
E
B
It
might
so,
it
really
depends
on
what
what
ultimate
means,
if
we
want
to
have
like.
B
Oh
okay,
so
so
you're
saying
that
other
arbitrary,
because
something
we
need
we
have
to
solve
at
some
point.
A
The
bigger
push
for
cytica
container
and
a
lot
of
the
flexibility
came
from
that
use
cases,
but
if
I
know,
there's
the
istio
community
actress
start
move
away
the
new
architecture
at
least
there's
the
proposal.
Your
architecture
is
removed
of
the
cytica
container,
so
there's
a
hold
of
this.
This
is
this
is
why
I
try
to
push
away
for
the
a
lot
of
statical
container.
A
The
reading
is
not
just
all
this
flexibility
understand
water,
okay,
so
there's
the
flexibility,
all
those
kind
of
the
things
I
think
I
mentioned
that
all
the
policy
we're
defined
for
the
powder
include
of
the
quality
of
the
services.
I,
think
people
last
time,
I
think
using
the
whole
world.
People
didn't
understand
what
I
just
really
say.
A
The
meeting
notes
even
wrong,
so
actually
the
quality
of
services
also
will
be
messed
up
because
randomly
injected
of
the
silica
container
and
the
rendering
decided
of
the
order
and
also
there's
the
overhead,
because
if
I
remember
correctly,
there's
certain
use
cases
is
actually
the
is
connect
the
opposite
of
the
init.
They
want
a
clean
up
container,
but
they
couldn't
do
that
because
we
don't
solve
this
at
ultimate
of
the
flexibility
and
the
stud
water.
So
they
end
up.
A
They
want
to
even
that
ones
only
do
the
logging
upload,
so
they
are
going
to
running
forever
and
but
the
only
things
they
try.
It
is
make
sure
that
it
is
the
last
one
being
killed
right.
So
so
here
you
can
see
that
circuit.
You
are
missing.
So
many
things
you
just
say:
oh
I
wanted
this
one.
It's
only
only
be
killed
with
this
main
containers
die,
but
on
the
other
hand,
you
also
will
you
also
in
another
sentence.
A
You
say:
oh
I
want
this
one's
upload
of
the
log,
how
you
are
going
to
so
there's
the
many
awful
things
it's
controversial.
You
want
the
unit
dependence.
In
my
opinion,
this
is
what
we
are
discussing
when
we
first
design
pod.
This
is
why,
last
week,
I
did
a
share.
I
said
initially,
what
design
part
spec
I'm
think
about?
That's
not
the
scheduling,
unit,
I'm
thinking
about
that's
the
destination
could
be,
and
there
could
be
at
one
time
I
just
separate
of
the
resource
of
the
graduation
from
the
my
real
containers
scheduling.
A
So
that's
kind
of
the
among
my
computer
resource,
which
is
node,
then
I
cave
out,
something
reserve
some
the
resource
and
then
the
then
decided
what
is
right,
but
that's
over
complicated.
So
a
lot
of
people
think
about
that
cannot
fly.
So
we
decided
majority
cases
like
the
more
than
90
percent
of
the
cases.
We
at
least
that
time
feel
do
you
I,
believe
people
give
in
95
of
the
use
cases
we
don't
need.
So
let's
just
go
with
a
simple
washer.
So,
but
so
a
lot
of
things
go
simple
version.
We
even
change.
A
Next
restart
the
policy
become
to
per
part.
We
even
change
of
the
quality
of
the
services
become
to
provide,
so
even
original
version
is
container
from
me,
so
so
a
lot
of
things.
So
that's
why
I
agree
with
Manu.
If
we
really
want
to
do
this
one,
we
basically
need
ultimate
flexibility
and
the
other.
Then
we
need
to
start
from
that.
One
thinking,
because
all
the
all
the
use
cases
listed
here-
actually
it
is
required
ultimate
flexibility
here.
B
Yeah,
there's
all
the
scenarios
you
need
to
have
ultimately
stability,
but
yeah.
The
question
is:
if
we
get
to
this
ultimate,
can
we
get
to
like
very
close
to
this
ultimate
flexibility
by
introducing
a
couple
more
types
of
containers
and
be
done
with
that
and
satisfy
majority
of
cases
and
don't
even
go
further
anyway?
A
Er,
what
it
is
the
rest
of
the
use
cases
right
and
we
need
to
understand
the
rest
of
the
use
cases.
Then
we
say:
oh,
this
is
solve
some
problem
or
not
solve
problem
like,
for
example,
Apple
of
the
log
I
do
see
that
has
the
use
cases
and
the
other
thing
I
may
think
about.
There
is
the
alternative
already
and
also
even
the
uploading
log
can
we
solve
from
other
perspective,
what
we
need,
like
the
r
logging
and
all
those
kind
of
things
actually
is
already.
A
B
As
well
but
I
mean
it
really
will
depend
on
architecture
that
customers
will
want
to
implement.
B
Okay,
so
I
hear
that
we
need
ultimate
flexibilities
like
interesting.
A
My
wait
wait
a
minute
based
on
you
use
kisses.
We
said
in
here
it
is
Ultimate
flexibility,
Optical
rights,
but
if
winning
the
majority
like
the
istio
move
away
from
the
center
container,
the
use
cases
will
be
larger
of
the
requests
that
will
be
dropped
right
and
then
we
need
to
understand
the
real
use.
Cases
then
understand
the
world.
Why
and
try
to
see
if
there's
alternative,
that's
the
reason
people
shut
down
my
original
idea
right
and
I've
been
convinced
otherwise
I
will
I
won't
be
that
easy
to
convince
that
right.
A
B
Think
my
question
is:
who
may
decide
on
which
use
cases
we
support?
And
let's
say,
can
we
say
that
for
126
we
ready
to
support
this
side
of
use
cases
and
we
like
well
that
will
solve
this
side
of
use
cases.
We
will
leave
with
that
because
it
solves
a
lot
of
problems
and
we
will
not
hold
ourselves
into
business
ultimate
future
if
we
can
like
who,
who
will
be
these
judges
to
decide.
A
Community,
here's
the
executive
reason
right
so,
like
even
tarika
and
I.
We
like,
for
example,
device
API
right.
Even
we
worry
about
it.
We
clearly
see
use
cases.
We
we
produce
use
cases.
We
we
help
that
move
next
stage.
The
problem
is
the
second
container.
We
didn't
really
see
it
because
everyone
have
their
wish
list
and
we
didn't
see
the
clearing
of
the
use
cases
laid
out
here.
The
only
things
I
do
see
it
is
I.
A
Do
have
to
aggregate
agree
of
the
Keystone
of
the
container
it
is
they
push
forward
and
do
the
actual
work,
and
so
that's
why
we
say:
oh
okay,
this
is
kind
of
we
in
the
community
and
the
present
here
and
we
do
see.
This
is
a
real
use
cases
they
couldn't
walk
around
and
but
on
the
other
hand,
we
reserve
some
of
the
consent,
and
so
that's
why
we
try
to
help
in
the
community
try
to
help
them.
A
So
even
we
landed
some
feature
can
help
of
the
certain
use
cases,
because
that's
because
that's
clearly
out
use
cases
here,
it
is
oh
I
want.
This
is
one
last
one
oh
I
want.
This
is
rent
like
this
stage.
Oh
I
want
this
is
restart,
but
in
this
case
it's
a
student
restart.
You
need
to
give
us
the
use
cases.
The
comments,
because
that's
the
complexity
to
the
kubernetes
right
and
and
also
the
apis,
will
be
complicated.
The
management
people
management
kubernetes
as
the
as
the
whole
offer
that
also
have
the
complexity.
A
A
So
so
a
year
ago
they
told
me
he
said.
Oh,
we
have
that
clear
of
the
design
and
but
we
haven't
implemented
reason
I
heard
actually
that
I
really
have
the
plan.
They
even
have
the
implementation
and
in
mind,
and
they
can
move
away.
I
haven't
seen
the
detail
yet,
but
at
least
they
are,
they
are
from
three
years
even
before
that
they
already
decided
to
move
away
from
side
of
our
container,
because
Celica
cannot
give
them
actually
also
give
them
a
lot
of
management.
A
So
so
so
when
they
first
approached
me,
I
reached
this
problem,
they
said.
Oh,
then
we
want
to
move
away
and
but
I
just
yesterday,
people
even
told
ask
me:
oh
damn:
do
you
know
that
we
are
going
to
move
away?
I,
don't
know
that
is
already
in
the
which
stage
I
haven't
followed,
but
I
do
think
about
the
people
say
that
even
people
most
the
pro
understanding,
they
say
that
harm
to
their
own.
So
that's
why
they
want
to
move
away.
B
Yeah
I,
okay,
my
only
comment
about
my
biggest
comment
about
ultimate
flexibility
is
that
we
always
block
ourselves
on
this
ultimate
flexibility.
So,
let's
decide
on
like
ultimate
solution,
but
we
can't
draw
this
housing
institution.
It's
it
over
complicates
things
and
we
we're
trying
to
create
it
and
then
we're
saying
like
it's
too
complex.
Let's
not
do
that.
Let's
come
up
with
some
scoping
causes
problem
at
least
come
up
with
a
scorpion
because
the
problem
and
getting
back
into
this.
But
what
is
the
ultimate
solution?
B
So
I
guess
we
need
to
maybe
from
some
groups
that
will
lock
some
decisions
at
least
today
we
are
not
locking
decisions.
What
we
agree
on
and
what
we
don't
agree
on.
F
For
my
my
thoughts,
I
think
it'd
be
really
good,
really
valuable
to
get
like
the
the
istio
feedback
like
why
why
they
moved
away
from
I.
Don't
have
the
full
context
answer,
maybe
there's
some
article
or
something
that
explains
it,
but
why
they
moved
away
from
cyber
containers
and
like,
for
example,
if
they
don't
need
sidecar
containers
I
feel
like
that
was
a
big
use
case.
F
A
Yeah
yeah,
that's
also
my
behind,
when,
if
we
are
for
sure
they
are
moved
away,
then
we
can
say
what's
left
right
so
then
we
can
actually
what's
the
use
Cases
left
here
and
because
the
East
here
it
is
the
one
asked
for
start
earlier
and
and
and
also
like
arbitrary
time
to
inject
it,
and
also
maybe
last
yeah.
B
Yeah
I
kind
of
agree
with
Matthias
here
on
on
a
child
who's
saying
that
history
is
not
the
only
service
match
like
if
we
say
that
istio
is
not
doing.
Sidecar
containers
doesn't
mean
that
we
don't
need
ultimate.
Flexibility
doesn't
mean
that
we
never
need
any
container
starting
before
we
need
containers
or
guaranteed
to
be
started
first,
if
we
we
need
to
log
this
decision
like
we,
we
can
say
like
okay
for
the
next
foreseeable
future.
B
We
say
that
no
container
should
start
before
you
need
container,
and
we
look
on
this
decision
and
like
proceed
with
this
understanding,
at
least
for
next
few
releases.
So
next
few
years
this
will
be
the
case.
A
We
basically
start
start
part
V2.
Maybe
we
start
from
the
pathway
too.
We
just
go
negative.
What
do
I
say
the
next?
Initially
we
want
to
have
this
decided.
So
then
we
even
don't
need
you
need
Contender
right,
so
you
could
decide
it
which,
which
content-
and
we
think
that
the
pod-
which
one
is
the
start
first,
which
one
is
the
so
that's
kind
of
the.
If
we
really
want
to
go
to
that
dot,
then
we
can
start
to
initiator,
but
that
takes
really
long
time.
A
That's
the
start
that
effort
to
think
about
how
we
are
going
to
move,
to
support
ultimate
ultimate
thread
flexibility
and
introduce
of
the
start
of
dependency
container
dependency.
That's
kind
of
original.
We
were
discussed.
B
So
as
we
will
Design
This
Broadway
too,
what
would
be
the
next
step
to
implement
s
of
it
in
V1
or
V1
can
do
its
own
thing,
while
we're
going
to
V2.
That
will
be
one
of
the
questions
that
may
hurt.
G
B
G
B
Come
back
to
the
same
kind
of
Association
as
we
are
in
today:
yeah,
okay,
I.
Also,
okay
for
group
sounds
good.
I
I
will
start
some
work
group
for
127.
You
go
with
that.
The
last
question
for
126.
Is
there
any.
B
Can
we
take
some
scenario
to
126?
Can
we
agree
on
subset
of
scenarios
or
to
like
any
scenario
will
come
up
with?
Will
change
broad
life
cycle,
Port,
spec
definition
and
probably
will
be
for
a
long
time
there
are
we
do
we
feel
we
can
get
to
the
some
conclusion?
B
Unfortunately,
Derek
is
not
here.
We
cannot
get
to
the
critical
mass
of
like
we
will
agree
on
like
one
of
this
can
be
implemented.
B
Don't
do
you
want
to
take
any
have
any
say
here
like
do
you
want
to
implement
like
a
sidecar
container
class,
keep
in
mind
that
it
may
it
may
not
be
aligned
with
a
final
proposal
or
Keystone
or
like
a
spirit,
container
start
policy
or
like
fines
to
any
of
this,
is
there
any
feeling
that
we
can
make
this
decision
soon?
Why
not.
A
A
But
nobody
will
guarantee
right
so
because
we
need
the
review
the
cap
and
so
I
know
the
team
team
hacking
already
reviewed.
The
Keystone
capitalists
still
have
some
open
question
there.
A
So,
let's
just
move
forward
with
this,
but
I
just
want
to
see
Sergey.
Even
when
we
see
the
move
forward,
it's
just.
We
are
located
investment,
all
those
kind
of
things,
this
Dynamic
guarantee
that
will
be
finished
in
1.26
right.
We
don't
want
later.
We
regret
right.
So
if
you
really
think
about
the
next
in
place,
pod
Auto
scanning
vertical
Auto
scaling
right.
So
that's
I
really
want
that
feature
a
long
time
ago.
I
want
that
feature
still
take
years
so
right.
A
A
Yeah,
the
kids,
don't
actually
I
believe
the
author
already
commit.
They
are
going
to
do,
and
I
also
quickly
checked
checked
with
the
team.
He
also
want
to
make
sure
and
allocate
his
bandwidth
on
the
API
review.
So
that's
why
and
I
believe
that's
already
committed.
B
Okay,
it's
a
good
outcome,
let's
press
it
with
Keystone
and
see
if
we
can
get
through
all
the
Hoops
in
1.6.
Thank.
A
You
Manu,
do
you
want
to
secure
chimping
on
this
one?
Because
you
are
the
new
that
from
the
signaled
yeah.
E
B
I
can
keep
sharing
if
you
want
so
one
next
one
is
updated.
H
Yeah
hey,
this
is
just
a
quick
question
from
me.
This
is
so
previously
we
had
some
discussions
around
like
app
cap
around
something
called
a
runtime
assisted
mounting
and
I'm.
Just
looking
for,
like
one
recommendation
around
a
question
that
came
up
in
six
storage,
a
specific
question
was
like
today.
If
we
look
at
the
runtime
class
and
the
fields
there
like,
none
of
them
are
used
to
kind
of
influence,
anything
that
the
cubelet
does
when
handling
a
pod
and
like
in
sick
note.
H
We
discussed
this
once
and
I
was
specifically
recommended
that
nothing
from
the
runtime
class
should
be
sent
out
to
the
to
the
runtimes
through
cry.
Apis
like,
except
for
the
Handler
that
is
sent
out.
I
was
just
curious,
like
does
that
recommendation
also
apply
to
like
non-cri
aspects
of
cubelet.
The
specific
context
we
were
thinking
of
is:
is
it?
Is
it
okay
to
Define
some
fields
in
the
runtime
class
that
the
cubelet
can't
pass
down
to
a
CSI
plug-in
in
the
context
of
mounting
volumes
where
the
CSI
plugin
and
the
runtime
Handler?
H
Does
some
coordination
around
its
Mount
I
I
was
just
like
looking
for
any
guidance
around
this
today
there
doesn't
appear
to
be
any
fields
in
the
runtime
class
that
the
cubelet
looks
at
to
make
decisions
around
how
it
will
handle
a
pod,
but
is
that
something
specifically
that
is
not
recommended
by
signal.
B
Is
in
the
runtime
class
I
think
whatever
happens
there
right.
B
No,
it
may
not
be
cool
now.
Cubot
will
we'll
have
some
extra
Fields
there.
F
Yeah
my
understanding
was:
they
just
passes
the
runtime
class
field
directly
to
the
to
the
runtime
to
the
CRI
and
then
see
where
I
kind
of
figures
up
one
point:
I
should
run
time
to
class
to
use,
but
I'm
not
sure
if
there's
any
other
things
that
looks
up.
A
Originally,
when
we're
thinking
about,
we
are
not
limited
to
the
cell
right,
but
but
in
reality,
when
we're
really
design
and
also
the
implementation,
I
think
Miss.
Basically,
nothing
is
really
prci
so
far,
but
the
original
one
we
think
we
do
think
about
the
that's
everything's
related
to
that
part.
Information
right
so
could
be
potential,
but
do
we
need
to
find
some
more
concrete
so
that
time
only
CIS
concrete
things
for
us?
A
So
so
that's
why
we
only
consider
all
those
CRI
related
during
the
API,
the
API
design
and
also
implementation,
but
the
but
the
initial
we
did
talk
about
some
other
thing
potentially
could
be
yeah.
B
I
heard
of
people
in
some
issues,
I
heard
people
using
runtime
class
for
advanced
scheduling,
so
they
don't
have
extra
handlers.
They
just
define
specific
set
of
handles
on
different
nodes,
and
this
is
how
they
make
sure
that
some
ports
are
not
scheduled.
Some
places
it's
weird
use
case,
but
then,
if
CSI
Fields
will
also
be
added,
I
wonder
about
the
how
many
runtime
classes
will
need
to
be
designed
defined
on
like
a
single
node
like
do
we
need
to
have
all
combinations
like?
B
Let's
say
we
want
gvis,
there
is
a
runtime
faster
and
with
gviser.
We
want
this
two
variants
of
like
CSI
arguments.
Do
we
have
four
runtime
classes
now
defined
on
the
Node
since
I?
Don't
know
scenario
I,
just
like
I'm,
just
worried
about
the
explosion
of
combinations
that
we
don't
have.
A
The
the
Deep-
maybe
let
me
connect
to
you
with
the
Teemo
player
because
originally
here
and
I
discussed,
but
he
actually
he
have
a
way
to
think
about
the
in
the
long
run,
to
incorporate
other
requirements
so
but
I
lost,
I
forgot,
I
need
to
refresh
my
memory
and
I
was
discussing.
So
let
me
connect
you
to
the
team,
Eau
Claire
and
and
about
that
yeah.
Thanks.
B
Is
there
any
more
agenda
items
for
today.
E
G
Hi
Alexa
here,
can
you
hear
me
yep
yeah,
thanks
quick
question
from
the
one
of
the
things
that
we
thought
might
go
to
126
the
CRI
extension
to
have
an
API
for
pulling
image
with
the
progress
now
Derek
mentioned
on
the
issue
that
the
design
might
take
more
time.
That's
the
first
kept
for
me.
What's
the
acceptance
criteria
to
take
the
cap
into
the
release,
so
the
the
thing
itself
is
fairly
small
and
it
doesn't
affect
any
existing
functionality.
G
G
So
I
just
wanted
to
know
whether
the
proposal
with
technical
description
is
enough
to
get
the
thing
moving
into
the
126,
or
is
it
common
that
it
might
take
a
whole
release
to
discuss
something
and
then
get
the
Gap
released
in
the
next
release?.
E
Go
ahead,
I
think
so,
like
I
was
making
a
password
Derek
yesterday
and
I.
Think
it's
supposed
couple
of
things.
One
is
like
worrying
that
okay,
we
pulled
in
too
many
things,
we
don't
have
the
bandwidth
and
the
second
is
like
it
didn't
seem
fully
flushed
enough.
Like
did
you
include
the
CRI
changes,
for
example,
so
it
should
be
in
a
state
where
we
can
say:
okay
yeah.
These
are
the
CRA
changes,
it
looks
good
and
we
should
be
able
to
make
progress,
and
the
cap
freeze
deadline
is
like
couple
of
days
from
now.
G
A
Right
thanks
Alex,
you
still
can
make
a
progress
right,
so
it's
not
just
even
we
Mark,
that
is
the
Milestone
and
but
at
the
end
we
still
couldn't
agree
reaching
consensus
missing
certain
things
not
address
the
feedback.
You
still
cannot
roll
out
right,
but
you
still
even
that
not
the
merge
for
the
1.26
as
the
capital
we
still
can
improve
the
cap.
We
still
can
do
the
product
type
implementation,
still
mechanic
progress,
and
hopefully
we
can.
When
that
27,
then
we
can
have
the
earlier
merch
and
earlier
approval
right.
A
G
H
G
I
understand
that
it's
it's
fine
that
it's
been
discussed
and
agreed
and
I
agree
that
there
might
be
a
valid
and
good
points
at
the
end.
Then
we
didn't
consider
all
the
things
and
there's
plenty
of
work
to
be
done.
I
was
merely
wondering
what
are
the
acceptance
criterias
for
the
cap
to
start
to
get
merged,
because
when
you
feel
in
the
cab,
the
draft
says
that
I
mean
the
comments
in
in
the
markdown
file
said
that
you
start
the
cap
and
you
try
to
do
it
fast.
G
A
Thanks
I
think
we
can
continue
off
the
enhancing
of
the
type
and
and
also
there's
the
we
can
try
to
do
the
Prototype
right.
So
once
you
do
the
product,
you
can
see
that
the
feedback
and
there's
certain
things
missing
so
then
add
that
one
so
get
the
righty
for
for
the
review,
and
hopefully
we
can
merge
as
early
as
possible
for
even
we
miss
this
time,
guys
so
yeah.
B
B
Okay,
we
get
in
nine
minutes
back.
Thank
you.
Everybody
again,
look
at
your
caps
make
sure
they
are
not
at
risk
and
start
implementing.
Thank
you.
Bye.