►
From YouTube: SIG Service Catalog 20170313
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
B
It
might
be.
Can
you
hear
me
I
can
hear
you
super
yeah.
So,
for
the
last
couple
weeks
we've
been
putting
together
a
talk
for
the
GCP
next
and
I
believe
the
YouTube
video
of
that
was
posted
on
the
chat
slack
channel,
so
that
people
can
go
in
and
check
it
out
themselves.
But
basically
the
idea
was
we
want
to
go
and
demonstrate
what
a
couple
of
different
things
one
of
them
was
what
what
is
this
whole
point
of
having
service
catalogs
brokers
and
everything
else.
B
B
B
So
we
showed
up
a
little
bit
at
that
and
then
we
it's
kind
of
tied
all
together,
that
by
using
these
two
things
together,
you
have
a
pretty
good
story
for
being
able
to
say:
I
can
go
and
start
managing
these
services
and
not
worry
about
the
infrastructure
bits
quite
as
much,
and
we
make
per
usual
plugs
about
the
status
of
the
world,
P,
alpha
and
so
forth.
But
we
put
the
links
in
there
and
it
was
very
well
attended
to
talk.
B
So
there
was
standing
room
only
and
Martin
a
great
job
talking
about
it
as
well
as
the
gluey
Ryan
from
these
deals,
so
they
were
smart
in
can
home
who
was
representing
us
from
the
Service
Catalog
side
of
the
things,
and
then
there
was
a
Louie
Ryan
from
the
ischial
side
of
things.
So
that's
about
it.
Unless
there's
any
questions
and
the
video
again
has
been
posted
into
here
and
I-
think
yeah.
A
That's
awesome,
so
I
I
have
noticed
that
a
few
people
enjoying
the
slack
Channel
and
said
that
they
found
it
from
the
from
the
the
GCP
next
time.
So
that's
pretty
cool
I
expect
that
we'll
probably
have
the
same
thing
happened
after
the
the
Q
con
talk
and
panels
associated
with
this
work,
so
on
that's
a
good
segue
into
MVP
2,
which
is
what
is
on
the
agenda
to
talk
about
next.
Unless
anybody
has
questions
for
viewing.
B
A
There
are
going
to
be
a
lot
of
folks
that
are
really
interested
in
one
using
what
we've
done
so
far
and
to
contribute
so
the
where
we
left
MVP
after
we
sorted
sort
of
things
out,
is
that
we're
going
to
be
focusing
on
getting
to
the
functional
point
of
like
we
have
something
that
we
can
show
which,
from
a
functional
standpoint,
I
actually
think
that
we're
pretty
close.
Basically
what
I?
A
We
need
to
add
sorry
going
started
ringing.
We
need
to
have
the
docs
together.
We
need
to
have
test
to
the
greatest
possible
degree
so
that
we
can
more
easily
onboard
people
when
they
come
on.
We
also
need
to
have
a
way
for
you
to
be
able
to
run
the
catalog
with
that.
Having
built
it
yourself
so
I
as
we
go
through
the
issues
that
are
that
are
in
this
MVP
to
milestone.
You'll,
probably
notice
that
that
is
a
general
theme.
A
It's
just
sort
of
clean
up
the
house,
so
I'm
just
going
to
make
a
run
through
the
outstanding
issues.
If
you
have
any
questions,
just
do
whatever
your
best
impression
of
raising
your
hand
in
this
medium
is
so.
The
first
one
is
publishing
dr.
images
from
master,
and
this
dovetails
into
the
last
thing
that
I
mentioned
that
they're.
Ideally,
you
would
not
have
to
build
the
catalogs
in
order
to
be
able
to
deploy
it,
so
that
issue
is
to
publish
docker
images
into
the
right
tags
from
master.
A
The
next
one
is
handle
conversion
of
service
and
plan
metadata
and
into
our
API.
So
what
this
is
is
like
air.
You
can
send
a
JSON
object
back
from
the
broker
that
has
metadata
about
services
and
plans
in
it,
and
there
are
some
conventional
fields
that
used
to
be
documented
in
the
API.
They
appeared
to
be
to
have
been
inadvertently
removed.
Recently
I
made
a
tissue
to
add
them
back
in,
but
then
there
are
these
conventional
fields
and
then
you
can
send
brokers
can
send
other
fields
on
in
them.
A
So
we
need
to
model
this
the
right
way
in
the
API.
The
next
one
is
to
add
some
integration
tests
for
TPR
storage,
which
I
think
should
be
pretty
self-explanatory.
Next
one
is
controller
integration
tests.
We
have.
We
had
some
that
Morgan
put
in
a
couple
weeks
ago,
before
he
left
last
week,
I
started
adding
on
to
this
to
basically
have
an
integration
test.
A
It
implements
the
flow
that
I've
shown
in
the
demo,
and
in
doing
this,
I
found
it
like
the
fake
broker
server,
not
the
fake
client,
the
actual
fake
broker
server
has
some
things
that
it
needs
to
do
more
correctly,
so
I'm
working
on
that
one
right
now.
Next
up
is
related
to
release
process
stuff.
Like
tag
docker
images
with
the
appropriate
labels,
I
know,
there's
been
some
discussion
in
slack
today,
so
hopefully
we'll
get
that
sorted
out.
A
Next
one
is
somewhere
test
coverage
needed
for
some
of
the
TPR
stuff
and
then
hey.
It
looks
like
488
and
529
are
basically
duplicates
of
one
another,
so
maybe
we'll
just
close
488
later
on
529,
the
PR
that
closes
488,
oh
I,
I
wasn't
looking
at
little
icons,
okay
got
it
cool
next
is
MDE
for
the
walkthrough,
which
the
demo
that
I've
shown
we
now
have
the
walkthrough
in
the
developer,
guide,
Docs,
basically
being
able
to
recreate
that
and
I
would.
A
I
would
like
to
have
some
my
personal
desired
state,
for
this
is
that
the
demo
that
we
give
for
this
should
be
the
walkthrough,
and
that
should
also
be
in
de.
So
we
can
one
establish
that
the
walkthrough
stays
working
to
make
it
possible
for
anybody
to
just
go
through
the
walkthrough
for
an
audience
and
give
the
same
basic
demo
that
that
you
know
anybody
else
could
so
that's
what
that
is.
Next
one
is
make
API
server
health
check
fail
until
all
pprs
have
been
created.
I
think
Simon's
working
on
that
one
right
now.
A
Next
one
is
implement
async
provision
and
deprovision
I
think
VLA
you're
working
on
that
one
right
now
and
next
one
is
another.
Tpr
implement
storage
version
errs
update
list
function,
I'll
be
honest
with
you
guys,
I,
don't
actually
know
exactly
what
that
one
is
enter
here,
and
can
you
say
what
that
one
is.
A
Sure
so
there
are
quite
a
few
functions
to
implement
the
TPR
backend
for
our
api
server.
Almost
all
of
them
have
been
implemented,
but
there's
one
more
called
update
list.
I
see
Kent
Kent.
Do
you
want
to
do
you
want
to
explain
this
or
you
called
me
continuing
I
said
no,
sir.
Now
you
can
continue
I
think
you
can
explain
it
better
than
I.
Can
you
can
go
on
the
one
writing
it?
Okay,
so
yeah
there
are.
A
There
are
quite
a
few
functions,
basically
to
do
crud
and
watch
and
a
few
high-level
crud
like
action
in
our
implementation
of
the
API
server
storage
database
that
uses
TP
RS.
There's
one
more
function
called
update
list.
That's
currently
not
used
by
our
controller
manager,
but
is
nevertheless
pretty
important
to
have
update
list
is
probably
pretty
self-explanatory.
It's
obviously
to
update
a
list
of
objects.
A
Hopefully,
that
makes
sense
cool,
so
the
next
one
is
about
determining
what
conditions
we
have
in
the
API.
We
have
a
number
of
constants
for
conditions
that
we
don't
use
that
we're
added
honestly.
They
go
as
far
back
as
the
the
first
face
to
face,
and
we
should
take
those
out
to
expose
the
surface
area
of
things
that
can
confuse
people
when
they
come
in
and
look.
But
then
we
also
need
to
figure
out
which
ones
we
do
actually
want
and
need.
A
Michael
QA
has
been
working
on
this
one
and
from
a
conversation
that
I
had
with
them
shortly
before
the
meeting.
I
think
that
that
the
continuous
integration
piece
of
it
seems
like
it's
ready
to
turn
on,
and
hopefully
we
can
do
that
in
the
next
day
and
then
what's
remaining
is
having
being
able
to
have
an
EDD
tests
that
run
in
that
continuous
integration.
That's
a
bigger
hurdle
to
get
over
because
we
need
a
kubernetes
cluster
and
you
need
to
have
a
catalog
that
played
into
it.
You
have
a
broker
deployed
into
etcetera,
etc,
etc.
C
Comment
a
little
bit
on
that:
okay
yeah,
so
the
integration
into
github.
Yes,
that
should
be
good
to
go.
I
was
able
to
revert
the
github
integration
plug-in
so
now
we
don't
need
the
admin
rights
on
the
repo
immediately,
so
that
should
be
good
to
go
later
today.
The
intend
so
with
that
we
are
able
to
get
Travis
equivalency
and
the
into
end
section.
C
So
all
the
things
you're
mentioning
about
like
spinning
up
the
cluster
and
everything
I
already
have
all
that
solved
as
it's
going
to
spin
up
in
GCP,
but
it's
going
to
spin
up
regardless,
so
I
have
that
section
solved.
So
that's
not
hard
at
the
moment.
The
only
issue
is
now
that
the
this
controller
has
changed
a
bit.
I
need
to
modify
I
just
need
to
follow
the
new
walkthrough
basically
and
get
that
the
code
they're
up
to
parity,
but
that
shouldn't
be
actually
a
big
issue.
A
A
Sorry,
so
that's
that's
that's
good!
What's
missing
is
what's
missing,
is
a
test
binary
that
implements
that
EE
and
as
far
as
I
understand,
there
is
an
issue
with
the
pin
verging
on
kubernetes
that
were
using
so
that
we
can't
consume
the
kubernetes
kubernetes
mm-hmm
stuff
until
after
we
rebase
I,
actually
think
that
there
is
an
el
cheapo
solution
to
it,
where
we,
maybe
don't
even
use
the
upstream
Iggy
stuff,
but
we
can.
We
can
talk
about
that
later
anyway.
A
There
there
are
some
additional
challenges
beyond
just
getting
the
stuff
deployed
that
we
can
talk
about
Michael
all
right,
so
next
up
is
support
for
pod
preset,
which
is
the
resource
formerly
known
as
PIP.
We
went
through
a
couple
iterations
of
bike,
shedding
on
the
name
to
do
this,
one
we
have
to
rebase
on
the
kubernetes
1/6,
which
astute
observers
will
notice.
A
There
is
an
issue
for
that
one
too,
but
basically
for
those
of
you
that
aren't
aware
the
pod
preset
is
what
allows
you
to
declaratively
say
as
part
of
the
binding
which
pods
in
your
namespace
should
be
injected
with
information
about
how
to
use
the
service
your
binding
to
and
how
they
should
be
injected
with
it,
whether
that's
environment
variables,
whether
it's
volumes,
etc,
etc.
And
so
this
is
a
pretty
important
part
of
the
value
proposition
piece
for
Service
Catalog.
So
that's
that's.
Definitely
something
we
want
to
get
in
MVP
any
questions
about
that.
A
A
A
So
there
have
been
a
lot
of
API
machinery
factors
since
we
last
are,
since
the
version
of
kubernetes
that
were
into
and
when
we
rebase,
we
should
be
able
to
do
a
number
of
things
that
were
kind
of
locked
on
right
now,
just
due
to
the
situation
in
in
the
in
the
version
worked
into
so,
for
example,
those
of
you
that
have
been
looking
at
the
controller.
Some
of
you
have
noticed
I
in
some
cases,
rather
violently
that
the
that
we
use
both
the
Kas
io
/
kubernetes
api
packages
and
the
client
go
api
packages.
A
So
as
an
example,
the
reason
that
we
have
to
do
that
is
because
the
dependency
on
the
kubernetes
packages
wasn't
removed.
A
So
that's
what's
an
MVP
our
target
date
for
this
is
March
17th,
because
we
really
want
to
get
these
things
taken
care
of
well
before
cube
con
as
a
follow
up
to
this,
we
created
another
milestone,
called
MVP
3
I'm,
not
certain
what
the
timing
is
going
to
be
on
that,
but
we
need
to
be
getting
to
a
place
where
we're
cleaning
up
like
small
details,
making
the
developer
experience,
good,
etc,
etc,
etc.
So
a
bunch
of
stuff,
it's
an
MVP
3
is
around
that.