►
Description
#sig-cluster-lifecycle
#capn
#capi
A
Computer
all
right
good
morning,
everybody,
this
is
the
cluster
api
provider
nested
office
hours
that
happens
at
tuesday
at
10
a.m,
pacific
standard
time
this
meeting
is
being
recorded,
so
don't
say
anything
you
wouldn't
want
to
be
posted
onto
youtube
later
or
anything
like
that
and
yeah.
I'm
going
to
share
my
screen
and
get
this
started.
We
only
have
one
thing
on
the
agenda
and
I
want
to
make
sure
everybody
else.
If
you
have
anything,
please
add
those
to
the
agenda.
C
Hi,
I'm
justin
santa
barbara.
I
work
at
google.
I
thought
this
project
looked
really
cool.
I've
been
more
involved
in
class
provisioning
for
a
long
time
and
thought
this
project
looked
cool,
so
I
thought
I
would
come
along
and
learn
more
about
what
it
is
about
and
I'm
catching
up.
Thank
you
for
having
me.
A
All
right
sounds
good.
I
don't
have
any
psas
for
the
day.
Does
anybody
have
anything
that
they
want
to
bring
up
before
we
move
on,
to,
I
think,
probably
the
biggest
item,
which
is
now
that
we
have
the
proposal
done
thanks
chow
for
putting
all
that
in
it
looks
fantastic.
We
should
start
doing
work
breakdown,
so
we
can
actually
start
moving
forward
on
on
the
rest
of
this
unless
some,
unless
work
has
been
done,
that
we
just
haven't
that
hasn't
been
pushed
up.
D
I
don't
know
if
you
guys
have
this
requirement,
but
have
you
got
you
know
even
internally
or
even
from
the
community
people
ask
what,
if
you
have
not
one
super
cluster,
you
have
more
than
one
super
cluster.
How
does
that
work?
My
current
answer
is:
no.
We
don't
support
it,
unfortunately,
but
but
I
do
think
that's
that
legitimate
request,
because
there
are
cases
that
you
just
cannot
combine
everything
in
one
cluster.
So
I
was
thinking
the
the
the
way
to
let
our
you
know.
D
The
whole
architecture
support
the
mardi
gras
supermaster,
so
I'm
not
going
to
use
proposed
details
today.
I
just
want
to
give
you
guys
a
heads
up,
I'm
thinking
of
this
problem
and
I
have
a
kind
of
a
solution
in
mind
in
next
couple
of
I
will
find
a
time
a
proper
time.
Maybe
I
will
share
some
of
my
thoughts
about
this
topic.
D
There
are
some
changes,
but
my
design
will
mod.
My
hope
is,
you
know
mostly
leverage.
Our
current
infrastructure,
don't
you
don't
think
it
as
a
you
know,
traditional
federated
thing,
it's
kind
of
different,
because
I
want
my
solution
to
fit
our
architecture.
That's
the
number
one
sort
of
yeah.
I
just
want
to
kind
of
give
you
guys
a
heads
up,
I'm
thinking
of
this
problem-
and
I
probably
will
give
you
some
thoughts
in
next
couple
of
minutes.
A
Awesome
yeah,
I'm
very
interested.
I
I
mean
if
you
want
to
start
talking
about
it,
I
would
be
absolutely
interested
in
hearing.
I
know
I've
kind
of
noodled
on
some
some
thoughts
about
that,
because
that
is
a
path
that
I
want
to
go
long
term.
I
know
we're
we're
not
ready
for
that
internally,
yet
everything.
D
D
Yeah,
so
let
me
just
spend
a
little
bit
more
minutes
about
this.
So,
okay,
one
problem
is
the
scheduling
problem,
because
you
need
to
design
once
you
have
a
talent
object,
you
decide
which
classes
you
go.
This
is
a
scheduling
problem.
It's
kind
of
this
problem
is,
like
you
know,
common
federated
cluster
scheduling
problem,
but
I
want
to
do
it
in
a
different
way.
The
second
problem
that
you
said
is:
how
do
we
synchronize
the
objects
right,
so
we
realize
on
synchro,
then
this
is
a
single
topology.
D
Basically
you
have
a
bunch
of
you
have
a
bunch
of
canon
cluster.
You
have
a
bunch
of
supercluster
and
you
probably
have
one
or
multiple
thinker
is
sitting
in
between.
You
just
need
to
build
up
the
mesh
to
connect
them
together.
That's
the
whole
thing,
so
this
using
is
actually
a
little
bit
separated
because
you
can.
This
is
kind
of
separate.
You
cover
the
problem,
but
we
can
discuss
it
one
by
one.
So
even
for
the
match
kind
of
sync
mesh
kind
of
thing,
you
can
have
a
centralized
match
or
have
multiple
thinkers.
D
A
Cool
yeah,
looking
forward
to
hearing
hearing
about
that,
I
think
that
that
is
a
a
a
good
goal
for
us
to
eventually
get
to,
because
that
will
really
take
us
to
to
a
completely
new
level
of
of
trying
to
treat
these.
These
super
super
control
planes
under
the
hood
as
or
like
as
they
are
in
cappy
at
least
management
clusters
in
into
a
different
level.
D
Yeah
yeah,
I
yeah.
I
agree
because
this
probably
if
you
think
far
and
think
loudly
this
is
probably
the
biggest
you
know
the
benefit
that
people
can
gain
this
project
other
than
have
this
simple
stuff,
because
if
you
have
a
way
to
combine
all
your
cluster
into
one
and
the
provides
provides
a
kind
of
multi-tenancy,
isolated,
multi-tenancy
user
experience,
that'd
be
fantastic
myself.
A
Cool
all
right,
sweet
and
just
make
sure
ciao
is
on
right,
yeah
cool,
so
I
wanted
to
actually
go
through,
so
I
think,
moving
on
to
the
next
item.
At
least
I
wanted
to
do
like
an
actual
work
breakdown
of
everything
we
need
to
do
now
that
we
have
that
proposal
merged,
so
we
can
move
forward.
Does
that
sound
good
to
everybody?
A
D
A
D
A
A
D
A
D
Of
blocking
you,
you
mean
we
have
all
the
components
stuff
down.
We
don't
have
our
chest
straighter,
it
still
doesn't
work
so
sure.
So
I
think
the
next
immediate
item
is.
We
need
to
figure
out
the
the
top
level
prd
design
and
okay
yeah
coding
wise.
I
think
the
child
can
start
this
to
send.
You
know
to
submit
the
you
know:
scaffolding
code
for
the
following
controller
stuff.
A
A
B
A
D
I
think
a
voting
code
can
just
send
it
by
people
you
don't
have
to
so
you
just
all
the
ram
code.
So
how
about
like?
Let
child
just
just
assign
one
controller,
one
one
component
to
trial
and
he
will
set
up
all
the
you
know.
Smartphone
code
and
the
rest.
People
will
just
add
the
rest
to
component
components.
At
least
the
code
wise
most
common
code
has
been.
That
should
be
pretty
straightforward.
A
Okay,
oh
three,
so
for
all
three
components
and
that'll
be
expanding
upon
just
so,
we
know
go
back
to
here,
so
that'll
be
expanding
on
the
the
base
defaults
that
that
vince
put
in
for
for
getting
up
and
running
with
cappy
projects
like
the
main.go
so
making
sure
it
just
mutates
those
things
so
we'll
just
do
the
base.
Scaffolding
for
the
three
components.
A
A
D
A
A
Great
and
then
we
need
one
for
creating
controller
for
nested
api
server.
You
can
assign
this
one
to
me
cool
now,
actually
justin,
since
we
have
you
on
the
line,
I
want
to
talk.
I
want
to
open
this
up
a
little
bit
since
I
didn't
get
a
chance
to
meet
with
you
all
last
week
for
the
cluster
add-ons
group
since
you've
been
since
you've
done
a
lot
of
work
in
that
space
just
to
open
up
the
conversation
before
I
completely
file
all
the
rest
of
these
issues.
A
What
we're
planning
on
doing
here,
if
you
haven't,
had
a
chance
to
actually
read
the
the
design
dock,
is
we're
planning
on
using
the
cluster
add-ons
and
like
the
qbuilder
declarative
patterns
project
in
essence,
to
go
and
deploy
three
different
components
within
the
control
planes.
I
think
you've
reviewed
some
of
the
the
virtual
cluster
docs
a
little
bit,
but
the
idea
there
is
we'll
have
an
individual
cr
for
nested
control,
nested,
api
server,
nested
controller
manager
and
nested
lcd.
A
Most
of
that
is
so
that
we
can
swap
out
those
implementations
as
we
need,
for
example,
we're
not
looking
at
using
what
we
build
in
tree
as
a
nested
scd
provider.
For
example.
We
want
to
use
something,
that's
more
off
the
shelf
that
has
a
that's
a
little
bit
more
battle
tested
because
there's
a
lot
of
prior
art
in
that
space,
and
we
don't
need
to
reinvent
that
wheel.
A
C
C
Awesome,
evan,
cordell
from
red
hat,
is,
has
a
cap
around
sourcing
it
from
an
image
registry,
so
you
know
there's
more
flexibility
about
where
those
images
come
from,
and
I
think
I
have
a
pr
up
to
support.
I
don't
think
you're
going
to
need
this
for
the
things
you've
described,
but
if
you
wanted
to
put
something
into
the,
I
can't
remember
what
you
call
them
you
the
tenant
clusters.
If
you
want
to
put
something
into
the
tenant
clusters
from
the
super
cluster,
I
think
I
have
a
pr
up
that
enables
remote
application.
C
It's
still
in
an
early
stage,
so
you
could
have
a.
Let's
suppose
you
want
to
manage
your
cube
proxy
in
the
tenant
cluster
from
the
super
cluster.
You
could
maybe
do
that
using
a
crd
in
the
super
cluster
which
would
then
be
applied
into
the
tenant
cluster.
You
don't
have
to,
but
that
there's
some
initial
work
going
on
there
as
well,
which
might
also
be
relevant
but
yeah.
It
should
the
basic
use
case
of
I
have
a
crd.
A
A
Cluster
deploys
a
cluster,
go,
deploy
additional
resources
because
we
were
thinking
about
using
say,
for
instance,
the
core
dns
operator
that
you
already
have
using
that
to
using
the
cluster
resource
set
to
be
able
to
deploy
things
like
core
dns.
So
you
had
tenant
dns
in
every
tenant,
control,
plane.
C
Yeah
we've
spoken
with,
I
can't
remember
the
person
working
on
it,
but
them
around
like
reusing
some
of
the
code,
and
I
think
they
want
to
keep
their
the
one
in
cluster
api
super
simple,
whereas
we
want
to
do
sort
of
the
ongoing
reconciliation,
so
it
wasn't
necessarily
100
overlap.
Okay,
but
I
think
in
my
ideal
world
those
two
things
would
converge
like
there
would
be
more
reuse
of
the
libraries.
C
A
A
A
A
D
A
D
Yeah
yeah,
I
don't.
I
don't
have
something
in
my
right
now,
but
sometimes
maybe
maybe
I'll
be
kind
of,
because
we
need
to
write
documents
about
how
to
use
it,
because
the
deployment
model
is
kind
of
different
from
what
it
looks
like
before
you
were
using
class
version
to
define
everything.
Now,
if
you
look
at
the
selection
of
people
already
asking
why?
Why
not
just
last
version
so
yeah
and
that
guy
sent
me
in
a
bride
that
guy
sent
me
everything
messages
he's
he's
used
to
customization.
A
D
A
Cool
yeah,
if
we
can
get
them
if
we
can
get
them
involved
or
something
at
some
point,
that
would
be
awesome
because
yeah
they
have
great
great
thoughts
and
another
person
from
another
company
with
different,
different
different
designs
and
goals
that
they're
trying
to
get
out
of
out
of
the
use
cases.
So
do
you
encourage
him.
D
A
Yeah
we're
not
stuck
stuck
on
anything
specific,
so,
okay
cool
all
right,
so
it
sounds
like
we
have
at
least
three
components
that
we
need
to
build.
Hopefully
we
can
get
something
something
by
next
week,
if
not
keep
moving
forward
when
we
can
actually
get
these
out.
So
chris
with
you,
we'll
first
go
through.
A
A
A
D
Oh
yeah
yeah,
but
not
immediate
action,
but
some
guys
from
internal
guys
have
some
suggestions
in
terms
of
the
coding
they
said.
Maybe
the
current
single
code
can
be
can
be
organized
in
a
better
way,
because
all
the
resource
think
logic
there's
some
duplicate
code
or
maybe
organize
them
like
in
a
runtime
library
kind
of
thing
to
make
the
code
looks
better.
D
That's
definitely
a
good
suggestion,
but
yeah,
as
we
know
also,
but
I
put
it
as
optional
things,
but
it's
not
definitely
not
necessary.
As
of
now,
because
a
few
sources
I
have
is
the
current.
The
current
code
looks
a
little
bit.
You
know
chubby,
that's
kind
of,
but
it's
not
a
very
concise
structure,
but
in
other
ways
we
have
a
strong
control
about
the
resources
that
we
want
to
think
I
want
to
go.
I
don't
want
to
go
to
another
extreme
that
people
can
easily
think
everything
right.
That's
my
thought.
D
So
I'm
afraid,
if
you
do
a
kind
of
long
time,
framework
kind
of
thing
people
can
easily
add
more
and
more
things
into
it.
That
has
a
downside
because
it's
not
directly
copied
there
is
a
abstraction.
There
is
a
kind
of
abstraction
that
is,
you
make.
I
mean
super
class
as
a
resource
provider
owning
just
a
resource
provider.
Nothing
more.
I
don't
want
to
kind
of.
You
have
a
control
logic
in
the
you
add
some
controller.
For
example,
if
you
using
using
workload,
crd
that'll,
be
incredible
because
you
have
two
workloads
work
together.
D
Why
is
intended?
Why
is
it
super?
It's
a
disaster.
So
that's
another
thing,
I'm
thinking
of
so
maybe
you
guys
have
better
ways
to
achieve
both
make.
We
have
a
you
know
clear,
common
size
code
structure,
but
by
the
meantime
we
have
easy
control
of
what's
it's
ubc
and
what
other
things
you
want
to
be
seeing.
B
Yeah,
so
goals
will
go.
Let's
go
ahead
away,
sorry
yeah!
So
there
are
also
a
question
so
here
in
our
implementation,
we
have
two
syncer
implemented.
One
is
of
course,
the
standard
resource
thinker.
Another
is
our
internal
crd
thinkers,
I'm
not
sure.
In
the
long
run,
can
we
combine
it
into
two
thinkers
and
using
the
dynamic
package
so
that
the
the
the
chrono
syncer
can
also
handle
the
crd
whatever
customer
they
find
that.
D
B
D
That's
just
I'm
afraid
you
give
a
very
nice
framework.
People
can
add
everything
that
they
want,
but
they
can
make
a
mistake.
They
probably
don't
understand
and
make
mistake,
and
so
I
want
to
have
some
exactly
control
over
what
things
should
be
think,
but
for
now
the
way
that
I
control
is
we
hard
code
it.
So
everything
needs
to
be
sync.
At
least
our
technique
has
to
be
approved
because
we
think,
through
all
the
side
effects
of
sync
this
object.
D
A
Yeah,
it
seems
like
you
could
probably
add
that
same
function
that
we
use
for
syncing
at
least
bi-directionally
syncing
up
into
the
tenant
control
planes.
If
we
use
the
same
function
that
we
use
for
priority
classes,
storage
classes
like
the
actual,
the
annotation
or
the
label
to
label
it
as
public,
true
or
like
tenancy
x,
dot,
k
station
public.
True,
if
we
did
that
on
c
or
d's
in
the
super
cluster
it'd
be
nice
to
be
able
to
sync
those
automatically
up
to
a
tenant
control
plane.
A
D
C
A
Cool.
Thank
you.
We
appreciate
that
also
on
that
note,
because
of
the
projects
that
you're
working
on
at
some
point
thinking
about
what
you're
doing
around
like
the
annotated,
open
api
schemas
for
kept
I'd,
be
very
interested
to
hear
if
there's
ways
that
we
could
leverage
what
that
is
doing
and
if
that's
gonna
end
up
being
more
in
tree,
so
that
we
could
make
our
syncing
a
little
bit
more
a
little
bit
more
dynamic.
A
I'm
not
sure
if
you're
familiar
with
this
but
like
kept,
has
like
these
really
cool,
annotated
fields
that
allow
you
to
correct
me
where
I'm
wrong
justin,
but
like
basically,
you
you
have
annotated
field,
so
we
could
say
anything
that
is
called
namespace.
We
can
annotate
that
field
and
then
you
could
pass
it
into
a
starlark
function
that
goes
and
mutates
all
of
those
fields,
and
so
you
could
in
essence
in
theory.
A
This
is
very
hand
wavy,
but
like
in
theory,
we
could
make
it
so
the
sinker
could
be
more
dynamic
and
use
something
like
like,
like
controller
runtime,
to
do
it,
but
then
pass
it
into
a
preprocessor
to
look
for
anything
like
automatically
prefix.
The
namespace,
because
it
had
an
annotated
field
on
it
now
justin,
you
told
me
if
I'm
completely
completely
wild
there
and
that
wouldn't
work.
No.
C
Like
add,
like
extensions
to
the
crd
schema
itself,
I
would
say
that,
like
the
code
approach
is
probably
better
for
built-in
types,
and
so,
but
this
approach
would
be
much
would
be
great
for
like
if
you
did
want
to
sync
crds
for
some
reason
in
between
the
two
clusters
and
you
weren't
able
to-
or
it
was
less
practical
to
put
that
into
code
right
then
like,
but
you
can
always.
I
think
you
can
extend
the
open
ape.
C
A
A
That
would
be
my
one
concern
because
there's
like
an
optional
field
or
something
like
that
in
open
api,
which
could
be
which
could
be
very
cool,
and
that
would
help
both
the
the
the
use
cases
that
way
was
bringing
up
about
syncing
crs
and
doing
that
because
we
don't-
I
mean
it
depends
how
how
complex
those
crs
the
mutations
on
those
crs
are.
If
there's
a
ton
of
nested
name
spaces
in
there,
it's
gonna
be
more
complex
to
write
that
but
yeah
cool
all
right.
D
Yeah,
maybe
next
time
or
way
you
can
you
present?
How
do
you
do
the
crdc?
You
have
some
crd
synchronization
internally.
Maybe
what
you
have
now,
because
I
already
know
the
rough
idea,
but
I
don't
know
the
details.
Maybe
it's
great.
You
have
a
presentation
and
I
ask
some
questions
about
how
to
do
that.
Wait.