►
From YouTube: Kubernetes SIG Multicluster 2020 Apr 21
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
A
A
A
A
A
B
D
I,
don't
have
a
huge
update,
because
last
week
has
been
far
more
chaotic
than
I
expected,
but
I
have
a
basic
reconciler
portion
protect
out
the
way
it
works
right
now
is
it
just
gets
a
whole
bundle
of
llamó
from
some
sources
meant
to
represent
the
entire
cluster
state,
and
then
it
does
current
operations
to
line
it
up
with
anything
that
has
an
annotation
there's
a
couple
changes
after
talking
with
Paul
and
David
that
I
think
I'd
make
to
that
model
such
as
making
the
remote
API
a
little
bit
more
advanced
to
track
individual
item
state
sorrell
than
trying
to
sync
them
and
garbage
collect
the
whole
cluster.
B
C
Her
the
option,
if
she
wanted
otherwise
I
think
trying
to
describe
some
of
the
edge
cases
that
you
hit
when
you're
doing
this
sure,
though,
like
I,
can
see
some
that
well
that
I've
hit
firsthand
right
where
I'm
creating
a
namespace
and
I'm
creating
resources
in
there
and
like
if
you're
unlucky,
you
can
race
against
like
cash
as
an
admission,
and
so
I
wasn't
sure
that
you'd
hit
some
of
those
challenges
yet
or
not.
I
haven't.
D
Yet,
but
mostly
I,
don't
leave
my
reconciling
fairly
simple
demos,
so
there
are
an
unfortunate
number
of
edge
cases.
The
first
thing
that
I've
observed
is
the
problem
of
intent,
which
is
similar
to
what
the
server-side
apply.
It's
essentially
that
there's
some
fields
that
get
set
by
admission
or
machinery,
or
something
that
it's
hard
to
tell
whether
or
not
users
lieutenant
of
like
them,
such
as,
like
the
IP
on
a
service
or
the
number
of
replicas
on
something
that
an
HPA
manages
initially
like
I.
C
Yeah,
that's
that's
a
really.
That's
definitely
like
it
does
feel
like
we're
hitting
cuz,
because
when
I
started
playing
with
it
I
hit,
the
problem
of
the
secret
already
exists,
but
it's
of
a
different
type,
and
so
you
can't
update
a
type.
That's
an
immutable
thing
so,
like
the
update,
doesn't
work
and
the
only
way
to
fix
it,
I
think
is
to
delete
the
secret
and
recreate
it
and
have
you
found
some
things
like
that
to
like
I,
don't
know
how
many
of
those
were
gonna
bomb,
yeah.
E
D
B
C
C
So
I'll
say
that
some
of
these
bumps
that
you're
hitting
I
knew
where
to
look
so
I
was
able
to
like
look
at
it
and
play
with
it
and
I
found
out
about
these
bumps
because
Jordan
I
hit
them
about
about
a
year
and
change
ago.
We
hit
similar
problems
and
we
weren't
able
to
find
a
way
to
solve
them
generically
what.
C
B
C
F
C
D
C
D
Sure
there's
one
thing,
though:
I
haven't
had
time
to
implement
it,
but
Paul
suggested
specifically
moving
to
something
slightly
more
sophisticated,
where
there's
at
least
like
here's,
your
bundle,
the
animal
and
then
here's
the
history
of
everything
you
need
to
confirm
your
garbage
collected.
So
it
does
make
an
API
more
complicated,
because
then
you
have
to
specify
your
garbage
collected
something,
but
right
now,
the
way
it
does
GC
is
it.
Basically,
dynamically
pulls
in
every
single
resource
in
the
entire
cluster
tries
to
figure
out
what
to
delete,
which
is
not
great
plus.
D
C
D
C
So
we
we
encounter
similar
intent
kind
of
of
problems
in
in
narrower
cases
where,
like
we're,
trying
to
create
specific
resources
and
what
we
do
is
we
create
a
resource
that
says
like
this
is
the
set
of
things
I
created
for
revision,
6
and
I'm.
First
gonna
create
a
config
map
that
I
call
anchor
and
then
everything
else
is
created
with
an
owner
ref
pointing
back
the
anchor,
and
it
does
two
things
right.
C
It
gives
you
a
simple
spot
for
cleanup
because
you
can
just
delete
the
one
thing
that
obviously
this
is
a
narrower
than
your
case.
It
only
works
in
a
single
namespace,
but
you
can
delete
the
single
resource
and
everything
else,
sort
of
chains
off
of
it
and
get
slated,
and
it
gives
you
the
ability
to
diff
between
like
revision,
5
and
revision
sex,
because
you
can
say
what
did
I
have
before,
and
this
is
what
I
have
now.
It's
not
necessary
for
a
prototype,
but
it
is
the
sort
of
thing
I.
B
I
could
see
a
an
approach
like
that
being
a
workable
next
step.
My
own
gut
feeling,
when
we
were
talking
about
this
Valerie,
was
that
that
information
might
eventually
be
something
we'd
want
to
like
store
in
an
API
like
in
the
status
of
the
resource
that
gave
us
in
its
spec
the
manifest
or
manifest
to
use
David.
Do
you
think
what
is
similar?
Well,
the
the
GC
part
wouldn't
work,
but
for
cluster
scope,
resources
I.
Imagine
we
could
do.
We
could
use
a
config
map
to
hold
state
instead
of
relying
on
GC
I.
C
Think
I
think
you
want
gc4
for
some
aspects
of
it
and
then
some
it
becomes
like
they're
having
a
single
place
to
look
first,
rather
than
like,
as
Valerie
said,
she
scans
the
whole
cluster,
which
is
what
GC
does
today
to
be
able
to
like
back,
trace
the
links,
but
it's
expensive
to
do.
I,
wouldn't
rule
I,
wouldn't
rule
out
anything
that
tried
to
invert
that
mapping
without
trying
it
first
right
a
separate
resource.
You
know
that
kind
of
makes
sense.
B
D
The
GC
should
probably
come
first,
but
I
wanted
to
try
to
throw
some
spaghetti
at
the
wall
over
how
to
handle
the
intent
problem.
I
had
a
few
ideas
like
maybe
making
the
user
maka
fields
that
should
be
ignored,
cost
aside
or
trying
to
track
more
Delta
information
to
see
if,
like
a
missing
field,
is
meaningful
or
not,
but
that's
something
that
concerns
me
quite
quickly
for
usability
as
if
like
services
and
deployments
and
so
on
start
getting
whacked
in
the
reconciliation
process.
So.
C
C
D
C
So
so
we
encountered
two
different
sets
of
of
intent
when,
when
we
were
developing
it
right,
remember
so,
I
said
Jordan
and
I
came
to
the
conclusion
that
we
were
gonna
have
to
bake
in
knowledge
of
certain
resources,
because
they
behave
in
odd
ways
and
deployments
came
up
with
one.
We
were
gonna
commonly
use
and
we
came
up
with
two
cases
in
which
you
need
to
actually
stop
in
what
a
user
wants
and
those
cases
are
either
the
user's
intent
has
changed,
and
this
is
the
easy
one
right.
C
C
An
HPA
would
scale
at
some
time
later,
but
he's
changed
his
argument
to
add
logging
or
he's
done
something
first
image
and
to
determine
that
you
can
actually
hash
what
the
user
gives
you,
because
he
should
be
giving
you
stable
input
right.
We
require
that
for
for
other
API
interactions,
so
you
get
a
stable
input,
you
hash
it
and
then
you
can
put
that
into
an
annotation.
C
C
This
is
the
case
where,
like
you,
want
your
source
of
truths
to
be
this
external
thing,
setting
yamo
but
a
naughty
cluster
admin
or
someone
who
just
wasn't
thinking
came
in
and
tried
to
change
the
image
and
you
need
to
make
sure
you
change
it
back
and
to
do
that
for
deployments
we
had
the
generation
field,
and
so
what
we
did
is
we
tracked
both
of
these
pieces
of
information
generation.
We
tracked
in
a
separate
object,
we're
thinking
about
whether
we
can
make
that
better
or
not.
C
D
Think
that
it's
an
important
scope
question,
which
is
how
what
we
want
the
scope
of
a
reconciliation
to
be
because,
as
you're
kind
of
getting
at
there's
a
lot
of
fields
where
they
might
not
be
part
of
the
users
intent,
do
we
assume
that
having
them
empty?
Is
the
users
intent
or
do
we
treat
that
as
fair
game
for
any
state?
D
C
We
had
assumed
is
that
it
didn't
change
the
generation
of
the
field,
so
so
so,
for
example,
you
come
in
and
you
specify
a
lot
of
six
fields
on
a
deployment
or
something
there
was
a
new
field
at
about
three
releases
ago
and
it
had
a
default
value
associated
with
it.
Now,
when
you
have
an
old
Hamel,
you
definitely
won't
have
that
default
value
in
it
right
you
just
there
won't
be
anything
for
that
field,
and
so
you're
inputting
your
output.
They
never
match
right,
you
put
in
something
you
create
it.
C
You
get
back,
it's
different,
something
and
that's
what
the
generation
gives
you.
It
says:
I
created
it
like
this
or
I,
updated
it
and
I
didn't
specify
any
of
these
fields.
When
I,
updated,
I
cleared
all
these
fields
and
if
they
get
set,
they
get
set
by
some
other
actor
that
doesn't
change
the
generation
is,
is
the
is
the
goal
they're
like
because
so
that
means
that,
like
when
you
go
when
you
create
or
you
update
via
admission,
they
all
set
the
the
default
values
and
they
all
get
a
value.
B
B
D
B
B
Well,
I'm
not
sure
that
I
I
don't
think
we
can
rule
out
field
immutability
for
CRTs
right.
You
could
have
a
admission
webhook
that
prevented
a
field
from
being
beautiful,
mutable
after
it's
said,
yeah.
C
B
G
B
G
Maybe
that
needs
to
be
something
that's
kind
of
tunable
like
because
sometimes
you
might
want
to
like
to
force
reconcile
basically
to
to
set
back
to
an
own
clean
state,
because
something's
gone
wrong
right,
but
other
times
you
you
want
to
make
sure
that
anything
that
some
other
actor
in
the
cluster
hasn't
they
like
you,
you,
you
may
not
always
want
to
reset
a
given
state.
D
Yeah
I
was
hoping
that
whatever
would
emerge
would
make
it
easy
enough
that,
like
General,
Custer
administration
could
happen
on
the
source
of
truth,
and
we
just
have
the
specific
weird
cases
like
replicas
scale
left
over.
But
that
kind
of
thing
is
why
I
kept
circling
back
mentally
to
the
idea
of
like
the
intent
explicitly
saying
this
field
can
be
whatever
because
I'm
having
trouble
coming
up
with
a
generic
solution
that
doesn't
have
many
negative
side-effects
around
trying
to
guess
the
users
intent.
D
G
E
B
Yeah
I
think
I
think
I
was
I
was
thinking
of
a
similar
point
that
josh
has
made
like
say
that
say
that
we
had
really
good
heuristics
around
of
the
type
universe,
that's
known
to
us,
which
require
what
kind
of
special
handling,
if
I,
add
a
new
type
to
that
universe
via
CRT
and
like
have
my
own.
You
know,
validation,
webhook,
that
introduces
a
set
once
constraint
or
immutability
or
whatever
to
a
particular
field.
B
Probably
I'm
going
to
have
to
have
some
mechanism
to
make
to
to
express
that
I'm,
not
sure
if
I
think
that
should
be
in
the
resource
itself,
like
I'm,
not
sure
if
an
annotation
would
be
the
right
way
to
express
it
like
in
general,
I.
Think
one
thing
to
optimize
for
in
a
future
API
is
like
lowest
possible
additional
work
that
you
have
to
do
to
distribute
a
manifest.
C
There
is
that
I
think
I
could
also
see
a
case
to
be
made.
That's
as
if
this
resource
is
the
source
of
truth,
the
source
of
my
Amal
manifests
that
I
want
to
apply.
If
that
is
the
source
of
truth,
how
much
mileage
can
we
get
by
saying
it's
the
source
of
truth?
That's
what
it
is
if
you
want,
if
a
cluster
admin
wants
to
make
a
change
in
one
cluster,
well,
I
think
what
we
described
is
that
we
have
a
bag
of
the
analyst
a
manifest
reply.
C
The
cluster
admin
changes
it
there
and
it
gets
applied,
and
if
it's
slightly
different
per
cluster,
then
that
seems
like
the
sort
of
thing
where
you
would
build
a
layer
on
top.
You
build
it
on
top
of
this
building
piece,
this
building
block
that
says
I
have
these
things.
This
is
exactly
the
one
in
this
cluster
and
then
something
else
that
would
manage
things
like
template.
Izing
per
cluster
might
give
you
more
use
the.
D
Api
is
deliberately
meant
to
be
as
minimal
as
possible
for
the
inventory
right
now,
because
people
can
build
whatever
longer-term
like
for
what
I've
white
bordered
around
what
it
would
look
like.
Localization
is
definitely
a
part
of
it.
Ideally,
it's
just
the
automation
that
is
this
special
case
rather
than
generic
administrivia
right.
B
So
the
play
what
you
just
articulated
now
forward
an
example
David
with
the
deployment
say:
I
have
a
deployment.
That's
gonna
be
scaled
by
HPA
in
in
the
the
manifests
that
I
deploy.
I
can
leave
replicas
out
of
that
and
just
write
the
information
on
the
HPA
and
rely
on
HP
a
completely
governing
that
field.
That's.
C
D
G
Like
that,
that
seems
like
it
like,
it
seems
like
a
good
way
to
start
just
like
leave
it
out
and
and
and
see
if
that
works,
and
then
maybe
you
only
need
to
go
a
little
bit
further
and
you
know
Paul
your
example
of
like
an
annotation
with
the
JSON
path.
Maybe
it's
just
specifying
a
subset
of
fields
that
are
that
are
right.
Only
on
create
so
they're
ignore
them
update.
You
know
so
a
way
that
you
could
set
some
kind
of
default
and
see
if
that,
if
that
helps
close
any
gaps,
yeah
I.
B
Guess
another
approach
could
be
if
you
have,
if
you
have
like
heuristics
to
find
for
certain
fields,
you
could
you
could
write
a
warning
into
the
status
of
like
whatever
API
holds
the
spec.
That
has
the
manifests
in
them.
You
could
write
in
to
the
status
that,
like
hey
this
JSON
path,
expression
like
resolves
to
a
field
that,
like
is
known
to
be
problematic
problematic
when
you
set
it
in
this
way.
So
you
may
want
to
consider
whether
the
the
in
that's
the
actual
intent
that
you
have,
or
maybe
you
didn't
mean
to
set
it.
A
The
notion,
though
you
said
it
only
outright,
would
you
ignore
updates
as
soon
as
you
start
to
think
about
replica
counts?
You
may
also
really
want
to
think
about
ranges
as
well,
so
I'm
going
to
set
it
once
to
a
default
value
of
3
HBA
may
move
it
up
or
down.
Hpa
may
have
its
own
notion
of
policy
it.
Basically
it
I
guess
also
governs
you
could
do
min
and
Max
in
there,
but
I
kind
of
wonder.
Do
you
actually
end
up
adding
conditions
that
only
write
this
field?
C
B
B
D
A
So
what
happens
when
a
manifest
example
ultimately
ends
up?
Creating
other
kind
would
new.
You
simply
track
that
through
owner
references
to
those
kinds,
so
if
I
have
any
manifest
a
description
of
the
PBC,
the
PV
gets
created
on
their
milk,
luster
or
I
have
a
TRD
that
ultimately
creates
other
resources.
I
think
are.
D
A
A
D
D
D
D
More
than
two
weeks
might
be
beneficial
because
stuff
is
kind
of
crazy
right
now.
Smile
ability
of
various
next
up
I
think
is
changing
the
garbage
collection
story
documenting
some
of
the
like
nastier
edge
cases
of
this
hits
right
now
and
coming
up
with
ideas,
if
not
implementations
around
what
the
concrete
behavior
should
be.
B
A
B
G
Yeah
I
think
that
sounds
great
I'm
kind
of
incorporating
some
of
the
comments
on
on
the
cat
PR
to
kind
of
flesh
out
a
little
bit
more
so
that
probably
we
worth
doing
I
don't
know
that
it
needs
to
necessarily
be
as
long
as
last
time.
But
there
are
definitely
still
some
open
questions
and
that's
that
that
sounds
worth
it
and
then
I
guess:
what's
the
process
for
getting
they
kept
merged
and
I'm
getting
one
started,
at
least
as
a
draft.
B
C
I
think
there
needs
to
be
time
to
review.
There's
been
plenty
of
time
for
this.
I
would
say
that
as
long
as
it's
provisional
and
no
one
has
objected
given
enough
time
to
review,
if
someone
who
is
an
owner
in
there
like
is
that
you
or
Tim
it,
it's
been
brought
up
multiple
times,
I,
don't
see
significant
barriers
to
it.
Unless
I
haven't
looked
at
it
in
in
detail,
so
I
don't
know
if
something's.
H
H
This
is
something
of
an
experiment,
still
yeah
I,
think,
and
so
the
question
is
like:
do
we
leave
it
in
provisional
and
go
off
and
try
to
implement
experimenter?
Do
we
move
it
to
implementable,
with
the
caveat
that
this
is
you
know
the
first
version
of
the
ideas
or
second
draft
or
whatever?
We
think
it
is
actually
I'm,
not
sure,
there's,
actually
a
ton
of
precedent
for
keps
describing
things
that
were
really
not
sure
about
yeah.
B
My
my
god
I
think
it's
fine
with
me
yeah,
my
gut
would
be
I've
liked
it
not
to
linger
as
a
PR
I
expect
that
we
will
probably
refine
the
content
of
the
kept.
Think.
Probably
that
means
let's
leave
it
as
provisional.
We
can
go.
Do
some
hacking
around
it
see
if
we
think,
like
the
the
concepts,
are
durable
in
that
hacking
or
if
we
discover
any
gotchas
and
then
assess
what
to
do
next.