►
From YouTube: Kubernetes SIG Multicluster 20180319
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
B
So
I
think
I
think
the
intentions
of
the
two
are
slightly
different.
The
document
is
intended
to
capture
what
we've
agreed
upon
as
a
reasonable
framework
for
building
an
implementation
and
an
API
specification
and
I
think
the
prototype.
Correct
me.
If
I'm
wrong
Maru
is
mainly
to
investigate
options
available
and
what
implementation
challenges
might
arise
while
implementing
so
I,
don't
think
we
need
to
necessarily
consider
the
two
to
be
the
same
thing:
I,
don't
think
the
prototype
is
intended
to
be
a
spec
and
I.
B
C
Mostly
I
think
that,
where
I
would
probably
differ
is
that
when
it
comes
to
making
a
decision
about
how
we
want
to
detect
things,
if
that
hasn't
been
proven
out
in
prototyping,
and
it's
just
an
exercise
and
like
I'd
like
it
to
be
this
way,
then
to
me
that
has
less
value
than
the
prototype
this
and
it
works,
and
therefore
I
know
the
pros
and
cons.
Yeah.
B
I,
just
think
that
it's
useful
to
agree
on
a
proposed
way
forward
and
and
I
have
no
doubt
that
we
will
come
across
numerous
implementation
challenges
and
we
will
have
to
go
back
and
iterate
and
say
well.
We
wanted
this,
but
we
can't
implement
it.
So
we're
going
to
change
that
and
I
think
that's
totally
fine
I,
don't
think
we
can.
C
B
I
saw
your
question
and
I
tried
to
answer
it
and
I
gave
it
some
more
thought
so
so
I
mean
one
concrete
example
where
I
can
see
that
that
actually
placing
the
final
per
cluster
kubernetes
resources
in
some
persistent
storage
would
be
useful
is
in
the
case
of
Poole
propagators.
So
you
can
imagine
if
you
have
a
propagator
running
in
each
cluster,
which
has
been
proposed
as
one
potential
solution.
B
That
propagator
needs
to
know
what
to
pull
into
the
cluster,
and
it
would
be
useful
to
be
able
to
decouple
the
scheduling
so
deciding
which
which
resources
need
to
go
into
which
clusters
and
what
per
cluster
specializations
occur
could
be
implemented
in
one
place
and
then
the
actual
propagation.
If
the
clusters
could
be
implemented
by
a
full
propagator
and
it
would
be
convenient
for
that
pool
propagated
to
be
able
to
read
what
it's
supposed
to
propagate
into
its
cluster
from
some
well-defined
place
so
that.
C
That's
definitely
a
use
case,
but
I
I'm,
sorry,
I
didn't
catch
where
the
whole
propagator
innocent
sense
would
be
reading
from.
Are
you
suggesting
an
api
or
when
you
said,
persistent
storage?
Yes,
the
api
we
give
repo
I
guess
the
assumption
I've
been
running
under
is
that
a
pol
propagator
wouldn't
necessarily
be
reading
from
the
API.
C
So
if
you
look
at
it
more,
it
may
well
be
reading
from
a
gift
Depot
or
some
other,
like
persistent
storage
that
doesn't
like
that,
doesn't
require
you
to
have
an
API
and
have
it
like
it's
easier
to
replicate
storage
that
replicate
an
API.
So
if
the
simplest
possible
thing
like
the
representation
that
a
propagator
needs,
a
pool,
propagator
needs
to
read
like
if
you're
trying
to
make
it
really
simple.
I,
just
don't
know
that
I
think
that's
fine,
but
yeah.
C
B
Think
I
think
it's
listed
in
the
document,
which
is
that
that
intermediate
representation
is
optional.
If
you
want
to
implement
a
consolidated
piece
of
software,
I'll
call
it
in
practice.
We
usually
call
these
things
controllers
that
does
not
emit
any
of
the
intermediate
stages
and
has
them
all
in
memory
like
a
prototype.
That
is
fine.
It
just
means
that
you
know
no
other
propagator
will
be
able
to.
You
won't
be
able
to
decouple
the
propagation
piece
out
of
that
or
the
stamping
substitutional
scheduling,
depending
on
how
you've,
aggregated
these
things
together
and
and
I.
C
Think
that's
the
case.
I
mean
if
you
look
at
the
diagram
for
pen
or
there's
kind
of
two
mechanisms
potentially
for
propagation,
and
you
know
you
generate
a
resource,
representation
and
combination
with
placement
resources.
You
can
drive
push
reconciler
that
you
can
just
as
easily
drive
the
animal
generation
to
get
repo,
so
I
guess
I'll
say
that
I'm
not
saying
that
if
you
want
and
Huawei
or
whoever
other
interested
parties
once
the
tackle
generating
kubernetes
resources
like
canonical
kubernetes
resources
into
the
API,
you
can
do
that.
C
B
C
A
B
Yes,
I,
agree
and
I.
Think
that's
where
this
document
is
intended
that
that's
the
place.
This
document
is
intended
to
go
and,
and
obviously
the
document
is
not
sufficient
there
we
need
actual
code
and
api's
and
and
I
added
explicit
waiting
to
the
document
to
say
that
one
of
the
outputs
of
this
will
be.
You
know,
API
specifications
and
reference
implementations
for
the
procedures
mentioned.
Not
everyone
has
to
use
the
reference
implementations
and
there
may
be
multiple
reference
implementations
illustrating
different
approaches
to,
for
example,
what
we
call
procedures
or
controllers.
A
B
A
A
B
If
you,
if
you
implement
a
combined
substitute,
ER
and
propagator,
which
I
think
is
what
marui
has
implemented,
for
example-
and
you
don't
want
to
enable
alternative
propagators,
for
example-
then
yes,
you
just
don't
output
the
substitution,
or
maybe
you
output
them
somewhere
else
like
to
github
and
I.
Think
that
within
the
spec
here.
D
I
think
the
part
of
the
confusion
that
I
have
perceived
around
this
field
is
that,
like
the
so
we
have
it,
we
have
a
tough
problem
in
terms
of
communicating
around
like
what
the
ideas
are
here
because
we
are
like.
We
are
both
like
fundamentally
we're
trying
to
find
the
right
building
blocks
that
give
you
the
tools
to
make
the
to
make
the
specific
constructions
that
you
want,
and
it's
hard
to
talk
about
what
those
building
blocks
do
with
that
saying.
D
D
The
clarity
of
this
document
by
just
drawing
lines
around
like
here
are
like
delineating
what
we
think
the
common
building
blocks
are
and
then
what
what
things
on
the
diagram
are
there
to
illustrate
examples
and
I
feel
like
we've
been
talking
now
about
something
that
is
like
that,
arguably,
might
be
an
implementation
detail
of
how
a
particular
flavor
of
propagation
is
implemented
and
I.
Think
if
that
was
more
clear,
we
we
would
probably
like
the
whole
thing,
might
be
clearer
to
folks,
but
I'm,
not
sure
if
that
makes
sense,
so
I'm
gonna
stop
talking.
B
E
E
D
D
Right
which
we
expect
there
to
be
like
at
least
two
fundamental
different
flavors
of
like
push
and
pull,
and
then
there's
also
like
higher
higher
level
stuff
like
different
flavors
of
status,
a
scheduler
thing,
right,
etc,
and
it's
it's.
What
we're
describing
and
what
we're
we're
talking
about
in
dealing
with
in
this
document
is
the
big
picture
and
I
guess
what
I'm
just
saying
it's
like
to
really
illustrate
the
big
picture.
D
D
So,
like
I,
what
I'm
suggesting
is
that,
like
we
can
probably
just
add
a
paragraph
or
two
to
the
document
that
like
explains
this,
so
that
people
understand
in
the
light
when
they're
looking
at
a
particular
piece
of
it
like?
Are
they
looking
at
something
that
we
think
is
a
building
blog
building
block
with
broad
appeal
versus
something?
That's
like
an
example
to
illustrate
a
concept.
That's
all
yeah.
B
B
I
also
don't
want
this
document
to
get
a
bit
late
to
get
to
and
wieldy
I
think
there
are,
you
know,
potentially
an
infinite
number
of
alternative
implementations
that
we
could
describe
and
I
don't
think.
They're
necessarily
all
belong
in
this
document
and
I
was
actually
going
to
make
a
comment
along
those
lines.
I
just
noticed
before
the
meeting.
Sorry
Google's
notification
mechanism
on
Docs
is
not
ideal.
B
In
the
sense,
I
only
just
saw
that
maru
added
a
whole
few
more
sections
at
the
bottom
of
the
document,
and
they
come
across
and
I
be
interested
to
hear
what
other
people's
opinions
are,
but
they
sort
of
it
comes
across
as
quite
disjoint
from
the
first
half
of
the
document,
so
the
terminology
used
is
different
and
it's
not
clear
how
that
part
fits
with
the
other
part.
So
I
was
going
to
suggest
that
we
moved
that
into
a
separate
document
and
have
a
very
clear
delineation
between
the
two
documents.
C
D
C
B
Think
I
understand
what
Murray
was
trying
to
say
and
I'll
talk
in
the
meantime,
while
he's
sorting
out
his
audio,
yes,
I
think
it
is
very
useful
to
have
documentation
of
the
floor
prototype
I
guess
all
I
was
the
point
I
was
trying
to
make.
Is
that
perhaps
having
it
in
this
document
is?
Is
not
the
best
place
to
have
it?
Maybe
a
separate
document
describing
if
northern
part
works
with
a
reference
link
from
this
document.
B
C
Though
I
mean
you
asked
me
last
week
to
update
the
document
with
details
of
the
Noren
I
mean
I,
expressed
early
on
when
you
created
this
document
that,
while
the
advanced
example
made
sense,
the
simple
example
didn't
really
match
up
with
what
I
was
proud
of.
Ivan
and
I
were
prototyping
was
Finn,
Ord
and
I
guess.
My
perception
is
that
code
beats
up
like
documentation
in
terms
of
like
this
is
something
I've
implemented.
It
actually
works
and
I'd
like
to
see
convergence
rather
than
like
trying
to
derive
code
out
of
ideas.
We
already
have
code.
C
D
A
Think
it's
not
conceptual
mismatches.
The
mismatches
that
I
observed
right
now
is
abstraction
levels
so,
for
example,
placement
decisions.
So
there
is
a
mismatch
in
the
sense
that
the
Quinton's
talking
money
suggests
spec
at
a
higher
level
of
abstraction.
And
what
problem
are
you
has
implemented?
Is
the
lower
most
level
of
abstraction.
A
A
C
It's
reproducible
like
I,
will
get
the
same
result
when
I
compute
the
replica
set
forgiven
cluster,
regardless
of
the
state
of
things
and
that's
kind
of
intentional.
It's
it's
leaving
the
variability
to
a
higher
level
and
for
some
reason
that
isn't
working
you
can
still
derive
the
exact
like
it's
deterministic.
C
A
B
That
particular
aspect,
I,
don't
think,
is
a
first
offer
I
think
we
can
reconcile
those
fairly
easily
and
I
must
be
honest
at
any
saumur
who's
part
of
the
document
a
few
minutes
ago,
so
I
haven't
really
looked
at
it
closely,
but
but
it
did
seem
that
it
was
a
little
like
used
different
terminology
at
the
very
least
which
made
it
difficult
to
understand
how
it
relates
to
the
rest
of
the
document.
But
but
let
me
reread
it
before
I
comment
further.
B
To
either
update
the
section
of
the
document
that
describes
the
simple
case
such
that
it
is
consistent
with
Meru
thinking
or
separate
and
or
separate
this
latter
half
of
the
document
into
a
separate
one.
I
understood
that
to
be
a
prototype
to
investigate
possible
challenges,
possible
implementation
approaches,
as
opposed
to
being
a
an
attempt
to
develop
a
specification
of
what
you
want.
So
my.
D
My
own
bias
would
be
towards
by
I.
I
have
been
looking
at
Nord
as
like
the
space
where
we
will,
where
we're
proving
out
and
finding
like
gacho's,
that
you're
only
going
to
find
what
you
sit
down
and
start
implementing
these
ideas.
I
think
that
we
should
feedback
experiences
from
'the
word
into
the
document
and
like
ensure
that
and
tried
to
make
sure
that
they
align
I
I
think
that
it's
might
be
worth
having
a
discussion.
Once
everybody
has
read
like
read
the
material
in
this
document
about.
Do
we
need
to
update
the
document?
D
Do
we
and
there's
there's
two
different
facets
of
like
potential
mismatches?
One
is
just
vocabulary
like
I,
called
it
frob
you
later
and
Darryl
called
it
fraud,
y
Electric's,
right
and
they're
the
same
concept
and
then
there's
a
more
like
material
difference
which
is
by
does
does
a
mismatch
conceptually
in
an
implementation
detail
level
of
what's
in
nord
versus
the
rest
of
the
document.
Like
does
that
represent
that
we
have
like
learn
something
by
implementing
nord
that
we
should
feed
back
into
the
rest
of
the
document.
A
A
And
what
I
was
trying
to
add
is
that,
as
I
said
a
couple
of
minutes
ago,
I
don't
see
a
lot
of
conceptual
differences.
What
I
see
is
differences
in
terms
of
abstraction
and,
for
example,
the
document
that
Quinton
has
described
it.
It
sort
of
lays
down
a
spec
for,
for
example,
five
or
six
different
penetrate
resource
types,
whereas,
whereas
maru's
implementation
is
I
will
take
it
out
for
the
most
simplest
type
and
only
needed
or
necessary
resources.
A
So
that
is
where
I
was
saying
that
do
we
converge
at
aspect
where
we
say
that
we
still
define
the
spec
four
five
or
six
or
seven,
which
is
the
superset
of
all
types.
All
the
sources
and
implementation
can
choose
to
use
two
or
three
or
four
or
any
number,
but
we
still
will
have
to
convert
that
the
exact
spec
of
each
of
them.
D
Yeah
I
think
it
like.
It
will
probably
be
most
useful
if,
if
we
can
agree
on
the
most
primitive
building
blocks
and
I
and
put
those
into
an
API
group
that
is
shared
so
that
if,
if
one
set
of
parties
wants
to
like
take
those
building
blocks
and
build
solution,
X
with
them
like
an
opinionated
version
of
status,
opinionated
higher
level
constructs
around
scheduling,
opinionated
propagation
and
some
other
folks
have
a
different
opinion
that
they
want
to
go
and
implement
that
like
we,
we
need
to
reuse
in
more
than
one
concept
concept.
D
B
Yeah
I
mean
it's:
it's
I
added
to
the
document
and
I
think
you
did
as
well
it's
it's
very
clear
that
the
output
of
the
result
of
this
will
be
a
set
of
API
specifications
in
a
federation
b2.
Let's
call
it
repository
that
says
these
are
the
API
building
blocks
that
we
have
agreed
upon,
and
here
the
API
specs
and
what's
more,
we
have
some
reference
implementations
of
things
that
generate.
B
Placement
decisions,
for
example,
and
whatever
other
things
that
there
are
some
processes
described
in
the
document
and
I,
think
it
would
be
useful
to
have
reference
implementations
of
those
for
two
reasons,
one
being
that
they
will
prove
out
the
feasibility
of
what's
described
in
the
API
and
two.
They
will
provide
useful,
either
directly
usable
controllers
for
people
who
want
to
actually
run
those
things
or,
at
the
very
least,
reference
reference
implementations
which
they
can
then
adapt
and
and
change
in
any
ways
they
want
to
for
their
own
purposes.
B
B
From
what
I
can
see,
the
lessons
learned
are
usefully
documented
and
I
think
it
would
be
useful
for
people
to
go
through
those
and
comment,
and/or,
agree
or
disagree
with
whatever
the
there's
some
potential
solutions
outlined.
There
I
think
that's
useful.
We
can
debate
what
we
think
might
be
better
or
worse
solutions.
As
for
the
actual
workflow
that
is
described.
B
D
Yeah
so
I
wonder
if
we
might
take
a
pass,
probably
offline,
so
that
we
don't
consume
a
lot
of
folks
time
and
reconcile
the
specific
vocabulary
and
then,
let's,
let's
try
to
highlight
what
the
differences
are
like
concise
in
terms
of
implementation
room.
Maybe
you
and
I
can
do
this
and
and
let's,
let's
find
out
what
the
actual
like
implementation,
mismatches
ours
and
it
seems
like
that's-
probably
the
next
step
in
terms
of
like,
let's
identify
where
it's
just
vocabulary
and
we'll
bring
the
vocabulary
into
alignment
somehow
and
where
there's
a
real
Delta
and
implementation.
D
Let's
hash
that
out
and
and
and
maybe
we
can
push
this
effort
forward.
That
way,
and
and
probably
this
like
the
feedback
loop
of
we've
implemented
things,
let's
discuss
what
implementation
choices
we
made
and
what
those
bought
for
us.
This
is
a
feedback
loop
that
we'll
have
running
until
we
identify
what
those
like
primitives
are
and
what
the
formulations
of
them
are.
So
this
this
is
progress
in
the
sense
of
like
we
we're
going
to
run
the
first
reconciliation
loop,
I,
think.
D
D
B
I
had
one
or
two
other
items
for
discussion:
they
don't
really
need
too
much
discussion,
I
didn't
think,
but
I
thought
I
would
bring
them
up
briefly
anyway.
So
one
is
that
as
a
multi
cluster
Federation
multi
cluster
sig,
we
need
to
publish
and
updated
manifest
I
think
it
is
called
which
just
described,
there's
a
there's,
basically
a
template
that
Phil
has
reduced
from
steering
committee.
B
That
is
because,
in
order
to
make
use
of
the
new
sinks
organization
in
github
and
create
a
reaper
there,
which
I
think
we
need
to
do
in
order
to
start
publishing
these
things
we're
talking
about
here,
we
it
it's
a
prerequisite
that
we
have
our
sig
in
order
with,
with
this
manifest
so
I'll
bring
this
up
in
the
meeting.
I
think
it's
on
Wednesday
the
sig
multi
cluster
meeting.
B
What
repo
we're
talking
about
so
so
we
need
somewhere
to
publish
our
v2
API
the
things
we've
been
talking
about
here.
We
need
somewhere
to
put
the
canonical
versions
of
those
things,
and
we
also
need
a
place
to
put
the
reference
implementations
of
the
procedures
that
we've
been
speaking
about
as
well
as
this
document,
for
example,
that
we're
looking
at
should
go
into
github
and
we
could,
you
know,
make
changes
to
it
with
proper
revision,
tracking,
etc,
so
that
all
has
to
go
somewhere.
B
B
B
Most
of
the
hard
work
is
done:
we've
already
got
a
vision
and
goals
and
sig
leads
in
the
sig
page
and
all
of
that
stuff.
So
all
I'm
going
to
do
is
transfer
that
into
the
new
template
that
they
want
and
fill
in
proposals
for
the
missing
bits.
I
think
there's
like
you
know,
you
need
to
describe
what
the
working
groups
are
and
who
the
leads
of
the
working
groups
are,
and
things
like
that.
So
I'll
just
put
the
draft
together
and
we
can
fill
in
the
missing
bits
as
a
group
submit
that
finalized
it.
B
A
Hi,
it's
machine,
yo,
I,
think
there's
a
couple
of
minor
things
and
I
think
I,
don't
know
what
that
I
should
go
ahead.
If
everybody's
free
I
think
I
can
this
does
not?
So
one
thing
is
related
to
the
defaulting
thing
which
befall
on
NF
Nord,
prototype
right,
so
I
think
I
am
also
interested
in.
How
do
we
tackle
the
validation,
I
think
similar
problem?
Is
there
the
validation
to
like
user
input,
some
objects
which
is
not
valid,
and
the
physician
can
do
plain,
try
to
propagate
that
through
the
member
cluster
and
it
finds
out.
A
E
D
E
D
D
It's
moving
to
the
Service
Catalog
API
server,
and
we
we
hit
this
problem,
then
of
like
you
once
you
move
it
out
of
kubernetes
kubernetes,
there
aren't
validations
that
you
can
easily
consume
so
one
one
thing
that
has
been
suggested
to
solve
this
problem,
which
we
still
have
to
solve
in
the
case
of
this
pod.
Preset
thing
is
what
is:
is
to
use
open
API
to
do
the
validation
but
I'm,
not
sure
if
open
API
can
describe
all
the
validations
that
are
applied
to
the
kubernetes
api?
I.
C
Think,
as
a
general
problem,
we
just
need
to
ignore
it.
For
now,
when
we
run
into
particularly
egregious
problems,
we
can
devise
a
strategy,
but
the
real
challenge
is
that
when
we
talk
about
ven
during
in
code,
then
we
get
into
the
same
problem
area
that
Federation
v1
has
that
we're
ven
during
a
specific
version
of
kubernetes
our
vendor.
C
If
you
infer
just
isolate
it
to
the
validation
code,
we'd
have
to
identify,
you
know
which
version
of
which
cluster
and
we
have
to
have
the
validation
that
corresponds
to
that
and
there's
always
the
potential
for
skew.
So
I
would
say
we
just
push
it
down
and
we
figure
out.
It
becomes
a
hard
enough
problem,
we'll
figure
something
out
as
Paul
says,
maybe
using
open
API
to
describe
some
of
that
validation
on
the
cube
side,
so
it
can
be
published
by
the
API
server
we're
targeting,
but
in
terms
of
I
mean
providing
rapid.
C
You
know
indication
like
failing
fast
if
I
create
a
federated
like
a
logical
federated
resource,
and
then
it's
going
to
be
propagated
to
end
clusters.
There's
always
the
potential
of
one
of
the
clusters
not
validating
right
and
the
only
way
to
find
out
is
to
propagate
to
all
the
clusters
that
are
intended
to
be
propagated.
C
To
and
I
think
that
to
me,
just
speaks
of
I
mean
the
nature
of
Federation
is
that
it
is
it's
distributed
and
it's
eventually
consistent
and
we
probably
have
to
provide
like
documentation
or
education
or
whatever,
so
that
users
know
that
they
have
to
actually
monitor
things,
and
then
they
certain
see
certain
classes
of
errors.
They'll
have
to
take
craft
at
auction
or
risk
their
application,
not
working
yeah.
D
I
think
I
think
that's
a
in
point
in
the
Rio
and
I
also
think
that,
like
there,
there
isn't
a
way
that
we
can
ensure
like.
We
can't
write
an
insurance
policy
and
say
that,
like
even
if
we
had
some
like
really
amazing
solution
to
the
question
of
applying
of
validations,
there's
there's
no
way
that
we
could
guarantee
that,
for
example
like
we
would
ensure
that
when
we
opted
into
the
API
in
the
sense
of
when,
when
you
made
a
create,
did
it
perform
to
create
operation
against
these
API
groups.
D
A
D
F
D
I
think
it's
worth
sitting
down
and
thinking
about,
because
one
of
the
one
of
the
things
that
I
could
see
being
very
surprising
to
users
is,
if
you
making,
for
example,
like
a
federated
replica
set,
and
then
it
fails.
Validation
in
the
cluster
that
you
put
it
in
or
one
of
the
clusters
or
more
I
should
put
it
in,
because
users
will
have
a
strong
expectation,
probably
that
things
are
validated
at
the
time
that
they're
created
so
I.
D
Think,
there's
probably
like
a
there's
two
axes
of
this
right,
like
one
of
them,
is
that
we
should
find
something
that
is
at
least
a
pretty
good
solution
to
applying
validations,
if
possible,
so
principle
of
least
surprise
and
then
also
clearly
articulate
to
users
that
that
they
need
to
monitor
their
placement
status
or
whatever
the
eventual
correct
channel
for
information
about
propagation
errors
or
validation.
Errors
that
happen
when
you
actually
tried
to
put
something
into
a
cluster
like
there
needs
to
be
a
very
clear
channel
for
those,
and
people
need
to
pay
attention
to
it.
A
So
if
we
are
giving
additional
jobs
to
the
user,
okay,
we
just
accepted
your
object.
Then
you
also
have
to
look
at
the
other
stuff
for
the
status.
Maybe
we
may
end
up
with
a
complicated
state
within
our
system
right,
so
yeah
I
think
yeah
it's
little
complicated,
but
yeah
definitely
need
to
think
in
solution.
D
C
It
might
be
I
mean
I
would
like
to
think
about
it
as
inherent
complexity
versus
accidental
complexity.
Are
we
making
this
harder
in
ways
that
it
doesn't
have
to
be
hard
or
we?
You
know
we
just
were
stuck
with
the
fact
that
a
distributed
system
with
delays
and
when
things
happen,
that's
just
kind
of
the
nature
of
what
we're
dealing
with
you
can
paper
over
it
to
some
degree,
but
in
the
end,
if
the
user
doesn't
have
an
understanding
of
what's
going
on
that
had
a
even
a
basic
level,
they're
kind
of
in
trouble,
yeah.
B
B
Don't
know
what
the
right
word
is.
Fixing
these
things
up.
So,
given
that
things
do
go
wrong,
you
know
nodes,
go
down,
etc,
etc.
Do
you
want
the
system
to
fix
that
as
best
it
can
like?
We
do
with
you
know,
good
news
replicas
sets
if
I
say,
I
want
five
replicas
and
some
of
the
machines
fail
at
some
point
then
I.
You
know
the
system
creates
new
ones
for
us,
and
the
same
principle
might
apply
here
versus
the
user
did
something
dumb.
C
D
So
here's
something
that
would
make
this
simpler,
I'm,
not
sure
if
it's
like
the
absolute
best
thing
but
I
think
it
would
make
this
simpler
to
think
about.
So,
for
example,
if
there
was
a
repository
that
held
the
kubernetes
validations,
that
was
that
you
you
were
able
to
consume
without
consuming
the
entirety
of
kubernetes
kubernetes
like
you
can
consume
the
API
types
themselves
now
without
consuming
all
of
communities.
C
D
Yeah,
that's
a
good
question
and
here's
another
little
wrinkle
that
I
think
I'm,
just
riffing
off
of
what
you've
brought
up
Maru
is
like
a
say,
you
know
we,
we
have
this
contract
that
API
types
and
kubernetes
kubernetes
are
not
going
to
have
backward
incompatible
changes
made
to
them.
However,
I
think
in
practice
that's
about
95
percent.
D
True
what
happens
when
there's
like
you
know,
at
least
through
human
error,
for
example,
what
happens
when
a
backward
incompatible,
validation,
sneaks
in
and
you
upgrade
like,
for
example,
you
were
to
upgrade
like
the
common
federated
API
is
like,
and
now
you
have
objects
that
wouldn't
pass
validation.
How
are
we
gonna
handle
a.
D
Yeah
I
think
I
think
this
is
a
an
important
thing
to
get
right.
It's
probably
worth
the
sitting
down
and
thinking
about,
like
all
the
different
scenarios
where
validation
mismatches
could
arise
and
for
each
of
those
scenarios
like
thinking
through.
How
would
we
handle
this
one
and
probably
for
each
of
them?
There's
a
combination
of
you
know:
user
education
and
then
potentially
software
solutions
to
them.
I.
C
Think
I'm
I
don't
know
that
there
is
a
tremendous
amount
of
value
and
putting
a
lot
of
upfront
work
into
this,
because
I
don't
know
that
we
can
necessarily
anticipate.
What's
really
gonna
hurt
users
like
what's
what
are
gonna
be
like
Oh
website
forgot,
something
or
oh
no.
This
is
like
really
a
problem
for
me
and
so
in
terms
of
prioritizing
effort.
A
D
C
C
C
A
Actually,
there
are
a
couple
of
other
unsolved.
The
similar
problems
which
are
sort
of
carried
over
from
women
also
I
think
we
need
to
set
aside
some
time
to
maybe
at
least
talk
about
them
and,
for
example,
like
we
chose
for
this
that
yeah
we
have.
We
need
to
keep
this
in
mind,
but
maybe
talk
you
in
future.
So
do.