►
From YouTube: 20190320 kubeadm office hours 1.15 planning
Description
Brace yourselves 1.15 is coming!
A
Hello
today
is
March
20th
2019.
This
is
the
standard
kuba
TM
call
today
is
planning
we're
also
known
as
Festivus.
So
if
you
have
an
aluminum
pole
and
want
to
hear
your
grievances,
now
is
the
time.
Otherwise
we
have
an
agenda
full
of
things
we
would
like
to
accomplish.
If
you
can
add
your
details
to
the
meeting
notes,
that
would
be
super
helpful.
I'm
gonna
get
a
window
here.
Pretty
soon,
I
can
walk
through
the
the
list,
see
where
we're
at.
A
A
B
A
B
C
A
E
A
E
There
are
multiple
tickets
here,
it's
kind
of
messy.
We
have
overlapping
tasks
between
the
tickets,
but
so
what,
in
one
of
the
these
tickets,
I
tried
to
outline
like
the
initial
steps
we
have
to
do
before
we
even
get
to
test
in
upgrades
and
stuff
like
that,
because
it's
not
that
easy.
But,
yes,
we
are
going
to
have
HEA
tests
in
this
cycle
and
115
cycle,
and
also
we
are
going
to
get
upgrade
tests
and
possibly
har
grade
tests.
Even
I.
A
E
A
E
A
G
I
think
that
we
can
rename
this
point
as
test
and
implement,
because
basically
we
are
creating
the
precondition
for
doing
tests,
that
is
to
have
a
kind
ready
to
run
test
for
a
cherry
or
cluster
gradiation
or
ever
to
the
end,
to
end
the
test
suite
in
place
and
working
and
then
for
each
feature
will
ever
test
a
specific
for
the
feature
make
sense
to
split
the
priority
in
this
way.
So
first
we
have
to
either
test
enablement.
E
G
A
Would
like
to
get
someone
new
involved
with
you
to
to,
because
the
testing
jiggery
is
a
minefield
and
having
someone
else,
you
know
so
that
way.
If
the
leads
go
on
vacation
or
go
on
holiday,
understand
the
CI
signal,
that's
gonna,
be
pretty
important,
I
mean
I.
Would
love
to
I,
don't
want
to
let
myself
too
thin,
though
so
I
want
people
to
be
realistic
about
their.
How
much
time
commitment,
they're
gonna
have
right.
Yeah
is.
I
I
E
Do
you
happen
to
also
be
on
the
release?
Team
yeah
see
I
signal,
shadow,
okay,
okay,
I
know
your
nickname,
yes,
yeah,
okay,
so
basically,
what
we
are
going
to
do,
I
think,
is
that
we
are
going
to
make
like
zoom
sessions
me
for
Bleach
you
and
you,
and
we
should
start
going
through
the
steps
that
we
have
to
perform
for
this
task.
G
A
A
G
A
D
A
G
A
All
right,
couponing
enhancements,
h,
ADA
beta
I,
definitely
consider
this
p1
for
those
who
are
not
familiar
with
sort
of
the
ghoulish
prioritization
p0
and
p1
czar.
Your
high
priority
targets
to
hit
they're
pretty
much
non-negotiable
right
like
this,
is
what
we're
gonna
do
like.
If
we're
gonna
drop
anything
else,
you
know
those
are
the
ones
we
need
to
hit
for
for
a
given
release
timeframe.
I
think
this
is
totally
blocked
by
the
dot
v
right.
Yes,.
A
There
were
some
final
questions
before
we
went
to
beta
I
did
want
to
start
to
look
at
but
I.
They
escaped
me
right
now.
I
there
were
issues
with
the
config
that
we
wanted
to
figure
out.
Config
mapping
was
obviously
one.
We
need
that
for
declarative
support
for
things
like
cluster
API,
but
the
remember
how
we
kind
of
like
we
agreed
for
the
time
being
of
how
we
wanted
to
do.
A
A
Well,
we
we
did
it
to
enable
it.
So
we
have
h
a
support,
but
I
wrote
I
always
remember
the
feeling
of
like
it
was
a
little
bit
dirty.
What
we
did
I
need
to
look
through
the
config
and
it
worked
I.
Didn't
you
look
through
the
config
and
see
if
that's
what
we
want
to
do
for
the
long
haul,
because
we're
gonna
read
config,
probably
this
cycle,
that's
probably
one
of
the
lists
down
below.
A
D
It's
actually
more
like
incremental
changes,
but
that's
expected
since
we
ran
better
at
the
current
config.
So
basically,
probably
the
biggest
change
to
her
is
like
dropping
of
the
coaster
config
from
the
unit
configuration.
This
is
more
like
not
a
user
facing
change
as
it's
more
like
eternal
changed,
cube
ATM,
and
this
is
probably
going
to
introduce
some
bigger
changes
on
the
API
level.
But
the
rest
of
the
stuff
is
more
like
fixing
some
minor
bug
there
and
probably
adding
some
new
options
that
users
just
requested
do.
A
A
A
G
E
D
G
I'm,
you
can
believe
me,
so
we
are
doing
several
things
to
around
this
doubted
that
the
biggest
one
is
faces
and
four
and
four
faces.
We
have
some
bad
clock,
which
are
more
that
there
is
a
list
of
things
that
we
are
not
happy
about,
the
the
UX
that
we
have
to
decide
out.
We
fanned
out
to
address
and
I
and
the
Riesling
a
Lincoln
document
where
I
put
all
of
them.
G
For
instance,
I
tried
to
explain,
but
the
least
we
have
a
steel
problem
flags
with
too
much
flags.
In
my
opinion,
we
have
arcs
management
that
is
not
addressed.
Yet
we
have
a
potential
conflict
between
the
phase
name
and
the
arcs
value,
because
now
phases
are
sub
common.
The
end,
if
your
command,
for
instance
droid,
is
a
argA,
and
if
this
arc
overlaps
with
the
name
of
a
phase
your
you
have
problem
so
and
then
there
is
a
some
cases
where
the
uux
is
not
a
nice.
A
G
But
I
think
the
problem
is,
and
so
when
we
design
it
faces,
the
the
main
driver
was
to
basically
share
the
same
code,
a
bit
between
the
top-level
workflow
and
the
phases
to
avoid
application.
Because
in
the
past,
though,
we
were
forced
to
maintain
two
piece
of
code
doing
the
same
things
yep
now
what
what?
What
is
happening,
that
people
see
the
sub
command
as
something
separated
from
the
top-level
workflow
and
they
and
they
are
starting
to
ask
that
when
I
called
the
workflow,
it
behaves
in
one
way.
G
When
I
call
the
faces
individually,
it
should
behave
in
a
different
way.
So
let's
try
an
example.
People
is
fine
that
I,
when
I
call
kuba
the
meaning
in
it,
I
have
to
pass
the
Minos
means
upload
a
flag.
This
is
a
separate,
but
they
starting
to
ask
that
when
I'm
cold
they
upload
the
faces
directly.
They
want
the
flag
to
be
said
implicitly
yeah.
A
G
G
A
It's
a
property
to
us
I
think
we
should
talk
to
with
Lucas
and
Mike
toughen,
but
if
and
how
they
plan
to
address
some
of
this
stuff
or
other
components,
because
we
should
have
it
right
now,
we
kind
of
blazed
a
trail
a
little
bit
and
in
having
such
a
hierarchical
sub
command
structure
for
what
we're
doing.
But
ideally
we
would
have
some
level
of
tooling
to
support
us
versus
us
kind
of
doing
everything
on
our
own
and
we're
kind
of
finding
warts
along
the
way
of
what
we've
created.
G
G
A
G
A
A
A
A
A
G
G
E
A
I
would
much
rather
at
least
four
bang
for
our
buck
for
execution
for
experimental
features.
I
think
customized
would
potentially
allow
us
to
reformulate
config
to
get
us
out
of
the
business
of
having
this
weird
apparatus
that
we
currently
have
for
config
overrides
right
since
the
very
beginning
of
the
project,
we've
started
to
create
a
config
or
even
the
very
beginning
project.
We
have
so
many
knobs
that
get
plumbed
through
all
over
the
place
and
customize
gives
us
an
exit
strategy
for
us
to
potentially
remove
a
bunch
of
those
knobs.
A
E
A
Presentation
from
the
Googler
who
who
gave
the
analogous
tool-
that's
like
customized
I,
think
we
should
evaluate
the
tooling
space.
You
know,
because
what
happens
with
especially
this
area.
It's
not
settled
right.
There
is
no
clear
winner
in
my
mind,
there's
a
lot
of
ideas
and
solutions
that
exist
for
for
how
to
deal
with
partial
specialization
of
yamo
overrides,
given
some
programmatic
interface
right.
A
That's
my
generic
way
of
saying
this
because
there's
so
many
ways
to
do
this.
People
have
configuration
languages
the
in
the
first
beginning
days
of
the
project,
people
just
generated
Yambol
with
bash
scripts
and
overrides,
and
then
they
used
Python
and
they
did
that
way.
Then
they,
then
they
tried
JSON
it,
and
then
people
are
like
yo
dog
I,
like
languages,
so
I
create
another
language
now
they're
into
customized.
So
this
problem
has
existed
since
the
beginning
of
the
project,
so
it's
very
experimental,
but
it
has
high
potential
ROI.
G
But
I
think
that
he
could
be
the
mean,
the
use
of
customized
or
whatever
tool
he's
not
for
customizing
the
config,
but
it
is
car,
stop
for
customizing
the
artifacts
that
could
mean
mean
generate
so
I
want
to
customize
the
coupe
API
server
manifest
I
want
to
customize
the
Kouga
proxy
manifest
or
the
Cabal
account
field.
Yes,.
G
Basically,
the
background
is
that
could
mean
very
quickly:
Cooperman
generate
some
artifacts,
some
are
Yamla
and
some
are
not
Yamla
certificates
and
the
config
file
or
the
environment
Pfeiffer
COO
ballot,
okay,
some
of
those
artifacts.
If
we
look
at
the
at
Yama
artifacts,
some
are
deployed
on
on
the
local
machine,
so
static,
both
manifest
and
some
are
applied
to
kubernetes
video
kubernetes
api.
This
is
that
the
the
background,
if
we
look
at
how
this
is
done
next
slide
out,
this
is
done
today.
G
Basically,
today,
EGM
is,
is
each
phase
deploy
the
yam
directly
to
the
target
static
pod
manifest
deployed
the
direct
to
the
folder
cubed
min
config
mod
is
deployed
directly
to
the
PI
server,
and
there
is
a
a
key
trick
to
do
the
Ryan.
Okay.
What
we
need
in
my
in
my
proposal,
I,
have
to
proposal.
Is
that
one?
If
we
change
each
phase
to
save
Yamla
in
a
folder
in
temporary
folder,
then
we
apply
customize
whatever
we
need,
and
then
we
apply.
We
deploy
the
customized
things
to
the
to
the
target
that
can
be.
G
G
Then
I
have
to
use
a
notation
to
keep
track
of
what
is
customized
and
what
not.
So
when
I,
when
I
do
upgrade,
I
can
detect
that
data,
if
I'm
doing
upgrade
on
a
customized
cluster
or
not
and
I
can
decide
how
to
behave.
That
is
I
can
ask
to
the
user.
If
he
wants
the
could
we
meet
I
couldn't
mean
try
to
do
its
job,
even
if
we
are
not
guaranteeing
success,
because
we
not
know
basically
what
the
user
customized
or,
if
we
should,
we
should
do
upgrade
in
your
ink
usto
mises
resources.
G
A
We
need
to
sit
down
and
chat
about
this
in
detail.
I
do
think
it
would
be
highly
useful
to
get
something
out
there,
because
almost
every
single,
almost
every
single
release-
I,
don't
know
how
many
issues
flow
in
where
a
user
doesn't
understand
how
to
specify
parameters
to
the
different
components.
Now
this
here's
another
thing
that
might
be
interesting
for
us
to
think
about
would
be.
If
we
have
grand
unified
component
config
in
the
New
World
Order,
do
we
even
care
and
I?
E
Think
this
is
bounce
to
the
component
config
work
in
a
way
that
if
we
enable
customize
before
we
get
rid
of
the
flags
we
pass
to
the
API
server.
For
instance,
we
don't
have
to
deploy
a
mechanic
that
determines
what
is
higher
priority,
the
customization
or
the
forks
that
we
pass
as
extra
arguments
from
the
config.
Well,.
A
E
Yeah
I'll
be
speaking
with
Michael
Michael,
Michael
and
Patrick
lengths
from
sick
windows
and
some
other
people
as
well.
Basically,
the
idea
is
to
bring
back
support
to
keep
idea
because,
according
to
them
cube,
a
DM
worked
fine
on
Windows
at
some
point,
but
somewhere
along
the
history
of
PR
sin
commits
we
lost
support
for
Windows.
Simply
because
of
the
fact
we
don't
test.
E
Windows,
support
and
testing
is
also
going
to
be
a
challenge,
but
this
is
something
I'm
going
to
work
on
in
this
in
the
115
cycle,
to
the
point
where
at
least
at
least
I
get
it
working,
but
possibly
without
signal.
So
this
basic.
No.
So
this
means
that
we
might
support
the
Windows
but
kind
of
in
alpha
state.
Something
like
that
are.
E
D
D
A
We
don't
want
to
go
there.
There
there's
a
lot
of
magic
sauce
under
the
hood,
which
is
basically
it's
a
bunch
of
hackery
inside
of
both
the
test,
automation
that
uses
a
weird
trick
in
cluster
up
to
provision
windows,
nodes
on
Azure
and
it's
it's
magic
and
yes,
cluster
up
is
supposed
to
be
deprecated.
We
weren't
supposed
to
add
anything
to
it,
but
that's
just
the
way
it
went.
The.
E
G
G
B
A
A
So
we've
run
through
the
list.
There's
the
wish
list
at
the
end
here,
I
did
want
to
bring
up
a
topic
for
the
broader
group.
We
have
a
bunch
of
certs
issues
that
have
been
kind
of
languishing
and
we
even
have
some
things
that
are
kind
of
weird
like
we
don't
actually
have
a
a
couplet
serving
cert
specified
by
default,
even
though
that
that
is
actually
used
for
a
direct
connect
through
to
the
couplet
from
the
API
server,
for
only
a
couple
of
operations,
exec
being
one
of
them.
A
So
if
somebody
does
coop
control
exec,
it
needs
to
actually
the
API
server
actually
does
a
connection
to
the
server,
which
is
the
couplet
right,
which
is
a
little
weird
thing
to
say.
But
that's
what
happens
so,
there's
a
there's,
a
bunch
of
other
certificate
issues
and
usability
around
certificates
and
liz
has
been
on
leave
and
probably
will
be
only
for
a
while
so
I'm
kind
of
looking
for
people
to
want
to
step
up
to
know
about
certificates
in
general,
echo-hawk.
A
One
is
solved,
for
the
most
part,
are
these
certain
renewals
is.
There
exists
both
the
sub
command,
as
well
as
the
automation
for
on
upgrade,
so
a
bunch
of
that
has
been
fixed
a
while
ago,
but
there's
a
bunch
of
edge
cases,
there's
so
many
edge
cases
with
certificates
because
of
how
people
want
to
set
up
their
certificate
authorities
that
understanding
those
issues
and
making
sure
that
the
ux
is
cleaned
for
those
people
has
been
troublesome
like
we
tried
to
submit
PRS
to
remove
like
the
coop
config
change
right.
A
A
G
Honestly,
I
am
not
so
convinced
that
the
story
about
or
anomalies,
please
speak
said
because,
for
instance,
people
asked
that
I
can
renew
certificates
which
are
in
the
kuba
config
I.
Don't
think
that
this
is
covered
now
and
I
I
didn't
have
time
to
dig
into
the
renewal
stuff
implemented
by
Elise
I.
Try
to
understand
the
from
day
from
the
document
which
is
in
the
website,
but
it
is
to
I
level
for
the
question
that
people
send
in
the
chat.
E
So
folks,
currently
what
they
are
doing,
somebody
wrote
the
guides.
There
is
like
they
found
out
that.
Fortunately,
our
document
is
not
sufficient.
Like
Fabrice
fishing
and
somebody
wrote
a
massive
comment
in
one
of
the
like
the
tickets
with
certificate
stuff
and
the
guy
explained.
How
should
should
you
do
renewal?
Basically,
what
we
have
to
do
is
now
the
the
changes,
the
suggestions
from
this
person
and
implement
the
implement
them
in
our
document,
because
our
document
is
not
sufficient
and
yeah.
That's
something
we
have
to
do
so.
A
Okay,
I
think
what
would
help
to
be
honest
would
be
documenting
user
journeys
and
that
I
think
if
we
started
from
there
and
then
we
said
you
know
you
are
trying
to
do
X
and
you
have
a
existing
CA.
This
is
how
you
go
about
your
process,
I!
Think.
If
we,
if
we
start
with
from
user
journeys,
it
will
be
easier
for
everyone
to
consume
and
also
for
everyone
to
understand.
I.
E
G
A
G
A
Think
if
we
start
from
user
journeys,
this
will
all
flow
out
right
talk
with
key
high
priority
users.
I
would
talk
with
the
coop
spray
folks,
for
example,
and
it
also
talked
with
Seth,
who
been
very
active
every
single
time.
We
actually
submit
a
change
he's
like
the
first
person
online
to
talk
about
the
thorns
and
the
issues
that
exist
with
certificate
management.
Yes,.
A
A
G
E
G
The
problem
is
that
okay,
changing
the
class
stuff
can
be
a
huge
topic.
In
my
opinion,
we
have
to
support
to
provide
a
decent
support
for
two
or
three
use
cases:
changing
the
extra
arcs
for
the
earth
or
the
config
map
for
the
components
changing
the
cooperage
settings
may
be
changing
the
cluster
and
the
point
end
point:
that's
it
if
we
managed
somehow
to
the
finest
story
about
around
those
three
topics.
G
J
A
E
A
In
a
totally
weird
space,
so
like
all
of
this
evaluation
of
customized
and
grand
unified
component
config,
and
how
to
deal
with
changes
for
the
cluster
they
caught,
it
all
fell
into
a
very
similar
bucket.
Yes,
and
to
be
honest,
it's
all
mostly
this
very
similar
bucket
to
how
people
are
dealing
with
changes
inside
of
kubernetes
proper
for
doing
variable,
substitution
or
partial
specialization
of
you,
programmatic,
whatever
I
think.
E
A
I
think
let
it
percolate
keep
on
thinking
about
it,
sometimes
those
background
tasks
when
you're,
sleeping
or
whatever,
which
variously
more
sometimes
help
right,
but
I,
think
we
have
more
than
enough
here
for
us
to
keep
busy
for
this
cycle.
We're
nearing
the
end
of
this
time,
but
if
folks
are
there
any
other
questions,
comments,
complaints,
concerns
on.
G
E
G
E
G
A
A
J
Quick
quick
small
wish
for
me
for
for
the
API,
so
there
are,
there
are
so
yeah
the
cube
idiom
API.
There
are
some
fields
so
for
the
Covidien
api
is
or
the
type
is
being
marshaled
now
buy
more
buy
more
tooling.
For
example,
the
custer
api
provider,
AWS,
takes
generator,
use
the
type
of
an
marshals
it
out
to
a
config
yamo
and
when
it
does
so
or
when
any
other
tooling
does
so,
there
are
fields
that
have
zero
values
that
are
that
are
not
omitted,
and
so
you
have.
J
You
know
you
have
all
these
fields
that
are
output
and
they
have
your
values.
And
then,
when
the
config
is
read
by
Kubb
ADM,
those
values
are
essentially
ignored
and
you
know
replaced
by
it
by
some
default,
but
I
find
it
somewhat
confusing
to
you
know
to
somebody,
that's
that
looking
at
the
config
seeing
these
fields-
and
it's
not
clear
whether
those
are
you
know
whether
that
zero
means
that
it's
like
a
zero
value
and
has
no
you
know,
has
no
meaning
and
that's
by
default
or
whether
that's
an
actual.
You
know
value
that.
A
J
A
We've
briefed
prioritized,
we
have
a
fair
number
of
things
that
fall
underneath
the
two
category.
Those
are
the
things
that
we
should
try
really
hard
to
deliver
on
and
if
we
need
to
and
try
to
like,
as
as
they
say,
or
as
a
sub-project,
try
to
shuffle
folks
appropriately
to
get
energy
and
effort
directed
towards
the
anything
that
falls
below
ptoo
ptoo
is
be
like
if
we've
got
time
and
your
employer
whatever
then
go
for
pts,
but
when
we
start
to
do
planning
for
how
we
want
to
do
PR
for
cycle.
A
Usually
the
PR
goes
around.
These
major
features
with
that
in
mind
where
we're
at
time
now
but
I
want
folks
to
think
about
whether
or
not
we
want
to
do
any
PR,
especially
around
H,
a
or
I,
don't
know.
If
we
do
any
packaging
PR
that
doesn't
really
but
yeh
doesn't
suck
as
much
but
the
the
H
a
work
would
be
I.
Think
for
promotion.
Debate
I
think
would
be
a
good
whiz-bang
for
the
broader
community.