►
From YouTube: 20220324 SIG Arch 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
All
right,
hello,
everybody
today
is
march
24th,
2022.,
oh
and
today
is
the
sig
architecture.
Community
meeting
for
kubernetes
jordan
cares
thank
you,
jordan
and
so
all
right.
I
think
we
just
have
one
agenda
item
today
and
let's,
let's
get
started,
patrick,
I
think
it's.
Your
item.
B
Yeah,
okay,
so
we
talked
about
this
pull
request
that
I
have
opened
in
component
based
logs
about
how
to
organize
the
api.
We
discussed
that
part
I
think
end
of
last
year
and
we
decided
that
moving
all
into
one
structure
is
the
right
way
to
go.
B
This
is
the
main
part
of
that
pull
request,
but
we
also
discussed
how
to
then
control
access
to
functionality
that
is
considered
alpha
or
beta,
because
that's
no
longer
part
of
a
b
one
alpha
configuration
structure,
it's
all
in
a
one
b
b,
one
alpha
and
v,
one
r
v
b,
one
structure
and
we
need
additional
methods
of
communicating
to
users
that
they
are
using
something
that's
unstable
or
not
hasn't
graduated,
yet
part
of
that
is
documentation.
B
That's
all
in
place
in
the
corner,
in
the
structure,
comments
and
in
the
command
line
descriptions,
but
then
there's
a
question
of
what
to
do
with
feature
gate
checks,
the
way
how
traditionally
has
been
done-
and
I
I
noticed
when
trying
to
implement
that-
that
I
can't
do
it
the
same
way
as
in
other
packages,
simply
because
component
base
itself
can't
use
the
default
feature.
B
Gate
instance-
and
I
started
I-
I
brought
it
up
on
slack
a
while
back
and
john
suggested
that
the
component
base
package
needs
to
be
special
and
should
accept
an
explicit
parameter
for
the
feature.
Gate
instance
that
it's
supposed
to
check
and
I
did
implement
that.
I
just
find
it
awkward,
because
suddenly
we
have
an
explicit
parameter
in
the
api
that
users
normally
don't
care
about,
but
we
need
to
pass
it
in
otherwise
the
feature
gate
checking
doesn't
work
and
that's
odd.
B
No,
no
other
package
does
it
like
that,
and
therefore
I
want
to
raise
the
question
again
if
it
really
has
to
be
the
way
it's
currently
or
whether
we
can
do
what
I
have
implemented
in
the
current
version
of
a
pull
request,
whether
we
can
move
the
default
feature:
gate
instance
from
k8s
api
server,
where
it's
currently
living
down
into
component
based
feature
gates
and
just
to
be
clear,
I'm
only
suggesting
to
move
this
one
default
instance
of
a
feature
gate.
Nothing
else.
Changes
where
features
are
get
get
added
to.
B
That
instance
is
the
same
as
before.
Basically,
whenever
something
has
a
feature
gate,
it
defines
the
feature
gate.
It
makes
sure
that
it
gets
added
to
that
default
feature
gate
instance
and
then
there's
a
global.
This
global
variable
that
gets
controlled
by
the
feature
gates,
command
line,
parameter,
and
everyone
is
happy-
and
I
just
want
to
do
the
same
thing
in
component
base
without
having
to
jump
through
any
additional
hoops.
B
And
that's
that's
one
thing.
I
can
also
point
out
the
other
thing
that
ilana
brought
up
when
reviewing
this,
and
that
is
whether
which
kind
of
feature
gates
we
should
have
in
in
that
pr,
whether
it's
the
same
as
I
think
the
cpu
manager
thing
that
that
is
for
precedent
that
I've
been
for,
but
I'm
following
here
whether
we
have
permanent
logging
alpha
options
and
logging
beta
options
as
a
catch-all
force
for
individual
features
that
are
behind
those
gates
and
get
enabled
by
additional
options
in
the
configuration
or
in
the
command
line
parameters.
B
That's
the
second
aspect.
I
think
that
we
went
through
that
before
I've
linked
to
the
the
google
groups
discussion
where
this
has
been
discussed.
I
just
wanted
to
refresh
everyone
that
this
is
also
something
we
are
planning
to
do
here.
The
main,
the
main
contentious
point
is
what
to
do
with
default
feature
gates,
because
john
basically
said
that
it
needs
to
be
different.
I
I
want
to
discuss
that.
C
What
order
do
we
want
to
discuss
this
in
cause?
Mostly?
Just
like
I
have
some
comments
on
the
default
feature
gates.
I
started
reviewing
this
pr.
I
haven't
gotten
through
all
of
it.
There's
just
a
lot
of
code
moving
around
and
like
with
you
know,
thousands
of
lines,
kind
of
being
like
thrown
around
and
moved
it's
really
difficult
to
do
the
diffs,
especially
because,
like
git,
isn't
recognizing
a
lot
of
them
as
moved
files
or,
like
you
know,
with
restructured
stuff.
C
So
thus
far
like
looking
at
that
pr,
really,
the
only
major
comment
that
I
have
is
like.
I
think
it's
good
to
try
to
like
version
this
a
little
bit
better
and
to
like
section
off
the
versioning
into
sections.
I
think,
like
the
overall
goal
of
like
making
these
vlogging
configurations
its
own
api
in
component
base
with
a
few.
C
Like
that's
good,
I
don't
think
the
way
that
we're
doing
feature
gates
right
now
makes
any
sense
like
the
idea
that
we
have
a
perma
alpha
feature
gate
set
and
a
perma
beta
feature
gate
set
that
doesn't
jive
with
the
way
that
we
do
feature
gates
for
the
rest
of
kubernetes
like
there
is
a
feature
that
gets
tracked
through
a
life
cycle
and
at
some
point
it
graduates
and
then
the
feature
gate
goes
away.
C
The
last
time
that
we
had
a
discussion
similar
to
this
was
for
some
cpu
policy
stuff
within
cubelet,
where
people
were
asking.
Can
we
just
have
like
an
experimental
feature
gate
where
things
are
in
there
all
the
time
for
these
policies?
I
said
well
like
at
that
point
like.
Why
is
this
even
in
tree?
We
don't
want
to
have
perma
alpha
stuff,
so
that
was
my
feedback
on
that.
I
don't
know
jordan
if
you
have
more
to
add.
D
D
One
is
to
allow
gating
off
problematic
code
if
it
breaks
something
and
that
didn't
really
apply
to
the
cpu
manager
case,
because
you
can,
if
one
particular
aspect
is
problematic,
you
can
turn
off
that
aspect
of
the
config.
The
other
reason
we
have
featured
gates
is
to
make
people
explicitly
opt-in
to
pre-release
stuff
and
so
doing
that
in
a
like
as
a
whole,
like
I'm
opting
into
alpha
cpu
manager,
things
didn't
seem
terrible.
D
I
take
your
point
that
if
the,
if
we
always
are
gonna,
have
an
alpha
like
omnibus
feature,
gate-
that's
weird,
presumably,
hopefully
the
feature
will
complete
and
then
we're
not
going
to
be
adding
more
alpha
stuff.
And
then
at
that
point
I
guess
we
could
clean
up
the
output.
D
I
I
don't
know
I
I
kind
of
want
to
talk
about
the
the
location
of
the
feature,
gate
registry,
because
that's
what's
blocking
patrick
right
now,
so
there
are
two
main
things
that
have
been
problematic
in
the
past
that
are
sort
of
global
variable
magnets
and
one
is
command
line,
flag
registration
that
used
to
happen
sort
of
globally
into
the
global
flag
registry
and
the
other
is
feature
gate
registration
and
both
of
those
things
being
treated
as
global's
have
made
testing
more
difficult,
have
made
it
harder
to
understand
the
boundaries
between
components.
D
We
run
into
situations
where
a
flag
was
being
registered
by
one
component
and
then
used
by
another
component
as
a
side
effect,
and
when
we
started
breaking
up
some
of
the
sort
of
monolithic
binaries
we
realized.
Oh,
this
component
is
using
a
flag,
but
it
isn't
actually
registering
a
flag
and
so
that
sort
of
side
effect
we
happen
to
be
in
the
same
binary.
So
I
guess
we
will
see
each
other's
registered
things.
B
D
I
think,
because
component
base
is
supposed
to
be
this
building
block,
and
so,
if
I'm
going
to
use
like
the
leader
election
component,
it's
reasonable
for
me
to
ask
that
component
like
register
your
flags
into
this
flag,
set
register.
Your
features
into
this
feature
gate
instance,
and
then
I
will
monkey
with
the
config
or
do
whatever
I
want.
And
then
I
will
instantiate
you
and
you
will
run
like
that
sort
of
building
block
without
the
component
library,
assuming
it
is
only
running
one
instance
or
is
the
only
thing
in
the
process.
D
Not
the
rest
of
the
code,
there
are
other
places
in
the
code
that
we
don't.
Let
do
this
already.
So
things
like
admission
admission
does
not
or
it
shouldn't
it,
we've
swept
it
multiple
times
and
we
try
to
hold
it
to
this
standard.
It
doesn't
use
a
global
feature
gate.
It
is
given
an
instance
of
a
feature
gate
when
it
initializes
and
it
pulls
out
the
values
that
it
needs
from
the
feature
gate.
B
Okay,
I
think
I
get
what
you're
saying
now:
it's
not
about
the
conceptual
location
or
it's
not
about
the
the
logic
of
the
the
place
of
the
feature
gate.
It's
really
about
whether
component
base
should
have
an
explicit
parameter
or
use
a
global
instance.
D
Yeah,
if
you,
if
you
imagine
leader,
election
and
logging,
it's
not
impossible
to
imagine
those
components
being
used
multiple
times
in
the
same
process
right,
especially
leader
election
or
something,
and
so
it's
it's
not
like.
Instead,
instead
of
those
things
taking
global
dependencies,
we
want
them
to
be
just
given
the
parameters,
how
they
should
operate.
B
I
just
I
understand
that,
but
I
just
failed
to
see
the
use
cases
for
feature
gates
in
this
case
here,
because
I
can't
imagine
that
we
will
have
a
component
where
feature
gates
are
getting
set
differently,
in
particular
for
logging,
which
is
basically
getting
configured
once
per
process,
except
for
tests,
but
yeah,
but
that
ben
in
tests.
We
already
have
this
defer
thing
with
temporarily
changing
feature
gates
for
for
all
of
the
other
codes
too.
So
solving
it
for
component
based
doesn't
help
us
at
all.
Well,.
D
The
changing
it
globally
in
unit
tests
and
was
definitely
a
stop
gap
it
doing.
That
means
we
can't
run
our
tests
in
parallel,
like.
D
D
B
We
can,
if
that
event,
is
the
argument.
Okay.
Well,
then,
I
would
like
to
have
say
I
don't
know
some
photo
review.
Look
at
the
alternative
solution,
which
I
linked
in
in
the
pr
and
say
whether
that
actually
is
a
better
api
for
component
base,
whether
that
is
useful
enough
to
have
the
additional
complexity
because
it
trickles
up,
we
have
component-based
cli,
which
is
actually
where
people
indirectly
initialize
logging.
So
we
also
need
to
extend
that
api
to
pass
in
a
feature
gate.
B
B
They
will
still
have
a
single
feature,
gates
command
line
that
is
bound
to
the
global
default,
and
that
is
what
everyone
and
whatever
one
needs
to
pass
into
component
base,
and
I
don't
see
that
ever
being
any
different,
except
that
it's
more
complicated,
but
that's
all
if,
if
that
is
the
direction
yeah,
we
can
do
that.
D
I
mean
I
I've
talked
a
lot,
I'm
happy
to
let
other
people
who
have
worked
with
feature
gate
stuff
or
tried
to
tease
apart
binaries
in
the
same
build
tree
way
in
if
they
think
I'm
off
base.
I'm
happy
to
hear
other
folks.
E
I'm
pretty
sure
I
was
the
guy
that
wired
the
feature
gate
so
that
it
was
required
for
instantiation
of
our
admission
plugins,
and
so
you
wire
it
and
pass
an
instance
through
and
what
I
found
when
I
was
teasing
these
parts
apart.
D
B
A
B
Deal
yeah,
I
I
just
really
don't
think
it's
it's
useful,
but
I'm
I'm
fine
with.
If,
if
that
is
what
everyone
is
happy
with
and
we'll
just
change
it,
I
think
we
we
can
still
change
the
apis
in
component
base.
It's
not
too
troublesome,
but
one
thing
that
I
found,
for
example,
is
that
I
actually
had
to
change
the
interest
infrastructure
code
a
little
bit.
The
feature
gate
enabled
parameter
assumes
that
the
feature
gate
that
it's
supposed
to
check
a
feature.
B
E
B
Yeah
but
then,
then
we
have
another
failure
mode
where
a
feature
gate
gets
passed
into
a
component
or
in
a
library
function.
The
library
function
expects
its
feature
to
be
registered
and
calls
enabled,
and
then
it
panics,
because
the
caller
didn't
set
up
the
feature
gate
correctly
and
well.
If
that's.
B
We
basically
have
to
say
you
have
to
pass
in
a
feature
gate
and
this
feature
gate
must
have
the
following
following
features
registered,
which
perhaps
very
hard
to
document
at
the
highest
level.
Because
then
you
basically
need
to
know
at
the
at
the
top
level.
What
feature
gates
might
be
used
anywhere
and
record
where
you
pass
through
that
feature
gate
instance.
B
D
A
B
Then
what
what
if
that
component
is
called
indirectly
so
command
so
say
a
component
uses
just
component-based
cli
component
c
is
component-based.
Cli
calls
component-based
logs.
Now
we
need
to
have
a
new
api
and
component
based
logs
for
farage
string
feature
gates,
and
we
must
have
the
same
thing
in
component
base
cli,
which
calls
component-based
logs
to
register
the
feature
gateway
it
trickles
down
through
all
of
the
components
that
are
involved
in
that
chain.
B
B
Components
just
use
component
based
cli
and
the
run
method
handles
log
initialization.
D
I
mean
I
I
feel
like
in
some
ways
this
is
like
we
had
a
very
unconfigurable.
A
D
Everything
was
a
global
method
and
it
did
what
it
did
and
then
all
the
configuration
got
added
as
global
flags.
Basically,
and
now
we're
saying
no,
we
actually,
we
actually
want
to
be
able
to
configure
this
like
nest,
the
configuration
inside
the
cubelet
config
or
the
scheduler
config,
or
something
like
we
don't
want
this
global
config,
and
it's
revealing
that
we
didn't
actually
have
an
instance
of
the
logging
component
that
was
being
configured.
B
Yeah
well
I'll
I'll
do
one
thing
I'll
I'll
update.
I
change
the
pr
to
this
other
alternative
implementation,
and
then
I
don't
know
jordan
or
elana
can
look
at
it
again
and
say
that
this
looks
right.
This
looks
looks
reasonable
and
if
it
does
then
yeah-
okay,
let's
let's,
let's
pick
back
that
alternative
and
if
not,
we
can
go
back
and
and
and
swap
out
with
the
current
content
of
the
pr
and
and
move
the
default
feature.
Gate
instance.
B
D
B
Gates
immediately,
which
actually
brings
me
to
a
third
topic,
which
I
noticed
when,
when
looking
at
this
pr
again,
we
have
traditionally
had
say
logging
output,
json
as
an
alpha
feature,
and
now
it's
beta.
But
now,
if
we
add
for
feature
gate
check,
suddenly
people
would
no
longer
be
able
to
use
logging
con,
locking
format.
Json,
like
we
did
in
the
previous
release.
They
would
also
have
to
enable
the
addition
they
have
a
corresponding
feature.
Gate.
B
Okay,
we
you're
right
beta
beta,
would
be
enabled
so.
Okay,
I
already
tracked
that
it
would
be
the
alpha
features
which
we
still
have,
but
those
are
fairly
new.
I
think
that
is
reasonable
and
yeah
okay,
never
mind.
I.
I
got
confused
about
the
enable
state
of
beta
again
yeah,
okay,
good
thanks
guys
for
listening,
and
I
hope
you
enjoyed
the
discussion
we.
B
D
Take
a
look
to
it
at
the
alternative
and
see
if,
if
there's
a
way,
we
can
make
it
user
friendly
and
also
sort
of
isolated,
so
I'm
I'm
open
to
tweaking
where
things
go
or
changing
signatures
on
things
to
make
it
clear
to
make
it
harder
for
people
to
make
mistakes,
so
we
can
think
about
anything
there.
Okay,.
A
Okay,
all
right,
we
have
the
other
topic
that
we
want
to
discuss
around
the
whether
we
have
multiple
feature
gates,
one
for
each
option
or
we
have
one
controlling
alphabet.
Do
we
want
to
talk
about
that
or.
D
Maybe
people
who
are
there
for
the
cpu
discussion
can
correct
me,
but
my
understanding
was.
We
didn't
really
need
the
granularity
of
one
gate
per
feature
as
long
as
we
also
had
the
granularity
of
one
config
field
for
future.
A
So,
basically,
with
the
cpu
manager,
one
you
would
be
enabling,
in
order
to
use
a
particular
option
value,
you
would
be
enabling
a
feature
gate
specific
to
that
option
value,
and
so
basically
it's
the
same
person
right.
It's
not
like
you
had
one
person
who
would
enable
the
feature
gate
at
a
different
person
who
would
configure
the
option.
It's
the
same
person
in
the
same
command
line
right
and
it's
just
sort
of
like.
Oh
I'm
going
to
put
two
options
in
instead
of
one
what's
the
value
here.
D
So
if
you
want
to
turn
the
feature
off,
you
just
comment
out
that
field
and
that
config
file,
as
opposed
to
like
an
api
where
there's
a
thousand
copies,
and
we
want
to
like
stop
new
stuff
from
coming
in
and
then
like
have
to
dig
through.
What's
already
there
like
that,
that
dynamic
just
doesn't
exist.
A
F
Sorry,
john,
I
I
just
tried
in
an
atomic
topic.
Sorry,
as
we
were
talking,
I
updated
api
snip
and
there
is
new
endpoints
that
came
in
properly
this
week.
Storage
capacity.
D
A
Okay,
awesome,
and
that
sounds
like
that's,
not
a
good
issue.
Okay!
Well,
thank
you.
Everybody
have
a
great
couple
of
weeks,
bye.
Everyone.