►
From YouTube: SIG Architecture meeting 20180301
Description
A
Hello,
everybody
welcome.
It
is
Thursday
March,
1st
2018.
This
is
the
kinetic
architecture
full
meeting
today,
I'm
your
host
Jay
singer,
Dumars
from
Microsoft
and
co-hosted
with
grant
grant
from
Google.
We
are
going
to
be
following
along
an
agenda
that
is
available
after
the
fact,
if
it
not
Lee
/
sig
architecture.
So
if
you
want
to
see
what
we
discussed
and
so
forth,
it's
all
in
there-
and
today
we
have
a
loan
agenda
item
presented
by
getting
psmith
at
Google.
Do
you
want
to
go
ahead
and
take
it
just
just
wanted
tonight?
B
I
said
this
is
a
big
topic:
it's
pretty
big
but
super
important
change
to
the
API,
something
we've
been
discussing
since
almost
the
beginning
of
the
project.
If
you
want
to
dig
down
through
or
across
the
github
history
start
at
1178
and
go
from
there,
it's
gonna
be
I.
Think
it's
one
of
the
unique
features
of
kubernetes
yeah,
the
good
old
1178
sega,
lead,
I
assume
is
Clayton.
B
The
anyway
I
mean
it's
everything:
doing
declarative
management
from
cute
control,
to
helm,
to
TU
eyes
to
cluster
add-ons
to
you
even
eventually
I
hope
controllers,
like
Mehta
controller,
that
want
to
assert
properties
and
resources
without
controlling
or
clobbering.
The
rest
of
them
really
need
this
pattern.
Super
well
supported,
so
so
this
is
really
critical.
We
are
trying
to
get
it
to
move
forward
as
quickly
as
possible.
I
also
just
want
to
put
a
plug.
I
wrote
an
overview
of
communities.
B
C
C
I
got
a
slide
deck
I
have
to
design
Docs,
which
I
believe
have
been
circulated
in
cig,
apps,
COI
and
API
machinery
and
I
know
at
least
one
of
those
design,
Docs
I
sent
to
the
city
architecture
list.
I
have
another
document
I'm
working
on
so
there's
like
50
pages
of
supporting
material
behind
these
slides.
A
C
A
C
C
Can
everyone
see
that
yeah
yeah?
Can
you
still
see
it?
Okay?
This
way,
you
don't
have
to
look
at
all
the
comments
people
leaving
on
the
slides.
So
this
is
I
called
this
advanced
configuration
management.
This
is
about
cute
control,
apply
or
fixing
cute
control
apply,
should
I
go
through
the
background
carefully.
Do
people
on
this
call
have
sufficient
background
here?
Do
you
think
yeah.
C
Okay,
so
you
know
what
it
does
I'll
briefly
say:
why
I
think
it's
good
I
have
three
reasons
here:
it
helps
users
build
familiarity
with
the
actual
API
resources,
which
means
you
know.
If
you
have
a
system
of
tools
that
work
together
on
API
objects
in
the
same
format,
then
it's
easier
for
users,
users
to
understand.
C
If
those
tools
are
doing
the
correct
thing,
you
can
introspect
any
any
step
in
the
and
the
pipeline
and
see
what's
going
on
you
if
you
switch
to
an
API
client,
you
know
what
resources
you're
going
to
be
building,
so
it
helps
users
understand
how
the
system
works
and,
in
contrast,
some
of
other
systems,
users
learn
a
special
config
language,
which
then
generates
the
API
calls
tonight.
I
think
that
that
means
users
have
to
learn
to
confusing
things.
C
From
the
perspective
of
system
integrators,
you
end
up
integrating
with
one
API,
you
make
one
API
call
with
varying
data
and
and
destination
instead
of
having
to
make
learn
how
to
make
a
API
call
for
every
operation
for
every
object,
so
significantly
less
effort,
those
terms
and
finally,
if
you've
read
Bryan's
declare
to
that
management
document.
As
he
mentioned,
this
is
a
central
building
block.
It
doesn't
really
work
without
this
concept.
C
C
Some
things
can
be
phrased
both
as
imperative
and
declarative
commands.
So
if
you,
if
you
send
an
RPC,
that's
like
open
the
pod
bay
doors
like
like
that's
imperative,
but
you
could
also
have
a
like
pod
bay
door
position
equals
either
closed
or
open,
so
you
could
do
it
either
way
right
for
some
things,
but
for
a
period
of
things
this
is
definitely
not
your
pattern,
which
he
knows.
Some
like
kubernetes
infrastructure
management
is
very
well
suited
for
declarative
management.
So
that's
why
you
have
the
system.
C
Why
is
this
hard,
which
is
hard,
because
we
have
to
figure
out
what
the
user
wants
to
do
and
that's
always
hard,
so
in
order
to
make
it
possible
or
easier
to
figure
out
what
the
user
is
trying
to
do?
We
may
need
to
restrict
the
API
service
area
to
certain
patterns
and
the
the
goal
of
this
whole
concept
is
to
allow
users
and
systems
to
cooperatively
determine
the
desired
state
of
an
object.
C
Users
make
some
changes,
systems
make
other
changes
and
together
you
get
the
the
state
that
you
want,
and
the
goal
for
this
particular
design
is
that
we
want
the
control
plane
to
deliver
this
solution
today.
This
is
implemented
in
strictly
client-side.
I
have
some
non
goals
like
any
good
design,
Q
control
apply
today.
Does
both
multi
and
single
object
apply
I'm,
focusing
only
on
the
single
object
case,
then
multiple
object
case
has
additional
complications
so
for
for
now
intend
to
let
that
remain
a
client-side
loop.
C
I'm
not
currently
it's
a
little
bit
in
flux
actually,
but
at
the
moment
I'm
not
planning
on
providing
an
API
that
does
solely
a
a
merge
of
API
objects.
I
think
it's
necessary
in
the
future,
but
there's
enough
work
to
do
and
that
that
is
pretty
clear
how
to
how
to
build
that
after
we
after
we,
the
rest
of
this
so
I'm,
leaving
that
for
the
future,
some
sources
of
user
confusion
are
not
fixable
by
moving
things
to
the
control
plane.
C
It's
unfortunate,
but
our
data
model
is
that
the
name
and
namespace
inside
a
manifest
identify
the
thing
that
you
want
to
change.
So
if
the
user
changes
those
and
expects
the
object
in
the
cluster
to
get
me
named,
they
will
be
surprised.
I
can't
really
fix
that
in
the
control
plane,
so
we
have
to
figure
out
documentation
to
figure
out
other
things.
There's
also
some
landmines
in
some
of
our
API
objects
with
fields
that
you
can
technically
change
them,
but
may
not
do
what
you
expect.
So
that
is
also.
C
C
The
first
one
is
about
what
I've
called
user
intent,
lifecycle,
management
and-
and
these
are
some
example-
problems
that
that
I
that
I
want
to
cover
in
this
section,
I,
don't
know
how
much
you've
played
with
queue
control
apply.
There's
an
excellent
talk
from
a
core
OS
engineers,
I
want
to
say
Aaron,
but
I
don't
want
to
get
the
name
wrong
from
cube
Con
in
Austin
Texas,
because
the
dark
art
of
queue
control
apply.
That
goes
through
some
of
the
ways.
C
Users
are
surprised
by
keep
control
apply,
there's
a
lot
of
ways
to
be
surprised,
and
these
are
all
ways
that
aren't
technically
malfunctions
of
cube
control
apply.
These
are
the
users
is
following
the
wrong
workflow
and
we
don't
really
detect
that
and
help
them
not
follow
the
wrong
workflow.
So
I
won't
read
the
slide.
C
Why?
Why
is
it
hard
to
get
this
right?
We've
been
working
on
it
for
I,
say
two
years
on
the
slide,
but
I
think
it's.
Basically,
since
the
beginning
of
the
project,
a
bunch
of
smart
people
have
been
working
on
it
and
it's
still
broken.
I
have
two
primary
reasons.
The
first
one
is
like
very
practical,
which
is
just
too
much
stuff
has
to
change.
C
In
order
to
get
the
thing
fixed,
you
have
to
change
a
maybe
you
need
to
make
change
the
schema,
which
involves
changing
the
types
deco
file
and,
like
our
schema,
building
tool
chain.
Maybe
you
need
to
change
the
strategic,
merge,
patch
format.
You
could
change
goop
control.
You
need
to
change,
maybe
some
other
server-side
machinery.
It's
like
at
least
four
components
that
you
have
to
mess
with,
to
fix
anything
about,
keep
control,
apply
and
then,
after
you've
figured
all
that
out.
C
C
Okay,
so
now
I
have
this.
This
is
this
is
the
slide
that
we
get
stuck
on
in
all
my
sig
meetings.
It's
the
slide,
listing
all
the
components
of
proposal,
so
I'm
gonna
try
to
tuck
each
one
without
talking
about
details,
I
have
slides
to
talk
about
details
following
this
one,
so
just
very
briefly
listing
all
the
other
things
that
we
want
to
do.
Clearly,
the
apply
logic
is
going
to
move
to
the
control
plane
with
a
new
API
verb
will
have
to
add
a
dry
run
mode.
C
C
The
last
apply
and
annotation
the
last
applied
state
used
to
be
stored
in
an
annotation
I.
Want
to
make
that
a
top-level
field
under
metadata,
sorry
I,
should
say
a
first-class
field
under
metadata:
we're
gonna
default
to
giving
users
errors
if
they
try
to
conflict.
If
they
try
to
overwrite
a
field
that
some
other
system
is
managing
when
they
use
apply
today,
it
will
just
clobber
your
object
and
maybe
you'll
get
a
warning.
Maybe
you
won't
even
get
that
I
have
a
few
mechanisms
to
detect
when
users
are
sourcing
manifests
incorrectly.
C
C
The
user
doesn't
actually
want
to
manage
those
fields,
but
that's
what
you're
doing
if
you
follow
that
workflow
today,
so
I
want
to
detect
that,
and
in
order
to
do
that,
we'll
be
needing
to
add
some
extensions
to
the
will
probably
be
needing
to
add
some
extensions
to
the
open,
API
schemas
that
we
use
in
the
future,
not
necessarily
as
part
of
this
proposal
but
in
the
future
I
want
the
other
API
verbs
on
the
control
plane.
Actually,
this
may
be
as
part
of
this
proposal.
C
C
Yeah,
let's
see
doing
it,
this
way
allows
us
to
make
bug
fixes
in
one
component.
We
still
have
to
worry
about
the
deprecation
cycle,
but
hopefully
will
greatly
reduce
the
number
of
systems
you
need
to
fix
to
make
a
to
make
epics
and
the
the
ultimate
goal
is
that
you
control
apply,
is
no
longer
just
in
cute
control,
but
other
clients
and
other
languages
can
use
it.
C
Yes,
yeah
today
today
you
should
work.
Yeah
versus
skew
is
in
the
document
and
not
on
the
slides,
yeah
and
series
queue.
Control
apply
does
not
work
for
series
today,
even
if
you
apply
supply
a
schema
that
could
be
wired
through
such
that
would
work.
But
then
you
would
have
all
the
bugs
that,
because
there's
no
place
in
the
open,
API
schema
for
you
to
state
like
the
merge
key
behavior
yeah.
D
C
That
is
chapter
2,
okay,
yeah,
the
the
actual
dipping
logic
yeah,
that
is,
that
is
coming
up
if
I
get
to
I've,
never
gotten
to
that
half
of
a
slide
deck
so
we'll
see
if
we
make
it
so
more
about
the
apply
verb,
I
independently.
This
is
also
in
Clayton's
older
proposal,
but
I
wrote
this
down
before
I
remembered
I,
read
that
which
is
the
we
used
the
patch
verb
and
set
a
content
type.
C
C
C
C
B
C
My
general
theory
on
that
is
that
we
should
shuffle
the
error
messages
to
users
and
not
to
controllers,
because
users
are
likely
to
read
them
and
maybe
understand
them
depending
on
who
wrote
the
error
message
and
do
something.
Intelligent
and
controllers
are
likely
to
just
try
again.
So
it's
best
if
we
give
users
the
errors.
B
C
C
If
you
want
to
put
your
your
the
stuff
that
changes
that
and
the
lower
land,
the
top
layers,
so
that
you
don't
rebuild
these
whole
thing,
I
think
maybe
Brian
will
correct
me
if
I'm
wrong,
but
I
think
the
primary
recommended
use
cases
for
users
to
have
a
CI
CD
system
that
users
check
in
the
exact
objects.
Perhaps
there's
some
overlays
and
then
there's
a
there's,
a
system
that
just
runs
apply
on
that
in
a
loop
stating
that
this
is
the
like
CI
CD
system.
C
B
B
B
But
since
we
have
the
rule
that
all
API
versions
that
you
can
convert,
among
must
be,
the
conversions
must
all
be
round
trouble.
The
schemas
all
have
to
be
isomorphic,
it's
one
another,
so
you
should
be
able
to
only
whiskey
the
transformation,
regardless
of
default
values,
they're,
always
round-trip
a
bowl,
but
that
can
require
defaulting.
B
D
B
Default,
these
are
patches
so
by
just
since
it's
not
a
stack
of
the
full
of
things
you
can
compress
to
get
the
full
state.
The
defaults
are
not
in
one
of
the
patches
they
are
captured
in
the
state
when
the
resource
is
traded.
Only
the
creation
operation,
the
version
only
for
the
creation
operation,
the
version
actually.
D
C
D
D
B
I
mean
so
my
opinion
is
that
all
that
complex
defaulting
stuff
was
a
mistake
and
we
backed
out
of
some
things
like
selector,
mutability
and
apps
v1,
and
we
can
constrain
it
more
for
people
using
the
apply
flow.
We
can
either
do
it
for
all
apply
operations
or
we
can
do
it,
for
we
can
provide
an
option
to
do
safe
applies
that
prevents
that
actually
validates
that
you're,
not
relying
on
squirrely
behavior,
yeah.
B
Yeah,
it's
not
intended
that
you
should
be
able
to
reconstruct
the
same
objects
strictly
from
the
these
last
applied
strings.
So
if
you
converted
to
a
new
API
type-
and
you
extracted
the
string,
you
think
you
applied
and
you
create
the
we
create
the
resource
through
a
different
API
version.
You
would
get
different.
You
could
very
well
get
different
defaults,
I,
considered.
D
D
B
B
C
B
C
C
Considering
that
so
I
have
two
responses
to
that.
The
first
is
this:
should
approximately
double
the
size
of
objects,
because
people's
feels
well,
there's
a
caveat
there.
There
are
multiple
combats
there
yeah,
so
so,
generally
speaking,
if
different
people
are
applying
are
using
applying
the
same
object,
they
probably
want
to
own
different
fields,
so
all
told
that
should
add
up
to
about
twice
the
object
size.
So
these
this
is
encoded
optics
that
these.
C
C
C
Yeah
and
not
includable
less
proto,
therefore
never
compressed
the
one
caveat.
There's
a
there
is
something
I
have
to
think
about,
which
is,
if
somebody
runs
a
system
that
like
tweak
something
on
across
all
objects,
it
never
runs
again,
and
you
do
this
a
number
of
times.
You
could
end
up
with
a
bunch
of
different
workflow
IDs
that
that
are
just
sitting
there
taking
up
space
without
providing
value,
so
that
that
is
something
that
I
need
to
think
about.
Yeah.
B
F
F
B
I
also
have
that
concern
I
actually
disagree
that
automation
should
be
using
using
this
I
think
most
things
should
continue
to
use
tool
a
merge,
the
regular
patch
we
need
to
fix
all
them.
Merge
behaviors
in
some
new
and
improved
strategic,
merge
patch
effectively,
but
I
don't
think
that
retaining
retaining
the
last
applied
States
is
more
of
a
liability
for
those
components,
but
the
mechanism
will
exist
so
we'll
have
flexibility.
B
C
So
I
have
an
entire
chapter
on
this
topic
on
schema
changes,
but
briefly,
I
actually
haven't
surveyed.
Our
hope
and
API
schema
extensions
to
see
which
of
these
we've
added
in
which
of
them
we
haven't
I.
Think
most
of
these
we
have
not
added,
but
briefly,
our
schema
has
lists
which
are
associative,
and
some
of
them
are
associative
on
multiple
keys.
This
means
like
each
each
list.
Item
must
be,
must
have
a
unique
value
for
that
key
or
set
of
keys,
and
we
have
unions
which
are
mixed
in
with
other
types.
B
B
There
are
cases
where,
for
example,
if
there's
a
default
value
and
the
user
didn't
know
about
it
or
didn't
want
to
know
about
it,
and
they
tried
to
then
set
an
alternative
that
they
get
an
error.
If
they,
if
we
add
a
new
alternative
to
the
Union,
then
the
user
can't
even
the
client
can't.
You
know
necessarily
know
that
it
would
need
to
clear
that
particular
part
of
the
Union.
So
the
current
way
we
deal
with
this
is
actually,
in
my
opinion,
completely
broken.
B
What
two
canonical
examples
I
use
are
the
deployment
rollout
strategy
where
for
rolling
update
there
is
an
alternative
for
the
Union
and
that
is
populated
by
default
and
we
do
have
a
discriminator.
But
if
the
user
changes,
the
discriminator
does
not
clear
the
previous
selection
and
not
all
alternatives
even
have
of
the
discriminator
have
fields
within
the
Union,
and
then
we
have
volume
sources
which
we
keep
adding
more
and
more
volume
sources.
Hopefully
that
is
more
or
less
stopping,
but
there's
no
discriminator
at
all
the
canonical
thing.
B
People
want
to
do
switch
from
anteater
to
PVC
and
there's
just
no
good
way
of
doing
that
really
with
apply
today.
So
if
we
had
a
discriminator
and
the
user
could
actually
just
convey
their
intent,
I
want
this
part
to
be
set,
then
we
could
automatically
clear
the
other
parts
for
existing
api's.
We
would
didn't
have
discriminators,
we
wouldn't
require
it
and
we
would
not
populate
it
by
default,
because
then
it
can
drift
and
conflict
with
what
the
user
was
trying
to
set
using
the
current
approach.
B
C
B
C
C
B
C
B
B
Well,
I
just
want
to
say
that
if
you
are
really
interested
in
this
problem,
daniels
doc
is
really
awesome,
and
that
covers
a
lot
of
use
cases
and
definitely
a
big
problem
with
this
is
that
even
people
who
are
working
on
even
than
people
who
don't
support
initially
didn't
really
have
a
complete
mental
model
of
what
it
was
supposed
to
do.
And
that
is
what
led
to
all
the
problems
with
the
organic
growth
and
it's
been
turnover
in
terms
of
like
who's
working
on
the
teacher
thing.
B
You've
done
inconsistently
and
in
a
number
of
cases
wrong.
We
were
actually
supposed
to
have
conflict
detection,
but
it
doesn't
work
we're
supposed
to
have
certain
behaviors
when
imperative
mutations
overlapped
with
applied
State
and
that
was
initially
implemented
incorrectly
and
then
later,
not
fixed
correctly
and
a
different
was
broken
in
a
different
way.
So
this
kind
of
is
a
repeated
pattern
over
over
again
where
people
were
trying
to
like
patch
up
the
behavior.
But
almost
all
the
fixes
were
in
the
wrong
direction,
so
I
think
covering
all
those
use.
E
C
E
C
Okay,
so
I
haven't
actually
made
it
to
this
half
of
the
presentation,
and
my
previous
runs
through
this
through
this
deck
so
and
I
forgotten
what
slice
I've
made.
So
this
could
be
an
adventure,
so
this
half
of
the
problem
is
about
actually
so
the
model
behind
apply.
Is
you
look
at
the
last
thing
you
use
your
sent.
You
look
at
the
thing
the
user
is
sending.
Now
you
look
at
the
live
state
and
you
put
it
all
together
to
get
what
the
user
wants
now.
C
C
C
So
this
is
an
aside
to
talk
about
an
identity
I
have
if
you,
if
you
read
this
document,
is
rather
mathematical,
I,
think
of
dipping
and
merging
and
sort
of
algebraic
terms.
So
this
is
first
equation.
When
you
take
a
difference,
you
take
two
concrete
objects,
take
the
difference
of
them
and
you
get
a
patch
a
to
emerge
adds
a
single
object,
a
concrete
object
with
a
patch
and
gives
you
a
second
concrete
object.
A
three-way
merge
is
just
a
difference
combined
with
a
two-way
merge
yeah.
C
B
C
Yes,
incidentally,
I
may
cover
that
later
kasyacit,
so
in
the
in
the
current
implementation
of
queue,
control
apply
the
client.
Does
the
diff
constructs
a
patch
in
strategic,
merge
patch
format
sends
that
patch
to
the
server
and
then
the
server
does
the
two-way
merge
operation
with
the
with
a
strategic
brush
patch
yeah,
so
that
that's
that's
problematic,
but
we'll
probably
come
back
to
that.
So
why
is
this
part
of
the
problem
hard.
C
Of
API
support,
client-side
implementation,
strategic
merge
patch
was
not
easy
to
version.
You
had
to
fix
multiple
things
and
wait
a
long
time
before
you
could
rely
on
the
fixed
things,
the
and
and
and
so
from
the
beginning.
I
think
Brian
is
sort
of
touched
on
this.
From
the
beginning
of
this.
The
implications
of
our
schema
weren't
well
understood
when
we
first
started
doing
this.
C
B
Yeah
right,
some
bugs
are
still
even
in
the
API
schema
itself.
The
canonical
example
is
ports
where
port
is
the
port
number
and
services
is
specified
as
the
merge
key,
but
you
can
add,
though,
tcp
and
UDP
ports
with
the
same
key.
So
really
it's
this
case,
where
you
need
multiple
keys,
that
together,
multiple
deals
which
together
are
the
key
and
the
current
implementation,
doesn't
even
support
that
yet
yeah
we.
C
B
C
Yeah,
so
fairly
large
part
of
the
work
of
this
aspect
of
the
problem
is
building
out
our
IDL.
The
types
that
go
to
the
open,
API
schema
to
the
validation
functions
like
building
off
that
pipeline
and
educating
developers
who
are
writing
the
API
optics,
so
they
can
get
it
right.
Education
includes
the
winters
in
this
case
I
thought
that's,
probably
the
most
effective.
C
So,
given
all
that
I
think
it
is
best
if
we
don't
send
a
DIF
to
the
server
I
think
it's
best
if
the
server
does
both
halves
of
the
three-way
merge
yeah.
This
is
just
best
involves
less
churn
and,
importantly,
for
me,
like
I
asked
you,
which
was
was
crew
ad-hoc
I,
don't
want
to
support
a
similar
thing.
I,
don't
want
to
write
in
RFC
for
a
batch
format.
That's
not
sound
like
fun
to
me.
C
D
C
Exactly
so
yeah,
so
if
the
server
is
doing
the
computation,
then
we
have
to
figure
out.
How
does
this
really
through
merge
has
a
base
optic.
We
have
to
figure
out
how
to
how
to
track
this.
So
there's.
Basically,
two
options
and
I
include
this.
For
completeness,
one
option
is:
when
you
send
it,
when
you
do
an
apply,
you
send
the
server
two
objects,
both
the
base
and
the
local.
If
you
do
that,
the
client
has
to
remember
the
base.
C
C
C
So
I
don't
mention
this
here,
but
one
reason
why
you
don't
want
to
make
the
client
do
this
is
that
the
client
might
be
sending
the
same
object
to
multiple
clusters
and
you
don't
want
that
client
to
have
to
keep
track
of
not
only
the
last
thing
they
send,
but
the
last
thing
they
sent
for
every
cluster
they
sent
it
to.
That's.
C
So
now
I
have
a
slide
about
our
data
model
and
I.
Think
we've
hinted
at
this
multiple
times
so
I'll
be
brief.
Our
data
model
has
a
few
atoms,
structs
lists
maps
and
the
fields
structs
contain
unions.
Structs
can
have
more
than
one
union.
Some
unions
have
discriminators
some
unions,
don't
there
are
fields
and
strikes
that
have
minions
that
aren't
part
of
the
union.
So
that's
complicated
and
I.
Don't
know
that
you
can
represent
that
exactly
an
open
API,
our
lists,
our
associative,
they
have
keys.
C
One
of
the
problems
in
early
versions
of
queue
control
apply
was
that
it
scrambled
the
the
list
and
map
order
because
it
read
it
into
a
go
map
and
then
wrote
it
out
again
and
go
likes
to
randomize
things
for
you
to
make
sure
you
don't
accidentally
depend
on
something
that
the
go
team
did,
and
finally,
we
have
what
I've
called
leaf
fields.
You'll
see
them
referenced
in
my
document
is
either
scale
ours
or
primitives.
Those
are
strings.
The
numeric
types,
integers
or
floats
think
I
think
JSON
lets
you
encode
floats
as
well.
C
Referring
to
you
can't
then
set
that
thing
to
null
it's
not
in
codable.
So
that's
the
primary
reason
why
what
I've
called
Delta's
schema
is
not
the
same
as
the
object
schema.
Oh
I
have
an
entire
slide
on
that.
Yes,
a
secondary
reason
is
that
required
fields
and
the
original
schema
are
always
optional.
In
the
Delta
schema
because
the
the
difference
object
might
not
change
them,
and
that's
okay,
and
this,
this
problem
is
essentially
why
three
huge
patch
had
to
evolve.
C
Some
non-obvious
details
and
and
I
put
these
here
because
they're
controversial
so
just
to
make
sure
that
everybody
sees
the
contour
controversy.
You
cannot
delete
a
field
that
is
required
or
has
a
default.
The
the
delete
option
operation
simply
doesn't
make
sense.
If
you,
if
you
delete
the
replicas
field
in
your
deployment,
you
do
not
get
zero
replicas,
you
get
one
replica.
It
just
fundamentally
doesn't
have
a
delete
operation.
So
so
there
is
this.
C
The
answer
to
that-
and
we
already
talked
about
unions
I,
think-
and
this
is
here
again
because
it's
not
obvious-
that's
a
very
nice
way
of
describing
it
I,
think
unions,
if
you
set
one
member
that
implies
clearing
all
the
others.
You
think
you
can
handle
that
and
the
two
way
merge
logic
and
it
will
more
or
less
get
things
correct,
but
that
doesn't
handle
the
case
where
you're
not
going
through
the
uruk's
logic.
So
yeah
I
mean.
C
The
last
item-
and
this
is
perhaps
the
most
or
one
of
the
most
non-obvious
things
about
the
original
apply-
is
that
list
ordering
is
really
hard
because
you
get
lists
in
different
orders.
So
if
you
look
at,
if
you
look
at
my
document,
I
have
one
recommended
algorithm
for
defining
the
order
after
a
two
way.
Merge
I'm
not
super
happy
with
it,
but
there
are
examples
there
listing
what
I
believe,
but
that
algorithm
does.
G
G
B
E
B
B
C
So
if
you
look
at
my
document,
I
have
like
a
constraint
based
or
like
topological
sort
inspired
approach
to
ordering
them
for
most
lists.
It
doesn't
really
matter
what
the
order
is
as
long
as
it's
predictable,
it
stays
the
same
for
some
lists.
The
users
really
care
a
lot
about
the
order
that
things
appear
in
and
if
you're,
in
that
condition,
I
think
the
best
way
is
to
in
your
in
your
doctor,
like,
even
if
you
only
want
to
own
some
of
the
in
it
continues.
C
But
you
want
to
you
care
about
the
order
like
you
can
mention
the
other
keys
in
the
order
that
you
want
to
appear
so
I
think.
That's
that's
the
way
to
go
about
it,
so
the
doc
is
pretty
rigorous.
I'm,
currently
working
on
on
filling
out
the
test.
Vectors,
like
I,
think
it's
important
that
we
cover
all
of
the
all
the
cases
here,
because
missing
cases
has
led
to
a
lot
of
bugs
and
stuff,
so
yeah,
all
right
and
wow
I
got
through
the
whole
Tech
and
just
under
time.
A
Daniel,
thank
you
so
much
for
being
so
thorough
in
this
cuz.
This
I
think
would
be
hard
for
a
lot
of
people
to
consume,
without
the
full
case
being
made
for
it,
so
Bravo
good
job.
If
I
can
understand
it
they're
doing
well
so
great.
Thank
you.
Are
there
any
follow-ups
that
we
need
to
do
to
help
raise
awareness
or
get
more
consensus
building,
or
how
do
we
enable
you
to
have
more
success
with
this.
C
I
think
what
I'm
hoping
for
initially
from
city
architecture
is
something
like.
Yes,
this
is
the
direction
we'd
like
to
go,
go
ahead
and
put
together
the
the
cap
or
the
you
know,
start
building
out
the
the
more
specific
concrete
designs
for
the
various
things
that
we
want
to
change.
I.
Think
that's
what
I'm!
Looking
for?
Okay.