►
Description
sig-arch recap from earlier in the day
think up options for implementations
B
B
What
we're
gonna
do
for
our
api
and
try
to
actually
I
mean
maybe
not
decide
in
this
meeting,
but
brainstorm
about
possibilities
and
try
to
maybe
rank
them,
or
you
know,
figure
out
what
we
think
is
best
when
everybody
else
thinks
is
best
or
not
form
a
matrix
and
try
to
choose
the
least
bad
one
that
sound
about
right
for
everybody
else.
I
like.
B
D
B
Somewhat
I
mean
since
it's
not
unrelated,
but
I
mean
it's
it's
partially.
You
know.
If
we're
going
to
say
you
know,
the
beta
version
is
the
beta
version
and
yes,
we're
going
to
support
it
for
nine
months
and
basic
I.
We
have
written
down
like
I,
guess,
goals
for
v1
I'm
concerned
that
they're
not
sort
of
up-to-date
and
realistic
anymore,
and
that
if
we
go,
we
eventually
we
get
to
v1
and
basically
we're
releasing
something.
B
That's
already
broken,
and
you
know
the
correct
working
version
is
is
v2
and
it
has
to
be
v2
because
we
said
we're
gonna
release
the
p1
as
v1
and
and
like
I
I.
Don't
think
we're
at
the
point
that
everybody's
going
to
be
all
of
a
sudden
confused.
If
we,
if
we
just
say
v1,
is
like
the
real
thing,
but
maybe
I
think
that's
something
we
need
to
discuss
and
well.
B
E
D
A
A
B
D
Well,
though,
so
I
think
the
question
around
that
is,
do
we
want
to
keep
the
big
lock
or
do
we
want
to
look
at
some
alternative
solutions,
like
somebody
mentioned,
converting
the
request
for
an
update
into
creating
an
object
that
goes
into
a
queue,
so
you
have
a
queue
of
pending
update
requests.
That
way
you
don't
need
a
big
lock.
You
just
stick
something
at
the
end
of
the
queue
and
you'd
be
pulling
things
off
the
queue
at
a
time.
I
think
that's!
D
B
Something
I
do
agree
that
Jake
that
we
did
kind
of
say
that
I
what
you
said,
we
should
feature
gate
that,
but
if
we
do
yeah
I
agree
with
that
part
and
I
agree
with
juggs
part
that
we
need
to
figure
out.
If
there
is
a
alternative,
that's
but
I,
I,
think
yeah
and
they're
in
the
meeting
yeah,
we
kind
of
did
say
that
maybe
the
Google
lock
is
just
something
IBM
does
everybody
else
doesn't
believe
in
the
problem
exists.
D
B
B
D
A
C
A
No
one
I
agree
I'm
just
saying
that's,
that's
one
of
the
questions
that
we've
been
talking
about
for
a
couple
weeks
now
and
I.
Don't
think
I
certainly
don't
know
the
answer
to
it,
and
it's
just
one
of
those
questions
that
we
want
to
answer
at
some
point.
You
know
how
long
is
our
backward
compatibility
with
me
one
day,
one
once.
C
B
D
They
are
in
control
over
what
you're
allowed
to
do,
and
we
are
not
in
a
position
to
to
be
able
to
do
all
the
checks
necessary
in
our
back
or
admission
controllers
to
know
for
sure
whether
the
resource
is
going
to
allow
us
to
perform
this
particular
action.
So,
therefore,
we
will
not
know
whether
the
resource
will
say
yes
or
no
until
we
actually
enter
the
reconciliation
loop,
which
means
after
the
speck
has
been
updated,
and
when
you
update
the
spec.
D
I'm
sorry
updates
to
the
spec
are
problematic
for
us,
because
we
need
to
be
able
to
figure
out
some
way
to
rollback,
but
we
kind
of
have
a
solution
for
that.
So
the
real
problem
is
delete
because
once
delete
hits
the
spec,
it's
updated
the
delete,
timestamp
and
there's
no
way
it
is
to
roll
that
back,
but
I
try
not
to
focus
too
heavily
on,
deletes
and
focus
more
on
the
abstract.
A
question
of
does
kubernetes
want
to
allow
external
resources
to
be
in
control,
as
opposed
to
kubernetes
being
in
control,
and
we
never.
D
We
didn't
get
a
definitive
answer
which
was
it
looking
for
it
was
more.
The
question
was:
do
we
want
to
explore
this
more
and
the
answer
I
got
back
was
pull
the
community
to
see
if
there's
interest
in
forming
a
work
group
around
this,
and
at
least
one
person
on
the
call
said
they
are
running
to
similar
problems
and
they
would
be
interested
in
participating
in
additional
discussions.
Does
that
summarize
it
well
Jay
and
Morgan?
Do
you
think
I
agree.
B
C
A
D
A
D
That
Brian
couldn't
make
it
because
I
I
could
have
sworn
in
the
past.
I've
heard
him
talk
about
integrating
with
third-party
systems,
and
we
need
to
want
to
be
able
to
support
that.
So
I
thought
we
might
be
able
to
get
him
on
our
side,
but
it
was
another
call
so
I,
don't
know
how
it
feels
about
it
for
sure
yeah.
D
But
all
honestly,
I
honestly,
don't
think
this
problem
is
unsolvable,
but
what
challenge
is
getting
people
to
expand
their
mind
to
allow
for
some
additional
flexibility
where
there
is
a
flexibility
today
and
I
think
this
is
really
no
different
than
any
other
extensibility
point.
The
Cooper
days
is
added
right,
whether
it's
you
know
adding
admission
patrollers,
adding
mutating
webhooks.
What
do
you
want
to
call
it?
Those
things
didn't
exist
at
one
point
in
time
and
then
they
added
them,
and
somebody
had
to
be
convinced
that
it
was
worthwhile
to
add
that
flexibility
point
agent
system.
D
A
D
C
Other
suggestion
that
arch
was
pushing
in
the
mailing
list
was
you
have
an
admin
fix.
It
is
that
right,
I
member,
they
were
saying
like
you,
just
let
it
get
stuck
and
you
have
an
admin
address
it
or
delete
it
and
recreate
it
like
remove
the
finalizer
and
just
rebuild
it,
or
did
they
have
more
engine
suggestions.
D
C
D
It
would
beat
yes
delete
and
recreate,
and
my
my
biggest
concern
with
that
is,
if
somebody
is
watching
this
resource,
that
you're
going
to
delete
and
they're
going
to
take
an
action
based
upon
the
deletion
timestamp
being
set
retrain,
the
resource
doesn't
help
because
they've
already
taken
of
action
like
perhaps
started
some
cleanup
process
right
and
you
can't
get
them
to
this
roll
that
back.
So
that's.
C
B
B
B
B
You
are
going
to
get
an
update
event
and
then
a
delete
event
like
that's
what
happens
yep
then
it
goes
that
say
say
those
both
call
the
same
method
and
the
same
callback
and
end
up
in
your
code.
Okay.
Well,
what
is
the
update
event?
The
update
event
is
adding
the
deletion
timestamp.
So
look
literally
the
the
only
point
that
we
have
there's
there's
you
can
be
looking
at
the
deletion
timestamp
at
that
point.
You
know.
B
Oh
yes,
this
is
going
to
be
gone
by
X
next
time,
butBut
when
we
say
that
we're
saying
it's
gonna
be
gone
from
storage,
and
so
the
deletion
timestamp
is
really
the
last
key
point
where
we
can
do
something
before
it
after
it
I
don't
see
what
we
can
do.
I
think
this,
the
the
other
aspect
of
it
that
came
up
was
doing
an
update
to
the
spec
after
the
fact
which
I
don't
think
helps
us.
B
A
Was
a
way
sicker
the
way
I
heard?
That
was
something
along
the
lines
of
in
some
cases.
If
the
update
fails,
you
can
change
the
spec
and
things
will
hang
on,
but
the
part
of
the
problem
that
statement
around
you
could
update
things.
Was
you
can't
undo
the
delete
I
mean
that
was
that
was
the
bottom
line
right,
yeah.
D
But
it
certainly
back
around
just
for
a
sec
to
Carolyn's
question
about
well.
Do
people
watch
the
deleted
timestamp
verses?
Do
they
watch
for
the
actual
delete
from
that
CD
itself?
I'm,
not
sure
it
matters
to
be
honest,
because
either
way
that
that
watch
was
gonna
kick
off
some
process
when
that
process
should
not
have
been
kicked
off
because
we're
gonna
recreate
the
object
right.
C
Not
so
sure
I
wouldn't
be
willing
and
be
willing
to
support
someone
who
said
I'm
watching
for
a
delete
timestamp
and
assuming
that
it's
going
to
happen
because
another
balcony
valid
thing
to
happen
in
kubernetes
is
that
delete
time
stamp
get
set.
And
then
it
stays
an
error
for
quite
a
while
right
or
is.
D
C
C
My
point
is
like
kicking
off
on
unchangeable
actions
based
off
of
an
update,
funk
that
could
get
changed
in
the
future
versus
a
delete
which
semantically
means
delete
like
one
I'm
willing
to
support
another,
be
more
willing
to
say
to
someone
that
they
have
been
going
down
the
wrong
path
like
taking
a
ton
of
engineering
time
to
support
their
one
thing.
You
know
what
I
mean
well.
D
D
So
if
you
can
watch
it,
if
you
want,
because
we
can't
stop
you
but
be
aware
just
because
this
flag
is
set,
does
not
mean
I
delete,
it's
gonna
happen,
it's
just
a
request
that
may
be
rejected
and
the
problem
is,
you
can't
make
that
kind
of
guarantee
and
a
deletion
timestamp.
They
can't
at
least
the
way
it's
currently
defined.
So
that's
why
I
like
Morgan
solution,
it's
introducing
a
new
flag
with
new
semantics
that
we
get
to
define
and
we're
not
gonna
break
anybody,
because
it's
a
brand
new
thing.
D
C
Remember
suggesting
something
last
week,
but
I
don't
quite
remember
like
what
was
brought
up
is
like
a
really
big
problem
with
it.
If
deletes
from
the
user
may
be
user
initiated
deletes
aren't
allowed
and
instead
we
relied
on
something
like
update
index
or
relist
index.
We
could
have
like
unused
index
basically
saying
like
we
don't
want
it
anymore.
Please
try
to
get
rid
of
it
at
some
point
and
here's
some
time
out
for
trying
to
get
rid
of
it
and
then
having
the
controller
handle
that
entirely
so
don't
get
into
the
delete
state.
C
That
seems
the
reason
why
I'm
saying
that
is
that
it
seems
to
me
that
the
one
of
the
things
that
sig
arch
was
very
concerned
about
was
a
hijacking
from
you
know:
Margaret
Morgan,
by
hijacking
the
delete,
regardless
of
what
kubernetes
does
under
the
hood,
it's
confusing
to
people,
and
it
seems
counter
to
how
people
expect
it
to
work,
and
so
I
was
curious
if
we
went
that
other
way
and
did
something
that
maybe
fit
user
expectations
better.
Would
that
be
a
viable
solution
as
well
that
we
could
consider
in
that
working
group,
but.
A
C
Less
thing
you
know,
they're
deleting
more
saying
I'm
done
with
this.
Please
clean
it
up.
If
you
can,
you
know
right
right,
who's,
interested
in
it
or
anything
like
that.
I,
don't
I,
don't
know
how
to.
Basically,
you
have
on
the
object
update
instead
of
a
delete,
but
instead
of
calling
it,
you
know
delete
like
get
rid
of
that
word
entirely,
because
it
sets
up
to
expectations
and
instead
reframe
it
as
something
else
that
fits
better
with
user
expectations
and
kind
of
works
with
what
sig
Arch
was
trying
to
suggest.
Okay,.
D
Yeah
I
see
my
point
of
view
on
that
is
I
agree
with
you,
a
hundred
percent
that
can
technically
work.
That's
not
the
problem.
The
problem
is
whether
people
will
accept
the
delete
not
being
a
valid
action,
the
HTTP.
Do
it
nothing
about
action
if
we
could
get
everybody,
including
someone
like
null
to
say?
Yes,
we
are
gonna
turn
off
delete
for
all
use
cases
for
all
uses
of
Service
Catalog
service
instances
and
service
bindings,
and
you
have
to
go
through
this
request:
delete
flag
type
of
mechanism.
D
C
Do
I
really
need
to
be
no
opt-in,
but
just
like
right
now
like,
for
example,
big
lock
is
opt
in.
Is
there
a
reason
like
someone
like
null
who
want
to
just
Yolo?
Do
things
a
specific
way
could
say:
I'm
gonna
change.
My
are
back
to
allow
deletes
there
why's
everyone
by
default,
those
through
a
more
staged,
safer.
D
Like
process
no
yeah,
the
problem
is,
you
have
in
it?
There
are
what
they
call
in
Iran
bility
a
portability
problem,
but
you
have
some
sort
of
pollen
on
those
lines,
because
what
you
then
have
is
I'd
have
a
script
that
works
on
one
platform,
because
it
does
a
delete
and
I
take
that
exact
same
script
and
take
it
over
to
a
different
platform,
and
somebody
doesn't
work
anymore,
I
now
to
set
a
flag
instead
of
do
a
delete
so
I,
my
back
page
is
up.
My
scripts
are
not
portable
anymore
and.
D
And
that's.
This
is
part
of
the
reason
why
I
keep
freezing
this
and
I
respect
compliance
issue,
because
I'm
I
I
don't
like
the
idea
of
this
stuff
being
behind
the
feature
flag,
but
if
it
is
data-feature
flag,
I
think
we
need
to
be
spec
compliant
by
default,
and
people
need
to
go
out
of
their
way
to
violate
the
spec
and
I
think
the
big
lock
needs
to
be
on
by
default.
In
my
opinion,
I'm.
A
Kind
of
in
Carolyn's
camp
I,
I
would
I
think
it's
I
think
you
went
at
a
hard
time.
You
know
changing
niles,
mind
and
probably
those
from
Red
Hat
about
going
to
a
request
Alicia
instead
of
a
deletion,
but
it
does
seem
to
me
that
we
could
straddle
both
camps
with
with
a
optional.
You
know
what
one
is
a
kill,
and
one
is
a
hey.
You
know
when
you
can
clean
this
out
and
remove
it
and
to.
C
Be
clear
what
I'm
trying
to
do
is
explore.
What
can
we
do
now
without
holding
up
one?
Oh,
and
what
are
things
that
we'd
like
to
take
to
this
working
group
for
a
long-term
solution
and
and
just
understand
what
our
options
are,
so
we
know
like?
Is
it
even
representing
something
to
people
or
probably
already
poked
enough
holes
of
it
that
we
should
set
it
aside?
You
know
what
I
mean
yeah.
D
I
totally
understand
in
you
know,
I
I'm,
all
in
favor
of
brings
from
different
options
to
see
what
you
know,
what
we
can,
what
we
can
do,
but
I
what
one
thing
I
don't
quite
understand,
though,
maybe
you
guys
can
help
me
wrap
my
head
around.
This
is,
if
you
look
at
something
like
mortgage
solution
right
where
the
delete
gets
mapped
to
setting
of
the
state
flag
and
then
under
the
covers,
eventually
that
gets
translated
to
setting
the
deletion
time
stamp
right.
What
I
don't
understand
is
if
all
that
is
hidden
from
the
user.
D
C
C
But
when
we
move
to
secure
DS
I
believe
that
option
is
removed
from
the
table
and
I'd
like
to
understand
what
the
continuity
of
user
experience
would
be
between
100
and
CR
DS
and
just
make
sure
that
we
don't
paint
ourselves
into
a
corner
if
we
decide
to
go
down
that
route
like
ok.
So
it's
a
temporary
solution
that
we're
gonna
have
to
break
UX
for
in
six
months
or
whatever
then
I'm
a
little
worried
about
that.
No.
D
D
C
E
D
C
C
A
B
A
B
D
C
Was
completely
transparent
to
them,
I
was
able
to
take
SV
cat
and
basically
point
it
at
my
CR
DS.
Instead
of
the
the
real
like
service
instances
and
things
like
that
and
get
pretty
much
everything
to
work
except
this
switch,
which
type
I
was
talking
to
the
whole
time.
So
the
idea
with
the
shadow
resourcing
or
just
CR
DS
in
general,
is
that
it's
still
a
it's.
The
exact
same
client
that
we
generate
ourselves
and
check
in
you
know
our
generated
client.
C
It's
no
different
whatsoever,
it's
just
a
matter
of
like
they
have
some
default
plumbing
in
API
server
too,
and
you
know
the
store
inside
there
like
tell
them
everything
through,
and
then
they
give
you
nice
little
places
for
your
controller
and
you
just
haven't.
You
don't
have
as
many
like
full
control
over
the
life
cycle,
unlike
all
the
hooks
and
everything,
but.
D
D
But
I
guess
so
so
the
the
the
type
and
kind
and
all
everything
remains
the
same.
So
an
application
I
write
that
watches
a
cluster
service
broker
today
and
create
or
or
interact
with
customers
today,
either
through
puts
deletes,
gets
and
through
watches
and
stuff.
Not
a
single
line
of
code
needs
to
change.
Wanna
go
when
we
go
to
see.
Are
these
as
long.
C
C
We
have
third
on
the
list
here,
shadow
resourcing
so
when
I
first
implemented
the
concept
of
how
to
set
up
like
default
provisioning
parameters,
so
that
zone
could
as
a
day
0
trial
like
say,
I
want
to
install
something
and
I
don't
want
to
understand
any
of
the
parameters.
The
way
I
did
that
is
I,
basically
put
a
CR
D
in
front
of
all
of
Service
Catalog.
C
That
I,
I
called
shadow,
doesn't
matter,
and
then
the
user
interacted
with
that,
and
then
my
controller
essentially
handled
performing
actions
on
behalf
of
that
user
c
rd
and
then
applying
them
back
on
our
existing
services
and
everything.
So
like
not
a
single
line
of
service,
catalog
changed
as
able
just
think
it
all
over
and
as
far
as
the
user
was
concerned,
they
like
pretty
much
ignored
anything
related
to
Service
Catalog.
C
C
We
could
have
a
couple
options.
We
could
either
have
that
C
or
D
completely
go
away
and
say
as
far
as
user
concern
it's
gone,
and
it
would
be
a
problem
for
the
administrator.
That
was
something
that
Paul
was
throwing
out
as
an
option.
The
other
option
is
that
someone
could
recreate
it
like
that.
Our
series
would
be
recreated
and
we
tell
people
don't
start
watching
these
CRTs
watch
the
true
backing
resource
before
taking
destructive
actions.
Essentially
so.
C
Potentially
or
some
solution
you
know,
Paul
threw
out,
like
we'd
only
make
those
in-case-of-emergency
like
when
we
really
can't
delete
things,
but
the
other
idea
is
just
you,
shadow
everything,
and
it's
only
ones
that
are
missing
there.
Cr
anybody,
like
the
user
facing
resource
that
we
basically
call
stock.
That
requires
attention.
D
Yeah
I'm
not
sold
the
idea
of
some
sort
of
weird
state
where
the
minister
needs
to
fix
it.
The
idea
of
saying
there's
two
resources
for
all
instances
and
when
a
delete
happens,
you're
always
doing
the
the
shadow
resource
as
you
call
it,
and
it's
only
when
the
broker
says.
Yes,
then
we
delete
the
real
resource,
but
in
circuses,
no,
they
recreate
the
shadow
resource
and
we
explicitly
say
in
the
documentation.
You
know
you
can
watch
instances
all
you
want,
but
make
sure
you're
watching
the
real
instance,
not
the
shadow,
because
those
are
transient
right.
D
C
Yeah,
that's
definitely
one
option:
yeah
I
I
went
one
step
further
and
actually
put
the
real
ones
that
I
didn't
want
the
user
in
acting
with
in
a
different
name
space
so
that
they
weren't
tempted
to
see
it
and
wonder
what
they
were
in
poke
them
as
well,
but
I
guess
with
our
back.
You
could
do
essentially
the
same
thing
to
prevent
people
from
looking
at
those
and
wondering
what's
going
on.
C
D
Cuz
I
mean
the
naming
of
these
things.
We
kind
of
funky
right
I
mean
when
you
want
to
do
a
list
to
see
what's
in
there,
which
one
do
you
list
right
and
then,
when
you
start
doing,
pointers
between
things
if
I
want
to
create
my
own
resource
and
point
to
a
service
instance.
I
need
to
make
sure
that
one
doesn't
point
to
the
shadow
they've
always
point
to
the
real
one,
because
a
shadow
could
go
away
down.
C
The
path
of
making
a
different
kind
for
the
user
facing
CRD
versus
the
shadow
or
you
know,
I,
don't
know
what
the
names
are.
You
know
the
one
that
actually
represents
the
true
state
of
the
world
and
the
other
one
that
represents
the
user
intent
or
the
spec.
They
were
ended
up
being
separate
CRTs,
so
I
could
auerbach
them
differently
and
also
because,
like
you
said
otherwise,
it's
really
hard
to
just
show
the
ones
that
matter.
When
you
do,
you
know
cube
CT
I'll
get
yeah.
D
I'm
trying
I'm
just
trying
to
wrap
my
head
around
around
you,
have
a
user
kind
of
almost
has
to
know
about
the
two
resources
right,
because
if
you
won't
have
some
that
points
to
an
instance,
you
probably
don't
want
to
point
to
the
shadow.
Well,
maybe
doesn't
matter
no,
yes,
I,
don't
think
any
one
point
to
the
shadow
you
kinda
want
to
point
to
the
rule.
One
right,
but
oh.
C
C
Have
that
say,
for
instance,
the
shadow
binding
connected
directly
to
the
shadow
instance
and
my
controller
handled
mirroring
that
onto
the
actual
service
instance
and
binding,
so
that
it
use
the
correct
references
that
make
sense
so,
like
the
user
would
see,
one
thing
and
they'd
have
one
connection
between
those
two
resources
and
then
I
would
have
that
same
connection
between
the
real
ones
that
the
broker
is
managing
and
their
work.
They
wouldn't
be
cross
references
between
the
shadow
and
the
actual
instances,
for
example,
can.
C
Sure
so
I
wanted
to
rapid
prototype
how
service
catalog
could
look
if
we
had
the
ability
to
default
provisioning
parameters,
binding
parameters,
a
template,
was
it
called
secret
transformations
things
like
that?
It's
kind
of
related
to
the
kind
proposal
that
Kant
made
last
week
at
the
OSB
group
and
I
wanted
a
below
this
all
together
without
actually
changing
Service
Catalog.
C
So
I
was
able
to
just
put
these
CR
DS
in
front
with
a
simple
controller
and
the
controller
handled
mapping
the
intent
that
was
represented
by
those
CRTs
filling
in
parameters
and
things
like
that
and
then
making
the
real
service
instances
and
bindings
behind
the
scenes.
Essentially,
so
the
user
would
see
one
thing
and
then
service
catalog
would
be
giving
the
full
set
of
information
to
the
broker.
You
have
to
worry
about
all
that
extra
information,
and
just
let
me
do
it
a
lot
faster
than
changing
our
code.
Yeah.
A
C
C
A
C
A
Don't
know
if
it
was
more
open
or
just
a
way
to
deal
with
it
and
say
that's
not
our
problem,
yet
you
know
go
and
prove
that
prove
that
other
people
want
this
and
then
come
back
to
us.
When
you
have
you
know,
army
people
behind
you
and
oh
I
mean
it.
Didn't
it
didn't
go.
It
wasn't
an
extremely
negative
conversation
at
all.
Okay,.
A
B
C
D
Well,
cuz
I!
Well,
yes,
I,
don't
mind.
Looking
at
your
your
idea
on
paper,
so
that
I
can
really
digest.
Ik
is
I
love,
Morgan
solution
that
is
headed
down.
I
actually
think
it
is
the
right
long-term
solution,
but
you're
you're
mentioning
the
problem.
Cr
DS
is
such
a
big,
wrinkle
and
heading
down
that
path.
That
I
really
want
to
understand
your
solution:
better
yeah,
yeah.
D
You
know,
and
maybe
Morgan
solution
is
maybe
it's
not
let
me
go
with
right
now.
Maybe
it
is
your
shadow
thing
and
maybe
instead
we
use
Morgan's
thing
as
a
proof
of
concept
to
convince
big
architecture
or
API
server
group
whatever,
then,
maybe
they
need
to
allow
this
kind
of
flexibility
and
here's
a
clear
concept
that
shows
it's
not
as
bad
as
I
think
it
is
I,
don't
know
you.
D
Yes,
a
fight
might
but
my
bigger
concerns,
though,
with
the
shadow
thing
is:
if
we
go
with
the
shadow
thing
and
then
a
miracle
happens
and
say,
architecture
or
API
server
decides
to
allow
some
flexibility
to
do.
We
want
the
more
real
way
we
want
to
do
it.
That's
gonna
be
an
API
change
for
us,
and
this
means
we
haven't
jump
up
to
version
2
just
to
support
us
would.
C
It
can
I
give
you
a
winner
sandal
bit
further,
because
I
would
have
expected.
We
have
two
sets
of
resources.
What
if
we
continued
exposing
service
instance
and
service
by
means
service
plan
class,
whatever
those
those
continue
to
be
exposed
to
the
user,
and
then
we
make
some
new
temporary
CRD
that
we
rely
upon
what
a
service
instance
I,
don't
care
if
names
are
hard
and
then,
if
we
give
what
we
eventually
want
upstream,
we
just
stop
using
those
but
the,
but
the
the
resources
that
we've
been
using
all
along
continue
to
be
the
same.
C
C
So
right
now
people
watch
servants,
instance
etc
right
and
they
kind
of
act
off
of
it.
If
we
were
able
to
say
starting
at
v1,
don't
watch
those
watch
the
OS.
What
you're
saying
I
finally
found
it
yeah,
because
we
would
tell
people
to
watch
whatever
is
backing
it
right.
We
would
have
to
tell
him
to
change
that
if
we
switched
it
around
which
to
them
would
be
a
different
set
of
right
everything
all
different
types
yeah.
C
C
C
D
Just
since
we're
recording
this
call,
I'd
like
to
officially
go
on
the
record,
I
think
kubernetes
decision
to
make
the
user
facing
API
match
one
to
one
with
the
backing
store.
Resources
is
a
huge
mistake
because
it
does
not
allow
you
to
change
one
without
changing
the
other,
and
that
just
is,
as
you
see,
is
causing
nothing
but
problems.
So
just
one
get
that
on
the
record.
C
F
F
B
B
The
cost
of
level
one
most
people
I
guess,
don't
trust
that
we
won't
blow
it
up
on
accident.
Even
though
I
find
that
as
strange
argument,
because
we're
using
I
mean
we're
using
the
API
machinery
from
the
cluster.
So
with
I'm
sorry,
what
do
you
mean?
Who
doesn't
trust
us?
The
upstream?
Whatever
core
Caretti
API
people
say
no
we're
never
going
to
expose?
Oh
okay,
the
cluster
NCD,
because
we
think
you
might
accidentally
blow
up
and
I'm
like
yeah,
okay,
I,
don't.
F
F
C
So
to
summarize,
though,
about
why
we
were
evaluating
CRTs
just
at
a
high
level,
it
was
the
ability
to
have
us
just
use
the
clusters
at
CD.
It
was
to
reduce
the
effort
on
our
part
to
sync
up
with
all
the
copy
pasted,
aggregated
API
code,
etc,
that
happens
at
the
kubernetes
minor
releases
and
because,
as
a
whole,
the
community
seems
to
be
like
narrowing
and
on
that
I'm
moving
forward
with
it
and
we'd
like
to
be
able
to
take
advantage
of
innovation
and
just
wheels
that
other
people
have
invented
as
we
go
forward.
C
D
B
B
D
Think
we
can
answer
that
until
we've
decided
how
we're
going
to
solve
this
problem
of
these
short-term
and
I
think
there's
two
things
that
have
to
happen
there.
One
is
it
I
think
Carolyn
Jim
could
write
down
her
proposal
for
the
shadow
resource.
We
can
all
evaluate
it
and
I
think
it's
worthwhile
for
you
to
continue
down
the
path
of
finishing
up
your
proof-of-concept.
So
people
can
see
how
scary
that
code
is
part,
not
scary.
C
I
mean
the
code:
it's
it's
helpful.
What
Morgan
was
going
down,
which
is
identifying
which
one
of
these
is
even
a
viable
short-term
solution
that
doesn't
just
push
down
the
road
people
having
to
make
braking
API
changes
like
which
one
of
these
would
include.
Braking
IV
API
changes,
all
of
them
yeah.
D
So
maybe
maybe
with
first
step
right
now,
is
to
enumerate
all
the
different
options
that
we've
thought
of
and
then
for
each
one
assign
an
owner
to
sort
of
make
sure
that
it's
understandable
by
the
full
group.
But
that
means
you
know
Morgan
show
them
they're
your
PR
or
Carolyn.
You
show
them
a
Google
Doc
with
the
description
of
it
or
whatever,
and
then
for
each
one.
Remember
eight,
you
know
long-term
short-term
impact,
you
know,
does
it
work
now?
This
will
continue
working
go
to
CR
geez.
B
I'd
be
more
than
willing
to
help
on
the
on
the
CRT
shadow
doc,
at
least
for
a
review.
If
you
know
I
mean
I'm,
pretty
sure
I've
done
the
same
thing
but
I'd
like
to
me
take
out
my
slides
and
yeah
I
think
I
have
at
least
some
of
this
thought-out
to
contribute,
but
you
know
definitely
want
to
see
that
and
agree
with
you.
C
Morgan,
would
you
like
to
take
point
then
I'm,
just
kind
of
at
a
high
level
figuring
out
the
pros
and
cons
of
shadow
resourcing
I'm
happy
to
help
with
any
experience
I've
had
with
that,
because
my
favorite
solution
to
be
honest,
considering
I,
think
the
middle
one
maybe
has
the
least
disruptive
a
migration
path.
If
we
do
get
a
good
resolution
out
of
the
working
group.
A
D
C
So,
just
to
make
sure
what
we're
all
doing
I'll
write
up
the
pulling
up
with
numbers
on
this
option.
Three
dates:
good
idea:
option
1
option;
4
all
right
up,
just
very
high-level
one-page.
What
I
would
look
like
for
number
3
and
where
we
would
see
breaking
changes
like
right
now
before
one?
Oh,
if
we
got
a
good
resolution
from
working
group
that
kind
of
stuff
that
sounds
good.
C
B
Yeah,
if
you
wrap
it,
if
you
wrap
it,
if
you
wrap,
you
see
a
lot
around
it.
If
you
wrap
it
yeah,
you
wrap
an
actual
client
around
it.
I'm
sure
the
user
experience
is
fine
as
an
API.
It's
confusing
it's
hot.
It's
kind
of
what
it
should
be
to
be
honest,
because
spec
and
status
shouldn't
be
tied
together,
except
they
should
be
sort
of,
but
yeah
yeah.
C
A
C
F
B
C
B
C
B
B
C
B
B
E
C
B
Mean
I
could
yeah
yeah
I
definitely
want
to
bring
it
back
up
on
Monday.
If
what
is
it
Thursday
now
you
know
is
Monday
a
good
is
soon
enough
for
everybody
to
to
do
a
review
of
what
everybody
is
going
to
write
up
and
then
like.
Can
we
have
the
write-ups
done
by
Monday
yeah,
and
when
can
we
schedule
the
next
one
of
these?