►
From YouTube: Kubernetes SIG Service Catalog 20170830
Description
- Define limits of work (ie, how long controller will retry)
- Block updates to resources while controller is doing work
A
Hello
welcome
everybody
to
be
Wednesday,
August
30th,
meeting
of
kubernetes
service,
catalog,
I'm
gonna
turn
it
over
to
Aaron
since
he's
elected
to
join
us
today,
and
maybe
if
we
have
an
a
volunteer
to
take
notes
or
to
end
or
to
share
their
screen
with
the
agenda,
that
would
be
fantastic.
If
not
I
will
share
my
screen
but
I
suck
at
taking
notes.
Even
when
I'm
not
talking.
B
Yeah,
so
can
everybody
hear
me,
can
anybody
not
hear
me
cool
all
right,
yeah,
I'm,
gonna,
take
notes
today,
George
couldn't
be
with
us,
so
someone
I
need
just
a
volunteer
to
share
their
screen.
That'd
be
great
as
usual.
Well,
first
of
all,
thanks
to
everyone
for
running
the
meeting
yesterday,
my
absence
appreciate
that
I'm
gonna
do
the
speaker
queue
again
with
my
new
and
improved
high
tech.
Speaker
queue
technology.
B
So
just
again,
as
you
guys
all
know,
if
you
have
something
you
want
to
say
just
put:
what
did
we
use
to
do
plus
Q
or
something
like
that
Oh
plus
hand?
Excuse
me
put
plus
hand
in
the
chat
and
we'll
add
you
the
end.
The
speak
you
so
with
that.
Can
anybody
share
their
screen
just
share
I'll,
take
notes.
B
C
B
B
B
D
Don't
don't
sweat
that
so
I
have
a
proposal
for
defining
limits
of
work.
We're
currently
the
controller
doesn't
behave
very
well
to
in
the
in
the
presence
of
communication
errors
with
a
broker
as
far
as
just
stopping
retries,
because
of
the
way
that
realists
happen
from
the
API
server
so
right
now,
retry
information
is
all
stored
in
the
worker
hue
in
the
controller
and
when
realists
come
in
or
if
the
controller
restarts,
then
all
that
information
is
lost.
B
C
But
everything
that
sounds
fine
I'm,
assuming
that's
upon,
marking
the
the
resources
being
in
a
failed
States
you're,
also
going
to
undo
whatever
mechanism
we
decide
on
that
blocks,
concurrent
updates
or
blocks
further
updates.
So,
for
example,
in
paws
proposal
he
had
the
the
presence
of
an
operation
string.
Being
that
being
said
that
the
flag,
we
hope,
you'll
clear,
that
out
or
we
decide
to
be
something
else-
you'll
undo
whatever
we
did
to
block
current
updates.
I
assume
right.
D
A
I
agree:
when
you
stop
doing
work,
I
think
you
have
to
do
the
following
things:
you
have
to
update
the
reconciled
generation
with
the
current
generation.
I
think
you
also
have
to
set
the
failure
condition
like
we're
doing
now,
for
if
the
worker
says
hey,
this
failed
I
think
you
should
set
that
same
condition
and
I
had
actually
forgotten.
When
I
wrote
up
the
other
thing
that
we
talked
about
the
blocking
behavior
being
based
on
reconciled
generation
and
current
generation
not
not
being
the
same.
B
Alright,
so
I
hear
consensus,
I
don't
think
I
have
a
hundred
percent
of
it
is
at
least
part
of
it.
I
think
that
we
do
need
to
eventually
quit
when
the
broker
says,
there's
a
termination
condition
we
need
to
set
a
new
status
accordingly,
we
need
to
update
the
reconciled
generation
accordingly
and
that's
all
I
know
of
so
what
am
I
missing
here?
I.
A
A
B
All
right,
so,
let
me
read
out
loud
here:
consensus
we
are
gonna.
Have
the
controller
quit
doing
work
after
a
broker
responds
with
a
failure
that
represents
a
termination
condition
when
that
happens,
we're
gonna
update
the
reconciled
condition,
set
the
failure,
condition
appropriately
and
finally
set
the
ready
condition
appropriately.
D
B
A
So
sometimes
mine
will
get
jacked
up
by
something
I
can't
control
anyway,
so
we
agreed
in
face
to
face
hey
Paul.
Could
you
increase
the
font
yeah,
so
we
had
agreed
in
the
face-to-face
that
will,
in
order
to
deal
with
this
problem
of,
say
that
you're
doing
an
async
operation
and
someone
can
come
in
and
update
the
spec
while
you're
doing
it.
A
A
Now
this
isn't
necessary
due
to
some
things
that
I'd
forgotten
the
controller
should
error
and
that'll
cause
it
to
retry,
actually
I
think
that
is
still
applicable,
because
you
could
error
due
to
a
conflict,
because
somebody
went
and
annotated
or
labeled
the
the
resource
that
you
were
working
on.
So
it
should
unset
this
field.
What
efficient
finishes
doing
work
on
the
resource
and
there
should
be
an
omission
controller
that
rejects
update
to
the
spec
of
service
instance
or
services
potential
I
had
written
here
when
the
current
operation
status
field
was
set.
A
Doug
is
correct,
though,
that
we
had
talked
about
this
being
a
the
blocking,
while
the
current
generation
doesn't
match
the
reconcile
generation
blocking
updates
to
the
spec
I
think
that
is,
that
is
just
as
good
of
a
criteria.
I
do
think
that
if,
if
the
current
operation
I'm
sorry
so
when
you
update
the
when
you
update
the
reconciled
generation
to
match
the
current
generation,
what
you
should
do
is
also
unset
the
current
operation,
because
it
means
you're
done
doing
work
and
then
I
have
some
write-up
of
this
to
illustrate
what
I'm?
B
A
B
B
B
All
right
we're
going
to
read
this
we're
gonna
come
back
at
the
next
meeting,
which
will
be
tomorrow
and
we're
gonna
be
consensus
on
this,
so
that
we
can
move
forward
with
implementing
it
cool.
Anybody
else
have
comments.
Questions
on
this
proposal
going
once
all
right,
cool
I
have
a
last
item.
This
is
very
short
I'm.
Looking
for
someone
who
has
experience
in
aggregated
API
authentication
to
give
me
maybe
a
15
to
20
minute
consult.
B
A
B
A
B
E
A
E
B
C
E
Troubleshooting,
why
names
and
strings
don't
equal
each
other
right
now
so
I
mean
I'd
like
to
have
it
done?
I,
don't
think
anything
is
majorly
broken
in
that
I
think
the
tests
that
are
missing
are
the
sort
of
stuff
that
was
checking
that
service
plan
equals
service
plan,
so
I,
don't
think
any
of
that's
actually
broken,
given
that
all
the
other
stuff
still
works.
But
it's
hard
to
know.
Okay,.