►
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
Hi
welcome
to
the
component
standard
breakout
meeting
for
discussing
component
config
problems,
issues
and
evolutions.
This
is
intended
as
a
collaborative
meaning
between
the
component
standard
working
group
and
api
machinery,
and
we
would
like
to
discuss
the
agenda
today
is
in
an
ad
hoc
meeting
document.
That's
been
linked.
C
Can
you
see
the
block
yep
okay?
So
the
first
question
here
is
what
is
like
the
place
where
we
would
like
component
context
for
different
components.
So
the
idea
is
that
many
components
would
like
to
store
their
conviction
component
maps,
but
we
don't
want
to
like
force
data
onto
components.
We
would
like
some
soft
solution.
C
Try
to
just
have
a
file
from
the
components
perspective
and
whether
this
file
is
actually
stored
into
a
config
map
and
brought
on
as
a
configmap
volume
source
or
whether
this
is
actually
pulled
from
somewhere
else
and
put
up
together
by
a
hit
container
or
something
like
this
like.
This
is
basically
the
choice
of
the
deployment
so
actually
like.
A
So,
where
we're
at
currently,
as
far
as
I'm
aware,
is
that
we
ask
components
to
provide
a
config
flag
that
accepts
a
file
name.
This
is
compatible
when
a
component
is
hosted
in
a
kubernetes
cluster
with
the
configmap
strategy,
and
then
we've
got
some
additional
magic
happening
with
other
components
that
are
not
hosted
by
kubernetes
being
able
to
fetch
from
the
api.
A
A
I
think
that
it
should
be
possible
to
run
kubernetes
outside
of
using
kubernetes
hosting
services,
but
you
might
argue
that
the
config
should
be
introspectable,
so
we've
had
issues
in
the
past
with
people
trying
to
determine
like
what
the
what
subnet
a
cluster
is
running
in
in
order
to
configure
a
networking
add-on
and
not
being
able
to
introspect
the
api
server.
Config
makes
it
really
difficult
to
know
what
that
value
is
like
just
from
the
primitives
inside
the
cluster.
D
A
Like
my
because,
if
you,
if
you
look
at
other
tools
in
the
space
like
prometheus,
has
a
config
endpoint,
you
know
where
you
can.
You
can
see
what
the
running
config
is,
but
docker
has
docker
info
container
d.
You
can
inspect
like
how
it's
running
so
I
mean
it
makes
sense
that
with
some
level
of
access
you
you
should
be
able
to
know,
but
you
may
need
to
query
the
component
itself
and
not
just
the
api.
A
A
B
A
A
A
A
Kuberdam
does
something
interesting
in
that
it's
storing
multiple
versions
of
the
kubelet
config
in
different
config
maps-
I'm
not
mistaken.
So
there's
even
that.
I
think
we
have
listed
here
that
the
component
name
would
be
the
key,
but
version
at
a
minimum
is
at
least
another
key
and
then,
if
people
are
running,
you
know
components
for
different
reasons.
You
may
even
need
additional
keys
so.
C
E
So
I
have
a
few
comments
about
this
question
in
general,
if
you,
if
you
want
to
store
a
company
config
in
the
cluster
in
my
understanding,
config
map,
my
understanding
here
is
that
you
use
use
the
cluster
here
as
a
medium
to
transfer
the
component
config
from
one
node
to
another,
or
this
is
something
this
is
a
component
config
that
applies
to
all
the
nodes,
so
it
has
to
be
shared.
Shared
basic
configuration,
some
sort
of
a
base
configuration
for
all
the
components
that
run
on
the
nodes.
E
A
I
I
have
some
questions
and
I
think
some
some
fundamental,
like
disagreements
and
understanding
on
problem
space.
So
if
there's
only
one
config
map
allowed
in
the
cluster,
then
it
makes
it
very
difficult
to
do
a
proper,
rolling
upgrade
of
components
if
there
are
multiple
of
them.
The
kubelet
is
a
great
example.
A
If,
like
a
rolling
upgrade,
should
always
allow
you
to
store
both
versions
of
the
config
that
are
intended
to
be
used
explicitly.
They
should
never
be
implicitly
loaded
because
components
started
at
a
certain
time
and
that
doesn't
not
need
to
even
be
a
different
version
of
the
kubelet
config
api
or
different
versions
of
couplets.
F
A
F
F
F
So,
if
you
are,
you
know
changing
the
data
that
goes
into
config
map,
you'll
get
a
new
config
map
with
a
new
name,
and
then
you
can
roll
that
new
one
out
by
changing
the
reference
on
a
deployment
or
if
it's
like
cubic
config,
you
know
that's
in
the
node
object
or
whatever
you
that's
pretty
streamlined
to
do
it.
That
way.
So
there's
we're
really
we're
not
forcing
anyone
to
to
change
config
maps
in
place.
C
So
here
is
another
question
like
whether
we
should
actually
allow
this
to
be
done
solely
by
the
component
itself,
like
upgrade
their
own
coffee
mug.
When
a
version
is
like
changed
or
like
their
own
conflict,
when
a
version
is
changed
in
the
conflict
or
whether
we
should
actually
ask
cluster
provisioning
tools
to
actually
do
that.
For
us.
F
F
The
common
owners
are
going
to
have
to
do
some
amount
of
work
to
allow
those
conversions
to
happen
now.
I
think
the
second
question
is
like
it
sounds
like
there's
a
common
piece
here
on
some
method
of
up,
converting
and
writing
back
out
or
like
querying
a
component
for
what
you
know.
The
data
in
the
old
version
would
look
like
in
the
new
version
or
something
like
that,
and
maybe
that's
something
that
we
can
reach
common
ground
on
and
implement
as
a
common
tool.
F
G
F
G
F
Maybe
I
think
when
we
start
thinking
about
tools
like
cube,
adm,
that
write
config
out
and
if
cube
adm's
involved
or
some
other
tools
involved
in
an
upgrade
there.
There
was
a
conversation
a
few
weeks
ago
about
whether
such
a
tool
should
be
able
to
automatically
up
convert
your
config
across
the
version
boundary
for
you,
and
I
think
that's.
C
Yeah,
I
think
that
by
generally
speaking,
in
most
cases,
we
would
actually
be
like
just
converting
already
existing
options.
So
nothing,
that's,
really
dropped
out
of
support,
so
allowing
us
to
up
convert
the
like
component
configs
for
the
components
that
are
managed
by
keep
admin
will
actually
allow
us
to
do
like
simplest,
simple
upgrade.
That's
like
just
not
bothering
users
to
go
and
manually
edit
yaml.
G
G
F
G
A
version
boundary
typically
is
intended
to
be
a
conscious
change
like
I
was
writing
to
this
old
api.
I
could
expect
the
behavior
of
that
old
api
to
be
consistent
release
to
release
when
I
change
the
new
api.
What
are
the
differences
between
them
and
it
seems
like
this
automatic
conversion
is
trying
to
hide
and
mask
that
which
either
means
you
do
something
unexpected
to
users,
which
is
change
behavior,
silently
or
it
does
what
we
don't
want,
which
is
lose
the
benefit
of
the
version
boundary
like
by
hiding
this
from
users.
A
A
G
A
G
I
the
tool
is
the
tool,
is
adding
a
layer
between
the
api
and
the
user,
and
so
in
a
sense,
the
tool
is
its
own.
Api
right,
like
people
are
invoking
cube
atom
in
a
certain
way,
with
command
line,
flags
or
overrides,
or
something
and
expecting
consistent
behavior,
so,
like
cube
atom,
has
become
its
own
api,
even
though,
under
the
covers
it's
making
use
of
component
config
apis.
F
A
So
my
proposed,
I
do
have
proposed
solution
that
I
was
working
toward
with
that
kind
of
background,
which
is
that
you
have
the
ability
to
do
a
sophisticated
conversion
that
preserves
what
the
user
is
explicitly
intending
in
their
file.
That
is
exposed
via
the
components
command
line
api
as
an
explicit
action.
That's
documented
as
to
what
it's
doing
the
other
conversion
type
you
know
maybe
could
also
be
available
through
that
method,
but
that
when
an
old
api
is
provided
to
a
component,
that
we
do
the
existing
automatic
conversion.
As
noted
in
the
document.
G
B
G
F
I
think
I
think
what
what
the
question
is
is
like
today
now
correct
me
if
I'm
wrong,
because
I'm
not
super
familiar
with
cuba
dm
and
I
don't
use
it
frequently.
However,
my
impression
is
today
cube.
Adm
has
its
config
for
cube
adm
and,
as
a
result
of
that,
it
spits
out
configs
for
components
of
kubernetes,
and
I
think
the
the
sort
of
question
is.
You
know
across
upgrades
over
a
long
period
of
time.
F
We
have
to
assume
that
on
in
terms
of
the
kubernetes
components,
old
versions
will
be
eliminated
and
what
qbm
was
spitting
out
for
those
before
it
will
no
longer
be
able
to
like
provide
and
it'll
have
to
go
to
the
new
version,
and
the
question
is
like
how
to
manage
that
transition
from
the
end
user
of
cube,
adm's
perspective,
so,
like
you
know,
does
q8m
have
to
you
know,
be
more
helpful
and
say:
hey
look!
We're
gonna
like
spit
out
new
versions
of
these
configs
and
defaults
change.
Do
you
want
the
new
behavior?
F
C
G
B
F
G
And
a
lot
of
the
reason
that
we
have
the
requirements
around
defaults
and
behaviors
staying
consistent
is
one
component
in
isolation,
doesn't
know
how
the
rest
of
the
cluster
is
configured
right,
and
so,
if
the
api
server,
like
suddenly
said
you
know
what
every
time
I
talk
to
a
cubelet,
it
has
to
be
secure.
Now,
like
the
api
server,
doesn't
know
if
all
the
cubelets
are
have
been
configured
correctly,
but
a
tool,
a
cluster
lifecycle
tool
that
is
responsible
for
setting
up
the
whole
cluster
can
know
like.
As
of
this
version,
we
have
this.
G
G
So
that's
that's
more.
What
I
expected
like
the
the
cluster
lifecycle
tool,
that
has
knowledge
of
the
different
components
and
knows
how
it
is
configuring
them
over
time,
moves
them
to
use
to
stop
using
deprecated
options
to
start
using
more
secure
options,
and
once
it's
safe
to
move
all
of
the
pieces
to
work
together
and
you're,
not
using
any
more
deprecated
options,
then
you
can
start
writing
the
new
v1
config
yeah.
That
allows
those
old
options.
F
C
Expose
basically
everything
so
almost
like
cube
proxy
and
cubelet
do
have
their
entire
component
complex
exposed,
so
you
can
actually
supply
them
and
in
addition
to
that,
we
also
support
extracts
and
extra
volumes
for
all
the
kubernetes
core
components.
So
you
can
actually
supply
an
extract
to
the
api
server
and
you
can
actually
override
practically
everything.
That's
exposed
by
a
command
line
and
in
addition
to
that
cube,
adm
actually
does
have
some
knowledge
and
hardwires
a
bunch
of
stuff
and
maybe
even
in
some
corner
cases,
override
user's
byte
options.
G
And
over
time
that
alpha
config
is
deprecated
and
the
beta
and
v1
versions
become
available
and
like
if
the
user
has
taken
it
among
themselves
to
customize
this
install
and
provide
like
the
underlying
config
files,
then
they
should
be
responsible
for
updating
those
being
aware
of
the
changes
between
them.
The
user
doesn't
have
to
provide
those
right
like
cube.
Atom
provides
reasonable
defaults.
If
you
just
say
like
give
me
a
cluster,
so
users.
G
C
Do
we
actually,
like
is
the
baby
and
the
component
that
stores
the
logic
inside
of
it
like
for
pumping
each
and
every
field
inside
of
this
config,
or
is
it
actually
invoking
some
somehow
either
a
scheduler
itself
or
some
other
component
to
actually
do
that
automatically?
Basically
outsourcing
the
logic
from
kubernetes?
How.
G
G
C
Well,
in
the
case
that,
like
the
user
is
not
interested,
it's
probably
going
to
be
cube
atom.
So
if
you
have
like
initialized
clustering
via
running
cubed,
a
minute
and
then
kubernetes
enjoying
on
a
bunch
of
machines
and
you
haven't
supplied
any
config,
so
basically
just
run
kubernetes
a
minute
incubation
join
and
then
upgrade
that
this
version
by
accubation
upgrade.
G
G
That's
there
and
like
regenerate
it,
or
should
we
try
to
like
patch
in
these
things
to
an
existing
config
like
separating
inputs
and
outputs,
really
really
clearly
and
saying,
the
output
is
owned
by
cube
atom,
the
inputs
are
owned
by
the
user
and
the
power
user.
That
provides
a
fully
provides.
A
config
file
like
that
might
just
be
a
pass-through
like
q.
Adam
takes
that
and
stomps
it
onto
the
output,
the
the
simplistic
user
that
just
says
give
me
good
defaults.
G
Yeah,
like
you
really
you
really.
It
makes
it
hard
to
handle
cases
like
the
thing
in
place
is
corrupted
or
messed
up
and
it's
like.
Is
it
really
messed
up
or
do
we
is
this
just
a
fancy
user
provided
thing
that
we
don't
understand
and
by
fixing
it
we're
gonna,
destroy
their
data
and
so
like
inputs
and
outputs
and
cube
atom,
owning
the
outputs
and
being
free
to
stomp
them
or
regenerate
them,
or
generate
a
peer
file
and
roll
out
the
new
file?
However,
the
rollout
happens.
F
F
A
F
C
G
E
A
I
mean
I
don't
I'm
not
I
as
an
operator,
I
would
not
be
concerned
with
you,
know
old
versions
of
my
config
maps
for
components
sitting
around
in
the
cluster
as
long
as
they're,
clearly
named
by
their
timestamp
passion
version.
I
can
see.
Oh,
like
those
are
old
api
versions
that
were
used
at
this
time
stamp
with
this
hash.
A
A
C
Yeah,
I
think
we
have-
and
there
is
like
probably
some
room
for
the
last
question,
which
is
basically
exposing
some
sort
of
validation
for
component
conflicts.
So,
basically,
cubadiem
allows
users
to
just
do
sort
of
a
basic
component,
config
validation
on
what
it
is
generating,
and
this
is
probably
going
to
go
away.
If
we
move
out
of
trees.
C
Since
we
can,
we
can't
actually
use
the
internal
types
of
like
the
different
component
conflicts
and
we
should
probably
like
investigate
whether
we
should
allow
for
some
sort
of
command
line,
option
or
a
piece
of
code
that
we
can
actually
use
inside
of
cubadiem
to
basically
validate
component
configs
or
simply
like
just
prepare
everything
like
just
start.
The
the
public,
the
static
bots
and
just
see.
If,
if
it's
going
up
or
it's
crushing,.
G
Yeah
there
are
like
three
levels
of
validation,
there's
kind
of
the
direct
syntax
validation
like
did
you
put
a
negative
one
in
a
field
that
should
only
be
positive
numbers
or
something,
and
then
there's
like
referential
validation.
So
if
you
reference
like
a
tls
certain
key,
do
those
files
actually
exist
and
do
they
load
and
parse
correctly?
G
And
then
the
third
level
is
like
environmental
validation
like
if
you
start
the
cubelet
on
a
machine
without
swap
or
with
swap-
and
you
don't
have,
the
tolerate
swap
option
turned
on
like
that's
gonna
fail
and
so
like.
The
first
two
can
be
done
on
other
platforms
like
not
in
the
actual
target
environment.
G
If
some
of
the
user
input
is
folded
into
the
config,
and
so
it's
like
a
user
said,
I
want
this
dot
and
the
other,
and
then
that
got
generated
into
a
config
file.
It'd
be
nice.
To
be
able
to
say
is
this:
is
this
valid
or
did
the
user
give
me
data
that
produced
like
an
impossible
config
that
the
component's
gonna
barf
on.
A
F
Yeah,
that's,
I
think
it's
valuable.
I
think
the
question
is:
how
do
we
do
it,
because
there's
today,
like
there's
sort
of
a
policy
that
we
don't
export
internal
types
from
the
tree
if
q8m
moves
out
of
tree
validation
code
today
runs
on
internal
types.
So
how
does
it
continue
to
consume
the
source
of
truth
for
validation,
for
a
given
config
there's
also
a
question.