►
From YouTube: Kubernetes SIG Service Catalog 20161207
Description
SIG service catalog continues API discussions around unbind and finalization of API resources
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
Hello,
everybody
and
welcome
to
the
Wednesday
to
sever
December,
7
2016,
meeting
of
cigs
Service
Catalog.
Today
we're
going
to
be
talking
about
unbind
and
all
of
the
all
of
the
nitty
gritty
details
that
we
can
get
our
clammy
cold,
but
somehow
wet
hands
on
regarding
unbind.
So
I'm
gonna
point
this
at
the
board:
you're,
actually
not
in
the
way,
then,
but
that's
alright.
So
now
my
question
to
the
group
is
where
we
would
leave
what
we
like
to
pick
this
up.
A
A
So
what
oh
and
it's
it's
Paul?
Well
hello,
Paul!
While
how
are
you
so
now
that
we
have
this
binding
resource?
The
typical
way,
the
precedent
in
Coober
Nettie's
along
indicating
that
you
no
longer
want
to
use
something
as
you
delete
it,
and
since
we
can't
we
have
to
ensure
that
after
the
API
server
is
has
gotten
that
delete
request
that
we
still
have
something
to
reconcile
on.
We
have
this
pattern
in
urban
Eddie's
called
finalization,
and
what
it
means
is
basically
that
the
API
server
accepts
the
delete
request
and
I
I.
A
Actually,
here's
where
I
realize
now
that
my
what
I
have
written
on
github
on
this
is
imperfect,
forget
what
is
written
on
github,
and
I
will
just
tell
you
now,
I
think
finalization
and
anybody
that
can
correct
me
on
this.
Please
please
do
so
now
is
driven
off
the
presence
of
a
deletion
timestamp
on
an
object.
So
what
this
means
is
basically
it
gives
us
a
chance
to
do
some
other
actions
before
the
delete
is
completed
and
the
the
pattern
goes
like
this.
So
I'm,
the
there's
me
what's
just
like
me:
I'm
a
service.
A
What
happens
inside
the
API
server
is
at
the
rest
api,
for
this
puts
the
deletion
timestamp
on
the
object,
but
doesn't
actually
delete
it.
So
I'm
just
going
to
put
a
little
asterisk
here
to
indicate
that
that's
been
changed,
I'm
going
to
widen
this
just
a
little
bit,
so
we
know
controllers
in
here
too,
and
the
controller
gets
a
watch
event
for
this
and
says
AHA.
A
The
deletion
timestamp
is
set,
I
need
to
go
and
finalize
this
resource,
but
before
we
talk
about
what
finalization
means
here
like
what
actions
we
take,
I
want
to
call
out
the
reason
that
we
do
this
finalization
pattern.
This
way,
instead
of
just
deleting
the
resource
and
relying
on
controller
observing
a
watch
event
is
that,
like
we
have
to
assume
that
watch
event
channel
is
lossy
and
assume
that
we're
gonna
miss
events
and
without
getting
into
too
much
detail
on
the
subject.
A
This
is
why
controllers
and
Cooper
Nettie's,
in
addition
to
the
watch
events
that
they
get
from
the
API
server,
also
have
a
periodic
sync
loop,
where
they
reconcile
the
entire
state
of
the
world,
and
it's
because
you
might
miss
a
watch
event.
In
fact,
the
the
Cooper
Nettie's
watch
API
implementation,
terminates
HTTP
connections.
After
think,
it's
five
minutes
and
you
will
not
get
a
long-lived
watch.
You
just
won't
you'll.
A
C
A
B
Guess
just
clarifying
I
thought
there
was
a
way,
and
maybe
he
said
this
in
different
words,
but
I
thought
there
was
a
way
to
go
and
specify
like
a
version
stamp
or
some
like
that.
So
let
me
do
a
list.
You
get
back
like
a
version
or
something
like
that,
and
then
then
many
call
watches
you
would
be
able
to
say.
Okay,
give
me
any
new
events
after
this
point.
There
is.
A
And
so
the
field
you're
thinking
of
is
called
resource
version
yeah.
It's
like
it's
a
monotonically
increasing
a
counter,
basically
across
all
of
the
API
and
what
you
can
do
is
you
can
window
your
watch
that
way,
so
you
can
establish
the
event
that
you
start
getting
watches
from,
but
the
and
then
I
think
there's
a
deep
distrust
within
the
Cooper
Nettie's
community
of
such
mechanisms,
and
so
you
I
have
found
that
the
realists,
an
initial
list
like
the
pattern,
is
list
and
watch
I'm.
A
D
Yep
we've
clean
that
if
you
list
sorry,
if
you
start
a
watch
from
a
resource
version,
that's
too
old.
You
won't
get
all
the
watch
events
since
that
I
believe
it's
because
of
the
events.
Cash
has
been
that
it's
been
partially
evicted
and
I.
Think
it's
because
they
use
an
LRU
mechanism.
But
don't
quote
me
on
that
because
I
looked
at
it
last
week
and
that
feels
like
three
years
ago,
if.
A
Continuing
down
the
path
of
discussion
about
finalization,
so
there's
there's
one
major
thing
that
we've
already
covered
the
territory,
but
we
didn't
call
it
out-
is
that
in
order
to
implement
this,
you
need
control
over
the
rest
implementation
of
the
resource
that
you
want
to
do
finalization
on,
and
this
is
where
we
get
back
into
like.
There
is
a
need
to
have
our
own
API
server.
So
we
can
control
these
details.
There
is
finalization
40
PRS,
but
I.
D
To
add
one
thing
about
a
tpr
based
implementation:
that
would
be
that
a
user
that
wanted
to
unbind
would
have
to
not
do
a
cuke
CTL
delete,
but
instead
we
put
basically
do
a
cube,
CTL
edit
and
add
the
deletion
timestamp
and
potentially
a
list
of
finalized
errs.
If
that's
the
way
we're
going
to
go.
So
it's
a
little
bit
non-intuitive
to
do
a
unbind
operation,
but
not
do
cube.
Ctl
delete
on
that
tpr
mm-hmm.
A
A
A
A
There
is
a
list
in
the
spec
and
I
think
there
might
be
a
I
started,
making
a
pull
request
to
add
that
to
the
binding,
in
instance,
resources
but
I
was
enlightened
and
made
aware
the
fact
that
there's
now
a
object,
meta
based
mechanism,
that's
just
part
of
the
object,
metairie
sort
or
object,
meta,
API
type
that
we
can
use
for
this.
But
the
crux
of
it
is
that
there's
a
list
of
finalized
errs
and
as
those
finalized
errs
act,
they
remove
themselves
from
the
list
and.
A
A
Good
question
Doug,
so
the
way
that
that
works
in
Coober
Nettie's
is
that
there
is
an
emission
controller
that
adds
a
finalizer
to
namespaces,
I
and
I
believe
other
actually
I'm.
Sorry
in
Coober
Nettie's,
one
of
the
defaults
for
namespaces
is
to
add
the
finalizer
I
believe
for
other
resource
types
that
use
finalization.
There
are
also
defaults
that
add
them
in
systems
that
consume
Cooper,
Nettie's
and
layer.
On
top
of
it
like
open
shift.
C
That's
good
information,
but
that's
not
quite
what
I
asked.
I
was
wondering
if
I
were
to
actually
look
at
the
resource
itself.
What
does
that
list
of
finalised
look
like?
Are
they
identified
by
name
some
ID
with
hello,
how
they
actually
stored
in
the
resource
they're
stored
as
list
of
names?
Okay,
so
they're
just
names
that
are
known
to
the
controller
I
guess
yes,.
A
A
D
Me
figure
out
how
software
works.
Okay,
can
everybody
see
that
yep
yep
okay?
So
this
is
a
obviously
a
snippet
from
a
manifest
file
taken
roughly
from
the
tpr
finalized
errs
examples
that
Kent
and
I
basically
packed
up
and
found
that
they
didn't
work
for
TP
ours.
So
the
list
here
finalized
errs,
is
what
we
we
manually
cube.
Ctl
created
the
list
with
something
de
estado
/a
and
/
be,
but
we
also
noticed,
as
Paul
said,
that
some
of
mission
controllers
will
add
the
KU
benetti's
default
value
and
I
think
there
are
others
as
well.
D
So
as
we
went,
we
would
cube
CTL
edit,
the
GPR
take
off
this
one
and
it
would
still
be
there
and
then
after
we
took
this
one
out,
the
thing
would
be
deleted
and
the
deletion
timestamp
would
stay
static
throughout
the
entire
process,
from
when
we
initially
cube
CTL
deleted.
Until
we
remove
the
final
element
in
this
list
of
finalized
errs,
at
which
point,
of
course
the
thing
would
cease
to
exist.
A
A
C
Nope,
that
makes
perfect
sense,
and
is
it
correct
to
assume
that
it
really
is
usually
the
the
resources
controller
that
does
the
final
deletion
of
the
resource
itself.
So
he's
the
one
that
the
text,
all
the
other
finalizes
are
gone
or
have
you
seen
cases
where
some
other
controllers
actually
responsible
for
that
I.
A
Think
it
I
believe
it
varies,
and
it
I
think
in
this
case
it's
sufficient.
Just
that
our
controller,
do
it
I
need
to
think
through
additional
ability
is
that
I
haven't
bothered
thinking
through,
because
I
I
tend
to
think
based
on
what
the
next
thing
is
based
on
what
the
group
is
accepted
and
I
just
haven't
gotten
that
far
okay.
A
Cool
okay,
so
in
this
case
what
the
finalizer
will
do
is
it
will
go
and
delete
the
resources
that
have
been
created
in
Cooper
Nettie's.
So
it
will
do
two
things
and
I'm
not
sure
about
the
ordering
of
them.
Perhaps
we
can
get
some
ideas
floating
around,
but
they're.
Fundamentally,
there's
two
categories
of
things
that
have
to
happen.
D
Think
there's
two
ways
that
we
can
go.
Paul
I
wanted
to
add
one
piece
sure
so
ordering
notwithstanding
I
haven't
thought
through
the
ordering,
but
at
some
point
before
the
real
delete
happens,
I
think
we'll
need
to
remove
the
finally
last
finalizer
from
the
list
and
then
the
thing
that's
watching
the
list
of
finalized
errs:
do
the
delete
the
real
delete,
yeah.
A
A
And
and
I
there's
a
we
might
decide
that,
since
there
are
categorically
two
types
of
things
that
have
to
happen,
that
we
can
make
two
different
finalize
errs.
We
can
have
a
coup
burn,
a
t-score
finalizar
and
a
broker
API
finalizer
that
both
have
to
run.
But
Aaron
is
exactly
right,
as
actors
in
the
system
implement.
These
finalize
errs.
They
need
to
the
pattern.
Is
you
do
your
work?
B
B
B
If
I
put
a
secret
in
there
and
ask
Cooper
Navy's
to
delete
this
object
by
setting
a
time
stamp,
one
behavior
could
be
that
Cooper
Navy's
looks
at
it
and
says
OMG
this.
This
object
needs
to
be
deleted
and
its
dependencies
other
object,
I
complete
that
object,
and
then
you
know
by
a
recursion
it
could
basically
delete
whatever
that
depends
if
it
needs
to
delete
that
I.
A
A
So
we
delete
the
binding,
we
get
a
tua
to
back
deletion.
Time
stamp
set
on
binding
controller
sees
this
controller
goes
and
say
for
this
example.
It
does
the
deeper
bit
I'm,
sorry,
the
unbind
at
the
broker
level
and
then
so
I
papa
frame
out
the
stack.
There's
two
things
in
the
finalizer
Lister's
broker,
finalizing
Cooper,
Nettie,
skoura,
finalized
broker
finalize
or
does
the
unbind
of
the
broker
updates
that
to
take
its
name
out
of
the
list
and
when
I
say
broker,
finalizar
I
mean
controller
and
then
the.
A
Sorry
distracted,
then
the
the
controller
goes
to
final.
I
implement
the
cooper
Nettie's
core
finalizer.
It
deletes
the
secret
and
say
that
the
secret
is
is
just
deleted,
which
I
don't
think
there's
any
finalization
on
secrets
at
this
moment,
so
secret
just
gets
deleted
and
then
it's
and
then
controller
can
take
a
controller,
can
take
its
banker.
Burnet
ease
poor
finalizar
out
of
the
list
and
do
the
final
believe
does
that
clarify
things.
F
C
I
have
a
question
for
you
and
if
it's
too
low
level
of
detail
at
this
point
in
time
to
stop
me,
but
I
am
kind
of
curious
about
how
people
don't
wear
this
in
the
past.
Do
people
normally
have
the
controller
watching
the
resource
they
notice
the
delete
and
then
what
they'll
do
is
they'll
they'll,
look
at
obviously
delete.
Timestamp
is
set
and
say:
they've
noticed
there
are
three
finalizer
there.
Is
it
basically
just
a
switch
statement
that
says?
Okay,
there
are
three
finalized
errs.
C
Therefore,
I'm
going
to
go
off
and
asynchronously
or
potentially
asynchronously
take
some
action
and
then
the
controller
is
kind
of
out
of
the
picture,
and
then,
when
that
finally
gets
removed
on
another
watch,
event
happens
and
this
time
I'll
say:
oh
there's
only
two
finalizar,
so
much
switch
damage,
jump
to
a
different
spot
and
now
I'm
going
to
take
this.
This
other
action
or
there's
some
other
pattern
that
we
should
be
aware
of.
So.
A
Yes,
that's
true!
So
going
back
to
the
namespace,
the
namespace
implementation
in
open
shift,
we
have
other
resources
that
have
to
be
finalized
to
fully
delete
a
namespace,
so
I
believe
the
behavior
is
that
the
name
space
controller
is
like
I'm
gonna
go
I'm
going
to
let
everybody
else
go
first
and
when
it's
just
me,
then
I'm
going
to
do
my
thing
and
during
the
everybody
else
goes
first
phase,
there's
a
controller,
an
open
shift.
That
is.
A
Watching
the
namespace
resource
and
saying
I
need
to
I
need
to
finalize
this
thing
now,
I'm
going
to
go
and
delete
all
the
open
shift,
specific
names,
a
bunch
of
specific
resources
and
then
I'm
going
to
take
the
open
shift
finalizar
out
of
the
list,
after
which,
in
the
context
of
open
shift,
the
only
one
left
is
the
core
finalizar
and
then
the
core
namespace
controller
acts.
Does
that
make
sense?
A
G
C
A
A
We
can
talk
about
d
provision
next,
which
might
be
a
good
thing
to
do,
or
we
can
talk
about
some
aspects
of
API
server.
My
gut
leans
to
wear.
Let's
talk
about
deep,
because
if
we
all
understand
finalizer
pattern,
the
provision
has
some
other
things
that
other
details
like
cascading
deletes
that
we
should
talk.
I.
A
A
A
What
a?
What
are
people's
feelings
on
cascading,
delete
and
I
will
say
as
I
asked
that
question
that
and
maybe
Brennan
you
can
answer
this.
The
cloud
foundry
docs
on
the
current
API
are
a
bit
ambiguous
on
the
subject.
I've
read
both
that
it
is
not
allowed
to
D
provision
an
instance
that
has
findings
against
it
and
that
if
you
d
provision
an
instance,
there
may
be
orphaned
bindings.
A
A
So
I
think
the
right
behavior
is
to
do
a
cascading
delete,
because
it
sounds
to
me
like
if
I've
d
provisioned,
in
instance,
of
a
service
class
that
I
should
not
expect
the
manifestations
of
bindings
that
may
be
orphaned
to
still
work.
I,
don't
want
to
leave
them
around
if
they're
not
going
to
work
well,.
C
Obviously,
but
it
seems
to
me
that
we
should
walk
through
that
scenario.
The
cats
came
to
leak
is
worst
case
scenario,
Shannon
comes
back
and
says
no
wheel,
allow
you
to
do
the
gleet,
and
so
okay,
we
just
ban
it,
but
at
least
we've
gone
through
the
discussion
of
what
it
means
and
community
to
do.
A
cat
scan
delete.
Yes,.
A
G
State
up,
if
I,
try
and
delete
this
and
their
findings,
you
get
forgotten,
and
then
you
have
to
explicitly
say:
yeah
I
want
to
delete
this
and
either
orphan
the
bindings
or
delete
plumbing
click.
The
default
state
should
not
be
item
instance
and
boil
away
other
people's
stuff
or
working
on
the
people's
stuff.
A
A
A
B
A
C
G
D
That
was
my
understanding
too
well.
That
was
my
assumption
of
where
we
were
going
here
so
always
return
to
2accepted,
with
the
understanding
that
the
instance
has
been
marked
for
finalization
and
where
finalization
is
defined
as
complete
when
all
of
the
bindings
have
been
deleted,
but
not
necessarily
cascading
delete
those
bindings.
So.
E
Are
you
really
sure
you
want
to
delete
it
and
then
I
have
to
say:
I
really
mean
it
I
need
this
thing
to
be
gone,
whereas
if
you
do
the
soft
believe
it's
up
to
consumers
of
your
thing
to
go
clean
themselves
up
and
then
you
will
be
able
to
be
deleted,
it
puts
you
the
person
so
put
it
this
way.
So
it's
saying
I'm
running
in
a
page
here
and
paying
for
these
services
to
run
and
then
oki
work
to
confirm
if
suddenly
I'm
out
of
money,
I
got
shut.
E
D
B
G
Share
that
with
the
group,
this
almost
all
the
options
that
I'm
hearing
so
far
so
think
I've
heard
Bella
found
with
an
additional.
You
can
force
cascade
deletion
to
happen.
I
heard
softly
Paisley
marks
the
services
essentially
deprecated,
and
then
you
kind
of
wait
for
all
the
bindings
to
go
away
and
then
delete
the
instance.
G
G
G
A
C
But
wait
a
minute,
though,
is
that
is
that,
true,
because
the
bindings
are
owned
by
the
person
who's
running
the
app
right,
which
may
not
necessarily
be
in
the
same
namespace
as
the
instance
so
depends
on
how
far
the
Delete
goes.
If
the
leak
doesn't,
I
should
delete
the
bindings
regulate,
but
at
least
other
stuff
and.
E
G
G
A
G
D
Are
you
guys
saying
I,
don't
know
everyone's
name
in
that
room?
Apologies!
So
I'm
gonna
refer
you
guys.
It's
you
guys
for
now,
Upsy
you
guys
saying:
there's
a
requirement
to
do
hard,
delete,
delete
everything
immediately
and
deeper
vision,
but
there's
also
a
requirement
to
effectively.
Like
you
said,
someone
there
said
have
a
ref
count,
so
you
can
tell
who
you're
forcing
to
delete
bindings
of.
Is
that
what
I'm
hearing
you.
D
A
B
C
Iii
think
we
have
to
assume
that
has
to
be
some
way
to
get
some
information
to
at
least
notify
someone
else
that
they're
there
instance
is
about
to
be
deleted.
I
I
understand
the
security
concern,
but
if
that
security
concern
is
that
real,
then
you
probably
wouldn't
let
them
link
to
your
instance
anyway,
you
have
to,
as
an
owner
of
an
instance,
I
have
to
be
able
to
know
who's
using
my
instance
yeah.
D
C
A
G
It
is
probably
not
the
right
answer
to
say
we
can
just
how
all
the
options,
but
these
are
not
mutually
exclusive.
You
could
have
all
three
of
those
be
options
together.
Right,
you
can
say:
I
want
to
fail
if
it's
bound,
I
want
to
market
for
soft
deletion
and
I
want
to
be
able
to
force
destined.
So
you
don't
have
to
make
this
decision
now.
They
should
probably
all
be
considered
on
the
table.
G
A
A
C
A
Me
cascade
from
instance,
level
means
your
instant.
Your
bindings
get
deleted,
normal
unbind
happens
for
those.
So
really,
this
is
not
an
aspect
of
D
provision.
It's
an
aspect
of
unbind
right.
So
what
happens
when
you
unbind-
and
you
have
a
you-
have
a
pot,
that's
using
a
secret
is
in
this
is
just
based
on
my
understanding,
which
actually
I
had
a
user
complaining
to
me
about
this
yesterday
and
so
I
think
there
may
be
a
bug
that
we
go
fix.
A
What
should
happen
is
like
it
if
you
so
there's
a
few
different
layers
right
just
from
a
pod
standpoint.
It
means
that
the
next
time,
the
eventually
consistent
volume
plugin
goes
to
run
it'll
say:
oh
crap
I
can't
get
the
secret
so
I'm
going
to
bail
out
on
and
you're
kind
of
left
with,
where
you're
at
for
environment
secrets
that
are
consumed
in
the
pods
environment.
We
have
no
mechanisms
in
place
to
update
those
pods
based
on
anything
that
happens
to
the
secret,
so
nothing
happens.
C
I
think
I
understand
that
little
whatever
I
wasn't
sure
on
what
you
just
said
is:
let's
remove
everything
that
we're
doing
from
the
picture.
Let's
say:
I
have
a
pod
and
I
have
a
secret
mouth
fit
into
their.
If
I
delete
the
secret
am
I
allowed
to
and
what
happens
to
that
pod?
Assuming
it's
not
been
restarted,
its
it's
still
running
is
the
volume
will
are
accessible
to
me.
What
happens
so.