►
From YouTube: Kubernetes SIG Service Catalog 20170807
Description
- Parameters
- Kube names of service classes and plans
- Defaulting plan names for instances
- Broker update semantics
- Broker relist behavior
- Bearer token support
- Scope of first beta release
B
Thanks
everyone
thanks
Paul
all
right,
a
quick
reminder
for
anyone
who
forgot
or
doesn't
know
we're
gonna
do
speaker
queue
like
always.
So
if
you've
got
something,
you
want
to
add
it
at
the
discussion.
Please
type
in
the
chat
+
hand.
I
just
did
a
little
example.
There
I'll
keep
track
of
you
with
my
high
tech,
speaker,
queue,
equipment,
paper
and
pen
and
on
to
the
agenda
for
those
who
don't
have
it.
The
agenda
link
is
in
the
chat.
I
will
not
be
sharing
my
screen
if
someone
else
wants
do.
B
That's
fine,
otherwise,
I
think
that
we're
all
good
everyone
can
view
the
doc
on
their
own
and
see,
updates,
I
and,
finally,
I
will
be
taking
notes
in
the
doc.
So
you
should
be
able
to
see
those
I
was
weak,
come
from
up-to-date
on
the
discussion
and
with
that
I
will
start
with.
You
is
nyle
here.
I
was
not
here,
can
I
get
a
volunteer
to
go,
trying
it
nyle,
Doug
and
Paul
you've
already
pinged
him
Thanks,
so
we're
gonna
move
on
Doug
and
Paul.
B
A
A
I,
don't
think
that
we
should
do
that
until
we
get
a
feedback
from
Sigma
architecture.
We
have
gone
in
circles
on
this
issue
and
I
tried
to
get
some
closure
on
it
today
in
cig
architecture,
and
we
there
wasn't
time
in
the
agenda,
so
I
I
don't
think
it's
productive
to
discuss
any
further
until
we
have
that
good.
All.
B
B
C
Okay,
yeah,
so
I
just
pasted
a
link
hand
already
up
I,
just
nice
little
lincoln's
up
with
chats
with
the
latest
version.
My
proposal,
which
I'd
like
to
I
like
to
go,
avoid
trying
to
talk
about
too
many
things
at
once
with
this
issue.
So
I
want
to
try
to
focus
just
on
what
an
end-user
does
to
create
a
user,
provided
instance,
and
my
latest
proposal
is
basically
from
an
end
user
perspective
exactly
what
they
do
today.
They
specify
user
provided
service
as
the
class
name.
C
C
No,
as
a
first
step,
I'm
perfectly
okay,
with
doing
what
Vela
they
were
suggesting,
which
was
there,
there
is
a
service
class,
called
user
provided
service
or
whatever,
and
we
could
figure
out
whether
there
it
gets
pre-populated
or
redeployed
or
whether
we
still
force
he'll.
Do
it
manually
or
not,
I
think
that's
a
secondary
discussion
so
just
trying
to
fix
the
UX
issues.
I
was
having
around
creating
an
instance.
Okay,.
A
A
B
Let's,
let's
try
to
use
the
hand
system
so
that
we
can
get
complete
thoughts
here.
So
you
know
I'm
finish
my
line
please.
So
let
me
tell
you
guys:
what's
gonna
happen,
so
Paul
I
want
you
to
finish
your
thought.
Doug
I
know
you
have
a
hand
up
so
you're
next
to
the
queue
and
cable
I
have
cables
and
then
V
lay
after
that,
in
order
did
I
miss
anyone's
hand
for
this
discussion
speak
now.
Okay,
Paul,
please
continue
go
ahead.
Okay,
so.
A
The
I
think
I
think
that
what
I
will
do
is
I
will
try
to
address
this
by
way
of
an
alternate
suggestion
and
I
will
try
to
articulate
why
I
think
my
alternate
suggestion
is
better.
Is
that
I
do
not
think
that
it
is
possible
to
do
in
a
kubernetes
way
to
have
special
names
in
an
API
or
special
resources
that
are
populated?
Somehow
during
bootstrap
of
this
component,
here
is
my
alternate
suggestion
is
that
there
should
be
a
union
type.
That
is
the
expresses
where
a
service
instance
comes
from,
and
there
are
two
options.
A
One
option
is
from
a
service
class
and
a
plan
that
is
provided
by
a
broker
a
real
broker.
The
other
option
is
for
a
user
provided
service,
okay
and
I'm,
the
in
the
case
of
a
service
class
and
plan.
This
would
hold
the
coordinates
that
we
eventually
decide
on
whether
those
are
the
open
service
broker,
ID
or
some
other
name
to
address
the
to
address
the
service
class
and
plan.
In
the
case
of
a
user
provided
service,
it
would
hold
a
secret
key
reference
to
where
the
credentials
are
supposed
to
come
from.
A
Based
on
this
particular
combination
of
names,
which
we
do
not
have
an
other
kubernetes
api
resources.
So
that's
my
suggestion
and
I
agree
with
belay
that
we're
at
Holden
rattling
on
this
thing.
We've
gone
around
and
around
on
this
several
times
and
we
don't
seem
to
be
able
to
come
to
a
solution.
So
I
think
that
we
should
try
to
get
some
closure
on
this
issue
and
I.
Also
wonder
whether
people
think
that
this
is
a
requirement
for
the
first
beta
release
and
that's
what
I've
got.
Okay.
B
B
C
The
floor
is
yours,
so
I'm
going
to
repeat
my
proposal.
I
am
NOT
suggesting
any
other
change
other
than
make
plan
optional,
so
they
could,
for
this
particular
use
case,
meaning
when
there
is
just
one
plan
for
a
particular
a
service,
because
I
think
that
was
a
belay
was
suggesting
earlier.
As
of
right
now
we
would
still
register
a
user
provide
a
broker
or
UPS
broker.
Whatever
it's
called,
we
would
still
have
a
UPS
service
class.
Everything
would
still
work,
basically
the
exact
same
way
it
does
today.
The
only
difference
it
is.
C
C
B
Okay,
so
so
Doug
I
want
to
make
sure
I
have
the
summary
of
that
proposal
in
notes.
So
what
I've?
What
I
heard
was
that
the
plan
in
the
incident
should
be
an
optional
field?
You
would
still
register
a
broker
and
still
have
service
classes,
but
in
the
case
of
user-provided
services
there
would
be
no
plans
and
therefore
we
would
not
have
to
rely
on
a
special
words
or
keywords.
In
the
instance
correct.
C
C
We
don't
all
have
to
force
people
to
type
it
in
that
improves
the
usability
quite
a
bit
and
I
think
the
other
aspects
of
this
issue
that
I
raised
in
my
original
issue
about
you
know
why
forcing
people
to
deploy
a
broker
and
stuff
I
think
I'm
willing
to
look
at
that
as
a
secondary
issue
and
I.
Think
belay
had
some
good
suggestions
there.
C
You
know
what,
if
we
can
figure
out
some
way
to
deploy
it
when
you
deploy
the
controllers,
you
know
that
kind
of
stuff,
so
it
you
know
I'm
going
to
look
at
those
are
the
secondary
issues
for
right
now,
I'm
more
focused
on
the
usability
interaction
from
the
user
when
they
go
to
create
that
instance
and
they're.
Doing
something:
that's
unnatural,
meaning
specifying
a
default
plan.
Will
implants
make
no
sense
of
these
guys?
Okay,.
B
D
B
E
So
I
just
want
to
make
sure
that
we
addressing
the
case
of
whether
we
need
it
for
the
beta.
The
answer
is
yes,
because
there
are
plenty
of
use
cases
where
people
want
to
be
able
to
rely
on
legacy
services.
So
so
that's
why
I
think
it's
something
that
we
need.
Second
of
all,
as
far
as
addressing
the,
how
do
we
solve
this
problem?
I
feel
like
the
kind
of
bringing
down
both
especially
the
the
that's.
What
I
was
saying
about
the
rat
holing
is
talking
about
resource
naming
everything
else.
I
really
feel
like.
E
We
need
to
step
back
and
saying
what
are
the
important
reasons
about
these
user
provided
services
for
the
end-user
and
I
firmly
believe
that
the
reason
why
they
should
behave,
act,
look
and
smell
just
like
any
other
service
is
because
the
concept
of
a
service
is
fundamental
to
the
service
catalog
and
if
he
starts,
if
you
start
deviating
from
that
and
saying
like
oh
well,
these
things
behave
differently.
You
have
to
do
something
different
with
them.
I
think
we
have
a
chance
to
go
ahead
and
confuse
the
user.
E
We
have
a
chance
to
go
ahead
and
create
more
work
for
UX
designers
and
so
forth,
and
I
really
have
a
hard
time
understanding.
Why,
like
what
prom
we
have
really
trying
to
solve
by
creating
the
magic
words
in
the
different
places,
because
I
don't
see
the
need
for
it,
we've
been
able
to
go
ahead
and
do
all
kinds
of
interim
temos
with
them
for
a
long
time.
We
have
used
them
internally
for
a
long
time.
E
They
work
really
nicely
because
they
are
exactly
just
like
any
other
broker
and
give
you
give
the
user
a
nice
experience.
Now.
As
far
as
we
talked
about
the
the
defaulting
of
the
plans,
which
would
make
it
more
user,
friendly,
I
would
argue,
that's
going
to
improve
the
system
as
a
whole.
That
has
nothing
to
do
with
user
provided
services.
E
If
there
is
only
one
plan
for
a
sequel
service,
there
is
no
reason
why
we
should
ask
the
user
to
go
ahead
and
specify
that
pair,
so
again,
I
think
having
a
default
behavior
would
make
the
system
perform
better
as
far
as
the
user
is
concerned,
in
any
case.
And
lastly,
if
there
are
multiple
plans,
I
I
thought
the
OSB
spec,
oh,
so
it
might
be
better
to
go
ahead
and
try
to
go
ahead
and
push
into
the
OSP
spec.
If
there's
multiple
ones
to
go
and
say
hey.
E
B
A
B
Plan
on
it's
like
Paul
hold
on
one
sec,
so
I
believe
that
we
can
make
some
progress
here,
albeit
a
little
bit
of
progress
by
stating
that
we
have
consensus
that
we
can
create
an
API,
an
instance
that
specifies
that
you
can
omit
plan.
If
there
is
one
an
exactly
one
single
plan
in
a
service
class.
Does
anybody
disagree
with
just
that
going
once?
B
A
A
F
B
Okay,
so
Jimmy
in
the
interest
of
moving
this
discussion
forward,
I'm
gonna
have
to
continue
with
the
speaker,
queue
and
I
can
talk
to
you
offline
and
help
you
get
it
up
to
speed
on
this
entire
discussion.
So
just
please
ping
me
after
this
meeting
is
over
at
around
2
p.m.
Pacific
and
and
we'll
talk.
Ok,
thanks,
great,
ok!
So
next
up
in
the
queue
I
have
you
Doug
and
by
the
way
Doug
you've.
C
Appreciate
you,
volunteering
me,
that's
cool!
Thank
you.
I
just
raised
my
hand,
basically,
because
you
asked
me
to
to
take
Jimmy's
question,
which
was
you
know.
What
is
the
use
case
or
original
issue
behind
all
this
and
whoops
sorry
thing
dropped
on
my
ear,
so
Jimmy.
If
you
look
at
the
top
of
this
issue
at
the
dish,
you
went
10
10
when
I
was
playing
with
the
walkthrough
Doug.
C
B
Me
let
me
interrupt
for
a
second
yeah,
so
I
I
just
told
Jimmy
that
I
would
be
happy
to
get
him
up
to
speed
after
this
talk
or
after
this
meeting,
would
you
be
willing
to
take
that
over
from
me
and
get
him
up
to
speed
after
the
meeting?
Instead?
Oh
sure,
I
thought
was
a
slight
different
topic,
but
yeah
I'm
perfectly
happy
to
do
that.
Okay,
that'd,
be
great,
so
Jimmy
can
you
link
up
with
Doug
after
this
meeting.
B
You
all
right,
so
we've
got
Martin
and
veal,
a
left
and
a
speaker
queue
since
this
is
the
first
item
that
we've
talked
about
here
and
we
have
five
more
after
this
and
I'd
like
to
get
to
at
least
one
more
of
those
I
would
like
to
limit
the
speaker
queue
to
these
two
people
and
if
anyone
has
reactions
to
what's
the
next
discussion
will
hold.
Please
put
your
hand
up.
B
I
will
get
you
onto
the
queue
Thank
You
Martin
I'll,
get
you
into
the
queue,
but
we're
gonna
move
on
and
then
come
back
to
this
after
we
get
to
the
next
item.
Okay,
so
all
right,
so
we've
got
okay.
We've
got
some
activity
here
so
Martin.
It
looks
like
you
put
your
hands
down
so
then
we've
got
mr.
I
cos
otherwise
known
as
V
lay
you
have
your
hand
up.
So
please
take
the
floor.
B
E
So
so,
instead
of
like
I,
feel
like
there's
a
couple
of
times
as
of
late,
where
we
we
get
together
a
technical
proposal
but
you're
not
particularly
ting
super
clearly
what
problems
we
are
trying
to
solve,
and
it
seems
like
yep
making
good
progress
on
this
issue,
because
we
have
chipping
away
at
very
specific
problems
at
any
given
time.
I
like
the
default,
one
is
a
good
example
and
I
think
it
was
good
to
be
here.
You
made
some
progress
and
bad.
The
second
part
is
sort
of
kind
of
okay.
Well,
what
is
the
problem?
E
The
ups
broker
and
I
know,
for
example,
the
one
thing
we
heard
is
like
well,
the
user
has
to
install
it
again.
I
feel
like.
That
is
something
that
can
be
addressed
in
a
different
manner,
but
it
would
be
good
to
go
and
have
a
list
of
problems
that
we
are
trying
to
solve.
Instead
of
jumping
into
the
solution
right
away,
I
hope,
I
covered
everything
Martin
that
you,
you
are
expecting
to
say,
because
you
just
gave
away
your
hand,
so
you
can
use
that
hand
to
slap
me
later.
You.
A
B
The
user
provided
service
concept
is
just
another
broker
in
some
way,
so
that
the
conceptually
this
model
is
the
same
to
the
implementation
and
to
the
user
as
a
non
user
provided
service
and
also
it
feels
like
you
said
it
feels
like
we're
trying
to
solve
a
lot
of
problems
that
we
haven't
actually
defined
yet
so,
of
course,
we
should
try
to
define
those
problems.
First,
okay,
so
V
lay
did
I,
get
anything
incorrect
or
miss
anything
first
of
all
nope.
That
is
exactly
right.
B
Okay,
great
thing,
I
am
happy
to
report
that
there
are
no
other
hands
up.
I
know
we
still
need
to
make
some
progress
on
this
particular
item
and
we
will,
but
just
not
right
now.
I
would
like
to
move
on
to
the
next
point,
which
is
issue
number
eight
zero
one
broker
updates
semantics,
and
that's
you
Doug,
so
please
take
it
away
just.
C
B
I've
only
found
that,
in
these
notes,
what
I
recorded
is
that
we
only
have
consensus
on
emitting
a
plan.
The
plan
field
from
the
instance
right
there
is
a
single
plan
in
the
service
class.
My
understanding
is
that
we
still
need
to
do
work
on
the
user
provided
service
front
and
also
the
only
action
item
that
we
have
created
out
of
this
item
is
for
you,
Doug,
to
create
an
issue
for
the
plan
to
feel
omission
topic
that
we
just
talked
about.
Okay,.
C
B
B
So
it
sounds
like
you're
satisfied
done
when
you
create
that
issue.
We
can
have
continued
discussion
on
the
issue
if
we
need
to.
We
may
not
need
to
come
back
to
this
point,
then,
which
is
a
good
a
good
thing,
and
with
that,
let's
move
on
to
issue
number
801
and
Doug.
Why
don't
you
explain
what
that
one's
all
about
yeah,
so
this
one
just
hold.
C
C
All
in
a
minute
we're
doing
a
broker
updates
and
plans
have
vanished
basically
and
the
issue
I'm.
Sorry.
The
proposal
talks
about
what
to
do.
I'm,
sorry
when
that
does
when
the
plan
vanishes,
but
when
the
service
vanishes.
So
we
look
at
the
text
here.
Basically,
what
I'm
suggesting
is
that
if
the
plan
vanishes
and
no
one's
using
it,
then
we
just
go
ahead
and
delete
it.
If
the
plan
vanishes,
but
someone
is
using
it,
then
we
mark
it
for
as
inactive
or
Micra
for
deletion.
C
C
Now
you
can't
once
a
service
vanishes
existing
it
uses
of
that
service
can
continue
to
work,
but
you
can't
create
new
ones
and
then
once
those
uses
go
away,
then
the
service
itself
will
eventually
be
deleted
and
I
believe
Paul
was
ok
with
that
proposal
and
he
actually
might
have
gotten
someone
from
Red
Hat
to
start
looking
at.
Actually
implementing
it,
but
then
today
I
realized
that
we
never
actually
I,
don't
think
anyway
talked
about
on
this
call.
B
B
B
C
B
All
right,
the
next
item
up
is
from
me.
This
is
a
proposal
on
the
behavior
and
API
surface
for
relisting
a
broker,
so
that
would
be
triggering
the
controller
manager
of
Service
Catalog
to
do
another
call
to
the
get
v1
API
up
the
v1,
slash
catalog
API.
If
you
look
on
the
dock,
the
original
issue
for
this
is
issue
number
seven,
zero
five
and
the
proposal
that
I
wrote
for
this
is
issue
number
ten
eighty-six.
B
The
proposal
that
I
wrote
is
basically
a
formal
specification
as
a
formalization
in
specification
format
of
the
issue,
which
again
is
number
seven:
zero.
Five,
so
I
see
that
there's
a
ton
of
response
on
the
proposal
number
ten.
Eighty
six
I'm
going
to
open
the
floor.
Sorry
Doug
yeah
me
too
I'm
gonna
open
the
floor.
Here.
We've
got
Paul
with
a
hand
up
so
Paul.
Why
don't
you
take
the
floor?
I'd
like
everybody
else,
to
think
about
your
reactions
to
this
as
well.
B
A
Yeah
I
think
I
think
as
far
as
the
API
surface
for
describing
whether
something
should
be
relisted
manually
or
on
a
duration
and
if,
on
a
duration,
what
the
duration
should
be.
It
sounds
like
we
have
agreement
on
that.
I
talked
to
some
folks
that
are
very
knowledgeable
about
API
mechanics
last
week
about
this
and
the
idea
for
the
the
the
the.
A
Sorry,
I've
completely
lost
my
train
of
thought.
The
idea
for
how
we
should
indicate
that
a
user
had
requested
a
a
manual
realist
was
something
that
there
were
some
suggestions
on
which
I'm
happy
to
go
into
detail
about
now.
I
have
not
had
a
to
write
them
down
in
the
issue
yet,
but
the
takeaway
was
that
so
we
currently
use
these
checksum
things
that
we
calculate
in
the
API
server
to
know
when
we've
reconciled
the
latest
state
of
an
object,
spec
and.
A
That
was
my
brainchild
and
I
learned
something
about
kubernetes
when
I
started
this
discussion
with
these
folks
that
there
is
a
mechanism,
that's
more
conventional.
That
is
a
lot
less
complex,
which
is
that
there
should
be,
or
is
that
the
object,
meta
type
has
a
generation
field
and
we
could
implement
the
semantics
around.
A
However,
you
wanted
that
was
like
the
you
could
either
call
it
the
observed
or
manual
realist
after
some
generation
or
you
could
have
whatever
semantics
you
wanted.
Basically,
just
give
you
something
to
update
when
you
want
it
to
bump
the
generation
which
would
activate
the
controller's
reconciliation
behavior.
So
I
don't
know.
A
B
B
Okay,
now
next
up,
then
we
have
a
lot
of
implementation
detail.
So
Paul's
question
was:
does
anybody
have
questions
on
any
of
the
implementation
stuff,
particularly
around
the
generation
that
he
just
described
so
Doug?
You
have
a
hand
up
before
I
get
to
your
hand,
I
want
to
hear
if
anyone
has
questions
on
the
implementation.
C
All
right,
Doug
your
hands
up
so
take
the
floor.
It's
just
a
quick
question,
the
sink
sub
resource.
What
is
the
actual
type
of
that
sub
resource?
Is
it
just
like
a
boolean
or
something?
And
whenever
someone
tries
to
set
it,
that's
it's
just
the
the
action
of
doing
a
set
on
it
is
the
trigger,
or
what
what's,
going
on
they're,
just
trying
to
understand
how
those.
A
Are
the
semantics
that
I
think
we
had
originally
had
in
mind
I'm,
not
sure
if
we
need
the
sub
resource
anymore
at
all?
Actually,
if
we
move
to
using
a
generation
like
I
described,
we
could
have
a
porcelain
command.
Basically,
just
took
the
value
of
this
field
that
holds
the
that
is
basically
a
marker
for
weather.
Resync
has
been
requested,
and
just
on
that
value
or
flip
it
or
change
it
in
literally
any
way,
and
the
controller
would
do
the
right
thing
so.
C
A
Sorry,
I
clicked
off
of
the
the
window
to
go
to
unmute,
I,
yeah
and
I
mean
the
we
can
project
some
semantics
on
it
right,
so
the
the
if
we
wanted
to
still
want
it
to
do
a
sub
resource.
We
could
have
that
set
that
set
that
field
somehow
based
on
the
current
generation.
But
really
you
could
do
basically
anything.
We
don't
actually
have
a
precedent
for
this.
This
type
of
thing
in
kubernetes
right
now.
C
C
C
Called
sink
got
it:
okay,
that
that
clears
up
what
I
was
trying
to
wonder
about
okay.
So
then
the
other
question
I
had
was
someone
a
k-mer
who
would
made
a
comment
in
the
issue
saying
you
know,
even
if
this
thing
set
up
to
periodically
do
an
update,
they
still
want
the
ability
to
do
a
manual
forcing
of
that
I.
Remember.
C
Thought
someone
else
mentioned
it
I
and
I
and
I
Eckerd
it,
but
anyway
I
think
it's
a
good
requirement,
but
I'm
wondering
are
we
still
going
to
be?
Are
we
gonna
be
able
to
support
that
because
I
remember
in
your
proposals,
I
read
a
long
time
ago
you
talked
about
the
sink
behavior
being
duration
or
manual,
but
I
wasn't
sure
whether
you
allowed
for
the
sink
is
when
you're
on
a
duration
model.
C
B
C
E
E
E
Would
it
mean
that
on
failure
we
would
just
give
up
and
try
again
in
a
week
which
seems
not
exactly
probably
right,
it's
and
then
Misha
papi.
Also,
when
specified
what
would
happen
like
where
we
then
try
five
times
what
we
tried
ten
times,
do
we
do
exponential
back-off
so
forth
and
I
was
a
little
bit
curious
about?
E
B
Cool
so
ve
I
can
address
some
of
my
I
can
say
a
few.
My
thoughts
take
off
my
my
impartial
facilitator
hat
for
now.
I
didn't
write
this
in
the
proposal.
Obviously
one
thing
that
I
thought
was:
we
keep
the
existing
mechanism
for
error
reporting
and
the
existing
mechanism
for
retry,
so
the
existing
mechanism
for
error
reporting
would
be
in
the
condition
and
I
actually
don't
know
for
sure
if
the
existing
mechanism
for
retry
exists,
but
my
thought
was
exponential
back-off,
and
that
is
all
for
me
to
put
my
hat
back
on.
E
Ahead,
villi,
no
I
was
gonna,
say
yeah,
I,
think
I
I
think
that's,
that's
that's
fine
and
I
mean
they
seem
yeah
I
mean
yeah
exponential
back-off,
and
things
like
this
seem
like
pretty
standard
stuff.
I
just
want
to
get
them
explicitly,
typed
in
just
so
that
a
broker
writer,
for
example,
can
reason
about
the
state
of
the
system
at
any
given
time
I.
E
E
Because
if
we
clear
the
status
field,
then
I
think
we
have
no
way
of
knowing
what
state
the
broker
is
currently
in,
except
maybe,
for
example,
you
know
syncing
or
whatnot,
so
I,
just
I,
I
I,
just
don't
get
those
details
nailed
down
on
what
happens
in
those
cases
and
I
think
they
should
basically
get
them
into
a
into
that
proposal.
Okay,.
B
So
I
have
put
an
action
in
for
myself
VLA
to
tighten
up
wording
about
the
following
error:
reporting:
how
we're
gonna
do
retries
on
duration
errors
and
then
also?
What
are
we
gonna
do
about
failed,
resyncs
after
I?
Do
that
tightening
up
then
I
will
re.
Add
this
discussion
item
to
a
future
meeting?
Is
that
acceptable
to
you.
A
Okay,
so
just
want
to
note
for
the
record
that
the
proposals
basically
a
write
up
of
a
comment
that
I
originally
wrote
up
and
want
to
express
my
original
intent
and
then
offer
some
details
about
the
behavior.
The
controller
that
can
help
make
this
more
explicit
in
the
proposal.
So
I
think
that
if
there
is
a
manual
a
way
to
indicate
that
you
want
manual
only
resync
that
the
however
you,
however,
we
allow
you
to
do
that.
A
Secondly,
the
as
far
as
the
semantics
regarding
the
question
that
I
saw
in
the
chat
about
is
this:
is
the
interval
between
the
last
time
the
controller
looked
at
it
or
the
last
time
it
was
successfully
reconciled
to
answer
that
question.
The
current
interval
is,
from
the
last
successful
reconciliation
of
a
broker.
A
So
that
means
that
if
on
Monday
I
try
to
do
it
and
I
can't
do
it
and
I
keep
retrying
and
I'll
talk
about
the
retry
semantics
in
a
moment
and
I
don't
and
I
and
I
don't
I'm
not
able
to
successfully
do
it
until
Tuesday
and
my
interval
is
one
week
next
Tuesday
I'm
gonna
I'm
gonna.
Do
it
not
next
Monday,
so
last
point
D
on.
A
Exponential
back-off,
the
current
retry,
that
the
controller
implements
is
an
exponential
back-off
one.
So
that's
currently
what's
implemented
today,
we
won't
have
any
code
changes
required
for
that
facet
to
do
exponential
back-off.
I
think
it's
appropriate
in
this
case
and
then
actually
one
last
bonus
facet,
which
I
thought
of
while
I've
been
talking,
is
that
currently
what
happens?
If
you
have
a
successful
reconcile
against
the
broker,
and
then
you
go
to
do
it
again
and
it
doesn't
work
you
get
in
there
is
the
can.
A
The
ready
condition
becomes
false,
I'm
sorry,
the
ready
condition
takes
on
a
false
status
and
there's
some
kind
of
error
message.
I
think
it
would
be
sufficient
to
make
sure
that
that
error
message
in
the
ready
condition
says
there
was
a
problem.
The
last
time
we
tried
to
reconcile
this
broker
and
were
currently
retrying
similar
to
what
we
do
for
other
things
like
this
and
that's
what
I've
got
uf.
B
Okay,
Paul,
would
you
mind
writing
in
the
notes,
at
least
the
last
point
you
talked
about,
which
is
the
that
new
ready
condition
that
says
we
were
successful
before
we
just
failed
now
we're
gonna
keep
trying
and
I'm
gonna
focus
on
moving
on
with
the
Q
Jimmy
I
put
your
hand
up
for
you.
My
intention
was
for
you
to
verbalize
the
long
ish
comment
that
you
put
in
the
chat
and,
of
course,
to
add
anything
else
that
you
have
shared
at
the
floor.
B
F
Basically,
I
can
echo
agreement
with
everything
that
Paul
just
said
in
that
I've
worked
on
a
previous
project
Claire
if
you're
familiar
list,
so
is
a
vulnerability
like
senic
analysis
tool
for
container
images,
and
it
does
time-based
updates
to
vulnerability
like
CV
tracking
databases
and
that
worked
very
similar
to
how
we
are
describing.
There's
a
timer
there's
simply
like
the
last
update
time,
and
you
have
a
bunch
of
different
instances
and
they
try
to
basically
grab
a
lock.
F
If
they're
passed
what
configuration
they
need
to
be
from
last
successful
team
once
they
take
down,
then
they'll
proceed
you
to
do
an
update
and
then
update
that
last
successful
update
and
if
they
failed
and
immediately
I
couldn't,
after
sleeping
for
a
short
amount
of
time.
So
while
they're
little
instruments
will
come
back
up
and
retry
and
we
have
exponential
back-off,
essentially
on
individual
instances
and
not
a
whole
cluster,
we're
just
just
interesting
to
think
about
it
as
well.
But
we
found
this
to
be
a
successful
model
in
terms
of
doing
that.
F
I
guess,
like
a
version
that
is
essentially
I'll,
get
checked
some
of
the
current
state
of
the
catalog
right.
So
if
the
cattle
unchanged
in
the
broker
that
it
was
offering
like
to
remove
or
change
something
I
wouldn't
need,
you
know
rather
than
link
them,
then
you
can
definitely
avoid
creating
something
immediately.
That's
inactive!
F
B
B
C
Yeah
so
so,
though,
a
lot
of
obviously
things
discussed
here
of
first
of
all,
the
the
checksum
versus
generation
stuff.
If
we're
going
to
head
that
direction,
I
think
we
need
another
issue
to
replace
checksum
and
all
the
other
resources
that
are
currently
using
it
so
that
we're
consistent
across
our
resources
do
I.
Have
that
right,
I
think
so
right,
because
we
want
to
be
consistent.
Okay,
I
see
Paula,
not
even
Ted,
so
yeah
okay.
So
we
should
probably
open
up
an
issue
for
that
and
get
to
change.
They
replace
Allison
I'm.
B
C
It
excellent
so
that's
1095,
okay,
cool
yeah
nevermind,
then
that
issue
already
have
it,
because
the
reason
I
wanted
it
was
because
I
thought
that'd
be
good
learning
exercise
to
make
sure
we
actually
do
want
to
use
it
on
this
one
as
well.
So
that's
all
good.
The
other
reason
I
raised
my
hand,
was
I
feel
like
during
this
discussion.
We
brought
up
a
lot
of
other
possible
tweaks
to
it.
I
know
Aaron
and
notes
you
added
some
additional
things
that
you
wanted
to
quote.
Tighten
up
or
add
language
about.
C
C
I'd
like
to
get
a
definitive
answer
before
we
get
final
agreement
on
the
proposal,
even
though
I
think
in
general,
everybody
has
agreed
with
the
general
direction
and
I
would
just
like
to
put
in
my
hand
and
vote
for
between
the
two
I
would
prefer
a
sink
sub
resource
because
I
kind
of
view
Generation
as
an
internal
processing
type
of
field.
That
I
don't
think
we
should
expect
the
user
to
muck
with
that's
my
current
take
on
anyway,
but
I'm
willing
to
be
convinced
with
otherwise
or
a
different
opinion.
So.
B
B
A
Okay,
so
I'm
documented
everything
that
I
said
earlier:
Jimmy
I
think
you.
You
have
brought
up
the
idea
of
doing
a
realist
before
responding
to
a
provision
request
and
I.
We
discussed
that
before
I.
Don't
think,
I
think
that
I
want
to
make
sure
that
I
understand
the
motivation.
Is
that
so
that
you
can't
bind
to
a
service?
That's
disabled,
I'm,
sorry,
camp
provision,
the
service,
that's
disabled,
yeah,.
E
A
F
B
I'll,
let
you
talk
just
once
again,
so
we
have
one
more
person
in
speaker
queue
or
one
minute
over
time.
If
you
need
to
leave
totally
cool,
we
won't
make
any
more
decisions
today.
This
is
gonna,
be
a
purely
discussion
from
here
on
out
paalam
and
let
you
continue
and
then
viele
I'll
get
to
you.
Thank
you
after
this
discussion
is
over
sorry
for
the
eruption.
Paul.
Please
continue.
I.
A
Accept
your
apology,
Aaron.
So
that's
an
interesting
idea,
Jimmy,
but
it's
different
than
what
you
initially
described,
which
is
that
you
would
do
a
an
eager
realist
before
responding
to
a
provision
request.
Tennis
card
yeah
I.
Think
that
that's
an
that
is
an
interesting
idea
and
I
think
perhaps
you
it
would
be
productive
if
you
wrote
that
up
as
a
separate
thing,
I
think
that
would
be
a
lot
more
doable
than
to
do
a
realist
before
every
provision
requests
is.
F
B
E
You're
laughs
but
not
least,
let
me
go
ahead
yeah!
Well,
let
me
look
at
this.
I
guess
was
oh
yeah.
It
was
basically
just
trying
to
be
couple
the
generation
use
from
this
particular
issue.
So
if
we
can
go
and
find
a
way
to
go
and
say
yes,
there
will
be
a
way
to
understand
what
the
last
reconcile
point
was.
If
we
can
go
and
say
that
should
be
a
generation
is,
is
the
proper
method
to
do
it
in
kubernetes?
Then
it
might
make
the
issue
easier
here.