►
From YouTube: 20210211 SIG Architecture Community Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everybody:
this
is
the
kubernetes
architecture
meeting
for
february
11th
2021,
please
treat
each
other
with
respect
and
let's
get
started
pretty
short
agenda
today.
First
item
is
from
derrick
and
derek
reached
out
earlier
today
said
he
couldn't
make
it
today,
but
just
wanted
to
raise
the
everybody's
attention
on
this.
So
we
had
this
come
up
since
we
did
in
121.
For
the
first
time
we
made
a
production
readiness
review
required
for
all
the
new
caps
coming
in
one
item
that
came
up
is
that
that.
A
Apis
and
so
the
question
came
up
of
whether
those
should
be
protected
by
a
feature
gate
and
how
to
evolve
those
apis.
So
what
we
ended
up
doing
and
through
discussion
was
say
that,
yes,
they
should
be
protected
by
a
feature
gate
and
that,
with
the
feature
gates
off
because
the
way
grpc
works,
you
can't
remove
them
completely.
A
He
couldn't
make
it
today,
but
he
he
just
want
to
let
everybody
know
he's
going
to
put
a
doc
together,
send
it
out
for
review,
and
so
the
folks
here
that
are
interested
in
this.
Please
take
a
look
at
that
when
he
does
send
it
out
and
then
we'll
move
that
into
some
sort
of
contributor
guidance.
Pr.
Once
once
that's
done
once
that's
agreed
upon
so
any
thoughts
or
comments
on
that,
or
I
think
it's
probably
appropriate
to
just
wait
for
the
doc.
But
if
anybody
wants
to
say
anything,
please
do.
A
Okay,
then,
next
item
on
the
end,
assad.
B
Yes,
so
from
sig
storage
we
have
a
effort
called
csi
migration,
and
the
goal
here
is
to
move
all
our
entry
drivers
to
csi
as
part
of
a
larger
effort.
That's
going
on
within
kubernetes
to
remove
all
cloud
provider
specific
code,
so
we're
going
through
a
plug-in
by
plug-in
and
figuring
out
what
the
migration
plan
and
strategy
is.
So
with
vsphere.
B
The
vsphere
csi
driver
actually
introduces
a
a
new
set
of
kind
of
richer
functionality,
so
it
depends
on
newer
versions
of
vsphere,
and
what
this
means
is
that,
when
this
migration
happens
from
entry
to
csi,
older
versions
of
vsphere
are
not
going
to
work
with
the
csi
driver
and
the
goal
with
migration
is
that
it
should
be
seamless
that
the
user
shouldn't
notice
so
to
address
this.
B
B
B
B
So
the
question
to
sig
architecture
is
to
clarify
this
deprecation
policy,
and
the
question
is
does
on
by
default,
violate
this
policy
in
this
case,
and
if
so,
is
there
any
way
to
get
an
exception
around
that.
A
So,
in
my
opinion-
and
I
don't
know
what's
written
specifically-
but
in
my
opinion
I
would
treat
this
similarly
to
apis
in
that
it's
on
by
deprecated
means
on
by
default.
Isn't
the
same
as
removal
and
the
deprecation
is
a
warning
that
there
will
be
a
removal,
so
would
would
require
an
action
required
release.
Note
saying:
hey
if
you're
using
this,
you
know
in
this
new
release.
A
This
is
on
by
default,
and
so
you
need
to
turn
it
off
by
default
or
you
need
to
turn
off.
Rather,
if
you
are
an
older
version
of
vsphere,
but
I
don't
believe
that
it
would
be
a
violation
of
the
deprecation
policy
to
change
the
default.
I
don't
know
if
others
on
the
call
have
a
similar
or
different
opinion.
C
The
first
sentence
in
that
section
talked
about
significant
use
of
reasonable
behaviors,
which
impact
the
correctness
of
applications
running
on
kubernetes
or
that
impact
the
administration
of
kubernetes
clusters
and
which
are
being
removed
entirely
so
saying
like.
If
you
want
to
continue
to
use
your
cluster
with
an
older
vsphere
during
this
deprecation,
you
have
to
turn
off
this
migration
feature.
C
D
B
Okay,
so
that
actually
helps
us
a
lot,
which
means
we
can
go
ahead
and
enable
this
on
by
default
before
the
one
year
deprecation
policy.
And
then
I
guess,
the
only
remaining
remaining
bid
is
actually
deleting
the
entry
code.
It
seems
like
that
would
have
to
wait
until
at
least
one
year.
B
Okay-
and
I
think,
is
walter
on
the
line.
I
think
that
more
or
less
aligns
with
the
current
timeline
laid
out
by
walter
for
having
code
deleted.
I
think
they
wanted
it
done
by
124,
and
so,
if
we're
talking
about
125,
that
seems
feasible.
B
Okay,
I
don't
think
we
have
any
other
concerns
here.
Then.
D
Yeah,
I
think
this
is
isn't
completely
related
to
this
particular
topic,
but
in
our
last
csi
migration
meeting
we
were,
there
is
sort
of
one
dependency
on
cubelet.
Basically,
there
is
some
behavior
in
queue,
controller
manager
that
determines
whether
or
not
cubelet
has
the
feature
enabled,
and
I
think
we
were
trying
to
walk
through
the
timing
of
that
and
when
we
can
remove
the
behavior
in
the
queue
controller
manager
and
that
might
that
might
impact
the
code.
D
A
Okay,
thank
you
all
right,
oh
hippie
has
put
something
to
see.
I
I
normally
go
through
and
pick
things
off
the
mailing
list
and
put
them
on
here,
and
I
I
negligently
did
not
do
that
this
site
this
this
period.
So
thank
you,
hippie.
You
want
to
explain
what
each
of
these
is.
E
Sure
these
are
ones
I'm
interested
in.
I
feel
free
if
anybody
else
wants
to
add
other
ones.
The
first
ones
one
we
haven't
had
any
response
to,
and
it's
been
within.
The
conformance
subproject
noted
that
when
we
make
a
decision
there
about
endpoints
that
are
not
eligible
for
conformance,
we
have
to
track
that
somewhere.
So
it
ends
up
know
up
until
this
point
it's
always
been
sql
magic
within
zach's,
amazing,
api,
snoop
db
stuff,
and
it's
not
exactly
accessible
to
the
community
or
has
a
pr's
for
discussion
on
on.
E
Why
and
I
feel
that's
best
done
by
the
community
within
kk,
so
we
generated
a
pr
that
puts
the
ineligible
endpoints
yaml
within
the
conformance
test
data,
so
it's
still
governed
by
the
same
owner's
file
as
what
is
part
of
conformance
in
order
for
us
to
have
a
good
eye
on
that,
and
I
just
love
some
wider
feedback
or
merging
or
whatever
just
some
thoughts
on
that,
so
that
we
can
move
forward
once
that's
done
the
api,
snoop,
reporting
and
database.
E
Everything
will
stop
creating
that
query
internally
when
we
load
and
we'll
pull
that
from
from
the
main
branch
on
kk.
A
So
I
think,
that's
probably
on
me
and
clayton
and
aaron
to
review
that
list
to
make
sure
that
that
something
didn't
get
in
there
that
we
don't
think
should
be
in
there
and
and
then
other
than
that,
it's
all
good.
And
then
I
guess
the
other
item
was
that
tim's
comment
about
did.
Was
there
anything
we
wanted
to
discuss
about
that
I
mean.
A
E
I
think
there's
some
other
complexities
that
I'd
love
to
see
and
some
really
cool,
pioneering
work
by
jordan
way
early
on
that's
kind
of
been
either
just
it's
been
stopped
for
a
bit.
In
addition
to
maybe
adding
that
feature
gate
to
the
api
and
having
that
flow
through
somewhere
in
the
open
api
spec.
A
Well,
you
mean,
I
mean
it's
in
the
it's
in
the
version
for
the
whole
api.
C
E
C
C
Looking
at
the
open
api
dock
generated
from
a
server
that
explicitly
turned
on
all
alpha
invaded
features
is
probably
not
the
right
way
to
understand
all
the
features
you
need
to
test.
If
you
start,
if
you
pull
that
dock
from
a
server,
that's
only
running
ga
features,
then
it
will
only
include
ga
and
points
and
types,
and
so.
A
C
Yeah,
so
I
I
don't
object
to
putting
information
in
open
api.
I
think
that's
useful,
even
for
other
consumers,
but
specifically
the
dock
that
is
being
looked
at
is
being
pulled
from
a
server
that
is
running
a
mix
of
alpha
and
beta
features,
and
so
yes,
we
could
be
clearer
in
that
dock.
But
if
you
want
to
know,
what's
ga
pull
that
just
pull
that
schema
dock
from
a
server,
that's
only
running
ga
features.
E
Is
there
so
for
our
authoritative
place
for
that
we've
been
pulling
from
that
open
api
spec
is
on
the
repo,
and
that's
probably
it's,
like
you
said
it's
it's
generated
as
par
as
far
as
any
time.
There's
a
change
to
the
open
api
spec.
We
update
that
file
to
show
it
across.
Is
there
a
particular
place?
We
could
push
a
list
of
ga
features.
E
E
A
I
mean
I,
I
don't
think
I
have
at
least
that
first
blush
any
objection
to
if
you
want
to
put
in
the
tooling
to
add
that
to
what
gets
that
get
a
as
long
as
it's
clearly,
the
name
of
the
file
makes
it
clear:
it's
ga
only
open
api's
back,
not
it
doesn't
cost
confusion
with
the
other
one.
That's
checked
into
the
repo.
Putting
it
there
in
the
conformance
area
makes
sense
that
that's
actually
kind
of
nice.
It
gives
a
a
clearer
picture
of
hey.
A
E
A
All
right
that
is
the
end
of
our
agenda
and
I
for
one
am
happy
to
give
back
time.
If
I
will
give
others
an
opportunity
to
say.