►
From YouTube: Cloud Foundry for Kubernetes SIG [July 2020]
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
C
Good
thanks-
and
we
have
quite
a
few
folks,
already
joined
so
probably
we'll
wait,
another
minute
or
so
and
then
get
started.
D
B
C
Very
scary,
okay
for
past
I
guess
we
should
get
started
quite
a
few
folks
on
on
the
call
today,
thanks
everybody
for
joining
this
time,
we
have
sai
from
the
relent
team
and
I
think
by
and
large
the
topic
is
cfo
kate's,
but
then
I
think
so
you
wanted
to
talk
specifically
about
a
couple
of
sub-topics,
so
custom
builder
store
and
stack,
not
sure
if
that
is
still
the
plan
of
record,
but
I
would
hand
it
over
to
you.
D
Yeah,
so
my
hope
was
today
to
talk
about
two
topics:
I'll
try
to
do
it
in
about
15
minutes
each,
maybe
and
see
how
it
goes.
What
I'm
trying
to
get
to
is
like
create
more
informational
sessions,
so
I
would
love
to
hear
general
feedback
from
you
all.
D
Maybe
it
you
know
separate
office
hours
or
videos,
but
my
hope,
with
this
session,
was
just
to
talk
about
the
new
custom
builder
that
we
that
we
sort
of
built
for
kpac
and
then
also
talk
about
the
upgrade
up
time
checks
we've
been
doing
and
how
it
is
helping
the
contributing
teams
and
the
path
towards
our
to
meet
our
some
of
our
upgrades
and
uptime
slos.
So
that
was
my
sort
of
very
informal
educational
informational
session
sounds
good
cool.
D
D
All
right
sounds
great,
so
let
me
adjust
my
screen.
B
B
D
D
My
bad,
I
don't
know
what
you're
talking
about
yeah.
This
is
my
startup
before
startup.
I
have
completely
forgotten
about
it
and
that
message
now
is
like
numb
to
me.
So
you
just.
D
Yeah
yeah,
I'm
like
what
do
they
get
blind
to
that
message?
Cool
you
can
see
my
my
I'm
assuming.
Obviously
you
can
see
my
chrome
right,
like
everyone,
mm-hmm,
okay,
cool
all
right,
so
it's
a
quick
intro
to
custom
builder.
I
think
we
in
the
past
we
had
a
default
builder
that
we
use
that
actually
used
all
of
the
contained
all
of
the
language
bill
packs.
So
this
was
the
one
that
we
used
in
the
past.
D
So
the
the
challenge,
with
the
using
all
in
one
build
builder,
which
actually
contained
all
of
the
language
build
packs,
was
we
didn't,
have
a
control
on
the
types
of
language
build
packs
we
want
to
use.
That
was
one
and
the
challenge.
The
other
challenge
was
any
single
language
that
gets
updated.
D
Every
the
whole
builder
gets
updated,
which
is
you
know,
a
pain
in
the
ass
when,
if
you
had
multiple
languages
getting
updated
at
the
same
time,
we'll
get
consecutive
big
builder
images
in
a
row.
So
so
that's
something
that
we
weren't
happy
about
and
then
what
we
wanted
to
do
is
sort
of
expand
that
into
a
more
spelled
out,
build
packs.
Now
I
may
be
talking
about
store
and
stack.
Maybe
not
everyone
knows
what
it
is.
So
let
me
just
talk
about
how
k
back
works
for
a
second.
D
D
It
will
take
that
base
image
and
then
we'll
use
the
language
bill,
packs
which
I'll
show
you
in
a
moment
and
builds
the
app
based
on
that.
So
the
language
build
packs.
Let's
say
java
python
have
very
two
distinct
set
of
steps.
One
is
detect.
We
will
try
to
detect
if
this
is
the
right
language
and
then
build
so
if
it
detects
a
python,
then
the
python
bill
pack
will
take
care
of
that.
So
each
language
build
pack
goes
through
a
series
of
checks
to
see.
D
If
is
this
something
I
should
be
building
and
if
it's
true,
then
it
builds
it
so
so
the
language
bullpacks
go
under
this
crd
called
store,
which
lists
all
of
the
language
bill
packs
and
the
stack
is
just
a
stack.
That
is
a
base
image
that
you
use
to
build
the
image
and
now
also
the
image
that
you
use
for
running
that
image
itself.
D
So
those
are
the
two
constructs
that
bill
capec
uses
in
this
case.
Actually
the
bill
pack
spec
that
uses
to
build
the
app
images
and
so
custom
builder.
Oh
okay,
someone
had
a
question
great.
What
custom
builder
does?
Is
it
actually
stitches
them
together?
So
we'll
take
the
store
list
of
all
of
the
languages
that
that
it
it's
possible
to
build,
and
then
there
is
the
stack
which
is
the
underlying
stack
image
and
then
the
key
part
is
that
the
group,
what
the
group
does
is
really
is
ordering
of
the
order
in
the
group.
D
So
the
order
tells
you
in
what
sequence
do
you
want
to
go
through?
So
is
it
java?
Is
it
note,
first
go
and
a
dot
net
core,
and
then
you
can
define
any
number
of
sort
of
additional
languages
you
know
in
that
group
and
in
that
order,
so
why
you
know
this
is
one
of
those
places
where
the
operators
actually
could
modify,
but
the
way
we
are
packaging.
This
is
like
these
are
the
default
build
packs
that
will
package
with
cfo
codes.
D
All
right,
so
the
the
key
thing
about
the
order
is
that
each
of
these
languages
actually
have
a
sub
languages
or,
I
would
say,
sub
components
such
as
within
java.
You
may
have
tomcat-based
java
app
and
within
say
it
could
be
maven
based
build
maven
based
app
building.
D
So
each
of
these,
when
you
see
java,
there
are
many
other
sub
par
components
or
language
packs
to
that,
so
that,
because
it
to
understand
the
different
flavors
in
which
you
can
build
java,
an
app
so
same
thing
with
go
to
there
may
be
just
a
go
binary
to
go
a
web
app.
So
each
of
these
will
have
on
you
know,
sub
language
packs
that
will
detect
if
this
is
actually
a
web
app.
Is
it
a
binary
so
on
and
so
forth?
D
So
if
you
go
to
the
actual
pocato
bill
pack,
slash
java,
you
will
actually
see
a
list
of
sub
packs
under
each
top
level.
Language
and
that's
the
beauty
of
the
kpac
packet,
takes
care
of
that
it
will
make
sure
it
actually
automatically
runs
through
those
sub
packs.
If
needed,
we
don't
have
to
spell
them
out
here.
We
just
spell
out
the
the
top
level
language
pack,
so
so
given
sort
of
like
these
three
constructs,
so
these
are
all
crds
from
kpac.
D
What
we
did
is
we
spelled
them
out
individually
so
now
so
this
was
previously
just
one
massive
monolithic
builder,
who
went
to
then
create
individual
language
packs,
so
the
store
enumerates
individual
bill
packs.
There
are
a
couple
of
advantages
here.
We
can
now
actually
update.
You
know
individual
build
pack
when
there
is
a
let's
say,
an
update
to
that
ruby.
This
is
very
similar
to
how
we
do
in
cf
deployment,
where
we
have
individual
language
chain.
D
D
So
that's
like
another
advantage
that
they
may
they
have
when,
when
sort
of
using
cloud
native
build
packs
so-
and
I
think-
and
I
think
what's
interesting
about
the
the
custom
builder,
as
you
can
see
now
we
have
much
more
expanded
order.
So,
instead
of
the
only
the
few
you
know
language
packs
we
have.
We
now
actually
have
much
more
comprehensive
coverage
on
popular
buildback
languages.
D
Yeah,
so
I
think
it's,
the
sort
of
internal
implementation
is
different
from
safe
deployment
to
in
safe
deployment.
We
are
using
sort
of
the
build
packs,
which
is
a
cf
to
you,
know
very
cloud
founders,
specific,
build
packs.
These
are
the
new
build
packs
called
pacado
right
right,
which
use
a
build
box.
C
Actually,
my
question
was
like
from
the
list
of
supported
languages
and
technologies
that
looks
fairly
comparable
to
what
we
have
in
cf
deployment.
So
I
was
wondering:
is
this
there
any
major
gap
just
from
like
those
technologies
or
yeah
cf4ks,
meanwhile
complete
when
it
comes
to
to
language
support.
D
Yeah,
so
we
we
haven't
fully
audited
side
by
side
just
yet,
because
we're
still
sort
of
working
with
the
bill
packs
team,
for
example,
the
bill
packs
team-
have
sort
of
two
sets
of
two
phases
when
they
come
when
it
comes
to
releasing
language
packs.
D
One
is
where
the
first
phase
is
any
new
language
bill
pack
has
to
go
through
community
review,
so
you
can
see
that's
where
the
pacquiao
community
is
and
once
that
language
bill
pack
goes
through
review,
get
gathers
feedback.
It
graduates
to
the
sort
of
you
know
full
fully
supported
buildback.
So
that's
something
that
we're
working
with
them
in
terms
of
what
is
the
support
we
would
want
around
around
the
graduated
build
packs.
D
For
now
we
are
including
ruby
and
python
just
because
we
want
to
test
those
with
a
lot
of
apps
in
cats
and
other
places
that
use
ruby.
So
so
we
are
like
you
know
we
try
to
like
pull
them
early.
I
imagine
when
we
go
one
point
here.
We
would
want
these
to
be
actually
graduated
bill
packs
to
be
fully
supported
by
the
bill
pax
team
rather
than
being
in
community.
D
So
that's
one
like
I
said
I
have
the
one
of
the
areas
we
want
to
do
fully.
Audit
is
look
at
the
side
by
side
comparison.
I
think
most
languages
are
fully
supported
here,
but
one
thing
I
do
want
to
highlight
is
the
structure
of
the
apps
have
changed.
So
what
I
mean
by
that
is,
if
you
have
an
app
and
that
worked
with
the
cf
deployment
cloud,
foundry
bill
packs
the
structure
of
those
have
changed
in
the
new
potato
bill
packs.
D
So
that
is
one
action
item
that
we
have
as
a
team
to
document.
What
exactly
those
changes
are
for
both
the
operators
and
the
app
developers,
for
example,
the
the
the
cf
acceptance
says.
The
cats
has
number
of
assets
with
different
language.
You
know
apps,
so
you
know
we
have
php
python
and
we
have
ruby
and
so
whatnot
all
of
these
languages,
some
or
most
of
them
are
actually
gonna
have
to
change
to
work.
D
You
know
to
to
work
with
the
potato
bill
packs,
so
this
means
there
is
an
impact
for
someone
who
wants
to
migrate
from
cf
deployment
to
c4k8
that
their
app
would
have
to
go
through
changes
in
order
to
work
in
c4k.
It's
not
backward
compatible.
I
guess
long
story
short,
and
that
is
something
that
we
want
to
come
ahead
and
talk
about,
at
least
from
a
documentation
standpoint
like
what
do
you
need
to
do
in
order
to
go
from
cf
deployment
to
cfo
gates.
D
So
we
we
have
to
fully
audit
that.
So
that's
one
thing
that
we
have
a
explore
story
on
the
early
when
I
had
a
cursory
look
at
it.
Much
of
this
is
around
folder
structures
and
some
new
availability
of
some
specific
files
for
the
detection
to
happen.
I
have
not
seen
yet
around
there.
You
know
environment
variables
issue,
yes,
just
yet,
but
then
also
we
haven't
fully
comprehensively
reviewed
every
asset
in
cats
and
compare
that
to
what's
needed
in
the.
A
Yeah,
okay,
so
that
makes
sense.
So
that's
expected
expected.
E
File
structure
and
the
ability
to
detect.
D
Yeah
yeah
and
we're
trying
to
figure
out
like
how
can
we
some
of
the
examples
that
pacquiao
bill
pax
has
given
they?
They
have
a
use
of
their
sort
of
bill.
Pacquiao
like
how
should
you
be?
How
should
this
app
be
actually
measured?
How
should
we
detect
it?
So
we
need
to
be
very
careful
like
we
don't
want
apps
to
be.
You
know,
creating
build
pack
base
dml
to
have
a
better
detection,
so
so
there's
a
trade-off
that
we
have
to
consider.
D
Can
they
be
detected
without
actually
any
you
know
potato
specific
gamo
files?
Can
they
be
detected
automatically?
So
that's
one
thing
that
we
are
actually
have
to
explore
as
well.
D
E
In
the
custom
builder,
it's
listing
that
ordering
of
of
groups
and
ids
at
build
packs
correct.
You
have
to
implicitly
know
that
the
images
in
the
store
are
going
to
relate
to
those
build
pack
ids
in
the
images
when
you're
building
that
list.
D
Yeah,
so
the
each
of
these
builder
language,
build
packs,
have
id
in
them.
So
if
I
actually
expand
unpack
this
or
crack
open
this
docker
image,
they
have
ids
in
them.
So
and
those
ids
sort
of
re
resemble
this
one
like
pocket
or
community,
slash
ruby.
So
you
would
have
to
know
the
ids
when
you
are
pulling
a
bill
pack
that
actually
you
know,
follows
the
the
the
buildbacks
back.
So
is
that
answer
your
question.
D
Correct
yeah
and
you
can
docker
inspect
that
these
language
build
packs
just
because
you'll
hold
one
second
one.
D
D
Yeah
right
cool,
so
what's
interesting,
though,
is
that
I've
I
thought
playing
with
buildpack
is
that
the
the
custom
builder
is
actually
a
image
itself,
so
so
what
kpac
actually
does
is
it
takes?
All
of
these
images
takes
all
of
those
images
and
actually
rebuilds
a
brand
new
builder
image,
which
was
you
know.
For
me,
it
was
surprising
for
not
many
people.
It
was
like.
Oh
yeah,
that's
obvious,
but
it's
not
for
me,
so
it
actually
creates
a
brand
new
custom.
D
Cf
builder
bill
pack
based
on
this
spec,
which
is
in
this
case
our
the
the
new
one,
which
is
this.
So
this
is
a
sort
of
like
culmination
of
the
entire
stack
and
store
and
the
ordering
into
one
big
sort
of
builder
itself
and
which
you
know
I
actually.
What
I
did
is
if
I
share
my
screen
with
you
know,
where
is
my.
D
D
You
know
these
are
all
the
sub
packs
within
the
top
level
language
build
pack.
So
it's
fascinating
to
see
all
that
and
then,
as
you
can
see,
each
of
these
have
proper
detection
order,
which
is
taken
directly
from
that
custom
builder,
crd
that
you
saw
a
moment
ago,
and
then
these
are
all
again
additional
information
that
you
may
want
to
use.
D
So
that's
sort
of
like
you
can
just
dock
or
pull
that
image
and
inspect
it.
What's
interesting,
though,
is
I
took
that
and
I
I'm
using
pax
cli
so
pax
cli
is
the
is
the
cli
to
that
supports
any
cloud
native
build
pack.
You
know
implementation
of
a
cloud
native
bill
pack,
so
so
it
uses
pack.
D
So
this
is
like
interesting
because
you
could
potentially
see
an
app
developer,
trying
to
like
build
an
app
image
locally
to
using
the
custom
builder
image
that
we
just
had,
which
I
put
in
a
sac
set
default
to
test
if
it
actually
works
within
that,
so
this
is
like
something
that
a
workload
that
did
not
exist.
Maybe
it
may
be
something
up
app.
Dealers
will
try
to
use,
but
this
is
sort
of
like
debugging
situations
are
great
like
if
you
don't
want
to
debug
live
in
a
con.
You
know
an
entire
cf4k
foundation.
D
You
just
want
to
know
if
the
app
is
actually
not
loading.
Let's
say
for
some
reason:
it
didn't
restart
or
it's
not
starting.
This
could
be
one
way
of
debugging
that
locally
to
like
okay,
let
me
just
pack
it
and
run
it.
Docker
run
this
app
and
see
if
it's,
okay
and
that's
something
that
I
you
know
was
pretty
interesting
for
me
when,
when
I
ran
this
one
same
exact
line
of
code
just
happens
to
be
local.
D
D
So
I
had
these
two
sort
of
versions
of
bill
builders
and
imagine
a
workflow
for
the
operator
where
they
actually
have
a
new
cv
fixed
in
the
stack
and
they
want
that
whole
thing
to
be
not
only
to
rebuild
all
those
images
but
also
update
the
the
reroll
those
apps
in
you
know
in
cfk8s,
so
I
know
cappy's
working
towards
that
capability,
but
I
try
what
I'm
trying
to
show
you
here
is
that
how
the
the
builder-
or
in
this
case
the
pack,
can
actually
rebase
it
the
app
without
actually
rebuilding
the
whole
image
itself.
D
So
what
I
have
here
is
the
is
the
older
version.
So
I
set
that
as
a
as
the
default
builder,
then
I
did
a
build
and
then
I
reset
that
to
the
newest
one,
and
I
did
a
pack
rebase
and
voila.
It
just
builds
it
without
actually
rebuilding
the
whole
image,
so
it
just
rebases
it
by
just
changing
the.
I
believe
the
run
image
I
don't
know
how
he
does
it.
D
I
don't
know
how
it
changes
the
layer,
but
it's
there's
some
magic
of
like
changing
a
layer
and
then
just
keeping
the
rest
of
that
code
intact
and
not
rebuilding
it
so
anyway.
So
so
I
thought
this
is.
This
is
something
that
will
eventually
be
part
of
our
cfo
k,
its
workflow,
because
this
is
like
the
the
one
half
of
the
thing
where
we
let's
say
stack,
update
comes
in
you
know,
kpac
will
take
care
of.
You
know,
rebuilding
those
images,
so
imagine
that
10
apps,
all
of
those
apps
will
get
rebuilt
or
rebased.
D
Actually,
that's
the
right
framing
and
then
you
know
cappy
and
irony
will
work
together
to
reroll
those
apps
so
that
the
apps
can
they're
running
with
the
latest
stack,
so
that
workflow
is
pretty
awesome
for
for
many
reasons,
because
now
you
have
patching
your
apps
at
a
faster
than
light.
I
suppose.
C
So,
on
on
this
patching
of
applications,
what's
like
the
general
thought
there
is,
is
that
something
that,
like
ultimately
administrators
of
the
system,
need
to
decide
or
is
like?
Is
there
also
a
choice
that
administrators
could
take
and
say,
like?
I
wanna
have
for
new
applications
that
are
pushed
a
new
version
of
certain
or
build
packs,
but
then
like
leave
the
the
existing
running
applications
as
they
are.
D
I
think
that's
a
good
question.
I
I
wonder
why,
because
if
you
have
a
stack
update,
you
probably
don't
want
apps
to
be,
you
know
to
be
lagging
behind.
I
would
probably
want
all
the
apps
to
be
updated
with
the
latest
stack
to
ensure
you
know
they
are
passed
correctly,
but
I
think
not
at
least
the
way
we
are
thinking
about
that
workflow
is
just
going
to
be
all
apps,
but
you
know,
but
maybe
in
the
future.
D
If
there
is
a
enough,
you
know
enough
evidence
that
maybe
we'll
figure
out
a
way
to
I
think.
B
Psy
part
of
it
is
for
for
some
folks
that
they
have
policies
around
exactly
what
is
allowed
to
be
running
in
production,
and
so,
even
even
if
it's
more
secure,
they'll
want
that
to
run
through
pipelines.
B
They
won't
necessarily
want
to
to
update
that
right
away,
even
if
it
has
like
abi
compatibilities
and
we've
not
noticed
any
any
bad
abi
compatibility
related
updates
in
in
the
past
many
years,
we've
been
running
cloud
foundry,
but
even
so
there
are
companies
that
have
policies
around
what
what
exact
bits
are
allowed
to
be
serving
traffic
from
a
customer.
A
Yeah
ue,
I
think
the
place
to
control
that
is
actually
the
admin
of
the
foundry
would
decide
when
to
update.
So
there
might
be
an
upstream
release
of
a
new
stack
and
they
would
decide
when
they
want
to
apply
that
to
their
foundry
and
then
subsequently
restage
all
of
the
apps
on
it.
E
A
Okay,
that's
also
because
you
could
have
multiple
versions
of
of
the
build
packs,
correct.
D
Yeah,
as
long
as
the
ids
don't
collide,
collide,
yeah.
E
A
E
We've
seen
that
pattern
in
the
past,
where
people
will
intentionally
fork
build
packs
and
you
know
rename
them
to
some
pinned
version
again.
I
think,
because
of
more
of
those
compliance
restrictions
around
like
you
know,
you
know,
we've
we
vetted
the
language
version,
that's
coming
from
this
version
of
the
build
pack,
but
it's
getting
removed
in
a
later
one.
So
we
want
to
keep
that
around.
You
know,
even
if
there
are
security
implications.
D
I
have
to
check
on
that.
As
far
as
I
know,
this
is
managed
by
kpac,
but
I
could
I
could
take
a
look
at
it.
A
D
Yeah,
you
could,
are
you
talking
about
this
sort
of
like
this
sort
of
detection
order
where
you
know
so,
this
is
the
detection
order
like
we
will
check
ruby
first
and
then
python,
then
java
and
then
all
the
way
down
to
the
last
one
would
be
proc
file
and
then
within
ruby.
There
could
be.
You
know,
sub
packs
that
have
their
own
detection
order,
that
they
want
to
check.
A
And
so
an
admin
might
want
to
put
the
newer
one
first
or
the
newer
one.
Second,
so
that
I
don't
know
it
depends
on
what
they
they
want
to
do,
if
we
just
make
sure
there's
a
knob
still
to
configure
the
order,
because
I
I
don't
know
if
cloud-native
build
packs
are
sufficiently
different,
that
it
breaks
that
probably
wouldn't
I'd
have
to
start
playing
with
it.
A
Yeah
like
right
now,
so
I'm
not
familiar
with
kpac
yet
but
right
now
you
can
change
the
order
in
which
the
detect
clips
run
correct.
D
I
don't
believe
that
that's
going
to
be
a
problem
as
in
as
in
just
from
a
buildback
standpoint
like
what
would
it
like
if
you
I
can
rearrange
any
of
these
and
it's
just
a
matter
of
how
long
it's
going
to
take
for
me
to
build
right.
So
if
my
organization
is
exclusively
to
java
or
then
I
would
probably
want
the
java
to
be
the
first
order,
and
then
you
know,
let's
say
I
don't
never
don't
use
python
at
all
over
the
bottom.
D
So
that
way,
you
have
a
little
faster
detection
instead
of
like
having
languages
that,
don't,
though,
you
don't
use
at
all
as
a
top
on
the
top
of
the
order
but
yeah.
As
far
as
I
know
that
there
is,
I
have
to
double
check
this,
but
I
don't
know
if
it
actually
once
it
detects
it
just
exits
right
away.
I
that's
my
hypothesis
but
I'll
have
to
double
check
oftentimes.
C
Yeah,
I
guess
I'm
looking
at
it
from
like
a
couple
of
angles,
so
so,
first
of
all,
I
think
we
indeed
have
seen
things
breaking
in
in
very
subtle
ways
with
with
build
pack
updates.
So
I
guess
on
our
end,
we
want
to
give
developers
the
control
of
when
they
update,
like
we
even
tell
them
today
that
they
should
actually
pin
the
build
pack
version
and
kind
of
consciously
do
do
an
update
and
yes
granted
other
companies
and
organizations
might
have
had
different
rules
there.
The
the
other
thing
is
is
also
like.
C
Can
people
why
that
approach
still
kind
of
bring
an
own
build
pack
like?
Is
it
still
supported
that
you
can
provide
a
git,
url
and
kind
of
stage,
an
application
with
that
url?
Or
do
you
now
always
need
to
like
bring
a
container
image
and
are
you
kind
of
as
a
developer,
still
able
to
specify
them
on
the
location
of
that
container
image
to
actually
stage
an
application
would
be
like
follow-up
questions
that
come
to
my
mind,.
D
C
Be
managed
right
so
like
not
come
in
a
situation
where
what
they
are
running,
as
you
said,
is
like
different
from
what
they
see
if
pushed
initially-
and
I
think
that's
that's
one
concern.
C
C
That
version
to
something
that
they
have
tested
with,
and
I'm
kind
of
wondering
if
that
is
still
possible
with
with
kpec
or,
if,
like
the
metaphor,
changed
and
now,
everything
is
like
packaged
container
images
and
then,
if
developers
can
still
like
have
a
way
one
way
or
the
other
to
kind
of
bring
their
own.
Somehow.
D
Yeah,
those
are
some
good
questions,
so
kpac
really
just
you
know
it's
underlyingly,
just
like
a
wrap
around
pack.
So
I
think
these
are
just
like
fundamental
questions
around
like
when
adding
a
bill
pack
would
like.
Could
you
just
point
to
a
github
that
has
sort
of
like
you
know
the
structure
it
expects,
and
then
it
builds
images
based
right
off
that
or
you
can
just
consume
an
image
directly
with
I'm,
assuming
in
both
cases,
some
pin
abilities
spin
to
a
specific
version
so
yeah
I
will.
Those
are
some
good
questions.
D
I'll
take
a
look
at
it.
It
should
be
fairly
easy
to
verify.
What's
interesting
is
the
controlling
the
version
from
by
the
developers,
and
I
may
actually
check
with
you
on
that
post
this
meeting
just
to
understand
that
workflow,
what
that
looks.
D
Like
yeah,
this
is
great
discussion,
anything
else
that
comes
to
all
mine
and
if
one
area,
one
thing
I
will
quickly
share
also
is
the
there
is
sample
apps,
which
I
thought
I
had
it
somewhere.
D
Yep
so
I'll
share
it
in
the
zoom
chat.
Here's
a
quick
sort
of
like
list
of
apps
that
the
the
build
packs
team
has
put
together
on
different
apps
and
in
how
different
sort
of
like
sub
packages,
and
and
most
of
these
are
very
simple,
apps
and
I'll.
Give
you
like
an
idea
of
how
to
sort
of
build
unpack.
So
I
think
I
mentioned
earlier,
as
you
can
see
in
this
php
there's
a
bill
pack
yaml.
So
I
just
need
to
make
sure
understand
what
this
is
actually
doing.
D
Is
there
something
specific
to
php
or
is
it?
Is
it
something
that
bill
pack
team
introduced?
So
those
are
some
of
the
pros
and
cons
that
I
have
to
double
check
on,
but
you
can
all
take
a
look
at
this
when
you
have
a
chance.
D
Cool
I
got
about
what
20
minutes
left
is
that
accurate.
D
Okay,
I
would
love
you
to
show
some
of
the
new
things
that
we
have
done
around.
The
upgrade
up.
Time
is
sort
of
like
initiative,
so
one
of
the
key
outcomes
we
want
to
achieve
is
really
just
stable
upgrades
over
time
and
also
have
meet
some
of
the
uptime
slos
that
we
wanna
like
we
had
carry
over
from
cf
deployment
and
in
one
way
we
were
trying
to
figure
out
like
what's
the
best
way
to
enforce
this,
because
we
are
still
not
there
yet
to
enforce
upgrade
upgrades
in
our
main
pipeline.
D
So
what
we
are
doing
now
is
actually
enforcing
upgrades
like
any
any
new
change
or
any
new
input
that
we
get
from
the
contributing
teams
or
third-party
dependencies
will
go
through
our
traditionally
pull
request
and
what
will
happen
there
is
like,
if
I
can
show
you
one
example
of
that
perhaps
is
we
are,
and
we
are
checking
for
upgrades
and
uptime
at
the
at
the
source.
So
this
is
probably
not
a
good
example.
D
D
While
it's
actually
checking
that
it
also
checks
to
make
sure
that
an
app
that
is
pushed
to
the
to
the
foundation
is
available
throughout
that
upgrade
to
make
sure
that
we
don't
see
any
downtime
with
app
or
the
push
ability
of
recent
logs
we
put
in
a
threshold
of
zero
for
app.
So
any
you
know
that
means
if
for
app
downtime.
So
if,
if
even
one
call
fails,
the
pr
will
fail.
So
the
reason
we
did
this
is
this:
provides
the
quickest
feedback
to
the
contributing
teams
rather
than
testing
this
way.
D
You
know
past
the
in
our
pipelines,
which
may
be
caused
by
multiple
commits
or
could
be,
you
know,
could
be
caused
by
a
flake.
So
so
doing
this.
This
way
gives
immediate
feedback
to
the
teams.
For
that
specific
change,
and
they
can
use
that
as
a
vehicle
mechanism
to
test
in
there
locally
and
see
if
they
can,
you
know
they
can
solve
this
problem.
D
You
know
make
sure
that
it's
upgradable
and
uptime
is
available
or
if
it's
a
known
issue.
For
example,
when
we
add
route
controller
switch
over
from
cf
routing
to
route
controllers,
a
brand
new
crds
brand
new
routing
systems,
it
was
bound
to
break
then
we
would
then
go
ahead
and
merge
it,
because
it's
a
planned
sort
of
event
where
we
know
upgrade
and
up
time
will
be
impacted.
D
So
this
is
something
that
we
are
trying
to
like
make
a
first
class
citizen
for
upgrades
and
up
times
pretty
happy
with
this,
so
teams
are
liking
this,
so
we're
hoping
to
you
know
employ
this.
Basically,
at
all
the
inputs
we
take
so
including
auto
bombs
of
releases
as
well.
D
Yeah,
so
that
is
an
iteration
that
we
have
to
go
through.
So
this
is
the
first
iteration
we
came
up
with,
and
so
this
basically
I
don't
know,
I
have
a
double
check.
This
could
be
a
flake,
but
there
are
some
better
messaging
of
what
failed
and
making
sure
that
we
don't
have
flakes
that
reduce
or
ignore
the
value
of
this
check.
So
those
are
the
two
things
that
we
want
to
double
click
on.
D
We
just
recently
launched
it
so
we're
seeing
flake
for
every
five
pr,
so
we'll
have
to
figure
out
why?
Why
that's
happening
but
yeah?
I
think
it's
I
don't
know
why
it
fell.
I
think
it.
D
The
messages
got
mixed
up
apparently
because
of
this.
But
if
you
look
at
the
the
actual
check
itself,
it's
actually
you
know
upgrade
and
uptime
check
it
actually
passed,
so
we
just
have
to
figure
out
that
don't
mix
and
match
images.
So
that's
a
bug.
D
And
then
we
also
have
like
variety
of
other
checks
as
well
to
again
give
more
feedback
to
the
teams
right
at
the
source.
One
of
them
is,
we
have
noticed
contributing
teams.
Oftentimes
would
want
to
use
a
newest
version
of
gates,
which
is
which
may
not
be
available
in
the
current
version
that
we
support.
So
what
we
are
doing
actually
now
is
checking
on
the
newest
and
the
oldest.
D
So
that's
a
window
that
we
want
to
support
so
like
1.14
to
say:
1.17
is
a
window
and
someone
just
comes
in
and
says
I
want
to
use
this
new
feature,
but
it's
not
available
in
the
oldest
version.
So
that
gives
us
an
opportunity
to
test
here
and
then
ask
questions.
Is
it
something
we
want
to
do
and
also
there
may
be
some?
D
You
know
goals
for
as
a
team
that
we
want
to
stick
to
116
for
some
time,
and
you
know
this
will
shield
us
from
those
sort
of
like
random
sort
of
errors
that
we
didn't,
which
we
may
encounter
in
the
main
pipeline,
it's
hard
to
debug
at
that
point,
so
yeah.
So
this
is
a
good
way.
It's
like
a
ui
ux
way
for
teams
to
take
a
look
at
it
on
all
the
checks
that
we're
doing.
B
Would
it
be
too
much
to
ask
for
a
check
that
the
pull
request
still
works
against
a
very
small
environment.
D
A
small
environment
as
in
like
like
so
I
understand
that
small
environment
as
a
mini
cube.
Okay,
we
are,
I
believe
we
are
testing
these
unkind,
I'm
positive.
We
are
testing
this
unkind,
not
on
gke.
Some
of
these
are
because
of
the
because
gke
does
not
have
like
the
latest
versions,
and
we
want
to
test
against
certain
versions
that
the
providers
is
providers
may
not
have
so.
I
believe
we
are
using
kind
on
this
one
cool.
D
The
other
thing
I
wanted
to
show
you
all
is
the
on
the
on
the
same
wayne
of
upgrades
and
up
times
is
trying
to
look
at
long-running
environments,
so
figuring
out
a
way
to
run
cfo
gates
on
a
long-running
environment.
So
we
can
measure
how
stable
it
is.
We
can
also
measure
its
some
of
the
upgradeability
and
also
measure
its
uptime,
so
we
started
doing
this
recently.
D
This
is
our
long
lived
environment
and
what
this
is
is
is
basically
lives
at
least
forever
now,
and
then
we
upgrade
it
nightly,
and
what
we
want
to
measure
really
is
like.
Is
a
foundation
stable
over?
Let's
say
30
days
and
60
days
and
is
every
upgrade?
Does
it
what
kind
of
resource
are
there
any
resource,
leakages
that
we
we
haven't
seen
because
every
other
test
we
do
is
usually
just
between
create
a
brand
new
cluster
brand
new
foundation
upgrade
to
that?
D
But
this
specifically
is
testing
resources
and
then
also
the
health
of
cf,
and
also
the
app
availability
and
we've
been
testing
this
and
pushing
this
data
to
our
uptime
reports
to
pingdom
and
the
the
measurement
we
are
seeing
here
is:
oh
well,
very
close.
So
last,
how
long
has
this
been
running
june?
17Th
so
about
you
know
decent
up
time
and
we're
upgrading
every
night
we
saw
early.
D
D
Charts
at
you,
we
are
also
checking
how
generally
upgrades
are
doing
like.
What's
the
you
know,
upgrade
time
in
minutes,
http
pass
rate
and
fail
rate,
as
you
can
see
that
we
are
seeing
an
average
of
three
to
four
minutes
upgrade
times.
D
So
that's
pretty
awesome
and
then
also,
as
you
can
see,
like
some
markers
on
on
on
this
date,
we
released
the
0.40
release
and
we
test
the
upgrade
from
that
point
on,
so
we're
seeing
some
really
great
some
green
upgrades
at
this
point
again.
This
is
again
to
measure
over
time
how
we
are
doing
with
upgrades
and
stability
and
then
use
this
information
to
talk
to
teams.
Talk
to
you
know,
different
stakeholders
like
in
this
meeting
and
sort
of
build
overall
confidence
around
safe.
D
Grades
cool-
that's
all
I
had
from
for
my
session
today,.
D
Yeah,
as
always,
we
are
always
reviewing
these
things
so
love
to
get
your
feedback
on.
You
know
things.
We
may
have
missed
things
we
will
like
do
on
an
ad
and
thanks
you
for
that
feedback.
I
will
make
sure
that
is,
captured
and
put
in
a
bug
somewhere,
but
yeah
love
to
I'll.
Take
a
look
at
it
and
let
us
know.
B
Yeah,
I
wonder
bernd
sap
has
always
been
very
helpful
with
scalability
testing,
and
so
I'm
curious,
if,
if
you're,
if
sap
is
thinking
about
piggybacking
on
any
of
these,
these
pipelines
to
to
help
with
the
scalability
aspects.
C
A
Yeah,
so
I
think
we
are
in
the
process
of
setting
that
up
and
and
hoping
that
regard,
so
we
just
had
to
a
conversation
internally
from
a
kind
of
budget
point
of
view
right.
What
what
we
need
to
to
support
that.
So
we
are
good
good
on
that
side
to
to
go
right
and
I
think
yogeshan
team
started
with
some
scalability
testing
around
routing
infrastructure,
but
we
can
for
sure
also
discuss
how
how
to
extend
if,
if
there
is
need
to
do
so,.
D
Yeah
I
I
when
I
spoke
to
jan
and
rishto
last
during
our
regular
sink
last
week,
they
asked
me
or
they
they
were
going
to
introduce
me
to
yogesh,
who
was
going
to
join
our
call
on
on
our
next
regular
sink.
D
To
give
us
some
updates
on
the
scalability
test
that
they
have
done
so
far
on
a
cursory
sort
of
number
was
that
they
did
a
cf
push
with
1
000
parallels
here
push,
but
they
don't
have
didn't
have
results
then
so
yogesh
will
hopefully
give
us
more
details
on
some
of
that.
So
I'm
pretty
excited
to
hear
the
outcomes
of
that
test.
C
That
was
really
some
cool
topics
and
insights
on
those
and
then
I
guess
for
next
time
we
still
have
one
topic
left
that
was
kind
of
spun
off
from
from
the
whole
voting
around
people
wanted
to
get
an
update
on
irene
and
that
kind
of
went
crazy,
and
now
I
guess
we
got
a
whole
lot
of
very
interesting
fallout
presentations
from
that,
so
I'll,
try
and
reach
out
to
the
folks
from
sousa
who
had
a
couple
of
topics
to
present
and
then
hopefully
she
they
can
make
it
for
for
next
time.