►
From YouTube: Kubernetes SIG Service Catalog 2019-8-12
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
Okay,
we
are
recording
hello,
everybody
and
welcome
to
the
August
12th
meeting
of
SIG's
Service
Catalog
feel
free
to
fill
in
your
name.
If
you
hear
showing
up
late,
I'm
gonna
go
ahead
and
skip
judging
you
issues
because,
like
I
said,
I
kind
of
gotta
go
so
straight
down
to
the
agenda.
I
Mateusz,
you
have
someone
there
yeah.
B
So
basically,
it's
quite
short
what
we
have
I
don't
find
out
today
that
we
have
a
broken
chart
on
the
master
branch.
Basically,
we
added
a
parameter
to
devalue,
see
on
file,
but
we
didn't
bump
the
image
version,
so
the
binary
is
outdated.
When
we
install
that
char,
then
we
have
the
problem
that
the
parameter.
The
argument
is
invalid,
because
it's
not
set
up
in
the
binary
and
fix
for
that
is
quite
easy.
B
A
B
B
A
B
A
So,
just
what
I've
been
working
on
so
I've
been
working
on
bump
a
coupe
1:15.
It
came
out
right
before
I
left
to
go
to
all
those
conferences,
so
I
haven't
gotten
around
to
until
now,
I've
been
grappling
with
a
whole
bunch
of
tests
were
broken
and
eventually
I
figured
out
that
the
reason
these
sets
are
broken
aren't
because
of
anything
and
goo
bump.
A
So
when
I
bumped,
the
qu
bump
I
also
just
have
constructed
all
the
a
lot
of
the
the
regular
other
dependencies
and
apparently
P
mori,
the
guy
who
sort
of
maintains
the
library
we
actually
used
stock
service
brokers
added
some
stuff
in
his
library.
That
was
that's.
What
was
causing
a
whole
bunch
of
our
chests
ofili's,
including
some
checks
in
his
is
testing
package
that
used
to
not
be
there
and
that's,
causing,
like
literally
every
single
one
of
our
integration
tests
to
fail,
because
we're
not
not
because
our
tests
are
wrong
per
se
they're.
A
Just
not,
they
don't
have
all
the
setup
for
all
the
stuff
that
it's
expecting.
The
common
request,
which
previously
did
not
have
these
checks,
so
we're
gonna
have
to
bump
that
anyways.
When
we
start
working
on
updating
to
OSB
spec
214
at
you,
15
or
whatever
so
I
figured
I'll
just
put
that
off
until
then,
so
I
reverted
the
bump.
Just
to
that
one
specific
package,
and
now
the
Kubb
115
bump
should
be
going.
Green
I
was
looking
at
it
over
the
weekend.
The
X
build
thing
was
giving
me
crap
yeah.
A
B
B
B
His
own
his
own,
because
he
need
to
add
some
boiler
plates
to
play
that
and
it
was
done
two
hours
ago,
so
I
think
that
the
new
features
should
be
moved
right.
He
added
the
first
one
three
hours
ago
and
I
saw
that
also
Nikita
is
working
on
that.
Okay!
Well
him!
So
maybe
you
can
just
wait
for
moving
that
repository
under
current
the
six
right.
C
So
this
is
the
stuff
that
we
prepared
in
order
to
be
able
to
release
from
two
branches
simultaneously.
Some
from
the
this
is
something
that
we
will
need
after
migrates,
finally,
to
this
year,
crt-based
solution
and
I
tested.
If
you
were
able
to
simultaneously
release
our
artifacts
and
I
described,
prescribed
what
needs
to
be
changed
basically,
I
mean
I.
I
know
that
you
were
short
on
time,
but
I
just
wanted
to
mention
a
few
bullets
bullet
bullet
points.
C
Yeah,
just
everything
what
I
will
say
is
it's
described
in
the
ticket,
but
basically
the
idea
is
that
every
time
we
will
need
to
create
a
new
version
or
a
new
line
of
Service
Catalog,
and
we
will
create
a
new
branch
like
right.
Now
we
could
create
a
new
branch
named
API
server
to
the
old
one
and
all
the
artifacts,
almost
all
the
artifacts
that
we
released
so
docker
images
as
we
cut
and
pound
chart
can
be
just
so
fixed
with
the
branch
name.
C
So
first
proposal
was
that
we
could
use
something
like
API
server,
but
the
general
solution
would
be
to
use
something
like
vv0
so
in
in
the
future.
When
we
have
a
next
breaking
release
like
0.4,
for
instance,
then
we
can
just
create
a
new
branch
named
0.3
and
append
the
suffix
to
to
the
artifacts
with
0.3.
So
we
can
release
once
again,
ideally
patches
to
their
to
their
old
release.
So
so
the
idea
is
quite
simple
and
I
tested
it
on
a
separate
project.
C
I
created
an
integration
with
Travis
on
my
on
my
second
account
and
I
used.
Also,
the
Quai
repository
the
Google
DCP
cloud
for
for
for
the
Ezra
cut,
artifacts
and
so
on,
and
everything
works.
The
the
only
issue
is
that,
with
the
with
this
hand,
chart
because
we
have
to
just
change
to
the
name
of
the
of
the
of
this
hand,
chart
because
it's
it.
There
is
no
way
in
hell
to
specify
that
a
given
version
is
the
latest
has
a
latest
attack.
C
The
the
latest
version
in
helm
is
just
the
one
that
you
released
us
reset
most
recently,
so,
for
instance,
if
you
want
to
release
a
part
for
a
version
0.2,
this
will
be
treated
as
a
newest
one.
Even
if
a
repository
there
is
already
a
version
0.3
or
even
higher.
So
we
need
to
change
the
name
of
the
hand
chart
to
something
like
catalog
underscore
ipi
server,
and
if
a
customer
needs
to
install
our
back
port
to
to
the
old
branch,
then
he
will
need
to
specify
manually
upgrade
the
name
of
the
release.
A
C
A
new
chart
name,
so
in
this
case
it
will
be
a
catalog,
API,
server
or
catalog
underscore
zero
point.
Zero
points
do
something
like
that.
So
if
he
won't
specify
any
will
not
specify
anything,
then
he
will
be
automatically
upgraded
to
a
CD
based
version
and
this
stuff
is
described
in
this
ticket.
So
the
the
only
minor
issue
may
be.
Is
that
if
you
using
something
like
docker
latest
stack,
then
there
will
be
no
warning.
You
will
be
just
well.
C
You
just
start
using
the
the
newest
version,
catalog
with
potentially
breaking
changes.
So
does
your
the
best
solution,
because
we
will
append
the
the
API
server,
keyword
or
zero
pinpoint
to
even
to
add
latest
stuck
in
docker.
So
we
have
something
like
latest
underscore
points
to,
or
API
server
or
whatever
I.
Don't.
C
I
think
that's
basically
I.
Don't
think
that
we
have
any
issue
that
we
should
worry
about.
That's
something
that's
out
of
ordinary
for
for
the
kind
of
change
we're
doing
right
now,
so
it
looks
quite
quite
good.
We
tested
the
update
scenarios
between
when
we,
when
you
change
the
column,
chart
name,
it
works
okay,
so
and
the
most
important
stuff
is
that
a
in
the
make
file
we
were
using
this.
This
clever
tweak,
we've
we've
get
this.
This
is
there.
C
C
So
if
you
were
releasing
the
patch
for
for
the
version,
zero
point
to
something
that
was
the
well
inherited
from
version
zero
points
to
then
the
whole
pipeline,
the
whole
build
process
will
behave,
behave
correctly,
cuz
the
the
magic
one-liner
the
get
get
a
one-liner
will
give
you
a
last
release
from
this
branch
and
the
current
commit,
and
something
like
it
stuff
like
that,
so
that
we
can
simultaneously
own
not
nothing
in
the
same
time.
Obviously,
but
you
can
release.
A
C
Version
0.31
and
then
after
a
few
minutes,
you
can
release
the
version
zero
point
two
and
everything
will
be
kept
in
in
sync.
All
the
images
will
take.
All
the
built
processes
will
take
a
correct
version
of
sources
and
we
will
release
artifacts
that
are
correctly
named.
So
I
guess.
This
is
a
good
news,
because
we
don't
have
to
change
much
great
yeah,
so
that'sthat's
in
a
shortcut.
What
we
did-
and
we
just
want
to
well
somehow
do
to
validate.
B
Simultaneously,
so
maybe
from
my
side,
the
question
is
because
I
already
go
for
that
description
and
I
I,
don't
see
any
problems
with
that.
It
should
work
for
both
approaches
and
the
question
for
you
Jonathan
is:
are
we
able
to
configure
that
repository
current
repository
to
use
that
new
strategy
and
release
new
version
I
think
that
will
be
0.2
.
with
the
NEPA
process?
C
So
basically,
we
could
create
the
v2
branch
right
now
and
adjuster
with
all
the
patches
that
you
created
and
try
to
commit
the
modification
that
are
specified
in
the
ticket
in
the
issue
and
then
we
could
test
if
the
process
is
okay.
If
everything
is
as
expected
and
then
you
can
release
work,
then
we
can
just
replace
the
master
branch
with
that
with
this
year,
D
based
solution.
Obviously
after
we
validate
the
wholesale
dissolution
with
you,
yeah.
A
B
Mean
once
the
cube
bump
gets
marriage,
there
was
probably
gonna
cut
one
man,
so
1.15,
yeah,
okay
and
and
just
a
question.
Besides
that
we
want
to,
we
always
need
to
bomb
the
cube
version
service
catalog.
There
is
some
kind
of
the
agreement
between
the
repositories
under
the
26
that
we
need
to
follow
the
newest
kubernetes
version
or
it's
our
idea
about
it.
I
mean.
A
B
A
B
Okay,
okay,
so
that
I
get
it.
So
that
was
the
reason,
but
because
I
thought
that
there
is
some
kind
of
these
standards
that
we
need
to
follow
to
be
always
up
to
date,
but
yeah
so
I
think
that
maybe
we
can
just
maybe
not
in
depth,
maybe
in
that
week
or
but
or
in
the
next
week,
because
in
that
week
we
have
some
bank
holidays,
I
think
in
Poland.
So
maybe
next
week
will
be
a
little
bit
better
to
just
configure
the
26
typical
agrippa
story
and
cut
a
new
release
with
2.2.