►
From YouTube: 20200723 SIG Architecture Code Org
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
all
right:
this
is
the
code
organization
meeting
for
july
23rd
2020..
We
have
a
fairly
light
agenda,
so
hopefully
we
will
have
plenty
of
time
for
discussion.
A
couple
of
things
off
the
top.
There
was
a
link
around
the
discussion
for
picking
a
name
for
the
proposed
library
go
package.
A
A
A
Personally,
I
think
api
helpers
or
component
helpers
is
fine,
so
yeah
second
item
was
around
moving
cubelet
apis
to
an
externally
available
location.
So
it
looks
like
these
are
the
like:
the
device
manager
or
the
cri
apis.
I
know
these
are
the
config
apis
that
right.
B
Yeah,
they
still
need
review
from
sync
node,
so
I
just
like
it
was
just
an
fyi
in
case.
You
want
to
look
at
it
here.
Okay,.
A
A
C
B
A
All
right,
walter.
D
D
So
it'd
be
good
for
us
to
have
some
opinions
about
where
those
cannon
can't
live,
how
we
initialize
them,
how
we
make
sure
the
initialization
is
consistent,
and
it
would
also
be
nice,
at
least
in
my
perspective,
to
try
and
make
sure
that,
if
you're
using
a
feature
that
it
is
initialized
and
that
if
it
isn't
initialized
that
it's
a
compile
time
error,
not
a
runtime
error,
I'm
happy
to
chat
about
it.
D
That's
sort
of
my
broad
perspective
on
on
this,
and
then
I
know
like
david
on
david
eads
on
api
machinery.
Also
would
if
we're
not
careful
about
it,
he
has
concerns
that
we're
gonna
end
up
with.
He
doesn't
like
the
nets
to
begin
with
and
he's
a
little
concerned,
we're
going
to
end
up
smearing
init
in
multiple
packages,
each
separately
setting
up
a
subset
of
the
features.
C
A
All
right,
so
I'm
trying
to
take
each
of
the
things
you
brought
up
brought
up
so
we're
defining
features
in
multiple
places.
So
we
already
did
this
for
api
server
features
and
cube
features,
and
the
question
is
like
what
a?
How
do
we
want
to
approach
this,
as
we
start
like
partitioning
more
about
like
what
is
the
primary
owner
for
a
given
feature?
A
A
C
D
C
D
Registered
correctly
now
david
and
I
researched
this
last
week
and
we're
fairly
convinced
it
will
throw
an
error
if
you
ask
for
something
that
isn't
enabled
it
does
it
does
that
isn't
registered,
it
does
now
so.
A
D
A
Yeah,
and
so
the
only
way
for
that
to
happen
is
for
us
to
auto
register
on
init.
Is
that
correct.
D
I'm
not
convinced
it
is.
Actually
I
mean
so
if
there
is
well
maybe,
but
if
the
points,
if
we
somehow
can
hook
the
the
declaration
of
the
constants
with
a
a
something
that
puts
itself
in
or
is
somehow
called
from
the
inet,
then
the
the
fact
that
you're
pulling
in
one
means
you
get
the
other
but
yeah.
That
may
mean
you're
you're
dealing
with
the
net.
E
E
E
D
So
andrew,
I
don't
know
what
anyone
else's
experience
was,
but
that
was
mostly
static
for
me.
D
D
B
D
A
A
D
D
D
But
yes,
his
his
suggestion
was
definitely
that
there
be
a
register
method
so
that
you
could
actually
have
the
features
in
the
appropriate
places
and
they
would
register
in
the
appropriate
packages
and
then
they
would
register
with
some
some
very
low
level
library
that
actually
did
the
feature.
Work.
A
C
C
I
think
yes,
I
believe
so.
Okay.
B
A
Sorry
I
should
share
my
screen.
It's
not
watch
me
frown
my
monitor
yeah,
so
I
talked
when
I
talked
through
this
with
david
having
the
the
feature,
definitions
and
api
made
sense
to
me:
they're,
basically
just
constants
maps
to
current
state,
and
that
is
strongly
tied
to
a
particular
version.
D
Then
I
mean
to
be
clear:
it's
not
the
that's
a
nice
to
have.
I
just.
I
am
generally
in
favor
of
anything
that
allows
for
compile
time
versus
runtime
errors,
especially
since
every
cloud
provider
is
going
to
be
creating
and
maintaining
their
own
copy
of
the
ccm
and
maybe
adding
their
own
controllers
with
their
own
features,
and
so
I
would
like
this
to
be
as
bulletproof
as
possible.
A
Is
if
we
auto
register
features
on
import?
A
What
happens
if
a
cloud
provider
wants
to
change
a
default
value
for
a
feature
in
their
build?
A
Does
that
break
or
does
it
work
like,
because
I
can
imagine
like
the
defaults
for
x,
y
and
z,
especially
for
some
of
these
things
like
they
default
false
because
they
require
setup
and
other
things,
but
then
a
particular
cloud,
controller
or
cloud
would
want
to
say
we
want
to
default
like
we
are
now
doing
that
setup.
We
want
to
default
it
on
in
this
version.
Can.
D
They
do
that
well,
I
think
one
way
or
the
other
they're
going
to
be
able
to,
but
it's
an
interesting
question
because
I
believe,
if
you
actually
dig
through
the
code
today,
if
the
you
end
up
having
the
fields
re-register
between
public
and
private,
between
the
api
server
and
the
kk,
and
when
the
kk
re-registers
the
value,
if
it
finds
the
value,
has
changed,
I
believe
it
actually
blows
up.
D
D
And
I
mean
beyond
that
I
I
would
suggest
that
that's
probably
reasonable
in
that.
If
a.
If
someone
wants
to
change
the
feature
value,
it
could
probably
be
done
through
the
cli
or
the
config,
not
through
code.
A
A
D
I
mean
that's
true,
but
I
will
point
out
like
if
you
look
at
them
doing
it
with
a
different
library
like
client
go
if
you're
using
the
wrong
version
of
client
go
to
talk
to
your
master
sooner
or
later,
that's
going
to
create
problems.
So
I
don't
think
this
is
new
yeah.
A
And
then
the
other
question
I
had
is:
do
we
want
to
prevent
client
go
from.
A
Features,
I
think
we
do
because
client
go,
doesn't
have
a
mechanism
for
toggling
those
features
like
today.
The
features
are
defined
at
a
much
higher
level,
and
so
like
it's
just
sort
of
crazy
to
be
like.
How
does
my
client
behave?
It's
like
well,
it
depends
it
depends
like
did
you
set
a
features
like
what
future
I
don't
have
any
control
over
the
features.
D
So
to
play
devil's
advocate-
and
I
think
you're
right,
but
I'm
still
going
to
play
devil's-
advocate
the
new
priority
in
fairness
like
if
I
feature
gay
priority
in
fairness,
I
could
see
maybe
wanting
to
turn
off
or
somehow
control
the
client's
rate
limiting
behavior
in
conjunction
with
how
priority
and
fairness
is
set.
A
A
Okay,
if
we,
if
we
move
it
there,
I
think
at
least
to
start.
We
should
set
up
import
guards
to
prevent
client
go
from
referencing
that
package,
so
that
we
don't
do
it
accidentally.
C
A
The
the
the
one
downside
I
can
see
for
init
blocks,
so
if,
if
all
features
live
in
it's
I
o
api
and
all
register
on
emit,
then
the
utilities
we
have
that
bind
those
to
like
a
command
line
flag
will
always
list
all
features
in
that
release.
D
So
I
think
that
was
I
mean
so
so
the
thought
had
been
that,
while
we
did,
I
mean
so
we
should.
I
think,
let
me
go
back.
I
think
when
david
was
looking
at
breaking
this
out,
I
mean
he
was
looking
at
defining
them
at
the
bottom-most
level,
so
you
have
sort
of
the
visibility
of
what
all
possible
feature
flags
are,
but
then
actually
setting
up
the
initialization
at
appropriate
points.
D
D
So
you're
I
mean,
if
you're,
not
using
the
service
controller,
then
you're
getting
that,
even
though
those
flags
even
and
they're
being
registered,
even
though
you
don't
want
them,
but
only
when
you
pulled
in
service
control
or
would
you
get
those
too?
I
believe
that's
how
he
was
trying
to
set
it
up.
A
I
see
so
okay,
so
it's
on
a
nit,
but
it's
on
a
knit
of
a
particular
component,
which
means
that
you,
you
don't
get
the
behavior.
You
want,
where,
like
I've,
written
a
random
program
and
I'm
referencing,
the
kids
io
api
feature
definition,
but
I
didn't
import
this
thing
over
here
which
registered
it.
D
And
yeah,
like
I
said
mine,
is,
I
think,
more
of
a
nice
to
have.
I
just
worry
that
it's
really
easy
to
write
one
of
these
things
and
fail
to
admit
it
correctly
unless
you're
using
init
blocks,
like
you
have
to
know,
I'm
pulling
in
these
four
packages,
and
so
I
have
to
call
each
of
their
four
register
feature
methods
to
get
the
features
I
need,
and
if
I
don't
it'll
become
a
runtime.
C
A
Is
there
a
pattern
we
want
to
use
for
this,
like
if
you,
if
you
call
dot,
enabled
and
you
pass
in
the
feature
name
like
at
the
top
of
that
file,
there
needs
to
be
an
init
block.
That
says
I
use
this
feature
name
so
that,
if
anything
by
any
path
like
imports,
this
file,
I
I
can
be
sure
that
this
feature
is
registered.
D
A
I
mean
the
alternative
is
smearing
panics
across
multiple
repos,
because
if
it's
run
time
like
a
lot,
a
lot
of
the
cases
where
features
are
checked.
They're,
like
exceptional
cases
like
I
did
a
thing
and
then
I
encountered
this
and
then
I
did
this
and
it's
slow
and
I
got
an
error
so
now,
if
this
feature
is
enabled
boom,
you
know
like.
D
A
A
A
A
Package,
where
they're,
where
the
features
are
defined,
what's
what's
an
alternative?
A
A
What
about
having
a
register,
all
method
and
we
register
all
from
the
main
package
of
all
of
our
all
of
our
binaries
and
anyone
who
wants
to
use
features
it's
a
one-liner
to
say
like
register
all,
and
if
you
don't
care,
then
you'll
get
everything
and
you'll
never
hit
a
panic.
And
it's
easy.
If
you
do
care,
then
you
can
like,
instead
of
registering
all
you
can
register
the
particular
ones
that
you
want
to
honor.
A
Where
would
register
all
live?
I
would
say
in
the
same
package
that
we
define
the
features.
A
So
so
similar
to
where
we
define
types
and
we
have
an
add
to
scheme
what
about
a
register
public
in
a
register
all.
D
D
Staging
that's
what
I'm
thinking
and
I
mean
that
I
like
that
anyway,
because
if
we,
if
as
soon
as
we
make
it
staging
we're
saying
it's
part
of
our
public
api
and
now
we
have
to
worry
about
things
like
deprecation
policies
that
backward
compatibility,
deprecation
policy,
etc.
So
I
think
only
add
that
burden
to
ourselves
for
the
features
we
actually
need
to
support.
A
Seems
like
it's
probably
okay,
do
we
do
we
think
there's
a
do.
We
anticipate
like
shortly
moving
all
the
things
that
cube
api
server
uses
to
staging
and
then
moving
them
to
api
like
if
we're.
If
we're,
if
we
really
think
it
will
be
a
small
number,
then
it
seems
okay
to
divide
them.
If
we
think
it's
going
to
be
like
a
third
of
them
and
the
next
release,
another
third
of
them
are
going
to
move
and
then
the
next
release
the
rest
of
them
are
going
to
move.
A
D
D
D
A
So
api
server,
you
said
cloud:
is
it
mostly
cloud
controller
manager.
A
Right,
but
if
I
mean
if
there
were
other,
if
there
were
other
controllers
that
lived
in
cloud
controller
manager,
which
used
feature
gates
like
you,
would
need
to
be
available
also
so
things
referenced
from,
and
that
is
because
we
expect
people
to
be
sort
of
building.
On
top
of
cloud
controller
manager.
More
than.
D
D
Have
their
own
builds
like
the
the
ccm
that's
in
kk
as
a
reference
implementation?
It's
not
meant
to
be
used
by
we're,
not
necessarily
meant
to
be
used
by.
In
fact,
we
don't
even
ship
it
anymore.
So
it's
a
reference
implementation.
Only
in
kkk.
You
need
to
make
your
own
copy
for
your
own
cloud
provider
and
then
csi
csi's,
the
other
one
csi
would
be
the
other
one,
I'm
familiar
with.
D
D
D
A
D
But
well,
and
I
wouldn't
be
surprised
if
they're
pulling,
I
think,
there's
a
new
like
ephemeral.
Storage
feature
feature
gate,
so
I
wouldn't
be
surprised
if
they
end
up
calling
that.
A
A
D
A
D
C
D
A
But
the
default
state
of
the
feature
is
not
programmatically
referenceable,
so
I
agree
that
the
name
is
api
and
so
there's
there's
like
three
levels:
there's
is
there
a
string
constant
that
has
the
name
that
you
can
reference
like
eh
sure,
like
throw
all
of
those
in
case
I
o
api?
I
don't
I
don't
care
about
that
then
there's
like
is
it
alpha
beta
ga
deprecated
enabled
by
default
locked
to
the
default?
A
C
D
One
other
quick
question
sort
of
and
that,
on
your
point
two,
there
is
a
silly
end
run.
You
can
do
around
your
point
two,
which
is
to
pass
about
it
being
programmatic,
which
is
you
can
pass
a
string
in
and
that
will
rather
than
put
passing
in
the
constant.
A
That's
fine,
I
mean
like
requiring
people
to
reference.
Our
programmatic,
constant,
drives
me
crazy.
Like
someone
says
I
I
can't.
I
can't
drive
this
because
I
don't
have
a
constant
available.
It's
like
it's
a
constant
just
just
use
a
string
like
that's
fine.
If
the
string
worked
in
your
testing,
it
will
work
in
prod.
D
I
accept
well
here's
my
thing:
the
string
will
makes
it
so
it's
no
longer
a
compile
time
error
right
now.
You
converted
it
back
to
a
runtime
error,
yeah
and
so.
A
C
A
One
is
not
not
blindly
moving
all
features
out
to
kids,
I
o
api,
but
just
like
the
ones
that
we
intend
to
be
consumed
externally
for
now,
and
then
the
third
was
an
easy
way
for
people
to
register
all
of
the
features
we
do
expose
for
those
who
don't
care
about
curating,
and
then
we
would
call
that,
from
probably
from
the
main
method
of
all
of
the
components
we
ship
yep.