►
From YouTube: Kubernetes SIG Service Catalog 20161121
Description
SIG service-catalog receives a demo of the seed code donated from Google to the incubator repo.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
All
right,
everybody
welcome
to
the
Monday
November
twenty
first
meeting
of
cigs
service
catalog
featuring
my
cat
and
today
we've
got
two
main
things
on
the
agenda.
The
first
is
the
demo
of
the
code
in
the
incubator,
repo
that
the
Google
folks
contributed,
as
we
agreed
in
Seattle
and
second
is
I-
wanted
to
discuss
some
things
around
project
governance.
So
let's
try
to
time
boxes
demo
at
about
30
minutes,
and
that
will
give
us
some
time
to
talk
about
questions
next
steps
and
then
project
governance,
so
viele
your
assigned
to
do
the
demo
I.
C
So
at
the
top
level
of
the
code
base.
Now
we
have
three
main
components
with
a
service
controller,
which
is
what
we've
been
discussed,
describing
as
the
catalog.
It's
the
thing
that
watches
for
humanity's
resources
and
interacts
with
brokers
and
will
eventually
inject
binding
credential
information
into
the
Cooper
Nettie's
native
space.
So
that
is,
that
is
part
one.
That's
probably
the
biggest
piece.
Also
part
of
this
is
a
hell
maced
white
box
broker.
C
So
what
this
is
is
a
service
that
runs
in
the
cluster
that
implements
the
broker
API,
that
that
uses
helm,
charts
for
service
instances
and
bindings,
so
you
can
implement
service
classes
and
install
them
into
what
we
call
the
service
registry.
That
is
basically
the
dynamic
catalog
for
this
broker,
and
it
will
expose
it
through
the
catalog
interface
as
normal.
C
Finally,
we
have
the
examples
directory
which
contains
a
bunch
of
community
spook
files
that
do
all
sorts
of
different
stuff.
We're
going
to
go
through.
One
specific
subsection
of
the
examples
folder,
which
is
the
walk
through
and
that
walks
through
a
couple
of
different
use
cases,
are
not
going
to
do
the
full
demo.
I'll
just
do
do
a
small
subset,
so
this
is
the
architecture.
It
should
look
pretty
familiar
and
similar
to
what
we've
been
drawing
on
the
board
a
bunch
of
times.
C
You
have
crew
benetti's
objects
which
today
are
implemented
as
their
party
resources,
but
eventually
we
want
to
move
to
federated
API
and
we
have
these.
These
four
objects.
Their
service
broker
service
class
service
instance
service,
binding.
We
have
the
controller
running
in
the
cluster,
which
is
watching
these,
and
it's
also
it's
also
mod.
Is
it
does
it
today?
Does
it
do
any
modification
for
status
I
think
it
does
not
so
right
now,
it's
just
watching
them.
C
It's
really
just
a
read,
but
it's
also
set
up
to
you
know
eventually
post
state
back
when
we
have
that
and
then
on
the
flip
side,
you
know
you're,
adding
brokers
every
time
you
add
a
broker,
it
pub
it.
It
populates
all
the
classes
that
that
broker
exposes
to
its
catalog
as
new
at
all,
except
okay,
so
the
current
consumption
model.
This
is
where
we've
diverged
pretty
significantly
from
what
we've
been
talking
about
in
the
sig,
but
it's
done
in
such
a
way.
That's
really
easy
to
migrate
over
to
the
new
model.
C
As
we
were
building
this
thing,
the
consumer
side
was
with
service
instances,
so
you
would
be
binding
service
instances
to
service
instances.
This
is
really
just
a
function
in
the
cloud
in
the
in
the
service
controller
that
we
could
swap
out
to
say
you
know,
create
these
native
crew
benetti's
resources
instead
of
injecting
binding
information
into
a
consuming
service
instance.
C
Custom
service
instances
consuming
bindings
because
that
we
don't
care
about
that
in
this
context,
so
I'm
going
to
show
off
a
native
crew,
benetti's
application
consuming
a
binding
to
a
user-provided
service
instance,
because
I
think
that
that
that
hits
all
of
the
different
components
of
the
of
the
service.
So
right
now
we
have.
C
So
right
now
we
have.
We
have
all
these
things
running
on.
What
we
care
about
is
the
controller,
the
kates
broker
and
the
UPS
broker.
These
are
the
three
major
components.
Also,
the
the
registry
is
the
service
registry.
That's
the
dynamic
catalog
backing
for
the
kates
broker.
Everything
else
this
is
this
is
set
up
from
some
internal
stuff.
C
So
there's
some
extra
junk
in
here,
including
this
namespace
glory,
which
is
kind
of
our
internal
name,
for
what
we've
been
working
on
I
believe
the
namespace
is
actually
catalogue
in
the
in
the
code
that
we've
open
sourced.
So
we
can
start
out
by
looking
at
what
service
classes
we
have,
and
we
have
none,
because
we
have.
C
No
brokers,
so
we
need
to
install
some
brokers,
so
we
have
this
spec
file
that
contains
the
two
brokers
we
care
about
and
you'll
see.
Here
we
have
one
named
Kate's
and
one
named
ups
and
they
both
point
to
the
respective
brokers
running
in
the
cluster,
and
so,
if
we
just
keep
control
create
a
chef
program,
we
have
these
created
and
if
we
look
at
the
classes
there
should
be
a
bunch
of
class
exposed.
So
these
top
three
were
exposed
from
the
kates
broker.
C
Those
are
classes
that
we
created
that
are
backed
by
home
charts
and
then
this
user
provided
service
is
the
custom,
the
custom
class
that's
exposed
by
the
UPS
program.
So
let's
see
only
let's
hope
that
I
have
the
appropriate
stuff
set
up
for
the
demo,
because
I
was
tinkering
with
it
earlier.
Okay,
so
I
have
this.
This
random
service
running
the
cluster
called
bookstore.
Let's
assume
that
that's
something
that
I
managed
separately
from
the
catalog
system,
but
I
want
to
consume
it
through
the
binding
mechanism.
C
C
Have
this
service
instance
now
great
grand
wonderful
I
can
now.
I
can
now
create
a
binding
to
it
and
consume
that
binding
from
a
native,
true
benetti's
application.
So
let's
look
at
the
let's
look
at
the
binding,
so
so
peeking
under
the
covers
at
the
brokenness
of
this
demo,
because
we
have
that
conceptual
model
of
service
instances
binding
to
service
instances.
This
binding
has
a
as
a
from
field
and
I
will
need
to
create
a
a
another
service
in
sin,
static
that
it
injects
the
dividing
information
into
the
cluster
for
us.
C
C
So
we
now
have
a
binding
we're
this
in
the
conceptual
model
that
that
we've
all
been
discussing
and
agreeing
on
the
config
maps
and
secrets
and
services
and
whatnot
would
be
created
already
on
our
behalf.
In
this
current
thing,
I'm
going
to
have
to
create
a
binding
consumer
that
is
going
to
create
those
resources
for
me.
So
this
is
just
a
special
class
I
have
that's
a
helmet
korea
ates
completely
config
objects
in
the
cluster,
but.
D
D
C
C
Yeah
no
problem
so
so
that
created
a
config
map,
I
believe
called
bookstore
nodejs,
and
we
can
see
that
here
and
if
we
go
and
look
at
it,
that
has
all
the
necessary
things.
We
just
created
a
config
nap
because
that's
the
easiest
way
to
demonstrate,
but
as
we've
described
before,
that
would
really
be
a
secret
and
a
config
nap
in
a
service.
Now
that
we
have
that
we
can,
we
can
spin
up
a.
C
We
can
spin
up
a
native
application
and
we
don't
have
to
go
through
this
whole
spec
file.
But
you
can
see
here
down
at
the
bottom
that
we
have
environment
variables.
It's
not
Auto,
injecting
right
now,
because
we
don't
have
a
concept
of
sip.
But
you
can
see
that
somebody
could
use
this
in
a
native
manner
by
just
doing
a
config,
nap
ref
or
a
or
a
secret
ref.
So
if
we
do
that,
if
we
create
that.
C
We
now
have
that
new
service
and
it's
probably
going
to
take
a
minute
for
the
external
IP
to
come
up,
so
we
we
won't
actually
ping
it
to
test.
We
can
always
come
come
back
to
it
if
that's
important
to
people,
so
so
what
what
that
just
described
was
was
creating
a
service
instance.
In
this
case
we
created
a
user
provided
service
instance,
but
it
could
have
been
a
black
box
instance
of
some
other
kind
that
took
input
parameters.
C
In
this
case
it
took
the
credentials
because
that's
what
a
user
provided
service
instance
takes
and
then
we
bound
to
it
and
that
that
binding
allows
us
to
inject
the
credentials
into
the
cluster
that
that
last
mile
bit
is
is
work.
That
needs
to
be
done,
but
it
should
be
very
simple
plug-and-play
into
the
into
the
codebase.
C
C
The
next
step
is
cutting
out
the
function
that
does
the
service
instance
to
service
instance
binding
and
replacing
it
with
a
code
that
generates
the
Native
communities,
resources
to
inject
the
binding
information,
completing
the
broker
interface.
So
in
this
code
we
implemented
most
of
the
broker
interaction,
but
there's
some
stuff
missing,
namely
around
a
sync
operation
stuff.
We
are
the
brokers
we
checked
in
our
synchronous,
they're,
going
to
return
when
they're
actually
done,
and
and
because
of
that,
the
current
service
controller
does
not
do
operation
polling
and
what
up?
C
But
the
I
think
the
object
models
have
operations
in
them.
They're
just
not
used
they're.
Just
it's
just
done
when
the
broker
returns
as
we're.
Looking
through
the
code,
I
think
we
have
a
list
of
a
bunch
of
things,
but
I
hope
that
other
people
as
they're
looking
through
the
code,
are
finding
lots
of
issues
and
are
capturing
them
as
github
issues.
I
know,
there's
a
bunch
of
rough
edges
and
incompleteness
there's,
probably
a
lot
of
naming
stuff.
C
A
So,
let's,
let's
do
this
in
two
steps,
since
we
are
going
to
talk
about
project
governance
next
on
the
agenda,
let's,
let's
have
a
period
where
we
just
had
questions
that
pertain
to
the
demo
that
Shawn
dug
I,
see
that
you
have
one
in
the
chat.
The
question
is:
can
you
elaborate
on
the
registry
thing
sure.
C
So
that's
a
that's
specifically
a
component
of
I.
Don't
have
a
good,
don't
have
a
good
slide
here,
but
that's
specifically
a
component
of
the
helm
based
broker.
So
it's
the
white
box
broker,
so
typically
brokers
have
a
have
a
pretty
static
catalog
because
they're
the
brokers
written
in
code-
and
it's
you
know
hard
code
of
that
it
serves
these
three
types
or
one
type
or
whatever.
C
So
how
we
chose
to
build
a
home
based
broker.
Is
that
as
your
as
your
ad,
you
should
be
able
to
dynamically
add
new
classes
right
as
your
as
you're
creating
new
services
as
you're,
creating
new
versions
of
services,
you're,
probably
going
to
be
coming
out
with
new
classes
too
Stan
she
ate
those,
and
so
you
don't
want
to
release
those
as
hard
coded
things
in
the
broker.
It
might
be
nice
to
have
a
dynamic,
catalog
backing
that
broker,
and
so
this
is
really
just
it's.
C
C
C
C
A
Okay,
so
are
there
any
other
questions
about
the
demo
that
we've
seen
here,
knowing
as
we've
already
as
Brennan
already
explicitly
said
that
there's
obviously
like
a
pretty
high
edit
distance
between
what
we
agreed
to
eventually
converge
upon
and
the
seed?
Oh,
that
has
gone
into
the
incubator
repo
question.
My
demo,
I
have.
E
C
C
Okay,
so
just
going
back
I.
Maybe
did
this
a
little
too
quickly.
So
when
we
started
out,
we
had
no
no
service
classes,
no
brokers
attached
to
the
controller
I
then
did
a
cube
control
create
on
this
spec
file,
and
so
this
is
telling
these.
These
are
two
objects
of
kind
service
broker,
and
that
is
how
you
add:
service
brokers
to
the
catalog.
C
A
C
A
A
That
is
probably
an
alpha
level
initially
and
then
the
second
is:
how
do
we
do
those
things
in
a
way
that
is
collaborative
and
what
are
the
right
kind
of
sops
for
governance
of
visa
V
pull
requests
I,
think
that
it's
probably
best
to
talk
about
the
second
one
that
I
named
first
and
establish
some
like
minimal
ground
rules
that
we
can
have
to
inform
the
second
discussion,
and
since
these
are
two
pretty
big
topics,
I
think
we
can.
We
can't
I'm
box
the
the
time
box
each
of
them
at
15
minutes
max.
A
A
I
I
think
that
everybody
here
is
mature
enough
to
resolve
those
things
amongst
themselves,
I
in
an
expedient
way.
Keeping
the
end
goal
in
mind
and
I
would
also
proposed
that
if
there
is
a
really
passionate
disagreement,
that
cannot
be
resolved,
that
I
will
engage
the
dictator
hammer
and
make
a
completely
arbitrary
decision
based
on
my
personal
taste,
which
may
be
a
coin
flip
at
random,
org
I
just
to
keep
things
moving
in
the
right
direction
and
before
I
say
anymore.
I
wonder
what
folks
thoughts
about
that.
I.
A
Let
me
let
me
restate
first
and
here's
where
I
wish
we
had
a
floor-to-ceiling
whiteboard.
I
do.
We
all
agree
that
the
specifics
about
the
development
tooling
and
any
subjective,
developer
taste
related
matters
are
secondary
to
actually
making
a
primary
goal,
which
is
to
realize
Service,
Catalog
and
COO
benetti's
happen.
Does
anybody
disagree
with
that.
A
Okay,
so
I
also
would
say
that
that
we
all
should
agree
that
we
will
work
together
to
smooth
out
any
disagreements
that
might
arise
in
an
expedient
way
and
not
get
hung
up
on
it
again.
This
is
not
any
kind
of
commentary
on
personality
personality
is
involved
here.
It's
mostly
coming
from
my
like
personal
history
of
years
of
being
an
engineer
and
engineering
lead
that
I've
seen
developers
get
very
distracted
over
things
that
are
not
material
to
the
end
goal
of
their
project.
A
I
think
that,
since
this
is
also
communities,
incubator,
repo,
that
we
should
try
to
keep
the
conventions
of
development
and
the
code
structure
consistent
with
crew
benetti's
itself,
and
that
in
matters
of
subjective
disagreement,
that
that
goal
should
inform
how
we
resolve
it.
Does
that
make
sense
to
folks
I
see
a
plus
one
from
Gabe
and
I
hear
no
disagreement.
I
see
another
one
from
Doug
from
Dan
Wilson,
okay,
I'm
going
to
call
that
one
adopted.
A
So
those
are
the
easy
ones
right.
We
know
we're
going
to
work
together.
We
know
that
that
we're
going
to
try
to
make
this
look
like
uber
Nettie's,
which
also
dubbed
tails,
with
the
design
goals
that
we've
had
I,
think
that
there
are
some
other,
less
obvious
things
to
talk
about
with
project
governance.
So
I
would
like
to
open
the
floor
to
folks
that
would
like
to
bring
something
up
since
I've
been
talking
for
quite
a
while.
A
A
Okay,
so
I
don't
see
anybody
super
eager
to
speak,
so
I'll
just
go
ahead
and
kick
kick
it
off.
One
thing
that
was
brought
up
is
in
a
slack
channel
over
the
last
week,
is
what
should
the
process
be
for
establishing
whether
exchange
is
ready
to
be
merged?
I
will
call
out
what
has
also
been
discussed
in
the
slack
channel
that
the
the
co
drop
was
was
merged
without
any
review
and
I.
Think
in
that
case,
that's
totally
fine.
We
had
previously
agreed
in
Seattle
that
this
would
cede
the
the
incubator,
repo
and
I.
A
Don't
think
anybody
has
expectations
that
any
part
of
this
code
is
set
in
stone.
We've
just
gone
over
that
there's
a
fairly
high
at
a
distance
between
what
is
in
there
now
and
what
we
would
like
to
ship.
So
there
should
not
be
any
unnecessary
attachments
to
that.
I
do
think
that
it
would
be
great
now
that
we
are
entering
a
phase
of
the
sig
where
we
expect
to
be
having
like
fairly
active
development
in
the
sink
invader,
repo
it.
A
We
could
establish
a
convention
for
when
something
is
emerging
and
since
I
don't
want
to
put
my
finger
on
the
scale
I
wonder
if
anybody
in
the
group
has
opinions
that
we
can
use
to
jump
start
the
discussion
around
what
that
might
be
keeping
in
mind.
We
have
about
nine
minutes
left
dedicated
to
this
topic.
B
A
D
People
don't
feel
like
they
have
to
rush
things.
You
know
they
have
to
prove
it
to
within
a
day
or
so
so
it
should
give
them
these
a
couple
of
days
to
review
it
and
then
stuff
like
that.
But
at
the
same
time
anybody
has
a
veto
power.
That
means
it's
obviously
not
consensus
based
and
we
need
to
go
back
and
review
it
and
discuss
it
and.
B
A
That
we
have
already
in
the
work
for
Cooper,
Nettie's,
Cooper,
Nettie's
I
think
that
a
long
term
there
will
be
some
kind
of
easy
way
to
engage
those
BOTS
and
get
that
same
kind
of
functionality.
But
I
agree
with
you
vla-4
now.
I
think
we'll
probably
have
to
establish
a
convention
that
you,
your
PR,
has
a
TTL.
If
it's
not
merged
or
not
action
on,
if
it
could
fail,
it
just
be
close
to
avoid
accumulating
stale
PRS.
G
F
F
A
A
B
A
Sorry
didn't
mean
to
interrupt
I,
don't
know
yeah.
That
was
done.
How
about
we
call
it
one
day.
This
is
a
very
small
repository
right
now
and
I
I
am
personally
trying
to
allocate
that
the
majority
of
my
attention
on
this
repository.
So
if
we
feel
as
a
group
that
we
all
want
to
be
equally
involved,
then
perhaps
we
can
expect
that
changes
get
reviewed
within
24
business
hours
or
24
hours
within
the
business
week
at
this
and.
H
A
Lgtm
from
a
committer,
I
think-
and
I
do
have
a
I-
do-
have
a
to
do
to
add
some
of
the
dais
focuses
as
committers
we
have.
Currently,
it
should
be
Brendan
belay,
Doug,
Morgan
and
myself
are
n,
committers
and
yes,
Aaron
I,
think
committers
have
veto
power
and
I
am
going
to
add
heron
and
I
can't
as
committers.
Unless
there
are
objections,
because
the
dais
folks
have
made
some
fantastic
contributions
to.
H
A
So
my
overriding
feeling
that
I
want
to
communicate
on
on
this
recording
is
that
I
I
have.
I
have
a
high
degree
of
respect
and
Trust
for
everybody.
That's
involved
in
this
effort
and
I
think
that
we
should
I
sincerely
doubt
we
will
get
into
the
situation
where
the
no
no.
We
cannot
like
resolve
these
things
without
going
to
the
rule
book,
so
I
I
think
we're
all
mature
people
I
doubt
there
will
be
a
problem,
but
it's
it's
also
good
to
clearly
communicate
expectations.
I.
A
I
Sure
I
was
just
going
to
save
it.
I
recommend
reserving
the
the
heavier
weight
policies
about
you
know
three
days
or
three
LG
teams
or
whatever
for
major
changes
like
api
and
architectural
changes
and
allow
mirror
implementation
changes
to
go
in
with
single
log
m
and
passing
tests
that
much
like
we
do
in
other
repos
yeah.
I
D
A
A
Or
let
me
put
it
this
way:
safer,
API
changes
and
architecture
changes
that
we
extend
the
window
to
two
days
uncle
and
for
lighter
weight
changes.
I
think
that
we
can
for
something
like
a
lint
cleanup,
maybe
a
simple
lgtm
and,
as
Brian
said,
passing
tests
are
probably
sufficient.
Well
I.
Think
if
there's
any
question,
then
you
escalate
to
the
to
the
more
formal
process.
D
But
if
you
have
to
be
horrible,
if
we
started
with
just
a
single
process
and
then
wait
until
we
had
a
problem
that
caused
us
to
add
more
bureaucracy,
I
I
just
get
very
nervous
about
this
idea
of
trying
to
delineate
art
bar
everybody
on
the
same
page,
and
here
was
a
what's
minor
versus.
What's
bigger
and
I,
don't
want
to
get
into
those
discussions,
I'd
rather
to
say
here's
our
process
so.
A
I
would
I
would
prefer
to
start
with
something
lighter
weight
since
I.
Don't
expect
that
we'll
have
a
lot
of
architecture,
changes
at
first
home
and
go
to
something
more
formal
once
we're
talking,
architecture,
changes
and
informing
my
position
on
this
is
that
I
expect
that
probably
the
largest
architecture
change
is
transitioning
to
like
first
class
API
in
an
API
server
from
tpr.
F
So
my
view
is
that,
following
what
I've
seen
in
the
go
project,
very
roughly
there's
a
design
dog
process
where
design
doc
is
required,
not
necessarily
inside
of
a
PR
but
could
be
a
Google
Doc.
The
design
doc
is
then
discussed
in
our
case.
It
would
be
discussed
in
a
sig
meeting
after
the
design.
Doc
is
ratified.
It
goes
into.
It
basically
is
just
linked
from
the
repo
and
once
that
goes
in,
then
it
just
becomes
an
implementation
PR,
which
then
can
just
be
a
one
lgtm
one
day,
minimum
PR
so
in
in
reality.
F
A
This
is
very
similar
to
what
we
do
in
in
Coober
Nettie's,
where
the
API
change
API
changes
that
typically
have
a
proposal
associated
with
them.
That
is
reviewed
emerged
before
implementation
begins.
I
tell
you
what
I
I
have
an
idea
for
a
compromise
that
can
get
us
over
this
hump,
so
we
can
talk
next
steps.
Why
don't
we
say
this
I?
Don't
think
that
we
expect
any
API
changes.
I,
don't
think
we
expect
any
API
changes.
Currently
we
probably
have
many
small,
cleanups
and
subtractions
to
do
so.
I
tell
you
what
why
don't?
A
B
Yes,
yes
and
I
think
it's
also
easy
to
add
process
later
on,
to
address
shortcomings,
I
think
difficult
to
go
ahead
and
spend
a
ton
of
time
right
up
front
when
right,
there's
gonna
be
corner
cases
and
everything
else
and
and
I
think
we
are
mostly
sometimes
myself
included
adults
here.
So
we
can
go
ahead
and
self
police
for
the
time
being.
Yeah.
A
So
closing
that
topic
out,
let's
revisit
the
the
code
that
was
demoed
I'll,
kick
off
the
the
conversation
by
saying
that,
like
I,
the
probably
the
biggest
dimension
that
is
different
in
this
demo,
from
what
you
agreed
about
or
what
we
agreed
to
in
face-to-face
meetings
is
the
lack
of
the
binding
resource
Brendan.
You
already
brought
that
up.
A
C
A
A
C
C
That,
right
now,
the
service
controller
has
has
a
block
of
code
that
says,
I
now
have
a
binding
that
has
credential
information.
What
do
I
do
with
that?
Credential
information
and
what
it
does
right
now
is
calls
a
function
that
doesn't
update
on
the
consuming
service
instance,
and
that
needs
to
be
replaced
with
a
function
that
creates
a
secret
and
a
config
map
and
a
service
in
the
cost
per
game.
Everything.
C
A
C
C
A
So
I
agree
with
you
with
the
caveat
that
we're
going
to
eventually
approach
the
limit
of
what
is
possible
to
do
without
making
an
API
server.
So
since
this
is
a
short
week,
I'm
not
really
expecting
a
lot
of
changes
this
week.
In
fact,
for
all
I
know
the
folks
that
are
working
on
this
now,
you
all
could
be
all
you
all
could
be
taking
the
rest
of
the
week
off.
A
I
do
think
that
there
is
additional
discussion
that
needs
to
happen
on
the
API
types
before
we
are
able
to
to
start
adapting
into
them,
and
we
also
needed
an
API
server
for
them
to
live
in.
This
is
something
I
really
like
to
discuss
next
week,
just
because
we're
at
a
time
for
now
pretty
much,
but
if
we
could,
if
we
get
a
highlight
one
actionable
change
that
could
be
made,
I
know
that
that
it's
been
brought
up,
that
there
are
some
deletions
be
made.
I
love,
I
love
code
deletes.
A
If
you
have
code
delete
PRS,
please
bring
them
and
will
pair
this
thing
down
before
we
make
it
any
bigger,
and
this
is
my
suggestion
I
suggest
code
deletions.
Awesome
do
them.
I
suggest,
if
there's
any
actionable
change,
that
it
should
be
the
behavioral
change
of
making
a
secret
and
service
that
brendan.
I
hit
upon
now
any
objections
there.
I.
B
I
B
I
On
comment,
I
don't
know
if
it
was
discussed
before
that's
one
common
work
around
with
third-party
resource
that
they
help
us
get
a
little
farther
is
to
actually
create
separate
resources
for
spec
and
status
so
that
you
don't
have.
If
you
actually
need
to
report
back
status,
you
don't
clobber
this
back
provided
by
the
client.
I,
don't
know
if
you
run
into
that
problem,
but
if
you
have
that's
sort
of
the
typical
work
around
so.
A
A
I
B
It's
a
one
request:
I
had
12
people,
okay,
one
of
them
is
boiling
worse
to
the
conditions
and
things
like
that
in
run
the
document
AKA.
So
when
we
come
in
on
monday,
it's
not
the
nobody
knows
what
we
are
talking
about
and
the
second
one
is
any
kind
of
example:
pointers.
The
API
servers
for
the
Federated
API
servers
that
we
could
have
as
homework
to
do
for
next
Monday.
Okay,.
A
A
H
To
figure
out
a
best
way
to
help
everybody
building
the
code,
because
some
folks
have
had
issues
and
because
I
built
to
make
files
I
cannot
for
the
life
of
me
reproduce
any
of
them.
So
I
want
to
find
a
way
to
help
you
guys,
but
me,
trying
locally
is
not
at
it,
because
I
always
succeed.
Try
try
putting
your
source.