►
A
All
right,
good
morning,
everybody-
this
is
the
second
or
third,
I
guess
second
official
cluster
api
nested
office
hours,
this
video
is
gonna,
be
recorded,
posted
to
youtube.
Later
we
don't
have
the
official
or
I
don't
have
access
to
the
official
sig
cluster
lifecycle,
youtube
playlist,
but
we'll
get
these
uploaded
once
that's
actually
granted,
so
don't
say
anything
that
you
wouldn't
want
published
all
over
the
internet
and
to
kick
it
off.
A
We
only
have
one
discussion
topic,
but
I
think
it's
gonna
be
a
big
one
that
we
can
kind
of
dive
deep
into
throughout
the
whole
meeting
cool
fade.
You
wanna
get
started
because
you
added
this
item
and
you
wanna
just
start
the
spread,
the
conversation.
We
can
start
adding
issues
and
start
talking
through
what
we
need
to
do
as
an
architecture.
Please.
B
Yeah
yeah,
because
I
go
through
all
the
comments
that
the
review
provides.
B
I
think
I
think
why
is
the
mooner
mooner?
Is
he
one
of
the
kl
from
the
classic
api?
I
think
he's
a
kind
of
maintenance.
Okay
anyway,
first
is
naming,
so
that's
it.
There
is
one
proposal
is
changing
your
hosted.
So
what
do
you
guys
think
I
yeah,
I
feel
nasty
may
not
be
I
mean
for
the
repo
is
probably
okay,
but
for
the
entire
crd
name.
A
Yeah
confusing
might
be
kind
of
confusing
to
have
nested
as
the
name
of
the
project
and
host
it
as
the
name
of
the
crs,
because
you're
going
to
be
creating
different
things.
Now
that
doesn't
mean
that
we
can't
basically
have
somebody
go
rename
the
rename
the
repo.
I
don't
think
that
would
be
a
major
pain,
but
if
that's
something
we
want
to
do.
B
B
A
I
agree:
I'm
wondering
what
you're
thinking
about
the
actual
object
types.
Are
you
not
you
don't
like
it
as
a
as
in
the
actual
crs,
for
a
specific
reason.
B
Yeah,
I'm
just
for
all
the
name
because
think
about
it.
So
now
we
have
a
control
plane
right.
We
have
a
control
plane
template
we
have
now.
Car
is
working
on
three
individual
component
controllers
and
everything
we
are
starting
with
the
prefix
and
previous
either
nested
or
something
so
I'm
just
thinking.
For
example,
if
we
we
for
charge
of,
if
we
say
nested
api
server,
let's
see
the
etc
nested
control,
plane,
controller
manager
would
that
make
sense
or
but
if
you
say
hosting,
they
pass
server
host,
tip,
etc.
B
I
feel
it's
better.
I
don't
know.
A
That's
a
good
it's
a
good
point.
Okay,
so
you're
thinking
that
hosted
could
potentially
be
actual
object.
Types
I
feel
like
if
we're
gonna
do,
that
we
should
change
both
so
we'd
have
cluster
api
provider
hosted
and
cluster
api
provider
and
then
each
one
of
the
types
because
I
believe
they're
supposed
to
be
similar,
but
we
can
confirm
with
somebody
from
actual
cluster
or
from
like
sig
cluster
life
cycle
or
or
more
a
part
of
the
the
leadership
group
for
cluster.
C
C
A
Should
like
the
aws
types?
It's
always
it's
always
aws,
whatever,
whatever
whatever
aws
manage,
control,
plane,
aws
cluster.
Let's
look
at
some
other
ones.
A
B
A
A
Yeah,
this
is
the
vcenter
provider,
so
that
might
make
sense,
but
these
actually
aren't
physical
go
types
or
I
mean
aren't
kubernetes
resource
types,
or
at
least
it
doesn't
look
like
they
come
off
onto
that.
A
B
A
Look
at
say,
I
know,
aws
is
I'm
gonna
switch
to
azure
yeah,
see
what
their
types
are.
A
Yeah,
all
of
azures
are
all
done
with
azure
in
front
of
it.
How
about
packet.
A
So
I
think
either
way
we
should
pick
one
and
go
with
it
for
all
of
them,
in
essence,
just
to
keep
it
with
keep
with
the
same
format.
I'm
not
I'm
not
hard-pressed
on
either
either
direction.
I
think
it
could.
I
think
both
of
them
make
sense.
Okay,.
B
Yeah,
I
don't
have
a
strong,
because
if
we
want
to
change
them,
I
don't
want
to
go
through
that
again
because
we
already
go
through
one
round
to
come
with
that
name.
So
I
believe
in
that
round
you
propose.
A
Hostic
or
singular
it
wasn't
in
our
list
before
so
they
didn't
actually
have
that.
So
I'm
happy
to
pop
that
over
to
tim
and
vince
and
see
if
there's
any
objections
to
see.
B
If
that's
yeah
you,
if
we
don't
have
to
be
consistent,
then
it's
kind
of
even
higher
level
discussion.
So
it's
just
one
to
all.
If,
if,
if,
if
wings,
if
the
class
api
guys
thought
you
know
possibly
is
a
better
name,
let's
just
kill
them
and
be
consistent
for
everything
that
we
add.
Okay,
let's
see.
C
B
Okay,
I
think
that's
a
very
high
level
thing
then
I
think
chris,
how
about
I
just
go
through
each.
I
I
I
believe
there
are
only
two
major
crd
that
we
need
to
go
the
two,
the
the
major
ones.
We
got
got
the
most
comments
right.
There.
A
Yeah
so
there's
definitely
some
there's
some
overarching
things
within
within
the
the
entire
pull
request.
But
there
are,
there
are
a
couple
main
ones
in
here,
so
we
have
namespace
prefixing
calling
out
docs
that
they
should
be
readable.
A
I'm
going
to
actually
open
it
and
separately
without
comments
and
review
it
that
way,
or
how
do
you
want
me
to
look
at
this.
B
Yeah,
first
just
look
at
this
field
right,
the
class,
the
class
name
space.
I
I
yeah
so
this
one,
the
problem
is
they?
Don't
they
don't
know
the
context?
So
they
don't
know
exactly
what
uid
kind
of
thing
right.
B
B
A
So
I
I
think,
there's
I
think,
there's
a
couple
stories
in
here
that
we
could
do.
I
want
to
make
it
so
that
we
have
something
that
out
of
the
box.
It
will
work
if
you
don't
set
it,
but
that
you
have
the
option
to
set
it,
and
then
it
updates
the
status
at
the
end
so
that
we
can
key
off
status
for
the
actual
type.
Instead
of
calling
like
a
conversion
function
to
try
and
generate
these
the
actual
cluster,
the
actual
cluster
prefixes.
A
A
We
can
actually
plan
for
what
those
are
going
to
be
so
that
we
can
register
those
name
spaces,
for
example,
with
other
systems
within
how
our
architecture
set
up,
and
so
the
idea
there
was,
if
we
can
make
it
so
that
we
could
set
those
in
our
instance
and
it's
not
going
to
break
anything
downstream
because
we'd
be
king
off
of
something
like
the
status
field
on
the
virtual
cluster
cr
since
every
sorry,
not
the
virtual
cluster,
the
nested
control
plane
cr
will
have
that
loaded
into
every
every
informer
that
we
need
to
pull
this
from
anyways,
and
so
the
other
would
be
key
off
this
be
able
to
supply
something
I
wrote
like
a
again.
A
A
B
I
think
we
just
it's
fairly
okay,
to
have
this
aka
no
problem.
So,
but
my
my
I,
I
only
have
common
comments.
I
mean
I
have
some
comments,
regards
the
comments
of
this
field.
Okay,
so
so
the
comment
of
this
field,
we
should
I,
whatever
you
said,
is
okay,
because
you,
if
you
said
it,
you
own
your
risk.
The
problem
is,
if
you
set
it
and
if
you
don't
manually,
do
the
detailed
things
you
will
have
trouble
if
they
are
having
same
name
right.
So
your
own
risk
is
okay.
B
B
A
Yeah-
and
we
can
definitely
call
that
out-
so
we
need
to
call
it
that
this
is
typically
defaulted.
It
needs
to
have
a
max
length,
validation
and
warnings
about
its
usage
for
conflicting
name
spaces,
prefixes.
B
A
A
I
think
yeah,
I
think
I
think
a
lot
of
this
will
get
solved
if
we
have
something
like
a
design
dock.
That's
that's
just
out
of
the
box,
so
just
to
tell
you
so
I'm
trying
to
think
of
how
we
can
do
this
in
a
in
a
a
reasonable
fashion
to
make
this
work
well
for
everybody.
I
think
we
can
continue
to
review
these,
but
it's
very
pointed
feedback
towards
that.
A
I
don't
know
if
it's
actually
necessary,
because
I
think
we
probably
need
to
take
a
step
back
to
talk
about
general
architecture
of
this,
so
that
we
can
have
a
dock
that
other
people
can
understand,
so
that
when
we
get
reviews
like
this
or
when
we
get
james
monely,
reviewing
and
and
other
folks
that
they
we
can
refer
back
to
what
the
real
goals
are
of
the
project,
because
I
think
that's
missing.
For
some
people.
A
So
I
wanna
I
wanna
actually
take
it.
Take
us
to
take
a
step
back
because
I
started
to
do
this
just
just
lightly.
Not
I'm
not
trying
to
well
here
anyways,
I'm
just
gonna
open
this
up
over
here.
So
I've
done
this
locally
a
little
bit,
which
is
basically
just
the
base
cap
and
architecture
that
we're
talking
about
here,
and
so
I
started
to
write
up
this.
A
I
can
push
all
these
things
up
into
an
actual
issue,
not
this
doc,
because
I
don't
need
to
publish
this
yet,
but
at
least
we'll
have
something
that
we
can
all
add
issue,
add
things
into
user
stories
so
that
we
can
start
building
against
something
and
my
specific
callouts
here
are
these
sections
and
if
you
can't
read
that
I
can
make
well
actually
these
sections
and
we
can
make
that
bigger
if
we
need
to
because
that'll
help
help
ground
some
of
the
stories
for
folks.
B
A
A
Yeah,
that's
what
I
was
hoping
for,
and
so
what
I'd
love
to
do
is
I'm
going
to
actually
go
through
and
just
move
this
over,
because
this
is
just
going
to
be
creating
a
new
issue
and
what
I'm
thinking
is
that
I
can
just
copy
over
some
like
high
level
goals
of
the
of
here.
I'm
just
going
to
do
this,
so
I'd
like
to
do
high
level,
cap
and
goals
and
free
limb
goals.
A
A
A
C
A
A
A
Way,
what's
your
what's
your
github
handle?
Is
it.
B
A
A
A
Put
you
in
that
part
all
right,
so
this
is
we
should
we
need
to
create
a
new
proposal
document
from
box
proposals.
A
I'm
going
to
say
so,
I'm
going
to
well
what
do
you
think
about
this
art
of
this
doc,
not
covering
the
actual
low-level
objects?
I'm
just
thinking
that
this
is
going
to
be
what
cap
n
is
and
how
it's
going
to
be
built
and
then
ciao.
I
know
you
were
starting
to
work
on
the
actual
types,
the
actual
custom
resources
for
these
objects.
If
we
can
have
another
dock
that
outlines
each
individual
object,
either
one
dock
per
or
have
like
the
overarching,
what
the
actual
control,
plane,
endpoints
or
control
plane
types
look
like.
A
D
So
so
I
am
writing
another
documentation,
because
I
went
through
the
whole
like
working
process
of
how
to
provision
how
to
provision
each
component
for
a
control
plan
which
failed
last
week-
and
I
am
writing
a
documentation
right
now
like
like,
but
but
my
documentation
is
more
like
how
all
these
three
sub
components:
sub
controllers,
the
nasty
k,
nasty
api,
server,
controller,
etc,
controller,
nested
controller
manager,
controller
cooperate
with
each
other
and
what
we
need
from
the
control
manager
control
controller.
A
D
D
A
A
D
D
Of
the
the
major
parts-
and
I
think
when
I
when
I
decide
when
I'm
writing
the
documentation,
I
think
we
should
do
some
like
do
some
change
on
our
api
on
the
the
in
the
pull
request.
D
Actually
it's
just
just
something
like
we
need
to
add
some
field
to
some
specific
crd
like
we
need
to,
for
example,
if
we
have
something
like
nested,
ks,
nested,
api
server,
crd
then
in
links
inside
the
crd,
we
need
to
store
the
name
of
the
nested
pki
or
something
like
that,
and
I
also
feel
I
also
find
out
that
when
I
start
when
we
really
when
we
actually
start
creating
each
component,
we
need
some
information
from
the
nested
controller
manager
controller.
That's
that.
C
D
The
control
plane
controller,
like
the
nested
control
plan
controller,
need
to
create
the
cr
hcr
for
the
sub
controllers
and
it
need
to
create
a
pki,
and
I
need
to
create
something
like
the
root
namespace
or
the
cluster
namespace
in
a
store
all
these
things.
I
just
go
through
all
this,
like
the
process,
how
we
do
this
and
yeah.
That
is
what
I
am
writing.
Oh
yeah,.
A
Awesome
that
sounds
fantastic,
so
I've
just
made
this
add
more
information
into
this
as
you
need,
or
as
you
want,
but
this
is
at
least
what
I
think
you're
working
on
then,
if
that
makes
sense
I
just
covered
the
basics
of
this
is
how
all
the
nested
types
are
going
to
work
together
right,
but.
A
A
I
think
that's,
I
think,
that's
great,
so
that
would
that
would
mean
that
fay
you
and
I
can
you
and
I
can
collaborate
on
the
actual
high
level
architecture
for
what
it's
going
to
look
like
of
just
like
how
this
is
going
to
function,
generically
and
then
chow
yours
is
going
to
yours-
are
going
to
deep
dive
into
the
individual
resource
types
and
how
those
actually
work
that
makes
sense.
B
D
I
I
have
some
questions
so
when
you,
when
you
open
the
first
ecu,
I
noticed
that
you
said
we
are
not
going
to
taking
charge
of
the
etcd
right.
Well,
I'm
not
sure.
What's
what
does
that
mean?
Does
that
mean
we
do
need
to
create
the
etcd
parts
or
workloads
for
a
nested
edcd?
A
Yeah,
so
I
so
you're
specifically
talking
about
this
one
right
right.
A
Yeah
so
my
theory,
my
my
call
out
there
is
that
we
should
have
something
built
in
absolutely
have
something
built
in
a
state:
that's
something
that
just
works
and
provisions
and
that
people
can
start
to
work
with
cap
n
without
doing
anything
new.
The
minus
etsy
day.
The
minus
etcd
is
more
that
we
could
that
for
upgrading
and
things
like
that,
we
don't
need
to
reinvent
the
wheel
and
we
should
be.
We
should
be
planning
for
folks
to
actually
not
use
that
for
the
most
part
like
in
a
production
system.
A
A
But
we
don't
have
to
do
that.
I
mean,
if
we
want
to
if
we
want
to,
if
we
want
to
talk
about
putting
that
as
part
of
the
the
work
items
as
well
to
build
that
we
can
I'm
just
expecting
that
that
could
be.
That
could
be
an
easy
add-on
later
if
we
make
it
plugable
at
the
beginning,.
B
For
edcd,
we
probably
don't
need
to
worry
about
outgrid
at
this
moment,
but
for
other
key
components.
We
need
the
controller.
A
D
Yeah,
I
see
so
I
know
it's.
It's
maybe
a
little
bit
too
early
to
talk
about
it,
but
when
I
so
since
you
said
we
wanted
to
have
a
plugable
nasty,
the
etcd.
Does
that
mean
when
we're
doing
the
first
first
first
implementation,
we
wanted
to
have
something
just
define
an
interface
and
have
this
version.
First,
implementation
workways,
the
maybe
the
etcd
operator.
A
B
A
A
There
start
there
and
then
we
can.
We
can
work
to
to
make
it
pluggable
after
yeah
and
then
from
once
once
we
have
it
pluggable,
then
we
can
explain.
Oh
if
you're
going
to
use
the
improbable
etcd
operator,
you
do
it
this
way
and
you
have
to
deploy.
Maybe
this
extra
controller
that
does
some
some
collaboration
between
cap
n
and
that
operator
and
oh
if
you're
gonna
use
the
the
core
os
one,
that's
deprecated.
A
B
So
the
idea
is
what
we
I
think
we
discussed
last
week,
so
I
think
it
was
one
we
designed
the
it
is
dcrd.
We
should
be
prepared
in
the
future
that
that
adcd
is
not
created
by
us.
It
is
created
by
you
create
another
cr,
some
other
operator
reaction,
that's
the
argus,
etc
then
think
about
it.
If
we
do
that
way,
what
are
the
information
that
we
need
to
store
in
the
this
cdcd
crd
to
give
to
the
necessary
control
plan?
B
So
that's
always
using
one
so
for
the
implementation,
the
first
one
you
just
follow
the
whatever
api
that
we
designed
just
created
our
e-memory.
That's
it.
A
Yeah,
so
that
we
don't
well,
is
there
any
chance
that,
outside
of
outside
of
this
meeting
or
right
now,
ciao,
you
can
actually
add
those
notes
in
just
as
a
comment
on
this,
so
that
people
so
that
people
coming
in
and
reading
this
will
will
understand
what
we
just
talked
about.
D
Yeah
yeah
sure
so
just
to
be
clear
click.
So
we
wanted
to
have
something
like
still
have
a
basic
in
memory,
etc,
control
or
something
like
that,
but
it
will
also
be
plugable
to
popular
adcd
operator
like
the
core
os
one,
something
like
that
right.
Okay,
sure,
true,.
B
Yeah
I
mean
one:
we
just
probably
just
api
wise.
Just
don't
don't
give
you
anything
for
the
practical
thing,
because
that
needs
more
discussion
in
the
first
week
version
just
do
the
provisioning.
That's
it
there's
no
api
at
all.
So
next,
if
you
do
the
plugin
box,
then
we
discussed
the
new
api
and
some
fields.
You
say
if
you
want
to
use
edc
operator,
what
are
the
fields
that
you
specify
in
this
crd?
Something
like
that
and
let's
do
that
later.
A
Yeah
and
it
can
also
be
even
potentially
even
even
like
when
we
get
to
that
it
can
be
something
as
well
where
you
just
you,
pass
a
flag
or
setup
like
on
something
on
a
config
file.
That
says:
don't
use
this
etcd
controller,
just
don't
just
turn
it
off
entirely
and
then,
whenever
the
object
is
created,
we
have
some
out
of
band
controller,
that's
creating
those
things
and
we
like
there's
a
lot
of
ways
that
we
can
do
the
pluggable
stuff,
so
yeah
so
build
it
in
just
out
of
the
box
yeah.
B
Yeah,
I
think
I
think,
that's
good.
So
now
we
have
a
stronger
kind
of
documentation.
Let's,
let's
try
to
fill
all
of
them
yeah.
I
think
I
think,
for
the
high
level,
my
understanding
is
for
the
kind
of
architecture.
B
One
one
more
important
thing
is
just
go
through
all
the
exactly
workflow,
because
this
is
kind
of
a
complicated
workflow.
You
know
what
I'm
saying
the
workflow
is,
I
don't
know,
what's
the
right
figure
to
do
that
we
have
some
figure
in
here.
You
give
it
a
kind
of
life
cycle
span
of
each
object.
B
Once
you
create
this,
this
controller
will
create
another
object
right,
so
I
feel
that
figure
will
have
people
to
understand
what
exactly
we
are
trying
to
do,
because,
honestly,
this
part
of
work
is
hidden
by
all
the
other
providers
because
they
do
that
their
own
way.
Nobody
knows
how
they
do
this
so,
but
we.
C
B
A
D
Yeah,
I
think,
as
we
have
so
okay,
so
I
I'm
going
to
like
create
a
pr
and
upload
the
documentation,
but
just
the
pr-
and
I
will
link
it
to
the
eco-
is
that
okay
or
I
should
put.
A
No
no
yeah
make
it
make
an
issue,
and
then
you
can.
I
think
you
can
just
set
it
as
a
draft
if
you're
not
if
you're
not
ready
for
it
to
be
merged
or
anything
like
that
like.
If
I
prefer
a
call
correctly
that's
what
this
is.
If
it
loads
yeah,
you
can
set
it
as
like
an
actual
draft,
so
it
won't
actually
get
merged,
and
then
we
can
do
like
do
not
work
like
a
whip,
flat
label
and
so
on
and
so
forth,
like
we
typically
do
with
pro.
D
A
Cool
all
right
so
fae
you
and
I
can
work
on
you
and
I
can
work
on
the
base
architecture.
Stuff
I'll
push
this
up
just
so
we
can
start
talking
about
it.
I'm
trying
to
figure
out
the
best
way,
because
we
need
to
collaborate
on
this.
Maybe
we
do
have
to
drop
back
to
google
docs,
just
just
to
do
like
back
and
forth
on
it.
A
B
A
I'll
take
what
I
wrote
up
into
and
put
it
into
a
google
doc
and
link
off
link
to
that
from
the
issue
outside
of
this
meeting.
I.
B
Think,
let's
just
focus
on
just
exactly
you
know
the
basic,
how
many
crds
or
total
all
the
cities
are,
what
we
want
to
create
and
the
workflow,
which
is
a
major
work
controller
that
controls
everything
else.
So,
okay,
we
just
focus
on
that.
You
know
figure
explanation.
So
that's
our
very
important
one.
So
then
people
will
know
what
we
are
doing
kind
of.
A
Okay,
yeah,
okay,
cool
yeah.
That
makes
sense
so
I'll.
Ask
I'll
ask
about
the
hosted
versus
nested.
I'm
just
going
to
pull
this
out.
Put
this
down
here,
we've
got
child
you're
working
on.
You
are
working
on
the
object,
types
or
the
actual
resource
proposal.
A
A
Great
anyway,
you've
been
doing
a
lot
of
stuff
on
the
sinker
on
our
side
of
things.
It
doesn't.
If
you're
interested
in
picking
up
and
working
on
any
of
these
things
reach
out,
we
can.
We
can
all
figure
out
how
that
will
work
too
sure
sure
or
take
a
look
first
yeah.
B
That
is
real
users
use
user
stories
in
your
site.
We
can
put
that
as
well,
but
since
we
don't
use
this
approach,
we
use
a
slightly
different
approach
in
our
site,
but
I
I
think
I
can
create
one
or
two
at
least
that'd
be
great.
I
I
I'm.
B
We
need
to
have
some
use
cases
around
that
I
think,
but
I
I
believe
that
overall,
we
kind
of
have
one
use
case
since
that
say
saying
that
you
know
we
have
a.
We
have
a
multi-tenancy
requirement,
so
every
tenant
needs
a
cluster.
So
that's
a
very
basic
one
right.
B
We
should
highlight
some
exactly
why
we
need
to
use
it.
A
Yeah,
I
think
the
only
the
only
thing
that's
close
to
that
is
number
four
on
this
list,
which
is
just
I
want
to
be
able
to
as
a
developer.
I
want
to
be
able
to
use
control,
plane
level
resources
without
like
conflicting
with
another
control
plane,
but
it
doesn't
talk
about
the
actual
multi-tenancy
aspects.
I
had
written
a
little
bit
of
that
into
the
motivation
and
summary
on
this
doc
that
I
just
started
just
to
kind
of
like
not
jot
down
ideas.
A
B
B
A
Cool
all
right,
chow,
do
you
have
anything?
Do
you
want
to
actually
show
what
you've
been
working
on
so
far
or
wait
until
you
push
that
up
and
we
can
talk
about
it
over
in
issues?
I
can
give
you
access
to
share
your
screen
if
you,
if
you're
ready
for
that,
I
see
chris
how
about
how
about
we
go
through
the.
B
Api
that
the
promoter
that
you
have
rewritten,
let's
go
through
all
the
comments
on
that.
Let's
just
make
agreements
then,
overall,
I
don't
think
we
need
to
do
fundamental
changes
because.
B
D
So
also
the
template
graph
will
actually
be
just
the
pot
templates
back
or.
D
A
Yeah,
so
it
references
a
nested
control,
plane
template.
I
wonder
if
there's
a
way-
and
this
is
something
that
that
I
don't
know
the
best
answer
here
so
I'd
love
to
to
have
like
an
open
dialogue
about
what
what
we
all
believe
is
the
right
way.
So
in
my
in
this
example,
my
this
template
ref
refers
to.
Like
you
point
out
here,
it
refers
to
this
nested
control.
Plane
resource
find
the
actual
type
there.
It
is
so
it
refers
to
this
which
uses
these
config
add-ons.
A
I
know
we
already
had
comments
in
here.
Sorry,
I'm
jumping
ahead
a
couple
comments,
but
this
type
is
interesting
in
that
it
points
to
a
manifest,
so
it
either
points
to
a
raw
kubernetes
manifest
or
a
customized-based
manifest.
I
don't
know
if
that's
the
best
option
here,
because
there's
potentially
other
ways
of
doing
this.
So
if
you
look
at
what
we're
doing
in
cluster
resource
set,
I
don't
know
if
you
all
had
a
chance
to
actually
look
at
that
object
yet.
A
A
We
could
do
this
referring
to
like
an
object
somewhere
within
the
cluster,
and
you
could
say
that
when
you
deploy
this,
you
provide
a
you,
provide
manifest
files
for
each
one
and
refer
to
them
the
same
way
that
we
use.
We
do
in
the
cluster
resource
set.
B
I
think
I
think
so
in
my
opinion,
I
feel
that
the
resource
set
because
they
need
to-
let
me
put
it
this
way,
so
that
is
more
flexible,
because
the
resource
type
can
have
many
more.
Who
knows
right
yeah,
but
in
our
case
we
all
we
probably
are
only
limited
to
three
kind
of
ports:
api
server,
controller
manager
edc.
B
Objects
to
handle,
so
I
feel
I
prefer
the
azone
part
because
give
a
url
give
all
the
templates,
because
which
means
the
number
of
timelines.
We
have
is
kind
of
limited.
It's
not
very
unlimited
right,
because
each
one,
you
can
grow
the
template
version.
But
again
we
already
have
three,
so
I
feel
it's
still
manageable
to
have
this
add-on
thing
I
I
was
discussing
so
this
more
looks
like
if
we
have
amazon
thing,
we
give
all
the
up
somewhere
freedom
in
our
github
right.
B
I
believe
in
each
version
we
can
provide
one
template.
That's
most
likely
is
the
case
1.16.
You
have
one
right
for
e3,
so
there
won't
be
too
many
terminator
files
we
need
to
manage,
so
we
don't
want
to
need
to
worry
about
explore.
You
know,
explosion
of
all
the
files
sure
this
is
my
my
understanding.
If
you,
if
you
do
that
way,
you
in
our
bootstrap
script,
we
need
to
create
all
those
objects.
A
Each
one
of
those
objects
could
be
something
that
we
have
so
when
you
do
something
like
cluster
ctl
emit
and
it
generates
all
of
the
the
files
for
you
based
on
the
provider.
We
could,
in
theory,
make
it
so
that
it
generates
all
of
the
different
templates
for
you
as
config
maps
or
secrets,
most
likely
going
to
be
config
maps,
but
as
configmaps
locally
that
you
then
just
apply.
So
we
automate
the
management
of
creating
those
resources.
A
B
Yeah
another
thing
is:
we
need
to
be
very
as
we
discussed
before.
We
want
to
make
this
template
immutable.
We
don't
want
people
yield.
Everything.
Object
is
kind
of
too
flexible.
If
you
change
the
content,
you
don't
know
you
can
change
your
content.
You
have
to
write
another
controller
to
prevent
people
to
change
your
own
content
yeah,
but
yeah,
but
the
url
base
is
better
right.
You
can
just
give
read
permission.
No
one
can
change
it.
A
B
D
So
if
a
user
wanted
to
change
some
configuration
of
the
component
say
you
wanted
to
add
a
new
command
line:
option
for
the
control
plane
for
the
control
manager,
then
it
can
use
the
cluster
ctrl
first
to
generate
the
templates
and
then
manually
change
the
controller
manager
templates
and
then
apply
it
to
the
cluster.
We
have
some
corresponding
config
map
and
then
these
components
least,
these
components
will
refer
to
this
configure
map
and
create
actually
control
plan.
For
us
right
is
that
a
the
right
process,
the
correct
process.
B
C
D
A
Would
it
be,
would
it
be
beneficial
to
okay
if
we
took
a
step
back
and
thought
about
the
templating
in
general?
Is
that
the
right
path
to
have
a
built-in
template
or
should
nested
nested
k?
What
is
it
nested
control,
plane,
sorry,
nested,
lcd,
nested,
api
server
and
nested
controller
manager?
Should
those
just
contain
what
is
going
to
be
paved
and
you
can
technically
just
like
from
a
more
declarative
route,
not
a
not
a
dynamic,
not
a
dynamic,
based
on
a
template
use
every
single
time
you
deploy
a
control
plane.
A
You
could
supply
the
configurations
for
that
control
plane.
Now,
however,
you
use
that
in
your
implementation,
you
could
be
using
a
standard
set
and
it's
okay,
it
doesn't
matter,
and
then
we
get
rid
of
the
template,
but
your
actual
crs
that
we're
truly
creating
behind
the
scenes
have
all
the
information
about
what's
supposed
to
be
provisioned.
A
So
if,
if
nested
std
had
all
of
the
parameters
that
you
could
potentially
pass
in,
for
example,
it
could
technically
contain
a
pod,
a
pod
template.
Would
that
make
it
easier
for
us
to
do
do
this
or
is
that
make
it
too?
Is
the
con?
A
Is
it
too
much
of
a
concern
that
you
could
have
one
cluster?
Have
this
configuration
and
a
completely
another
cluster,
have
this
configuration
and
there's
drift
between
every
single
environment?
At
that
point,
I
know
we've
talked
about
this
in
the
past
and
I'm
just
trying
to
open
up
the
question
again.
B
So,
based
on
my
understanding,
so
I
think
I
discussed
with
child
again.
So
the
way
that
we
have
this
template
is
that
we
have
a
single
place
to
configure
everything
yep.
So
then
the
consequences
that
every
individual
controllers
once
they
once
they
want
to
know
exactly
which
water
part
template
I'm
going
to
create.
I
need
to
look
back
first,
find
the
next
control
plane,
template
and
check
exactly
the
components
as
on
url
gets
a
yammer
and
gets
gets,
get
the
object
right.
So
that's
a
workflow,
I
think
tao
is
we
discussed.
B
This
is
currently
how
it
does
we
need
to
have.
You
know:
reverse
link
to
the
template
for
every
controller,
for
every
new
cr
right.
So
in
a
centralized
place,
the
good
thing
is,
you
can
have
a
place.
B
B
A
I'm
thinking
that,
if
you
did
it,
if
you
did
it
so
that
you
had
individualized
crs
for
each
thing,
each
resource
you
could
individually
update
one
component
of
it
and
not
have
to
manage
like
you
as
a
human
could
do
update
the
api
server
and
then
you
as
a
human,
could
two
minutes
later
update
controller
manager.
After
you
know
it's
up
to
date,
and
then
we
can
build
automation
around
that
after
the
fact,
honestly,.
A
That
I'm
thinking
thinking
there.
B
Yeah,
but
I
think
that
that
approach
has
a
problem
is
if
different
components
can
be
upgraded
differently.
They
may
not
work
together
right,
but
the
template
is
a
good
thing
is
whatever
we
put
in
a
template
is
a
set
of
configuration
that
we
I
mean
the
addition.
B
Yeah
yeah
it
works
even
upgrade,
is
you
know
you
have
to
bump?
Maybe
you
need
to
bump
up
all
the
versions
you
want
to
make
it
work.
If
you
bump
individual
versions,
it
may
not
work.
So
that's
the
reason
I
still
like
you
know
as
a
you,
pretty
much
check.
Take
that
template
as
a
you
know.
Whole
cluster
version,
if
you
treat
everything
as
a
custom,
bundle.
A
I
wonder
sorry,
I'm
gonna
I'm
going
back
and
forth
between
meetings.
You
don't
hear
me
typing.
I
wonder,
though,
now
if
we,
if
we
again,
I'm
not
for
or
against
I'm
just
trying
to
talk
out
the
the
potential
ideas
here.
So
if
we
made
it
generic
that
this
could
technically
be,
this
technically
could
be
sorry.
We've
had
somebody
drop
into
the
chat
for
a
second
or
into
call
for
a
second.
A
So
I,
if
we
did
it
where
you
had
individualized
components
and
say,
for
instance,
the
virtual
control
plane
had
references
for
each
one
of
those
say,
for
instance,
in
the
virtual
control
plane
cr,
you
had
an
object
ref
for
the
api
server.
You
had
an
object
ref
for
the
controller
manager
and
you
had
an
object.
C
A
For
the
mcd
cr,
the
nested
resources
of
those
and
that
that
managed
as
our
template
for
each
control
plane
and
it
could
point
to
different
point
two
different
templates
and
update
itself
under
the
hood-
would
that
do
a
similar
function
for
you.
You
know
that
this
control
plane
is
now
stamped
as
this
and
and
you
can
guarantee
you
can
guarantee
that
these
versions
work
together
because
they're
being
deployed,
but
then
you're
outside
of
of
cap.
A
End
tooling,
is
what's
doing
the
true
validation
that
these
three
crs
work
together,
and
so
it's
not
built
into
cr
to
do
the
validation
of
the
control
plane
but
built-in.
But
it's
something
you
do
out
of
out
of
the
provisioning
life
cycle.
I
don't
know
like
I
don't
know
if
that's
better
or
worse.
B
I
think
yeah,
I
think,
let's
just
take
the
operation
of
one
point
of
view.
So
if
you,
if
people
indeed
has
you
know,
requests
to
do
individual
upgrades,
maybe
individual
each
crd
has
a
version,
maybe
better,
but
if
we
agree
we
do
customize
upgrade
most
likely.
I
feel
you
know
a
central
central
place
describe.
The
class
version
is
better.
It's
more
understanding.
D
D
D
So
I'm
thinking
about
can
we
have
something
like
steel?
We
have
a
default,
add
zone
or
refer
to
an
ui
or
a
default
template,
but
we
open
up
fields
like
a
patch
patch
yaml
or
something
like
that.
Then
user
can
put
in
their
things
they
wanted
to
patch.
When
we
create
a
new
controller
plan
or
any
components,
we
first
use
the
default
template.
Then
we
apply
the
user's
patch
yamo
onto
our
default
templates.
D
Then
we
can
like.
We
can
work,
we
can
work
with
the
default
version.
We
can
have
the
user
to
specify
layer
customize
the
options
we
can
do
both
right
and
if
we
wanted
to
update
upgrade
say
if
a
user
wanted
to
upgrade,
they
just
need
to
upgrade.
They
just
need
to
update
the
patch
llamo
the
fields
and
say
we
wanted
to
use
a
new
image.
D
B
Wow
tom,
my
point
is:
unless
you
do
it,
it's
a
lot,
which
means
unless
people
really
want
to
have
an
individual
patch,
you
have
you,
you
will
see
thousands
of
individual
patches
that
may
make
okay
to
give
a
flexible
interface.
B
A
More
templates
or
more
or
you
have
potentially
like
snowflake
control
planes
that
you're
then
dealing
with
because
they
have
all
these
patches
on
them.
And
if
you
upgrade
the
underlying
template
for
say,
for
instance
like
if,
if
somebody
went
in
an
upgraded
116
template
and
it
tried
to
reconcile
those
and
the
patches
failed,
then
we'd
have
to
figure
out
how
to
how
to
deal
with
yeah.
B
Failure
yeah,
I
still
like
the
template
thing,
is
that
first,
you
know.
Indeed,
we
shouldn't
have
too
many
families
in
practice
going
to
create
those.
Many
templates-
and
I
think
I
asked
chris
in
the
first
big-
are
you
going
to
send
all
every
request
from
the
developer?
Probably
know
you
probably
just
want
to
sell.
You
know
satisfy
what
you
I
mean.
You
probably
create
one
template.
That's
it
I
mean
if
you
total
number
of
ten
minutes
limited
this
way.
First
make
it
simple.
Second,
you
have
a
consistent
view.
So
it's
easy
to
check
exactly.
B
C
C
B
C
B
A
I
think
we
can
pull
what's
what's
in
cube,
adm,
because
you
can.
You
can
deploy
those
as
as
static
pods,
so
we
could
technically
pull
the
configs
from
from
cube
adm
from
the
first
yeah
for
the
first
excellent
or
definition
of
it.
B
B
A
Yeah
we've
been
doing
that
as
that
exact
same
thing,
we
potentially
have
noticed
some
interesting
stuff
with
the
sinker
and
118
because
of
endpoint
slices
that
we
should
talk
about
at
some
point,
but
that's
more
vc,
specific
stuff,
so
yeah
real,
quick,
just
a
time
check
we're
at
11.
I
believe
we
technically
have
the
multi-
maybe
not
not
today,
right
last
week,
right
not
today,
okay,
we're
at
time,
if
you,
if
you
all,
want
to
continue,
we
can
or
we
can
continue
this
conversation
over
slack.
B
I
think
that's
just
an
endless
moment:
let's
just
make
a
meeting
finish
on
time,
so
I
think
we
have
plenty
to
do.
I
think
we
can
discuss
api-wise
there's.
If
we,
I
guess
we
are
most
likely
agree
that
we
should
stick
to
what
whatever
we
have
now
for
the
first
reading
for
the
first
version,
because
it
is
simple,
I
feel
it
is
simple.
A
Agreed
no,
what
we
do
have
right
now
is
is
really
simple
and
it
will
work
really
well
just
to
get
this
kick
started,
and
then
we
can
continue.
We
can
extend
from
there
after
we
implement
it
in
the
new
types.
B
If
you
want
to
discuss
more,
please,
we
can
just
again
go
to
all
the
comments
that
people
give.
I
think
we
probably
only
have
one
or
two
left,
but
I
guess
the
naming
one
is
the
most
critical
one
yeah
some
other
parts
is
pretty
some
fields.
I
think,
for
example,
this
ready
one.
I
just
think
we
we
need
to
change
the
name,
don't
quote
it
ready
just
give
some
some
other
names
say
provisioning,
dong
or
something
like
that.
No,
oh,
it
is,
I
believe,.
C
D
You
know
one
thing:
it's
actually
we
can
use
use
ready,
because
if
we
are
going
to
use
something
like
stable
set
deployment,
we
can
use
something
like
readiness
probe
to
make
sure
these
components
is
ready.
Then
we
monitor
this
stable
set
status
and
we
can
say:
okay.
This
component
is
ready
because
we
have
already
probed
these
things.
A
Yeah
so
this
is,
this
is
from
the
control
point
types
so
required
field
required
status,
fields
include
ready
and
initialized,
and
then
we
have
the
rest
of
it
for
what
we're
going
to
use
if
we're
going
to
have
replicas
and
so
on
and
so
forth.
So
I
guess
technically,
we
need
to
we
need
to
re-evaluate,
because
I
only
used
the
the
top
one,
but
if
we're
going
to
be
using
replicas
of
everything
that
we.
D
D
A
I'll
be
honest,
I
was
having
some
issues
just
even
including
conditions,
because
it
was
screwing
some
some
stuff
up
with
the
with
the
imports.
I
believe
it
was
because
I
pulled
some
of
the
some
of
the,
because
I
was
vendor
bernetti's,
so
the
vendoring
of
kubernetes
was
causing
issues
but
trying
to
also
vendor
in
cappy's
types,
which
is
why
I
pushed
this
out.
A
A
To
here
so
yeah,
so
cluster
and
and
control
plane
both
have
at
least
some
set
of
things
that
are
required
for
them
to
be
defined
on
or
to
have
defined
on
them.
A
We
should
be
reviewing
and
making
sure
that
we
conform
to
those,
because
that's
going
to
be
what
allows
us
to
use
the
other
cappy
features
like
the
health
checking
and
and
cluster
resource
set,
because
it's
going
to
check
to
see
if
ready
is
set
and
if
ready
set,
then
it's
going
to
be
able
to
continue
on
forward
so
all
right.
Well,
I'm
going
to
call
this
meeting.
This
has
been
really
useful.
I'm
super
stoked
about
this.
Thanks
everybody
for
joining
and
eventually
I'll
get
this
posted
to
youtube.
A
Once
I
figure
that
out,
I
will
also
go
talk
with
timings
and
and
folks
to
figure
out
what
they
all
think
about
potentially
doing
hosted
instead,
if
they're
good
with
it,
is
that
something
that
you
all
want
to
do
as
well,
switch
it
up
to
hosted
or
do
you.
B
A
Yeah,
I
wonder
if
it
would
confuse
people
to
see
a
nested
control
plane,
or
I
mean
I
hosted
control
plane
and
think
that
that
means
that
it'd
be
backed
by
some
some
hosting
provider
like
like
that
would
be
my
one
concern
about
being
hosted
is
is
if
somebody
thinks
oh,
this
now
means
that
eks
and
aks
and
digitaloceans
provider
they're
meant
to
now
be
implemented
in
this
hosted
provider
implementation.
Then
I
think
that's
a
bad
idea.
B
But
cool
it
made
me
it's
kind
of
hard.
I
mean
it
is.
If
I
was
thinking
you
know,
repo
use
nested,
but
crd
use
another
name,
but
if
you
think
they
have
to
be
consistent,
I'm
okay,
let's
stick
to
nested,
I
mean
it's
just
once
people
get
used
to
it
and
people
get
used
to
it.
A
Yeah
also,
once
we
define
once
we
set
the
base
architecture,
I'm
think
I'm
sure
people
are
confused
by
what
this
project
is
doing
because
nobody's
really
seen.
I'm
sure
people
haven't
gone
back
and
actually
reviewed
all
the
docs
that
I
linked
in
in
slack
about
the
original
design
for
virtual
cluster
and
like
what
this
project
does.
So,
I'm
sure
there's
just
a
lot
of
confusion
and
we
can
just
iron
that
out
with
with
docs.
B
Yeah,
I
don't
know,
I
mean
just
that's
a
valid
concept
anyway.
Okay,.
A
Cool
I'll
talk
with
them
and
see
if
they
have
the
same
concerns
and
we'll
discuss
back
in
the
in
slack
what
the
feedback
is.
Okay,
cool
thanks.
Everybody
appreciate
everybody
joining
see.
Y'all
next
week.