►
From YouTube: Kubernetes SIG Service Catalog 20170828
Description
- Recap of F2F
- Status of issues for beta
- Do we need to continue pace of design meetings?
A
A
A
All
right
can
everybody
see
my
screen,
yep,
okay,
so
what
I'm
gonna
do
here?
We
we
had
pretty
detailed
notes,
go
into
the
document
I'm
going
to
scan
through
these
really
quick
and
read
the
items
that
we
chew
consensus
on,
and
if
anybody
is
interested
in
getting
more
information,
you
can
go
ahead
and
read
the
notes
that
are
in
the
agenda
doc.
It's
the
normal
agenda
document.
A
So
the
first
item
that
we
discussed
is
switching
from
checksum
to
generation,
which
we've
also
discussed
in
previous
design
meetings.
We
did
get
consensus
on
moving
forward
on
switching
over
to
generation
for
all
the
resources,
pending
any
special
cases
for
individual
resources,
and
also
that
the
controller
will
update
the
reconciled
generation
field
in
the
status
after
it
is
done
with
work
to
do
for
a
particular
generation,
and
the
salty
here
is
that
it
doesn't
necessarily
mean
that
everything
went
perfectly.
It
means
controller
is
done
doing
more.
A
So
next
item
was
having
reconcile
properties
and
status
for
resources,
and
this
basically
refers
to
the
idea
that
we
should
have
fields
in
status
to
show
what
state
a
resources
in
so,
for
example,
for
instance,
this
would
be
what
plan
and
parameters
are.
Does
the
broker
currently
have,
for
instance,
for
this
instance,
and
we
did
achieve
consensus
on
having
a
last
successful
state
set
of
fields
in
the
broker
that
show
what
is
the
last
thing
that
was
successfully
operated
on
at
the
broker?
A
I
guess
it
looks
like
we
have
consensus
that
this
will
be
struct
called
reconciled.
Spec
or
the
field
will
be
reconciled.
Spec
it'll
be
a
struct
with
a
with
the
fields
in
the
spec
that
matter
to
the
broker,
and
then,
let's
see
Michael
key
bei
was
going
to
propose
a
new
name:
that's
not
a
consensus,
but
that
was
in
bold
and
my
simple
brain
was
tricked.
A
So
next
up
was
orphan
mitigation.
So
just
a
refresher
on
this
one,
the
open,
serviceworker,
API
spec,
has
this
activity
called
orphan
mitigation,
which
is
basically
to
make
sure
that
if
you
have
a
provision,
request
that
times
out
to
ensure
that
the
requests
didn't
actually
complete
on
the
broker
side
and
then
you've
got
an
instance
out
there.
A
That's
using
resources,
but
the
platform
doesn't
know
about
it
and
we
got
consensus
that
for
the
first
beta
we're
going
to
make
this
a
terminal
condition,
meaning
that
if
we
have
to
do
this
for
an
instance,
that
instance
is
just
going
to
be
failed.
We're
not
going
to
retry
the
provision
or
anything
like
that,
and
we
have
an
action
item
two
to
talk
to
the
CF
folks
about
how
to
see
a
panelist
and
very
conveniently
we
established
that
Cloud
Foundry
treats
this
as
a
terminal
condition.
A
Next
up
was
plan
and
parameter
updates,
and
the
consensus
was
that
we
are
going
to
use
the
generation
in
the
instance
spec.
Well,
I'm.
Sorry,
the
generation
in
the
object
metadata,
basically
the
generation
of
the
spec,
to
determine
whether
an
update
needs
to
happen
and
use
a
parameters
checksum
to
determine
whether
parameters
should
be
updated,
and
if
neither
the
plan
or
parameters
need
to
be
updated.
A
Then
we
don't
have
any
work
to
do
and
there
will
also
be
a
way
to
trigger
a
manual
update
to
an
instance
for
cases
where
something
changed:
out-of-band,
meaning
like
if
you
had
an
instance,
that
is
on
plan
a
and
it
references
secret
X
to
get
some
parameters
and
the
plan
didn't
change.
But
the
user
needed
to
update
some
of
those
parameters
that
come
from
a
secret.
A
There
will
be
a
way
that
users
can
manually
do
that,
so
that
we
don't
have
to
make
controller
and
API
handle
things
like
watching
a
secret
to
see
if
that
changed.
Since
that's
a
no
bueno
and
then
user
information
for
operations,
the
consensus
that
we
achieved
was
that
were
okay,
with
adding
user
info
to
instance
and
binding
and
having
it
represent.
A
The
user
who
lasted
in
operation
on
the
resource
and
its
value,
will
be
in
the
originating
identity,
header
field
and
I
actually
think
that
there
is
another
piece
of
consensus
on
this
which
oh
it's
in
another
item,
so
forget
that,
but
it's
related
next
up
resync,
we
got
consensus
that
we're
going
to
have
a
realist
sub
resource
that
will
cause
the
controller
to
do
a
resync
and
I
I.
Think
we
had
consensus
on
some
of
the
how
with
that,
but
we
were
going
to
go
to
city
arch
to
test
that
idea.
A
So
next
up
this
was
we
we
had
a
very
productive
meeting,
which
is
why
we
have
so
many
consensus.
Things
to
read
through
next
up
was
async
processing
and
concurrent
updates
on
instances.
Now
what
this
refers
to
is
that
cloud
foundry
blocks
updates
to
instances
while,
while
there's
an
operation
in
progress
for
them,
which
is
not
something
that
we
have
precedent
for
in
kubernetes
and
is-
is
actually
against
normal
kubernetes
api
practices.
A
But
it's
an
OK
compromise
for
the
initial
beta
and
I
think
that
covers
all
of
the
consensus
that
we
got
so
I
I
have
not
been
looking
at.
The
I
have
not
been
looking
at
the
the
text
area.
I,
don't
know
how
many
people
have
their
hands
up,
but
I'll
just
say
really
quick
thanks.
Everybody
to
to
everybody
that
made
it
out
to
the
face-to-face
was
really
really
productive
and
I
personally
appreciate
the
effort
that
goes
into
going
to
something
like
that.
B
A
B
Paul
I
added
that
only
because
those
issues
that
I
quickly
went
through
I
quickly
went
through
all
the
beta
issues
and
for
the
ones
that
were
either
tagged
as
need
proposal
and
I
check
to
make
sure
there
wasn't
one
already
or
the
ones
I
felt
hadn't
been
fully
discussed,
I
put
them
there
now.
Some
of
these
may
just
need
us
to
write
down
the
resolution
from
the
face
to
face
yeah.
C
B
A
Okay,
so
I
opened
up
the
first
one
and
that's
orphan
mitigation
for
bindings
I
agree
that
needs
write
up.
I
will
I
will
be
happy
to
take
that
one
I've
spent
a
lot
of
time.
Thinking
about
it
and
I'm
pretty
sure
the
next
one's
gonna
be
orphan
mitigation
for
instances.
You
are
correct.
All
right,
I'll
take
both
of
those
and
I
can
do
a
write-up
for
them.
It's
gonna
be
pretty
simple,
because
the
consensus
that
we
have
and
precedent
for
other
parts
of
the
ecosystem,
ie
Cloud
Foundry-
is
actually
pretty
simple.
A
A
So
kubernetes
names
of
service
class
and
plan
versus
open
service
broker
grids.
I
we
did
not
actually
talk
about
this
one
in
the
face-to-face,
but
I
think
that
we're
kind
of
narrowing
in
on
some
consensus
around
it,
especially
based
on
the
open
service,
burger
API
discussions
that
we
had
I'm
currently
assigned
to
this.
But
I
don't
want
it
to
block
on
me
since
I'm,
going
to
write
up
work
for
mitigation
Doug.
Are
you
interested
in
writing
this
one
up
so.
B
Like
it's
well
next
in
the
queue
or
do
I
wanted
to
give
I,
don't
I,
don't
mind
taking
a
stab
at
it.
I
agree
that
we
do
sort
of
seem
to
headed
in
a
particular
direction.
I
guess
I'm
this
one
all
I
was
looking
for
was
someone
to
actually
write
down
that
direction
so
that
they
could
take
it
back
to
their
home
base
and
get
their
their
teams
to
review
it
and
make
sure
they're?
Okay
with
it.
A
B
A
A
A
B
I'll
go
so
I
grew
to
I
think
at
least
one
more
just
to
clear
out
the
the
queue
or
even
give
people
a
chance
to
come
back
from
a
holiday
or
sorry
travels
a
weekend,
make
sure
they
don't
forget
anything,
but
otherwise.
Yeah
most
people
come
up
with
the
specific
topics
and
think
issues
to
discuss.
We
may
want
to
go
back
to
weekly
meetings.
Okay,
I.