►
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
B
C
A
B
A
Yeah,
just
as
an
overview,
the
guiding
principles
that
we
want
to
focus
on,
as
we
define
the
control
plane
management,
we
want
to
focus
on
evolution
instead
of
revolution.
We
don't
want
to
try
to
reboil
the
ocean.
We
want
to
try
to
start
with
what
we
have
today
and
try
to
move
that
forward.
The
other
thing
that
we
want
to
focus
on
is
we
want
to
take
a
batteries
included,
but
swappable
type
approach.
A
So
we
need
to
make
sure
that
we
have
that
kind
of
extensibility
in
mind
what
we
do
want
to
at
least
or
the
initial
focus
of
this
cat.
The
the
initial
default
experience
for
what
we're
looking
to
do
with
that
I
think
probably
the
best
place
to
go
is
we
can
start
with
reviewing
the
goals
and
on
goals
that
we
defined
at
the
face-to-face
I
was
talking
with
Chuck
and
some
other
folks.
A
A
A
We
should
enable
declarative,
orchestrated
control
playing
upgrades
and
we
need
to
leave
room
to
support
the
following
features
in
place:
control,
plane,
upgrades
in
the
future
pod
based
or
other
topologies
control
planes.
Some
eventual
cloud
provider
load
balancer,
end
points
provider
for
control,
plane
machines.
We
specifically
wanted
to
call
these
out,
even
though
they
are
generally
non
goals
for
the
initial
deliverable,
but
we
wanted
to
make
sure
that
we
keep
kind
of
these
use
cases
in
mind
as
we
scope
out
the
initial
design
to
avoid
precluding
those
things
in
the
future
for
the
default
implementation.
A
A
D
One
one
question:
I
think
that
I
that
I
have
is,
do
we
need
to
do.
We
need
to
specify
in
the
goals
whether
we
will
rely
on
Kubb,
ADM
control,
plane
join
or
whether
we
will
you
know
you
have
a
cluster
API,
you
know
bootstrap
or
so
I
guess
it
would
be
the
coup
BM
bootstrap
provider.
You
know
pass
in
all
of
the
all
the
bits
of
information
certificates,
etc
that
that
I
think
are
currently
being
passed
in
University
retrieved
by
kuba.
D
A
A
A
Right
all
right,
in
that
case,
let's
go
ahead
and
go
down
to
the
non
goals
again,
our
little
blurb
that
we
came
about
non
goals,
listen
and
this
document
are
intended
to
be
scoped
out
for
currently
well.
Three
implementation
are
subject
to
change
based
on
useful
feedback
over
time,
so
anything
specified
here
is
not
saying
that
is
out
of
scope
for
future
releases
of
the
project,
we're
just
considering
them
non
goals
within
scope
of
this
project.
A
You
know
that's
not
preventing
it
from
potentially
happening
in
parallel
or
as
a
follow-on.
We
are
not
attempting
to
do
see
a
certificate
management
outside
of
what
is
provided
by
the
initial
committee
and
bootstrapping
to
manage
external
EDD
deployments
and
I
know.
There
were
some
things
around
how
we
scoped
this,
and
we
probably
want
to
elaborate
on
that
a
little
bit
more
and
that's
specifically
in
this
case,
we're
saying
not
to
manage
kind
of
stand-alone
SED
deployments
that
are
managed
by
cluster
api
that
are
used
in
a
non
stacked
control
playing
deployment
scenario.
A
A
A
Configuration
mutation
so
modification
of
configuration
files
on
disk
for
the
control
plane,
instances
managing
non
node
control
plane
manage
kubernetes
services
right
now.
Obviously,
we've
talked
about
that
for
longer
term,
but
just
not
for
v1
l3
automatic
remediation
of
nodes
that
go
into
a
state.
A
A
lot
of
this
is
going
to
depend
on
the
node
health
and
remediation,
which
is
being
done
kind
of
in
a
separate
step,
so
I
think
we
would
probably
want
to
build
automatic
remediation
in
the
future
based
on
the
work
that
is
being
done
in
the
remediate
through
the
remediation
stuff
for
regular
nodes
and
then
a
configurable
cloud
provider,
controller
managed
cloud
controller
manager.
We
don't
want
to
take
on
the
automatic
management
of
that
or
the
automatic
management
of
CNI
configuration.
C
Well,
this
is
one
thing
at
least
to
me.
It
looks
perfectly
fine
if
this
video
is
for
the
possibility
of
external
entities
right
so
we're
not.
The
clusters
managed
externally
by
the
users,
were
where
deputies
are
basically
managed,
a
sports,
and
so
on.
You
know
so
that
does
not
search
for
the
non-course
right.
C
I
can
understand
that
we
don't
have
to
consider
is
now
and
doing
for
the
given
alpha
3,
but
at
least
in
future
there
should
be
a
scope
where
we
might
want
to
manage
City
externally
when
we
clear
the
boards
of
their
cities,
and
that
should
still
follow
me
future
days
right,
miss
yeah.
You
should
follow
the
giving
group
for
the
future
there
yeah.
C
A
B
Guess
I
was
I,
I'm
curious.
How
how
we
like
to
work
together
on
this
I'm
sure
we
all
have
our
own
opinions
and
ideas
of
what
the
implementation
will
look
like.
Do
you
think
it'd
be
worthwhile
if
we
like
piece
together,
some
POCs
and
kind
of
play
around
with
stuff
or
you
know,
should
we
kind
of
agreed
upon
a
design
first?
B
C
So,
in
my
opinion,
if
you
start
doing
the
pieces
without
having
enough
activity
agreement,
at
least
at
least
among
three
or
four
of
us,
will
end
up
wasting
quite
so
much
effort,
it
would
be
really
nice
if
we
can.
This
from
the
high
level,
prepare
a
sort
of
design
that
we
have
in
the
mind,
probably
in
terms
of
how
how
could
the
CRTC
look
like
or
how
could
the
overall
stack
look
like
them.
D
B
I
think
it's
reasonable
I
would
like
to
see
yeah
I
mean
that's
sort
of
I.
Guess
part
of
the
design
details
are
sort
of
like
spec'ing
out.
The
CRD
is
what
those
are
gonna
look
like.
A
A
So
I
was
just
gonna
say
like
looking
at
kind
of
the
way
that
at
least
upstream
we've
handled
control,
plane
management
so
far
with
the,
where
we've
externalized
it
with
the
cube,
ATM
and
control
our
machine
based
deployments,
and
what
we've
done
with
the
cluster
api
upgrade
tool
for
automating
upgrades
of
those
I
was
plenty.
My
initial
thought
was:
we
can
basically
work
backwards
from
that
and
figure
out.
A
A
So
basically
kind
of
the
ways
that
we've
externalized
the
control
plane
management.
So
far,
you
know
how
we've
generally
told
people
as
far
as
the
upstream
community.
Here's
how
you
stand
up:
multi,
node
control,
plane,
yeah,
here's
how
you
are
able
to
upgrade
that
control
plane
from
one
version
to
the
next
yeah.
Try
to
basically
just
take
that
workflow
that
we're
doing
and
turn
that
into
a
data
model
that
could
internalize
that
with
a
lot
of
hand,
wavey
implementation,
yeah.
B
Yeah
I
think
that
sounds
really
good.
One
other
thing
I
would
like
to
do
in
that
process
is
also
kind
of
captured.
The
general
behaviors
are
expecting
this
controller
to
to
handle
like
like.
Does
this
controller
handle
upgrades
of
control
plan?
I
know
we
say,
control
a
management
but
like
we
should
define
what
that
means
more
specifically
as
well.
B
A
C
So
nothing
I
can
remember.
We
discussing
we
were
discussing
of
the
possibility
of
CRT,
which
was
called
control.
Plane
providers
realities
right
so
right
now,
if
you
see
we
have
good
script
providers,
you
have
this
perception,
difference
in
position
providers
and
then
I
could
remember
the
description
of
control
plane
before
the
C
or
D,
but
that
has
not
yet
caught
being
right.
So
do
any
of
us
know
or
oppose
the
protocol?
What
is
happening
for
that
specific
see
already
if
it
in
the
pipeline
or
for.
A
C
C
I
was
hoping
for
generic
one,
so,
basically,
a
kind
of
therapy
which
becomes
a
point
of
plug
ability
from
their
controller,
gets
to
decide
that,
because
this
provider
is
extra,
deploying
an
x-ray
and
also
see
already
this
mentioning
the
field
is
mentioning
about
why
it
should
deploy
it
in
a
while
so
amaura
thinking
of
no
way
that
how
can
we
plug
different
existing
models
inside
picosure
api?
So,
of
course
the
default
implementation
will
stay
and
will
not
basically
requires
users
to
mess
with
all
the
details.
C
So
by
default
you
should
have
it
always
flow
will
always
be
located.
The
control
plane
CR,
the
old
tea
bush
care
providers,
hearing,
will
be
set
up
to
the
QB
diem,
and
you
see
this
cluster
dedicated
machines,
but
if
user
is
compared
of
the
internal
socket
and
would
next
really
what
dimension
that
I
want
Y
provider
which
could
not,
which
could
be
something
else
from
the
QB
ADM
and
something
else
which
could
basically
spawn
the
control
plane
self
in
different
way?
And
that's
where
we
can
avoid
the
plug
right?
Yeah.
A
Think
I
personally
lean
towards
adding
it
directly
to
the
cluster
object.
Only
because
right
now
we
have
a
cluster
resource
that
doesn't
really
represent
an
actual
cluster
today
and
I
want
to
make
sure
that,
as
we
start,
building
out
additional
functionality
and
features
that
were
doing
it
in
a
way
that
it
rolls
that
information
back
up
to
that
generic
cluster
object,
so
that
the
cluster
actually
represents
a
cluster
rather
than
just
like
this
weird
thing
that
sort
of
does
like
prerequisite
infrastructure,
but
not
actually
anything
to
do
with
the
actual
cluster
that
we're
deploying.
C
Better
typical
confuse
I
mean
we
just
need
a
way
to
describe
the
information.
I
mean
I
also
do
know
that
a
search
person
Indian
toward
adding
unnecessary
moves
in
are
basically,
if
you
can
find
it,
but
we
could
place
in
the
cluster,
which
I
think
sounds
good
I
swim
and
fits
in
different
semantics
sockets
when
should
be
from.
A
A
A
Right,
great
and
then
other
than
that
I
think
we
should
probably
start
gathering
some
of
our
user
stories
around
managing
control
playing
both
for
kind
of
the
default
implementation,
but
also
I
want
to
start
gathering
some
of
those
user
stories
around
the
non-default
scenarios.
So
I
know
Daniel.
You
have
some
ideas
around
that
and
hardik
you
do
as
well.
So
is
that
something
that
you
both
are
willing
to
take
on
to
help
define
it.
C
So
what
I
would
love
to
do?
Is
that
so
understand
correctly?
When
you
say
you
would
try
to
define
the
data
models,
I
would
like
to
participate
with
you
and
try
to
figure
out
a
good
way
that
how
can
be
a
data
model
where
the
new
new
control
plan
provider
can
be
mapped
in
in
a
non-destructive
way,
so
I
would
let
me
make
sure
that
the
existing
flow
remains
as
similar
as
it
is
right
now,
maybe,
with
a
very
minor
datatype
changes
is
required.
C
A
Definitely
as
soon
as
I
as
soon
as
I
get
my
initial
brain
dump
on
paper,
I'll
reach
out
to
everybody,
and
we
can
continue
to
iterate
on
it
in
a
a
synchronous
manner.
I
just
want
to
make
sure
that
we
kind
of
identify
motors
for
some
of
the
action
items
before
we
wrapped
up
this
meeting
to
kind
of
lead
up.
Some
of
that
work.
A
C
Could
start
yeah,
you
start
so
I
would
say
a
lipst
I,
don't
keep
the
more
frequent
iterations
like
probably
yes,
of
middle
of
the
next
week
or
early
of
the
next
week,
would
be
nice
to
her
okay,
listen.
It
doesn't
mean
that
necessarily
her
to
complete.
Everything
can
then
come
here,
but
if
you
can
just
feature
that
again
and
review
the
ongoing
world,
the
pretend
was
just
make
it
better.
So
the
total
people
yep.