►
From YouTube: Kubernetes SIG Service Catalog 20170717
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Alrighty
close
back
okay,
first
I,
just
added
this
I
wanted
to
propose
requests.
I
wanted
to
start
the
discussion
by
talking
about
orphan
mitigation,
I,
understand
again
from
Paul
that
you
guys
have
made
some
progress
last
week
on
orphan
mitigation
and
I
wanted
to
try
at
least
attempt
to
finalize
our
plan
for
designing
some
solution
for
or
for
orphan
mitigation
and
then
to
start
into
many
in
a
proposed
in
a
prototyping
PR.
Sorry,
I
can't
talk
today,
so
if
someone
would
could
they
fill
in
kind
of
the
progress
we've
made
so
far?
B
A
So
the
only
one
that
I
know
of
is
Paul
has
added.
He
put
in
I,
think
noun
a
finished
and
ready
to
review
PR
for
terminal
conditions,
that's
kind
of
a
foundation
for
orphan
mitigation.
So
what
I'm
going
to
do
is
basically
just
leave
it
at
that.
For
now
this
again
with
all
the
press,
so
I'll
ask
him
to
go
either
write
something
up
for
this
or
bring
it
up
for
next
week's
meeting.
A
We
also
have
design
meetings
I
think
tomorrow,
through
Friday,
except
for
Thursday,
maybe
so
that
would
give
us
plenty
of
time
to
go
into
it
there
as
well
all
right,
Doug
we're
going
to
move
on
to
you.
You
looks
like
you
have
review
agreed
to,
but
on
hold
decisions.
The
first
one
looks
like
something
about
splitting
in
plan
service
class.
So
I
will
let
you
take
it
away.
Yeah.
B
New
topics
I'm
moving
on
so
I
just
wanted
to
quickly
sort
of
read
based
on
where
our
decisions
were
from
last
week.
First,
one
splitting
the
plan
out
from
service
class
I
camera,
which
day
was
it
made
then
Wednesday
I
think
we
agreed
split
it
up.
We
want
to
get
people
a
couple
days
to
make
sure
they're
okay
with
that
direction
and
it
sounds
like
no
one's
complained,
so
we're
going
to
head
that
that
step
path
or
down
a
path,
so
people,
so
we
just
keeps
wanting
to
get
volunteer
to
actually
write
up
the
PR.
B
A
B
Thanks
remove
pod
preset
from
binding
I
didn't
hear
what
we
agreed
last
week
that
our
tentative
agreement
was
going
to
be
to
remove
pod
presa
from
binding,
but
we
haven't
agreed
yet
on
what
was
going
to
happen
after
that,
but
we
did
want
people
get
people
a
couple
of
days
to
think
about
whether
splitting
it
out
was
the
right
thing
to
do
again.
We
ever
heard
any
complaints
about
that.
So
that's
our
current
plan
of
action.
B
However,
Paul
has
asked
for
us
to
hold
off
really
discussing
pod
presets
until
he
can
make
the
call
I
think
mainly
because
he
wants
to
advocate
his
pod
preset
binding
resource
as
well
as
make
a
case
for
requiring
that
to
go
in
at
the
same
time,
or
least
possibly
before
the
removal
of
pop
preset.
Even
though
some
of
us
think
it's
a
gentle
issue,
he
wants
to
wait
so
rather
than,
of
course,
not
decision
without
it.
B
Here
we
should
probably
wait
until
you
can
make
the
call,
so
that's
that
one,
but
the
short,
the
net
of
that
one
for
the
notes
is.
It
looks
like
everybody's
agreed
to
remove
pod
preset
from
binding,
and
we
just
need
to
turn
out
the
next
steps
and
we
already
have
a
PRI
to
do
that,
so
we're
just
on
hold
rename
of
our
classes.
B
Let's
see,
learn
correctly
I
believe.
Last
week
we
agreed
that
we
do
wanted
to
rename
the
general
consensus
was
that
we
should
use
a
common
prefix
for
our
classes.
I
believe
we
decided
to
try
to
resolve
that
on
slack
and
resolve
with
the
prefix
boson
slack,
and
we
were
bouncing
between
service
versus
Service,
Catalog
and
I.
Believe
we
landed
more
on
Service
Catalog,
even
though
it
was
a
bit
longer.
B
B
One
aspect
that
was
merged
into
that
issue
at
Paul's
request
rather
than
convenience.
A
pretty
shoe
was
I
brought
up
an
issue
of
renaming
binding
to
something
else,
potentially
just
serve
as
key
or
as
nail
was,
promoting
or
suggesting
something
like
instant
access
cake
to
be
a
little
bit
more
descriptive.
B
The
reason
I'm
suggesting
that
we
rename
binding
to
something
else
is
because,
if
we
remove
pod
preset
from
binding
a
binding
no
longer
does
a
binding,
it's
just
there
to
obtain
credentials,
in
other
words,
some
kind
of
key
or
secret,
or
something
we're
going
to
have
other
resources,
whether
it's
just
pod,
presets
or
pod,
pre-set
binding
or
something
else
that
that
you
can
do
the
action
of
quote
binding.
So
we
model-
you
know,
save
that.
That
word
for
the
proper
resource
and
that's
how
to
overload.
A
Binding,
so
it's
it's
also
worth
mentioning
that
binding
is
a
core
kubernetes
resource
that
in
1/7
defaults
to
not
accessible.
If
you
have
our
back
turn
on
not
readable,
so
you'll
be
forced
to
coop
CTL
get
binding
that
service
catalog
that
capes
at
I/o
versus
just
goop
CTL,
get
instance
for
example.
So
we
may
want
to
consider
not
using
binding
at
all.
If
we're
talking
about
Renee
making
now
well
yeah.
B
Now
that
was
actually
brought
up
last
week.
We
talked
about
this
issue
because
that
was
actually
the
main
driver
for
this
I
think
was
the
overlap
with
the
core
binding
thing,
but
just
to
be
clear,
even
if
we
did
keep
binding
around
it
would
probably
be
Service
Catalog
binding
anyway,
because
of
the
pre,
because
the
common
prefix
decision
well
right.
A
B
C
I
just
like
to
say,
I
I,
like
going
with
service
catalog,
but
an
important
point
that
was
brought
up
in
the
meeting
and
in
the
slack
channel
is
that
it
would
be
good
for
us
to
use
that
to
try
to
drive
some
consensus
or
or
something
new
in
the
kubernetes
community
itself,
that
there
is
this
problem
of
namespacing
api
resources
that
aren't
in
the
core,
and
it
would
be
good
to
get
that
address.
Do.
C
So
so,
as
as
more
kubernetes
incubators
come
online
with
their
own
resources
right,
there's
going
to
be
this
name
spacing
issue
in
in
cute
kernel
for
for
for
resource
names
and
so
I
think
one
of
things
Morgan
brought
this
up.
Let's,
let's
make
our
resource
names
as
obnoxious
as
possible,
so
that
so
that
it
can,
it
can
drive
discussion
in
the
API
review
about
how
people
are
going
to
be
able
to
name
their
resources
and
have
them
be
names
based
or
scope.
Some
out.
A
Yes,
I
agree.
I
would
ask
that
whoever
opens
that
issue
in
core
as
I.
Probably
you
I
guess
I
would
say,
talk
about
binding,
specific,
but
also
acknowledged
in
that
issue
that
it
is
possible
to
reference
the
fully
qualified
name
of
anything
that
any
API
a
grated
API
server
adds
I
believe
that
will
probably
help
frame
the
discussion
a
lot
better.
B
D
B
C
I
guess
my
main
question
is:
how
are
how
okay
are
we,
with
with
breaking
from
the
open
service
broker
or
naming
convention
that
this
is?
This
is
not
yes,
it
is
doing
binding
things
in
the
general
sense
and
and
our
specific
implementation
of
binding
is
not
necessarily
binding
to
something
or
binding
binding
from
something.
But
it
still
is
a
wrapper
around
the
open
service
broker
concept
and
function.
B
So
I
think
normally
I
would
I
would
have
the
same
kind
of
concern,
but
Cloud
Foundry
itself
already
set
a
precedent
for
this.
They
allow
you
to
create
bindings
as
well
as
they
like
to
create
service,
keys
and
I.
Think
in
our
in
our
current
use
of
this
particular
resource,
we
are
actually
creating
service
keys
and
so
I
think
there
is
precedent
for
doing
this
and
it
doesn't
seem
to
cause
any
confusion
in
the
class.
C
Boundary
world,
and
so
just
to
clarify
that
a
service
key
in
their
platform
is
is
basically
just
a
credential
storage.
Is
that
Redis
yep?
Basically,
okay,
that's
interesting
yeah,
then
I
think
I'm,
okay,
I
would
I
would
almost
say.
Then,
let's
go
with.
Let's
call
it
service
key
and
keep
to
the
get
to
it
as
close
to
their
concept
as
possible.
Okay,.
B
E
B
So
so
one
thing
to
keep
in
mind
is
that,
with
the
previous
decision
of
removing
pod
preset
from
binding
that
linking
that
you're
talking
about
is
not
happening
anymore,
the
action
today
of
creating
a
binding.
If
we
accept
the
PR
that
nail
is
opened
up
to
remove
a
preset,
it
does
nothing
but
create
the
secret
and
get
the
credentials
from
the
broker.
That's
it
there's
no
binding
action
whatsoever.
B
E
That
help
mark,
but
I
mean
you
just
said
that
I
create
a
binding
and
it's
still
going
to
call
the
broker
and
and
get
the
stuff
from
the
broker,
whatever
the
fact
early
plumbs
it
through
into
pod
preset
or
not,
is
an
implementation
detail
that
if
you
choose
to
just
do
that
last
step,
but
you
choose
to
scroll
the
things
away
in,
you
know
in
some
other
store
that
we'll
just
leave
them
in
a
secret
I,
don't
understand
how
that
is.
Is
any.
E
How
that
changes,
the
intent
of
I'm,
creating
binding,
which
triggers
calling
in
the
service
broker
the
service
broker,
returns,
coordinates
and
credentials,
and
then
what
you
do
with
them
is
I
mean
that's
that
sausage-making
I,
don't
really
care
I
mean
my
intent
was
still
that
I
am
creating
binding
like
I.
Don't
know
why
why
the
binding,
while
you're
defining
binding
as
just
being
connecting
the
last
mile
and
shoving
I'm,
assuming
you
mean
shoving
that
into
environment
variables
or
something
okay.
B
A
A
So
so
so
I
disagree
that,
because
we
have
in
the
past,
it
sounds
like
in
the
past
three
or
so
business
days,
we've
now
redefined
binding
from
something
that
kubernetes
does
in
conjunction
with
the
OSB
api,
to
something
purely
kubernetes.
No,
no
based
on
the
previous
definition
that
we've
had
up
until
then
we
by
submitting
a
binding,
we
are
doing
a
binding,
regardless
of
how
the
credentials
coordinates,
etc,
gets
surfaced
in
the
pod.
We
still
are
creating
a
binding
okay.
B
Okay,
maybe
I'm,
maybe
I'm,
mixing
things
up
there.
Okay,
let's
assume
we're
in
a
world
where
nails,
PR
gets
merged
and
our
current
resource
called
binding.
No
longer
is
pod
preset
inside
there.
Okay
in
that
world,
the
only
thing
that
the
binding
resource
does
is.
It
goes
to
the
broker
and
gets
the
credentials
and
that
stores
it
inside
a
secret
and
then
stops
it
does
nothing
else.
The
notion
of
binding
from
a
kubernetes
users
perspective
does
not
happen.
E
So
III
don't
have
the
context
of
why
the
pod
preset
is
being
removed,
but
I
don't
really
care.
What
I'm
wondering
about
is.
What
are
you
saying?
I
mean.
You
also
mentioned
something
that
you
were
calling
the
pod
preset
binding.
Are
you
expecting
so,
if
that's
somehow
restoring
binding
to
the
way
it
has
been
or
is
right
now
and
giving
it
another
name,
it
will
pop
preset
attached
and
that
will
have
the
same
functionality
as
what
we
have
today
before
this
TR
gets
merged.
Is
that
a
fair
factorization
and
my
understanding
of
Jimena
I
think.
E
B
That's
unclear
to
me,
because
we
haven't
discussed
pods,
preset,
binding
resource
right
and
and
what's
not
clear
to
me,
is
whether
they
have
to
manually,
create
today's
binding
and
then
create
a
pod
preset
binding
on
top
of
that
or
whether
they
just
create
a
pod
preset
binding
other
covers.
It,
creates
today's
binding
I
think.
A
It'd
be
useful
exercise
here
to
go
back
to
the
days
of
for
pod,
preset
existed
when
we
decided
on
this
name,
so
we
decided
on
the
name
binding
originally
because
it
matched
up
with
the
OSB,
but
we
also
discussed
at
length
both
in
person
and
I,
believe
on
an
issue
that
this
represents
the
binding
of
a
pod
or
pods
to
the
credentials
that
get
written
to
a
secret,
correct,
I'm
glad
once
presets
came
on
the
scene
up
up
through
now,
we
still
considered
this
a
binding
operation.
Now
it
sounds
like
pod.
F
There
are
use
cases
where
we
don't
need
forceps
at
all,
and
that's
what
Backman
place
is
talking
about
that
like
now
at
this
level
of
winding,
we
just
say
that
like
binding
is
a
representation
representation
by
client-side
representation
of
the
object.
And
yes,
it
is
called
binding
and
that's
why
we
probably
like
called
it
binding,
but
in
communities
world
there
is
one
more
step
and
it
could
be
pod
presses.
It
could
be
passing
this
credential
somewhere
else.
It
could
be
deployment
whatever,
and
this
off
step
is
not
part
of
of
the
binding
resource.
A
Yep
I'm
with
you:
that's
how
I
view
it
I
mean
I
just
view
it
as
the
binding
is
a
thing
we
can
call
something
else,
but
that's
the
thing
that
triggers
the
OSB
call
and
writes
the
credentials
and
coordinates
back
to
the
thing,
probably
a
secret
and
I'm,
assuming
that
there's
something
on
top,
as
you
say,
Neil,
but
I.
Don't!
For
that
reason,
actually,
I
don't
see
the
reason
that
we
are
going
to
change
the
name
by
name
because.
B
A
B
A
Is
where
disagree,
because
there
are
use
cases
where
a
binding
is
enough,
because
a
binding
right
to
secret
out
so,
for
example,
I,
have
a
use
case
where,
if
you
install
a
help
chart
with
a
binding
in
it
and
the
deployment
in
it,
you
are
able
to
submit
the
binding
with
a
secret
name
and
submit
the
deployment
that
references
the
same
secret
name
and
that's
how
effectively
you
bind
your
application
to
the
service
that
you've
just
found.
Probably
provision
to
I
agree.
B
G
B
I
know
it's
a
little
bit
confusing
because
Cloud
Foundry
I'm,
sorry,
the
open
source
broker.
Api
does
mix
those
two
under
the
word
binding
and
that's
what
that's
an
unfortunate
artifact
of
their
history,
but
from
the
kubernetes
user
perspective
who
I
think
is
I
know
it's
like
I
think
making
things
make
sense
from
a
curated
users
perspective
it's
more
important
than
in
hearing
through
a
particular
word
that
the
Service
Worker
API
uses,
because
you
committed
user
will
never
really
care
about
the
open
source,
procreated
guy.
Okay,
all.
A
A
B
A
B
A
G
I,
the
only
thing
I
would
have
to
say
is
that
key
might
not
be
the
right
name
to
rename
that's
fine.
All
I
ask
is
for
suggested.
B
A
F
Yeah
I
think
two
main
issues
currently
raised
for
supporting
alternative
out
protocols.
One
of
one
was
raised
by
Erin
I
believe
for
JWT
talking
support
and
the
other
is
for
supporting
alternative
of
algorithms
protocols
in
general
and
I
do
if
there
was
something
about
Google,
JW
choking
again,
and
my
suggestion
is
to
probably
talk
about.
F
Whatever
is
still
there
in,
however,
it
is
produced
there
and
then
they
could
be
a
completely
separate
running
process
which
is
responsible
for
maintaining
this
torque
and
stored
in
secret
and,
for
example,
rotate
is
taught
in.
If
the
token
is
shortly
is
like
ten
minutes
or
so
it
could
like
continuously
run
and
every
five
minutes
refresh
it
or
can
or
or
anything
like
that,
and
then
first
log
rule
will
just
consume
the
talking
without
really
understanding
what
what's
the
algorithm
of
generating
is
and
I
think.
F
F
So
are
there
any
objections
against
having
a
page
jerking
support
in
Service
Catalog
and
requiring
basically
the
like
vendor
or
like
users
who
need
to
implement
the
tunic?
We
need
soup
for,
like
google,
specific
authentication
or
anything
else,
we'll
have
our
own
actually
JWT
based,
but
like
we
again
like
the
generation
of
talking
or
acquiring
the
talking
with
lack
of
scope
of
GWT,
so
they
must
be
some
specific,
like
separate
application,
implementing
particular
algorithm
of
acquiring
the
protein
and
putting
it
into
the
secret
other
any
objections.
Yes,
hey.
C
A
Yeah
as
a
think
like
you,
both
you
and
Jimmy,
said
as
a
first
implementation
of
this.
That
would
be
good
enough.
My
overall
goal
for
raising
that
issue
was
to
add
something
better
than
basic
US,
and
this
would
achieve
that
in
the
first
implementation,
and
then
I
also
think
that
this
will
help
us
decide
what,
if
anything,
to
build
next.
So
that
would
mean
what
is
the
shape
of
a
custom
off
plugin,
for
example,.
F
C
Think
that
I
was
just
gonna.
I
was
just
going
to
ask
that
because
I
love,
the
the
other
more
general
issue,
I
in
general,
I
think
it
sounds
like
a
good
idea,
but
I
would.
It
would
be
good
to
see
a
concrete
proposal
so
that
I
could
give
that
to
our
security
guys
here
and
and
make
sure
that
they
see
it.
As
as
meeting
our
requirements
around
being
able
to
do
off.
A
C
A
E
C
F
Well
for
serviceable,
it
would
be
out
of
scope
right.
It
just
means
that
there
must
be
at
some
like
this
secrecy,
critical
controller
which
will
be
doing
whatever
it
needs
to
and
I
think
it
should
actually
watch
for
all
broker
objects,
probably
and
like
check
what
was
the
type
of
authentication
and
if
the
pal
type
of
authentication
is
equal
to
your
to
the
one
which
you
are
responsible
for.
You
have
to
basically
based
on
the
I,
don't
know
brought
her
name
or
something
like
that.
F
A
The
purposes
of
your
proposal,
Neil
I,
think
writing
down
in
English
is
not
in
a
language
or
it's
not
credit
I'm.
Just
saying
this
is
what
a
out
of
process
system
might
do
to
update
the
JWT
token.
This
is
why
it
exists,
and
obviously
mentioning
that
that
process
will
be
out
of
scope
of
the
first
implementation.
That
would
be
good
enough.
Yeah,
that's
exactly
what
I
was
looking
for.
Thank
you.
Erin
Cressida.
F
A
B
Okay,
Taku
proposal
for
we're
starting
to
get
into
the
ones
where
we're
just
going
to
be
sort
of
designing
on
the
fly
or
talking
on
the
fly,
so
I
apologize
for
that,
and
this
first
one
is
sort
of
a
carryover
from
the
very
first
design
session
we
did
last
week,
which
is
now
that
we've
got
resolution
from
sig
off.
That
will
allow
these
secrets
for
our
use
cases,
there's
an
open
question
of
how
do
we
handle
secrets
that
are
being
updated
outside
of
a
Service
Catalog
process?
So
we
don't
know
about
it.
B
B
Do
we
detect
it
and
act
upon
it
or
do
we
wake
up
users,
even
explicit
action,
so
nail
correct
if
I'm
wrong,
but
I
think
we're
the
primary
use
cases
we
have
to
discusses
once
we
allow
secrets
to
be
used
for
parameters?
If
someone
was
update,
one
of
those
secrets:
do
we
automatically
detect
the
secret
is
updated,
or
do
we
wait
for
them
to
take
some
action
on
the
open
service
broker,
API
side
of
things,
I'm,
sorry
in
source,
catalog
side
of
things
to
force
us
to
reget
the
secret?
F
Yeah
I
think
this
is
correct
correction,
but
I
think
that
even
last
week
we
have
already
mentioned
that.
The
best
thing
we
can
do
for
now
is
probably
because,
as
you
just
mentioned,
that
bulk
watch
stickers
are
not
supported
yet
is
to
just
for
now
we
can
just
treat
secrets
else
beautiful.
How
are
they
obviously
not,
and
for
the
user?
F
It
means
that
if
he
wants
to
force
the
new
secrets
to
be
propagated,
he
would
be
required
to
rename
this
secret
or
something
like
that
to
be
scrapped
date
by
the
binding
or
a
or
other
resource
which
is
responsible
for
engine
injecting
a
secret.
Something
like
that,
I
guess
remember:
we
have
bulk
watch
support.
You
can
actually
like
probably
support
the
beautiful
series.
Okay.
B
So
it
sounds
like
highly
the
more
abstract
decision,
then
is
the
user
will
have
to
take
some
explicit
action
to
force
us
to
to
re-examine
the
secret
if
it
is
changed,
we
just
need
to
sign
to
agree
on
the
exact
mechanism,
whether
it's
renamed
you
described
or
something
else.
That's
a
decision
point
for
us.
Is
that
correct?
Yes,
okay.
B
A
B
F
Money
has
a
secret
name
field
and,
like
the
easiest
way
to
support
the
like
immutable
secrets,
which
I
actually,
which
can
actually
be
updated,
is
to
just
change
the
secret
name
field
in
binding.
So
that
binding
controller
will
react
to
this
update
and
will
have
to
generate
a
new
secret
potential
with
the
new
new
content.
Something
like.
B
F
B
What
give
you
reason
over
that
point
at
it,
because
secret
for
the
credentials
is
very
different
because
one
it
can
be
defaulted,
which
means
the
user
could
specify
like
alright.
So
then,
we'll
pick
the
instance
name
or
something
like
that
for
the
binding
name
for
the
secret
name.
So
that's
why
I
want
to
make
sure
we
talk
about
the
parameter
secrets.
Yes,.
F
Well,
there
is
a
secret
storing
the
credentials,
that's
it!
Yes,
if
we,
if
we
fail
to
create
a
secret,
what
we
currently
do
is
just
to
replay
the
entire
binding,
so
we
will
have
to
invoke
the
request
to
be
again
and
touch
the
credentials
again
and
that's
actually.
There
is
a
separate
issue
in
OSD.
I
have
raised
that,
like,
according
to
this
pact,
if
like
a
broker,
is
required
to
return
the
same
credentials.
If
the
request
contains
the
same
parameters
and
I,
don't
do
it
that
stateful
broker
can
do
that
right.
A
So
so
backing
up,
though
we
have
there,
one
of
the
use
cases
for
secret
is
to
store
the
broker
credentials.
That's
one
of
the
three
I
believe
yeah
I.
Don't
think
that
we
cache
those.
So
if
that
secret
has
ever
changed,
we
don't
need
to
no
one
needs
to
poke
service
catalog,
because
on
every
broker
request
again,
if
I'm
right
about
the
caching
on
every
broker,
request
will
reread
the
secret.
Yes.
A
F
A
Broker
the
secret
that
holds
broker
credentials
will
not
be
updated,
will
never
be
written
by
service
catalog.
It's
always
just
read
and
I
believe
that
it's
read
every
time
so
we
saw
we
don't
need
to
poke
for
that
use
case
of
secrets
and
if
I
remember
implementation
right
as
well
for
parameters
instance
parameters
secrets,
we
also
don't
cache.
So
if
the
secrets
the
secret
is
changed,
that
would
be
the
instance
where
neo
we
probably
would
need
to
use
your
message
of
poking
yeah.
F
Yeah
well,
the
only
problem
with
like
buffing
updated
parameters
is
that
South
Kotoko
will
only
watch
on
instance,
not
on
secret,
which
means
that
whenever
secret
is
updated,
there
is
no
reaction
to
it.
So
have
to
do
something
in
instance,
so
that
circuital
will
take
an
action
and
past
I've
dated
secret.
F
F
In
communities,
1.8,
1.8
I,
think
see
golf
because
I
set
up,
they
expect
to
have
some
kind
of
support
for
bulk
watch
secret
and
then
we
can
add
a
separate
resource
control
of
watching
on
secrets.
We
care
about,
and
then
the
like.
This
use
case
would
be
automated,
not
just
asking
user
to
do
something
manually.
Sure.
B
I
believe
so
I
never
check
the
code.
I
think
we
do
in
the
sense
that
if
they
do
change
the
credentials,
if
they
want
us
to
to
wreak
worry
the
Roker.
For
some
reason
we
have
to
have
some
posting
mechanism.
Now
we
will
have
that
poking
mechanism
at
some
point
automatically,
no
matter
what
right
you're
going
to,
because
Paul
suggested
we
have
a
cron
based,
beget
catalog
and
a
manual
for
Sarika
kind
of
loss
will
happen
automatically,
but
that
becomes
in
my
mind
the
poking
mechanism
right
yeah.
C
B
No
I'm,
not
I'm,
not
concerned
about
it
at
all.
I
just
want
to
make
sure
that
aaron
said
that
we
will
not
have
a
poking
mechanism.
We
implicitly
do
or
not
going
on
yeah.
We
in
a
roundabout
way
do
because
we're
going
to
allow
people
to
say
for
this
broker
go,
we
get
the
catalog
and
that
can
be
the
coping
mechanism.
If
someone
needed
a
poking
mechanism,
yeah.
F
A
A
So
that
would
solve
the
issue
yes,
and
it
would
allow
us
to
proceed
without
the
poking
mechanism,
but
I
would
recommend.
We
don't
do
that
until
sig
off
has
a
quote
blessed
way
to
watch,
essentially
what
we
call
bulk
watch
secrets
and
the
reason
for
that
is
because
I
would
like
to
make
it
very
explicit
for
a
user
to
do
a
mutated
call
to
the
OSB
broker
when
something
changes
in
the
secrets.
F
Yeah
I
think
it's
it's
good
enough,
and
probably
I
mean
like
with
the
problem
with
like
a
background.
Go
routine
is
that
you
have
to
like
step
up
the
periods
or
something
and
just
say
like
okay,
you
updated
the
secret
and
we
will
react
in
30
minutes
from
this.
Something
like
that
and
I.
Don't
think
this
is
a
good
user
experience
and
like
if
the
user
actually
needs
to
be
secret
to
be
propagated.
It's
probably
faster
and
easier
to
just
rename
the
secret
embassy.
C
Okay,
Erin
can
I
just
clarify
something.
You
said
it
sounded
like
earlier.
You
said
you,
you
weren't
a
fan
of
having
a
secret
rename
as
a
permanent
solution,
but
what
you
just
said
now
made
it
seem
like
you
wanted
something
that
was
more
explicit
than
just
changing
something
in
the
secret
itself.
Like
you
want
you
want
there
to
be
an
explicit
operation.
Almost
that
allows
the
user
to
say.
Yes,
do
the
update
now
yeah.
A
So,
for
example,
I
don't
want
someone
to
update
instance,
parameters
in
a
secret
and
then
have
it
automatically
go
and
reprovision,
for
example.
However,
if
in
the
future,
sig
off
has
a
again
blast
way
to
bulk
watch
secrets,
then
we
can
document
the
fact
that
we
bulk
watch
secrets
in
the
right
way
and
that
may
cause
if
you
change
an
instance,
parameter
a
secret,
for
instance,
parameters
that
may
cause
a
reprovision.
C
B
Be
clear,
I
think
what
I'm
hearing
is
the
user
has
to
poke
the
system
in
some
way
and
they
have
to
change
it,
not
instance
for
sec.
They
have
to
change
the
instance
spec
in
some
way,
and
we
can
recommend
one
good
way
to
do.
It
is
to
rename
the
secret,
but
technically
they
could
do
anything
they
wanted
as
long
as
they
do
some
sort
of
update
to
the
income
specs,
because
that
would
cause
the
exact
same
effect
right.
Yes,.
B
But
my
bigger
concern
here
is
I
I
agree
with
Bernie
was
saying
it's
not
a
great
user
experience,
but
my
bigger
fear
would
be
that
we
introduced
something
that
we
now
have
to
support
in
essence,
for
a
very
long
time
when
this,
when
the
both
watch
does
come
around
and
I,
don't
want
to
have
to
remove
something
or
deprecated
stuff
like
that.
So,
okay
with
you
know,
recommending
a
rename
for
the
secret
right
now
or
something
else,
one
we
don't
introduce
something.
They
agree.
F
And
also
like,
if
we
make
some
hockey
a
decision
that
probably
Jimmy
has
suggested
if
it
will
be
good
enough
from
the
use,
experience
I'm
afraid
that
it
would
stop
us
from
implementing
proper
way
west
by
figure.
And
if
we
have
this
like
painful
way.
It's
much
easier
to
justify
the
implementation
of
the
proper
way
of
supporting
secret
controllers
than
just
running
a
go
routine
into
the
grounds.
So
I
would.
A
B
C
B
C
D
B
A
B
It's
just
a
request
for
people.
Please
go
through
the
list
of
either
the
issues
that
I
put
into
the
agenda
doc
for
the
last
three
times
to
see
whether
that's
a
complete
list
or
not.
If
you
see
other
ones,
you
know
go
to
add
to
the
agenda
but,
more
importantly,
try
to
pick
one
of
the
ones
that
we
haven't
talked
about
yet
and
see.