►
From YouTube: SIG Cluster Lifecycle - kubeadm office hours 2021-05-26
A
A
B
Plane
yeah,
I
just
wanted
to
talk
about
the
utils
that
we
recently
added,
or
at
least
the
cl
the
pr
is
out
for
and
kind
of
get
an
agreement
on
like
how
we
want
to
move
forward
with
that,
because
I
saw
your
comment
on
that
that
you
were
experimenting
with
directly
in
go,
manipulating
the
files
and
then
I
started
reading
more
about
it,
and
then
one
thing
that
I
found
everywhere
was
that
hey
don't
like
manipulate
these
files.
B
Manually
use
like
existing
tooling
so
like
so
I'd,
be
interested
in
hearing
more
about
the
approach
that
you
wanted
to
take
for
that
because
one
of
them
one
of
the
there
is
a
manual
way
to
do
it.
There
is
like
a
command,
it's
I
think
it's
called
vipw
and
what
it
does.
Is
it
actually
mutually
exclusively
like
locks,
the
slash
edc,
password
file,
right
and
and
if,
if
we
can
do
that
in
in
go,
then
that
is
the
only
safe
way
of
doing
it.
B
Otherwise,
you
might
run
into
like
intention
issues
where
two
things
are
trying
to
like
write
to
that
file
together
and
they
might
mess
each
other
up
right
and
and
then
that
would
leave
the
user
in
like
a
state
where
it's
like
it's
hard
to
recover
from
without
manual
intervention.
There.
B
The
approach
of
like
creating
these
groups
and
kind
of
going
back
to
our
idea
of
like
having
the
user
specify
in
the
cluster
configuration
what
ids
they
want
to
run,
at
least
for
for
linux,
because
I
know
like
in
in
in
the
windows
world
right
like
you,
cannot
just
assign
ids
without
users
being
created
for
those
ideas,
but
in
linux,
that's
fine,
and
maybe,
as
like
alpha
or
like
early
stage,
we
should
offload
that
responsibility
to
the
system
owner,
because
each
system
kind
of
has
its
own
way
of
adding
users,
as
we
found
out
that,
like
the
commands,
the
the
utility
name
is
the
same,
but
the
way
they
behave
is
pretty
different
in
terms
of
the
arguments
they
take.
A
It's
a
complicated
problem.
I
think
the
biggest
argument
against
rnds
in
the
api
is
that
this
feature
is
offered
by
the
api
is
bitter,
so
we
are
jumping
a
hoop
and
going
graduating
the
feature
to
beat
it
by
adding
the
the
fields
which
is
a
problem.
Adding
the
a
bunch
of
flags
makes
this
very,
very
boss
on
the
command
line.
It's
like
it's
not
readable.
Even
I
cannot
imagine
how
are
we
going
to
at
so
many
flags?
A
The
fact
the
flags,
also
by
the
way,
are
unless
they
are
prefixed
with
experimental
means
that
the
flags
are
also
like
almost
a
ga
api.
A
In
fact,
the
coi
is
more
stable
in
kubernetes
than
the
configuration
format
so
that
that's.
That
was
the
main
argument
with
the
cap
like
maybe
we
should
add
the
users
automatically
and
then
we
can
pick
or
allocate
the
users
automatically
pick
the
users
and
then
assign
it
to
containers,
but
I
guess
this
is
also
context
for
fabrizio.
I'm
not
sure
you
saw
this
my
my
analysis
here,
but
the
the
basic
the
problem
is
that
the
linux
ecosystem
is
a
bit
of
a
mess
in
terms
of
tools
for
adding
users
using
groups.
C
Yeah,
I
I
I
don't
I
I
don't
sorry
I
I
I
didn't
saw
that
the
comment
I
like
it
a
little
bit
behind
because
we
are
near
the
copy
releases,
so
I'm
a
little
bit
over
scheduled,
but
I
I
have
a
question
for
vineyard.
So
so
these
are
this
by
the
way,
let
me
say
by
node,
so
they
can
be
different
on
each
machine
on
each
control
plane
machine
or
they
are
we.
We
are
asking
to
be
equal
for
the
across
the
cluster.
B
There
is
no
such
requirement
like
any
uid.
That
is
not
zero,
basically
would
work
for
our
case.
Well,
not
anyone
like
if
it's,
if
it's
being
used,
then
it
might
have
a
little
bit
more
but
randomly
assigned
unique
id.
B
Yeah,
well,
we
don't
have
to
reuse
them
like
if,
during
upgrade,
you
change
the
uids
the
way
the
code
like
is
written.
It
will
just
kind
of
react
to
the
change
of
ids
and
then
just
change
the
permissions
across
the
board
so
that
it
works
with
the
new
uid.
So
so
you
don't
need
to
but
like
on
the
same
machine
if
you're
upgrading
something
it
would
be
nice
to
not
have
to
do
that,
but,
like
you,
don't
need
to
like
the
code
will
react
to
it.
C
Okay,
so
because
I
see
two
problems
or
a
couple
of
problems
here,
one
one
is:
is
the
api
compatibility
and
lubami
already
talked
about?
This
second
problem
is
that
in
cluster
api,
currently
we
only
preserve
the
cluster
configuration
so
doesn't
mean
that
let
let's
explore
the
some
options.
So,
let's
assume
that
we
go
into
init
configuration.
C
So
cluster
configurations
cannot
be
used
because
cluster
configuration
means
equal
across
all
the
nodes,
and
this
is
not
the
case.
So,
let's
assume
we
use
init
configuration
and
join
configuration
and
we
add
some
field
there
to
be
defined
some
some
semantic
in
order
to
make
the
clear
design
experiment
still
stuff.
Like
that,
we
add
some
field,
then
basically,
this
field
percolates
down
to
the
to
the
static
manifest.
C
But
then
this
this
object,
the
unit
configuration
or
the
joint
configuration
basically
get
lost,
so
that's
mean
that
if
we
want
to-
and
there
is
no
way
to
give
such
that
the
same
config
during
upgrade-
that's
mean
that
if
we
go
down
this
spot,
we
have
to
store
this
setting
somewhere,
maybe
in
an
annotation
or
whatever.
So
when
we
do
upgrade,
we,
we
basically
retrieve
the
object,
the
the
information
that
we
need
in
order
to
doing
to
recreate
the
the
static
parts.
C
I
I
don't
know,
I'm
I'm
kind
of
preferring
this
option.
Instead
of
dealing
with
distribution,
differences.
A
Basically,
you're
saying
that
we
should
like
require,
from
the
user
to
feed
the
uid
gids
inside
the
init
and
join.
C
C
A
Okay,
the
non-standardized
part
from
this
is
the
tooling
across
distros,
the
ad
user
delete
user.
These
combines
have
different
implications
from
different
distributions,
but
the
underlying
storage
of
users
in
groups,
which
is,
as
you
may
know,
the
file
atc
passwd
htc
group.
These
these
come
from
unix.
So
any
linux
distributions
that
want
to
claim
that
they
are
like
a
propagation
of
the
unix
philosophy.
A
They
must
follow
the
format
and
in
fact
every
like
I
have
not.
I
have
not
seen
a
distro
that
is
not
following
the
format,
but
this
means
that
we
have
to
maintain
some
logic
for
parsing
and
updating
these
files
and
also,
as
vinayak
said,
we
have
to
lock
the
file
because
something
in
the
background
could
add
a
new.
C
C
A
I
mean
I
have
it
almost
ready.
I
don't
have
unit
tests,
it's
200
300
lines
of
code,
okay,
but.
C
C
C
We
we
are
just
okay,
let's
do
it
and
reconsider
the
the
alternative,
which
is
letting
the
user
to
pick
up
when
we
gotta
do
it.
So
I'm
fine
with
this,
if
we
can
avoid
the
or
specific.
A
Code
really
unfortunate
that
we
have
to
deal
with
linux
distributions
in
quick,
cube
idea,
but
that's
the
reason
I
want
to
avoid
shelling
out
two
commands
because,
for
instance,
like
busy
box
and
alpine
are
really
a
compatibility
hot
zone,
it's
a
one
mile
field
there
they
make
their
own
decisions
and
sometimes
they
are
completely
not
compatible
with
not
only
with
user
ad,
but
a
bunch
of
other
commands,
including
some
of
the
commands
around
dns,
I
think
ip
tables.
A
So
instead,
I
think
we
should
use
this.
I'm
happy
that
there's
some
agreement
with
that.
But
video,
can
you
remind
me
how?
How
do
I
walk
the
these
system?
Files.
B
The
atc
passwd
yeah,
so
that's
one,
that's
one
of
the
things.
If
this
was
like
probably
low
level
c
code,
you
would
call
f,
lock
right.
B
B
B
I
was
saying
like
the
reason
that
you
have
to
lock.
The
file
is
so
that
nothing
else
can
like
update
it
while
you're.
B
So
so,
here's
how
I
understand
it'll
work
right,
you're,
going
to
pass
like
the
group
style
you're
going
to
parse
the
the
the
password
file
and
then
you're
going
to
kind
of
come
up
with
like
oh,
this
is
the
current
state,
and
these
are
the
ideas
we
can
use
because
you're
also
going
to
probably
pass
the
login
devs
right
to
kind
of
see
what
the
range
for
your
system,
uid
is
and
and
so
the
system.
B
So
you
find
the
range
of
system
uid
you
find
what
are
currently
used,
and
then
you
say:
okay,
I'm
going
to
allocate
this
one
before
you
do
that.
If
something
else
it
comes
right,
a
system
uid
then
now
you're
kind
of
reusing,
a
user
or
like
screwing
up
the
current
existing
like
setting.
That
was
just
written
into
the
file.
So
that's
why
it's
always
a
human.
So
that's
why?
B
If
you
look
at
the
vi
pw,
which
is
the
manual
way
of
updating
this
in
in
the
nox,
it
will
always
like
lock
the
file
immediately
and
nothing
else
will
be
able
to
write
to
it
while
you're
in
the
vipw
scope.
A
B
I
had
yeah
to
think
it
should
work.
I
haven't
done
the
level
stuff
in
a
while.
I've
been
honest,
so
I
don't
remember,
but
I
can
go
read
about
it
and
we
can
kind
of
talk
more
about
it
in
the
in
the
pr
itself.
So,
like
I
think
I
love
the
discussion.
B
Thank
you
so
much
for
your
inputs
right,
like
what
I
gathered
from
it,
is
let's
go
explore
this
f-lock
thing
and
kind
of
see,
lubimer's
poc
for
for
updating
groups
through,
go
right
and
and
then
as
a
contingency.
If
that
doesn't
work
out-
and
we
realize
hey,
this
is
getting
too
complicated,
then
I
think
we're
fine
with
using
the
api
approach
with
maybe
annotations
to
support.
The
upgrade
scenario
is
that
what
is
that
correct?
Like?
Is
that
a
correct
assumption
to
have,
or
am
I
I
really.
A
I
really
don't.
I
really
don't
want
to
expose
the
this
feature
in
the
api
like
we
should.
I
think
the
fallback
is
to
unwrap
the
the
bunch
of
commands
in
us.
You
know
command
lines
in
a
in
a
string,
slides
and
basically
execute
those.
I
think
that's
the
alternative
you
want.
I
think.
B
That's
totally
valid
as
well
yeah,
okay,
so
somebody
in
quick
summary
would
be
like
try
to
see
if
your
peoc
works.
If,
if
it's
overly
complicated-
and
we
feel
like
this
is
probably
not
the
best
way
to
do
it-
we're
gonna
fall
back
to
multiple
commands
and
whichever
hits
we
use
that,
and
I
can
go
experiment
with
like
something
around
that,
so
that
we
both
are
kind
of
have
have
the
things
ready
in
battle.
Does
that
sound
reasonable.
A
Yeah,
absolutely
I
I
I
was
about
to
write
some
unit
tests
for
by
code,
it's
here
and
it's
in
a
private
gift,
but
I
can
share
it
soon.
I
mean
this
is
like
one
of
the
important
things
we
have
to
add
and
arguably
the
utility
is
one
of
the
complicated
moments
of
the
escape
like
we
have
to
solve
this
right
and
we
have
the
whole
june
for
it
yeah,
because
I
think
the
code
phrase
is
in
late
june
yeah.
A
C
A
I
can
also
experiment
with
locking
the
file,
and
at
that
point
I
can
just
give
you
this
code.
You
don't
even
have,
to
credit
credit,
be
about
the
contribution.
I
don't
care
as
long
as
we
have
something
that
works
honestly.
I'd.
B
And
then
I'll,
just
like
build
on
it
that
I
think
that
way,
you
get
the
credit
for
the
code
that
you
actually
wrote.
B
B
Is
it
could
I
do
this
that
I
write
the
create
the
interfaces
that
we
want
right
and
and
then
put
put
the
rest
of
the
code
like
synthesis
behind
the
feature
flag
and
make
progress
there
or
like
actually
going
and
using
the
interface,
because
you'll
just
create
an
object
and
pass
that
down
to
like
wherever
we're
using
the
wherever
we're,
creating
the
manifest
and
kind
of
write
down
all
the
code
for
updating
the
file
logic
and
because
that's
already
been
hidden
behind
the
feature,
gate
and
also
hidden
behind
the
drive
and
flag.
B
About
so
like
the
functionality
that
we're
gonna
write
here
right,
the
names
of
the
functions
are
already
probably
in
the
cl
that
I
sent
out
right.
So
can
I
build
on
that
and
kind
of
use,
the
same
name
name
and
like
check
in
code
for
updating
the
manifest
and
since
it's
behind
hidden
behind
a
feature
gate?
It.
A
So
your
main
the
code
to
update
the
static
ports
with
the
ids,
you
want
to
add
it
inside
the
static
port
logic
itself,
with
behind
the
feature
again.
A
Yeah,
I
think
you
can
do
that.
I
mean
it's
fine.
You
want
to
merge
pr,
basically,
with
this
knob,
okay.
B
Yeah,
I
think
I
think
I'm
fine
with
meeting
I
just
wanted
to
like
just
discuss
it,
but
that's
why
I'm
totally
yeah.
A
A
B
The
topic
sounds
good.
I
wanted
my
time.
I've
already
taken
most
of
the
time
of
the
meeting,
but
thank
you
so
much
for
your
input.
I
really
appreciate
you
guys
looking
into
this.
A
No
problem,
thank
you
for
working
on
this
and
the
investigation
that
you're
doing
thanks
a
lot.
A
All
right,
I
will,
I
should
add,
more
comments
here
after
the
meeting,
but
does
anybody
else
have
any
other
topics
they
want
to
discuss?
I
mean
for
british,
we
have
some
mobile
phrase
for
viewer
beta
3.
We
want
to
like
give
a
for
me
to
give
a
status
update
about
this.
C
C
The
pr
to
the
meeting
notes,
so
I
don't
want
to
keep
people
hanging
for
my
review
for
my
comments.
A
Okay,
I
will
send
you
the
lists,
there's
other
sorry
at
the
list
inside
the
the
jeddah.
A
Thank
you
I
wanted
to
talk
about
this
quickly
to
see
your
opinion
about
it.
Honestly,
let.
C
A
Because,
currently
we
have
a
bunch
of
flags
and
there's
no
way
to
configure
the
command
without
flags
for
a
set.
This
is
not
really
that
much
of
a
problem,
but
for
upgrade,
for
instance,.
A
Of
the
upgrade
version,
the
upgrade
version
forcing
the
upgrade.
A
C
C
This
is
a
possible
cause,
so
I
I
think
that
we
have
to
really
nail
down
the
the
problem,
scope
and
try
to
understand
if
the
flags
are
a
solution
for
another
problem,
and
so
we
try
to
tackle
the
another
problem
or
if
they
are
really
required
for
the
command
itself.
A
Yes,
I
agree.
I
agree
with
the
introduced
complexity
with
config,
that's
inevitable.
Something
else
that
I
found
is
patches.
For
instance,
we
support
dash
dash
experimental
patches
for
all
the
commands
right,
but
kubernetes
upgrade
has
no
configuration.
So
if
I
I
realized
that,
if
I
have
to
graduate
the
the
patches
support
to
ga
eventually
somehow
cubed
the
ab
upgrades,
I
cannot
remove
the
patches
flag
for
kubernetes
upgrade
because
there's
no
config
and
if
patches
are
a
folder
as
a
field
in
the
api,
you
know
the
upgrade
configuration
it
would
be
better.
A
That
is
true.
I
mean
we're
going
back
to
fundamentals
like
I.
I
think
I've
mentioned
this
already-
that
I
don't
think
we
should
have
indeed
separately
need
to
enjoy
configurations.
A
C
C
We
are
kind
of
using
the
api
when
we
talk
about
unique
configuration
joining
configuration.
We
are
using
api
in
a
imperative
way,
so
we
were
telling
we
want
in
it
to
do
to
do
these,
but
we
are
not
instead
of
telling
we
want
in
order
in
order
to
become
these,
these
things
so
to
to
to
to
become
this
spec.
C
Okay,
yeah-
and
this
was
fine
and
it
worked
well
and
it
maps
the
the
idea
of
the
the
cli
that
we
have,
but
it
has
some
design
disadvantages.
The
first
one
is
that
we
don't
have
a
representation
of
that
know
the
state
or
or
the
node
or
things
like.
Okay.
What
are
the
patches
applied
to
denote
this
node?
We
don't
have
because
we
we
don't
have
them
in
the
in
the
node
configuration
or
we
cannot
and.
C
And
yeah,
this
is
a
problem,
and
the
second
problem
is
that,
basically,
this
prevent
things
like
the
operator
stuff
like
that
to
basically
build
up
on
on
these
pieces.
So
I
think
that
it
makes
sense
to
start
thinking
about
this.
But
but,
in
my
opinion,
the
the
real
answer
is
that
let's
try
to
if
we
want
to
improve
these,
let's
try
to
move
away
from
the
imperative
part
and
start
to
model
node
as
a
set
of
as
a
as
a
spec.
Basically
like
we
do
for
the
cluster
configuration.
C
Because
this
will
enable
an
entire
new
set
of
use
cases
like,
for
instance,
I
want
this
node
or
this
set
of
node
to
to
have
a
family
of
to
have
different
cubert
settings,
because
I
don't
know
those
machine
are
with
gpu
and
I
want
a
different
kubernetes.
Config.
C
Okay
and
maybe
those
machine
are
tricky
and-
and
I
want
these,
these
patches
and
stuff
like
that,
so
maybe
the
the
right
term
of
framing
these
is
that
we
don't
want
node
specific
configuration
because
we
don't
want.
Let
me
say
to.
C
Like
a
node
group
yeah
but
yeah
like
another
configuration
that
they
ever
instead
of
having
they
know
the
name
it
has,
it
has
a
selector
for
selecting
the
the
node
where
these
are
the
this
is
it
applies.
This
is
an
interesting
idea.
I
was
thinking
some
time
ago
because
it
will
basically
allow
you
flexibility.
C
C
C
This
is
why
I
mean
this
in
mind:
let's
use
here
these,
let's
make
this
a
little
bit
more
declarative
stuff
like
that,
because
yeah
at
the
end
of
the
story,
I
see
the
operator,
but
also
without
the
operator.
There
are
really
nice
use
cases
that
we
can
address
much
more
flexibility
stuff
like
that,
and
this
will
be
a
huge
win.
A
It
will
be
a
like
a
big
refactor
as
well,
because
we're
changing
the
cube
idea
model
of
being
in
a
tool
that
you
execute
on
the
nodes
to
do
something
like
an
upgrade.
But
now
we
have
an
operator
that
users
can
modify
the
target
version
by
doing
a
change
in
a
in
a
field
somewhere
we're
changing
the
model
using
the
operator,
essentially,
which
is
not
about.
C
C
C
And
the
node
and
the
node
specification,
because
because
basically
the
lack
of
node
specific
configuration
is
is
becoming
a
limitation
for
kubernetes
is
becoming
a
limit,
so
these
this
really
goes
back
to
the
dfk.
C
I
agree
with
you
internally
now
is
everything
is
really
coupled
with
the
current
configuration,
and
we
we
already
discussed
this
when
talking
about
the
library,
for
instance,
so.
C
There
are,
there
are
things
that
that
makes
sense
and
the
the
second,
but
there
is
also
a
really
concrete
need
to
to
find
a
viable
part
to
get
there.
So
this
is
this
is
the
real
challenge,
because
we
have
a
lot
of
good
idea,
but
currently
we
lack
of
manpower.
So
we
can
work
to.
C
A
C
I
I'm
not
proposing,
because
I
I
I
don't
have
yet
in
mind
in
mind
where
we
want
to
get
this
is
this
is
part
of
the
discussion
on
the
of
the
roadmap,
because
let
me
say
these
really.
I
I
think
I
am.
C
I
don't
have
concrete
idea
in
mind,
but
in
my
opinion
it
is
important
that
that
we
we
chart
where
we
want
to
go.
Okay,
and
there
are,
there
are
some
area
that
has
to
be
addressed
and,
and
we
know
them,
accessibility
for
the
for
their
dawns,
no,
not
specific
configuration
and
the
operator
and
stuff.
So
so
this
area
is
it's
really
critical
and
we
have
to
provide
a
a
future
for,
for
these.
C
How
how
do
we
we
we
we
could
get
there,
it
could
be
an
incremental
part,
moving
from
where
we
are,
or
also
could
be,
some
a
breaking
change.
So
we
we
can
go
for
kubernete.z.
C
You
know
I'm
trying
to
to
develop
some
idea
around
the
library
around
the
operator,
and
probably
I
will
do
the
same
about
know
the
specific
configuration
and
and
then
we
will
collect
feedback
and
try
to
define
the
the
priorities
and
then
the
implementation
roadmap.
For
now
I
have
only
idea,
because
I
know
that
people
are
asking
for
something
more
and
my
opinion
is
critical,
that
we
give
them
something
more.
A
C
Yeah
yeah,
I
agree.
Some
of
these
efforts
are
or
orthogonal,
so
we
can
choose
basically
to
do
them
in
in
different
order
and
in
different
sequence.
I
I
I
totally
agree,
and
probably
and
probably
you
are
right-
if
we
can
develop
the
idea
of
another
specific
configuration,
it
will
be
a
huge
ad
addition
for
covered
mean.
C
A
A
We
could
design
the
api
it's
doable.
This
is
you're,
saying
that
we
have
to
define
the
roadmap,
but
it's
like
this
is
like
already
tribal
knowledge
at
this
point.
A
We
want
this
specific
configuration
in
one
way
or
another,
and
I
I
think
that
if
we
spend
more
time,
this
is
not
a
criticism
by
the
way,
but
if
we
spend
more
time
before
graduating
the
acoustic
configuration
that
is
shared
across
all
the
nodes,
if
we
spend
some
more
time
planning
instead
of
rushing
to
graduate
over
engineering,
things
is
sometimes
better
because
down
the
line.
Now
you
see
that
we
have
a
complexity
that
we
don't
know
how
to
migrate
from
this
centralized
configuration,
to
instance,
specific
configuration.
A
Unfortunately,
the
whole
global
configuration
problem
was
introduced
by
the
kubrick,
and
we
followed
the
cubelet
model,
which
is
all
nodes
in
the
cluster,
have
the
same
config
that
is
stored
in
a
config
map,
and
we
did
the
same
for
requested
configuration
and
the
question
configuration
currently
applies
to
all
the
like:
all
the
the
control
plane
machines,
which
is
not
what
some
people
want.
That's
why
we
added
patches
and
we're
graduating
patterns
to
ga,
but
maybe
we
shouldn't.
Maybe
we
should
stop
and
say
hey.
A
Maybe
you
can
just
customize
with,
I
don't
know
it's
just.
There
are
so
many
options,
but
we
picked
some
routes
already
and,
of
course,
the
biggest
concerns
are
whether
we
want
to
break
users
at
this
point,
and
it's
I
think,
for
some
of
these
things.
It
feels
like
the
ship
has
already
sailed
it's
nice,
but
if
we
start
breaking
users
we
might
eiger
some
people,
they
might
stop
using
kubernetes.
C
Yeah,
I
I
I
got
your
point,
but
I
I
don't
think
that
the
ship
is
is
gone.
Every
project
has,
let
me
say
the
right
to
to
change
and
we
have
a
tool
to
support
using
a
user
along
this
part.
C
So
I
I
I
think
that
we
we
can
get
there
and
in
an
incremental
way,
that's
mean
helping
the
user
in
the
transition.
What
what
really
is
important
to
me
is
that
we
we
take
the
time
and
then
we
work
on
defining
the
goal.
What
we
want
to
achieve
before
defining
how,
because
this
is
really
important,
because
if
we
frame
write
the
goal,
then
the
implementation
we
is,
we
will
just
follow.
C
So
if
you
want
we
can.
We
can
start
at
a
google
doc
and
try
to
to
reason
about
not
specific
configuration.
This
is
a
really
interesting
topic.
It
has
a
users
are
just
asking
for
for
this
and
we
can
okay.
This
is
what
we
want
to
support,
abc
and
and
if
we
provide
a
good
solution
and
this
these
are
the
tops.
So
if
you
find
a
nice
ux,
a
simple
ux
that
that
basically
covers
the
simple
is
really
simple
for
the
quick
start
and
allows
user
to
complicate
things
when
necessary.
A
We're
basically
entering
in
the
roadmap,
we
can
define
an
item
that
focuses
on
the
20
percent,
which
is
the
80
20
philosophy,
but
the
the
reality
is
that,
to
my
understanding-
and
I
don't
have
statistics
for
that-
is
that
80
percent
really
do
not
care
about
instant,
specific
config
yeah.
C
And
it
should
be
an
exception,
but
yeah
we
have
to
we
we
have
to
think
about,
and
this
is
really
where
it
comes
to
today
today
to
defining
the
goal
right
and
and
and
this
is
playing
the
solution
and
stuff
like
that,
but
yeah
now
I'm
I'm
overscheduled,
but
I
will
be
happy
to
to
start
a
document
discussing
this
and
and
try
to
figure
it
out.
Maybe
if
I'm
for
the
next
cycle,
we
can
think
about
this
idea
and
another
area
which
is
in
somehow
moving
on
is
the
probably
you
know.
C
C
C
So
if
I
got
it
it
right,
basically
what
happens
it?
It
happens
that,
as
far
as
understood,
each
add-ons
is
distributed
as
as
a
image
and
inside
this
image.
There
are
not
only
the
addon,
let
me
say,
manager
in
case
they
are
done,
is
as
its
own
controller,
but
there
are
also
some
utility
that
you
can
use,
for
instance,
to
generate
the
yaml
for
this
of
dawn
for
doing
stuff
like
that,
no
okay,
this
is
nice.
This
is
a
good
idea,
but
it
is.
C
It
is
also
a
weak
idea,
because,
basically
you
are
shelling
into
a
docker
container,
so
you
have
to
annoy
this
container
and
you're
shelling
into
without
having
a
a
proper
protocol
for
communication
and
also
proper
security
model
around.
How
do
you
run
this
this
container?
So
maybe
we
have
to
really
think
about
this.
I
like
the
approach,
but
it
should
be.
C
C
Kubat
mean
has
to
download
this
image,
call
the
the
the
executive
world
inside
this
image
and
get
the
yaml
and
that
that's
it.
So
we
can
clean
up
faces
and
and
and
if
you
want
to
differentiate
don
you,
we
we,
you
just
said
to
give
the
list
of
a
dawn
images
that
that
you
want
so
this
is,
it
is
nice
because
it
is,
it
is
building
a
kind
of
interface
between
different
projects,
but
this
kind
of
thing
this
interface
should
be
discussed
in
and
the
the
execution
model
should
be
discussed.
C
A
A
If
we
can
standardize
the
model,
we
have
done
this
for
at
least
one
different
scenario.
With
the
local
coast
repositories,
we
basically
asked
a
person
to
write
a
cap.
This
is
the
interface.
This
is
the
structures
we
want
to
use.
This
is
the
method
whatever
and
we
merged
it
as
a
document,
and
everybody
should
follow
it.
That's
how
we
do
standardization.
I
think
we
should
do
the
same
here.
A
I
think
we
should
talk
with
justin
on
the
next
week.
Kobe
justin
always
joins.
You
can
bring
this
as
a
topic
and
hopefully
we
get
someone
from
the
adults
people
as
well.
I
so
far
I
have
to
be
honest
with
you.
I
haven't
liked
the
single
add-ons
proposal
like
fully.
I
know
that
you
have
created
one
justin
has
one
lay
from
wave
work
has
one
I
I
you
know.
A
C
Yeah,
that's
the
point:
how
we
define
this
interface
in
a
let
me
say
in
a
generic
way
that
we
can.
We
can
we
we
can
use,
but
but
and
also
how
we
define
this
interface
in
a
way
that
does
not,
let
me
say,
pollute
each
stellar.
If
I
don't
specific
things
so,
ideally,
a
kubernetes
should
should
know
nothing
about
the
kuber
proxy.
C
C
A
Yeah,
I
agree
with
you:
it's
it's
a
must
to
standardize
this,
and
the
mechanism
is
not
clear.
I
have
to
look
at
a
bunch
of
diagrams.
We
have
to
have
a
discussion
I
haven't
joined
the
sadly,
I
haven't
joined
the
adults
meeting
in
a
long
time,
because
I
have
overlaps
internally
and
yeah.
That's
it's
a
a
problem
of
bandwidth
as
well.
You
are
busy
with
something
else
suggested
is
busy
with
something
else
and
not
like
random
stuff.
Yeah.
C
That's
true,
but
yeah,
let's
discuss
this
this
last
point
with
justin
in
the
next
meeting.
A
Okay,
just
to
to
somebody
again
about
this
upgrade
reset
apis,
you
don't
want
to
add
more
structures
until
we
have
a
clear
picture
about
no
specific
config.
That's
the
response
here.
C
Yeah,
I
think
that
it
makes
sense
to
nail
down
the
root
problem
and
if
the
root
problem
is
not
specific
configuration,
let's
tackle
this,
because
we
have
also
other
use
case
for
this.
A
Okay
flux
also
the
problem
which
yeah
all
right
thanks.
Let's
add
this
mintake
I'll
go,
I'm
going
to
add
some
more
comments
here
to
clarify
the
discussion
with
the
discussion
with
vidyak
and
we
should
free
the
room
for
the
quest
api
thanks
so
much
and
see
you
again
in
a
couple
weeks.
Thank.