►
From YouTube: Cloud Foundry for Kubernetes SIG [6/15/21]
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
C
It's
reasonably
warm
in
the
uk
and
we
have
to
make
the
most
of
that
it
doesn't
happen
very
often
greenhouses
over
there
nice.
What
are
you
growing?
We
got.
I
don't
know
what
you
can
see.
We've
got
some
cucumbers,
we've
got
a
red
currant,
no
a
blackcurrant
plant
with
about
four
blackcurrants
on
it:
some
raspberries,
tomatoes,
basil
and
some
chili
peppers
that
are
just
about
starting
to
fruit.
D
D
Yeah
I'll
be
here
for
the
first
half
of
the
meeting,
but
I
have
to
draw
for
something
else.
30
minutes
in
just
as
a
heads
up.
A
A
So
we
basically
have
rum
who's
who's
interested
in
incident
management
in
cfo
cates,
with
a
couple
of
detailed
questions,
and
then
it's
kieron
and
angela
talking
about
cloud
foundry,
custom
resources
and
that,
as
I
said,
probably,
we
should
just
switch
the
order
to
make
sure
that
angela
can
ideally
follow
kind
of
most
of
the
conversation
around
the
topic
where
she's
mentioned.
A
Okay,
then
I
guess-
let's,
let's
just
do
that-
welcome
everybody.
Officially
to
this
week's
special
interest
group
called
cloud
foundry
on
kubernetes,
as
mentioned
two
two
topics
on
the
agenda:
cf
custom
resources,
which
we
will
start
with,
because
angela
needs
to
jump
to
to
another
call
at
in
30
minutes
from
from
now,
and
then
we
have
ram
who
is
interested
in.
A
Management
in
cf
for
kate's
world.
So
with
that,
I
guess
I
would
just
right
away
hand
it
over
to
kieron
and
angela
to
talk
about
their
topic.
D
Yeah
cool
thanks
fran.
I
know
it's
been,
I
think
about
a
month
since
the
last
cf
on
kate's
sig
meeting.
I
know
in
the
last
conversation
we
had
a
lot
of
discussion
about
starting
to
dive
into
like
what
a
possible
technical
architecture
could
look
like
to
actually
support.
Like
the
cf
on
kate's
vision
statement,
that's
been
circulated
around
in
the
community,
and
so
I
think
you
know.
D
Since
then,
there's
been
a
little
bit
of
asynchronous
communication
and
thinking
about
you
know
not
only
the
high
level
architecture,
but
was
that
user
experience
like
as
well,
and
so
I
actually
wanted
to
tag
along
with
the
topic
you
suggested
of
karen
shared
out
a
document
about
sort
of
thinking
of
like
how
do
those
cloud
foundry,
custom
resources
actually
look
like
and
like
what
does
that
interaction
model?
D
Look
like
as
well,
and
so
maybe
we
can
start
by
like
going
into
that
document,
a
little
bit
getting
like
a
high
level
presentation
there
and
then
hearing
folks,
like
general
reactions
or
thoughts,
because
I
think,
like
maybe
taking
a
step
back
again
because
there's
a
lot
of
new
folks
here.
You
know
when
thinking
about
the
technical
architecture
for
like
where
we
might
want
to
take
cf
on
kate's.
D
I
think
we've
really
been
thinking
about
having
you
know
really
more
fully,
integrating
with
kubernetes
and
treating
custom
resources
as
the
source
of
truth
and
like
integration
point
for
them
being
able
to
you
know,
have
workloads
running
so
like
having
you
know
the
cfa,
having
like
a
cf
api
server
that
actually,
instead
of
you
know,
driving
objects
in
a
relational
database
is
creating
custom
resources
on
a
kubernetes
cluster.
But
then
you
could
create
different
controllers
to
like
actually
implement
different
outcomes
against.
D
D
Cool,
so
I
just
wanted
to
provide
like
a
brief
amount
of
context,
to
what
we
talked
about
last
time
and
maybe
from
there
we
can
go
over
into
the
dock.
That
kieran
wrote
up
and
you
can
talk
a
little
bit
more
about
that.
D
F
Yeah
yeah,
so
I
created
that
dark
a
couple
of
weeks
ago
after
the
after
the
meeting
where
we
saw
the
ideas
about
the
cf
civili
shim,
which
was
creating
the
and
the
any
suggestions
for
some
cids
that
that
would
do
so.
That
was
that
was
driven
through
the
cf
cli
and
how
that
goes,
how
that
needs
to
interact
with
cf.
F
So
I
was
trying
to
consider
another
use
case,
which
I
think
we
talked
about,
maybe
in
the
cf
kate's
vision
document.
So
if
we're
doing
cf
on
kubernetes,
my
assumption
was.
This
is
a
great
opportunity
to
allow
people,
operators
and
developers
to
do
a
kate's
native
way
for
deploying
their
apps,
and
that
should
feel
just
as
easy
as
doing
a
cf
push.
F
So
by
that
I
mean
you
should
be
able
to
create
a
custom
resource.
That's
got
the
information
that
you
would
have
in
your
app
manifest
and
anything
you'd
pass
on.
The
command
line.
Keep
couple
apply
that
and
then
that
should
just
be
processed
like
as
if
you
just
done
a
cf
push
leave
it
there.
F
Things
will
happen
and
eventually
an
app
will
be
running
in
the
end
of
it
yeah,
and
I
was
wondering
how
you
could
do
that,
based
on
the
the
objects,
the
crs
that
were
suggested
for
the
cf
shim,
and
I
was
just
looking
at
the
amount
of
interaction
that
was
maybe
maybe
implicit
in
that
design.
F
So
I
think
we
started
off
by
creating
an
app
manifest
what
the
shim
did,
which
contains
the
details
for
the
manifest
oh
yeah.
I
can
see
this
a
little
bit.
We
need
to
get
the
source
code
in
there
somewhere.
So
I
mean
that's
a
tricky
bit.
I
think
in
terms
of
kate's
native
way
of
doing
things.
Maybe
we
have
to
just
point
it
to
a
repository,
but
we
can
just
assume
that
happens
somehow.
I
think
I
suppose
my
problem
was
I
want.
F
I
want
that
code
to
turn
into
a
running
application
without
doing
anything.
I
don't
want
to
create
a
kpack
resource
watch
the
status
of
that
wait
for
that
to
be
finished
and
then
assign
that
to
my
object
that
I've
created
or
another
one
that's
been
created,
I
don't
want
it
to
be
a
multi-step
process.
It
just
should
be
a
declarative
thing
where
I
can
specify
my
app
bang.
Bang.
Bang
things
happen.
F
Yes,
there's
some
comments
on
here
and
I
realized
the
whole
structure
isn't
as
simple
as
just
being
able
to
create
one
one
cr.
Perhaps
definitely
you
might
end
up
with
very
many
different
versions
of
your
app
code
linked
to
your
app.
So
I
can
see
how
that
could
be
a
different
cr.
F
But
I'd
quite
like
to
say,
if
you
just
point
to
one
version
of
your
code
in
one
one
cr
your
main
app
manifest
if
that
could
trigger
the
generation
of
a
new
build
object
and
then
automatically
link
things
together,
saying
this
is
my
current
build
and
then
it
goes
on
and
all
the
other
crs
get
processed
by
the
controllers
to
create
the
app.
I
think
that
would
be
a
good
thing.
F
Yeah,
so
if
you,
if
you
have
this
model,
that
sort
of
kate's
native
driven,
then
I'd
say
if
you've
got
the
cf
shim,
how
could
you
utilize
that?
How
could
you
utilize
that
simple
model
with
the
cf
shim,
so
the
shim
does
a
whole
load
of
different
steps?
Doesn't
it
goes
and
creates
the
thing
it
uploads
code?
It
goes
and
says,
create
a
build.
It
waits
for
the
build
to
be
ready.
It
links
things
together,
so
I
think
I'm
hoping
with
statuses
on
that
single
object.
F
D
D
D
F
I
think
it's
it's
it's
just
things
that
are
hard
to
do
with
crs
are
like.
If
you
have
to
do
polling
or
you
have
to
go
and
watch
something
wait
for
status
change.
It's
quite
painful.
F
You
end
up
writing
your
own
sort
of
controller
and
go
or
something.
If
you
want
to
do
that
easily,
we
even
saw
that
using
ruby
code
to
do
things
like
that,
isn't
great,
so
yeah
to
keep
the
thing
as
simple
as
possible
and
sort
of
use.
The
patterns
like
if
you're,
creating
a
stateful
set
or
something
and
now
kate's
that
goes
and
creates
some
pods
or
something
underneath
it.
You
never
see
them.
You
can
just
look
at
the
status
on
the
stateful
set
and
know
what's
going
on,
try
and
hide
the
complexity.
F
B
Yeah,
like
I'm,
I'm
like
totally
on
board
with
hiding
the
complexity
for
for,
like
cube
cuddle
like
driven
users
for
it,
but
for
the
shim
itself.
B
I
think
a
lot
of
that
is
like
necessary
complexity,
because
we're
trying
to
like
take
a
an
existing
like
restful
api
that
is
already
designed,
and
we
already
have
clients
expecting
to
use
it
in
certain
ways
and
those
clients
expect
to
be
able
to
like
pluck
out
an
individual
build
one
of
many
builds
for
a
single
app
or
like
an
individual,
droplet
or
whatever,
and
for
to
power.
Those
in
points,
I
think,
like
some
of
that
cr
complexity,
is
actually
pretty
necessary.
B
There
we're
actually
doing
like
spikes
right
now
to
like
really
like
drive
out
these
dcr
designs
a
little
bit
better,
but
like
one
way,
I
like
to
think
of
the
intermediate
crs
or
those
are
both
like
basically
just
to
be
managed
by
machine
like
level
users
and
like
I'd,
never
expect
a
human
to
want
to
like
keep
cuddle,
apply
a
build
like
on
their
own,
like
they
would
apply
like
the
desired
app
like
like
you
proposed,
but
those
things
do
provide.
B
Like
extension,
points
for
us
to
be
able
to
like
swap
out
like
the
staging
implementation
or
the
runtime
implementation,
while
still
like,
allowing
us
to
like
power
this
thing
that
looks
like
the
cloud
controller,
but
is
using
those
instead
of
a
database,
I
think
for
for
the
relationships
that
are
like
definitely
mini
to
mini
like
it.
It
gets
a
lot
harder
to
to
be
able
to
like
collapse
that
into
individual
crs.
In
my
opinion,.
F
What's
what's
an
example
of
one
of
the
many-to-many
relationships
there.
B
On
the
on
the
dock,
I
I'll
link
this
mirror
here,
but
like
basically,
every
every
child
resource
under
an
app
is
like
pretty
pretty
complicated.
So
an
app
has
many
packages.
Those
can
all
be
like,
like
the
cli
can
like
coordinate
staging
of
multiple
packages.
At
the
same
time,
it
can
like
you'll,
have
multiple
builds
in
flight
at
any
given
time
it.
It
makes
it
difficult
when
you
have
like
many
things
that
could
be
like
in
flux
to
to
collapse.
B
That,
as
saying
like
the
app
is
a
single
build,
and
it's
then
it's
ready
and
like
if
we
were
like
doing
this
from
scratch
like
it
would
definitely
simplify
it
to
just
like
take
that
away
and
say
you
can
only
have
a
single
build
in
flight
like
very
much
like
the
like
v2
style
of
cf,
but
since
we're
targeting
like
being
able
to
support
v3
v3
clients
of
cf,
like
we
kind
of
have
to
have
to
think
about
it
more
more
in
terms
of
what
what
can
they
do
right.
F
The
thing
I
was
just
trying
to
say
was
like
just
hoping
not
to
have
the
user
creating
any
of
those
of
those
objects
tracking
all
that
stuff,
which
sounds
like
what
you're
saying
as
well
with.
D
B
I
think,
like
the
desired
app
that
you
propose
in
this
dock
is
like
definitely
like,
like
how
you
said
it's
like
a
stateful
set
that
ends
up
managing
replica
sets
and
pods,
but
the
user
doesn't
apply.
Those
like.
I
very
much
think
that
it
could
work
like
that,
and
that
would
be.
That
would
be
good.
F
D
You
know
a
continuation
of
like
the
doc
like
karen,
that
you
wrote
up
of
like
being
a
little
bit
more
explicit
of
like
okay,
like
how
does
this
like
if
we
have
a
desired
app
like
custom
resource
and
that's
what
the
user
is
interfacing
with
like
what's
going
on
in
terms
of
like
you
know,
all
of
like
what
is
that
desired?
App?
Actually,
that
generating
and
like
sort
of
like
to
your
point
of
like
noting
that
it's
like
you,
can
get
a
lot
of
information
off
of
the
status
field
like
calling
out
like
yeah.
D
What
is
that
relationship
of
like
what
resources
are
being
driven
out
and
like
what?
What
is
it
owning
and
like
what's
being
updated,
because
I
think,
like
fleshing
out
what
that
desired,
app
cr
would
look
like
might
make
it
like,
I
think,
would
bring
clarity
to
like
to
like
these
discussions
of
being
like.
Okay,
like
this
is
the
expectation
of
how
of,
like
the
user
shouldn't,
be
interacting
with
any
of
these
resources,
but
should
be
interacting
with
this
one
and
then
also
like.
D
Meanwhile,
if
you
compare
it
to
like
having
like
you
know,
a
new
api
shim,
like
the
api,
might
be
interacting
with
some
of
these
child
resources
for
things
like
get
endpoints
or
so
on.
But
what
does
the
push
workflow
look
like?
Can
we
make
sure
that
it
looks
similar
to
like
also
creating
a
desired
app
so
that
a
user
could
in
the
future,
then
if
they
wanted
to
bypass
like
the
cli
or
the
api
and
be
interacting
with
that,
like
desired
app
resource
directly.
A
I
I
was
just
about
to
say:
kieran
mentioned
k
native
and,
like
I
haven't,
looked
at
k
native
for
ages,
but
like
when
I
recall
how
it
how
it
started.
Wasn't
it
like
a
very
similar
model
to
what
what
I
think
kieron
was
was
proposing
like
the
top-level
entity
that
then
essentially
drove
many
of
those
sub
objects?
Ultimately,
so
I
I
guess
my
actual
question
is
how
close
or
how
far
away
from
the
way
k
native
works
today
is,
is
what
we
are
currently
discussing.
F
F
Yeah,
sorry,
I
didn't
I'm
not
the
expert
on
it,
but
I
mean
it
does
I
mean
you
ask
for
a
service
and
you
get
a
service
with
all
this
networking
as
well.
Doesn't
it
well,
whereas
we're
looking
at
pluggable,
networking
and
things
like
that,
so
we'll
we'll
have
additional
options.
D
So,
like
I
know,
there's
been
like
a
little
bit
back
and
forth
and
maybe,
like
you
know
talking
about
something
not
you
know
if
you
haven't
like
read
the
doc
or
like
looked
at
the
mirror
board,
it's
like
maybe
a
little
bit
more
difficult
to
engage
like
with
like
the
material
and
like
what
we're
talking
about
right
now,
but
I'd
be
curious
just
to
like
check
on,
like
you
know,
if
anybody
else
like
had
any
other
thoughts
about
like
what
we've
been
discussing
so
far
on,
like
you
know,
either
the
overall
vision
or
like
you
know,
talking
about
you
know
a
desired
app
like
custom
resource
as
like.
D
C
Oh
bye,
I'm
coming
into
this
cold,
having
not
attended
for
a
very
long
time,
and
I
came
to
the
meeting
just
to
try
and
get
a
general
sense
of
where
things
are
at
and
what
people
are
working
on.
So
if
this
ends
up
being
a
completely
new
question
and
derailing
things,
tell
me
to
shut
up
and
go
back
on,
mute
and
I'll,
happily
oblige.
So
we're
talking
about
defining
apps
as
custom
resources.
C
E
Homework
when
you
say
bits,
are
you
referring
to
the
application
source
code
that
gets
bundled
up
and
deployed,
so
the
idea
there
was
we'd
still
be
using
something
like
kpec
and
having
that
source
code
live
somewhere.
That
then
gets
built
into
an
oci
compliant
image
by
like
kpac
or
whatever,
and
then
the
output
of
that
being
the
image
that
gets
attached
to
the
object.
E
So
it
would
probably
come
in
updated
on
the
app
desired
app
and
then
that
gets
filtered
down
to
the
child
objects,
but
yeah
we're
still
using
some
sort
of
one
or
more
build
tools
that
lives
inside
of
the
kubernetes
cluster,
with
an
eye
towards
trying
to
make
it
as
compatible
as
possible,
with
whatever
offerings
are
there
recognizing
that
you
can't
do
that
for
everything,
but
you
know
whatever
we
can
use
we'd
like
to
use.
B
Yeah
pretty
one
one
thing
I
want
to
point
out,
though,
is
for
the
shim
it's
more
clear
how
that
works,
because
the
the
cli
would
be
pushing
source
code
in
its
traditional
flow
and
then
that
would
convert
it
into
an
image
that
that
kpak
would
use
as
a
source
for
the
desired
app
where
you
just
keep
cuddle
apply
a
cr.
It's
it's
less
clear
where
that
source
code
comes
from,
and
I
think
that's
what
karen
was
talking
about
like.
F
C
Yeah
and
I
think
you
kind
of
get
into
a
spiraling-
you
end
up
taking
on
the
responsibilities
of
cicd
pipeline
at
that
point,
which
is
kind
of
out
of
scope
of
the
current
implementation
of
cloud
foundry
and
the
user
experience.
C
I
do
wonder
whether
massive
sort
of
leap
away
from
how
things
currently
work,
but
whether
there
is
a
need
for
something
like
a
ci
cd
pipeline,
build
pack
that
you
tell
cloud
foundry
about
where
your
app
happens
to
live
and
what
ci
cd
system
you
use
and
there
is
a
pipeline
spawned
and
generated
and
set
on
whatever
ci
cd
server
that
you
have
so
then
you've
got
that
continuous,
pushing
of
things
into
cloud.
C
You've
got
that
the
the
issue
of
with
an
imperative
cf
push,
even
if
that's
you
know
affected
via
a
cue
cuddle,
apply
it's
a
point
in
time
right
and
that's
kind
of
counter
to
the
modern
github's
way
of
doing
things.
And
always
it's
been
a
kind
of
missing
part
of
the
picture.
E
Yeah
it'll
probably
become
more
clear
over
time.
What
direction
we
want
to
go.
I
would
point
out
that
capec
already
supports
some
of
the
stuff
out
of
the
box.
You
can
point
it
at
a
git
repo,
so,
theoretically
speaking,
there's
at
least
some
prior
art
for
doing
things
like
that,
but
yeah,
it's
something
where
we
gotta
be
careful,
because
we
don't
wanna
bite
off
too
much
before
we're
ready
to
support.
A
That
guess
my
other
feedback
would
have
been
like
the
the
names
that
we
give
to
to
that
entity
like
desired
application
or
application
manifest,
etc,
etc.
That,
at
least
to
me
kind
of
sounds
like
kind
of
the
old
implementation
is
shining
through
right.
So
so
I'm
I'm
kind
of
wondering.
Why
isn't
that
an
application
right
like
if
that
is
the
thing
that
an
end
user
would
want
to
create,
then
I
guess
an
end
user
would
want
to
create
an
application
at
least
kind
of
cloud
foundry
terminology,
but
that's
just
naming
right,
though.
D
Yeah,
I
think
we'll
definitely
want
to
get
the
names
right
so
that
we
don't
leak
through
like
old,
abstractions
or
or
just
default
to
you
know.
This
is
what
we
ported
over
from
like
cloud
foundry
like
as
is,
but
the
names
don't
quite
match
up
to
like
expectations.
Now
I
need
to
drop
for
my
other
call,
but
this
has
been
a
really
great
discussion.
Thank
you
for
switching
the
ordering
and
maybe
like
next
steps
wise.
D
I
know
we
have
like
the
next
meeting
in
a
couple
of
weeks,
but
I
think,
like
we've
started
to
you
know,
one
thing
might
be
looking
at
like
a
little
bit
more
about
like
this
desired
app
or
app
or,
however,
you
want
to
call
it
like
the
front
and
face
and
like
think
about,
like
how
does
this
actually
interact
and
like
drive
some
of
these,
like
other
cf
custom
resources,
so
that
we
can,
you
know,
share
that
out
asynchronously
and
talk
about
that
as
a
group
in
the
next
cig.
A
Thanks
angelo
so
topic-wise,
I'm
not
sure
if,
like
we,
we
have
concluded
on
on
this
one
or,
if
there's
like
additional
inputs
for
for
this
one
and
at
the
same
time
I
cannot
really
completely
judge
how
much
time
will
take
for
for
rams
topic.
So
any
any
thoughts
should
we
conclude
for
now
on
on
the
first
topic
on
the
crd,
or
is
there
any
additional
aspects
we
should
cover
now.
H
So
the
reason
I
put
that
question
up
there
was
because
a
lot
of
the
sort
of
advocacy
and
the
tutorials
and
the
educational
stuff
that
we've
been
putting
out
this
far
has
typically
been
with
regards
to
here's,
how
you
deploy
your
java
app
place,
how
you
deploy
a
javascript
app-
and
you
know
if
you
are
like
real
hipster-
here's
how
you
do
like
react
and
prisma
and
whatever
right.
H
So
a
lot
of
it
has
been
focused
on
that
developer
experience
and
not
an
awful
lot
on
the
platform
operations
or
some
sort
of
like
day
two
stuff
with
regards
to
cf
for
kids,
and
so
we've
been
having
to
field
a
lot
of
questions.
In
terms
of
how
do
I
set
up
monitoring
for
my
apps
that
are
running
in
cf4k?
It's?
How
do
we
set
up
like
to
give
a
very
specific
example?
H
How
do
I
set
up
like
an
elk
stack
equivalent
for
cf
for
kids
and
things
like
that,
so
we've
sort
of
been
getting
a
nudge
towards
the
ops
side
of
things
a
lot,
and
I
thought
I
could
start
with
the
folks
who
typically
gather
on
this
call
in
getting
some
wisdom.
Some
stories
from
you
know
the
trenches.
What
have
you
or
just
in
terms
of
high
level
design
about
you
know,
here's
how
we
are
thinking
of
incident
management
when
it
when
it
comes
to
cf
for
kids.
H
Here's
how
it's
been
in
the
past
here,
some
refinements
that
we
imagine
would
be
good.
Here's
how
it
is
with
like
vanilla,
kubernetes
and
so
with
cf
here
are
some
of
the
changes
that
we
thought
might
be
useful.
So
anything
with
regards
to
like
reading
and
managing
logs
setting
up
alerts,
doing
like
prometheus
grafana
dashboards.
All
of
that,
I
think
is,
is
useful
information
for
me
at
this.
A
I
Gates,
I
can
jump
in
here
a
little
bit
with
our
experience,
so
we
built
some
custom
dashboards
and
deployed
prometheus
operator
and
have
grafana
working
with,
alerting
and
stuff
like
that.
We
use
it
mainly
to
monitor
the
cf
stack
like
latency
and
and
the
processing
of
istio
how
fast
it
can
reconcile.
I
guess
whenever
it's
processing
changes
and
it
helps
us
decide
when
we
need
to
scale
up
cfrks
as
we've
been
growing
over
100
apps
now,
so
we've
really
liked
the
ability
to
scrape
our
apps.
I
You
have
the
annotation
support
built
in
so
it's
pretty
easy
to
add
metrics
to
any
of
the
apps
that
we
deploy
and
you
have
a
lot
of
metrics
already
available
on
a
lot
of
the
cf
components.
So
that's
been
great
where
we're
seeing
it
lacking
is
in
the
log
aggregation
side
of
the
cf
system,
components
we'd
like
to
see
something
that
could
aggregate
those
logs.
We
have
something
similar
like
on
bosch
with
logger
gator
and
we
can
ship
those
to
elasticsearch
and
get
those
logs
and
have
a
learning
based
on
those
logs.
I
But
since
we
have
multiple
replicas
of
the
cf
components
now
it
gets
difficult
to
understand
errors
when
they
happen,
because
we
have
to
be
checking
a
lot
of
different
pods
and
then
containers
inside
those
pods
as
well.
So
that's
kind
of
where
we've
had
and
especially
as
you
guys
talked
about
moving
more
to
custom
resources.
I
A
Yeah,
so
so
regarding
locks
processing.
So
so
it
sounds
like
you're
indeed
like
looking
into
the
the
kubernetes
locks
directly
to
to
kind
of
get
an
understanding
of
where
the
system
is
right.
So,
as
opposed
to,
I
don't
know,
having
a
demon
set
that
kind
of
collects
all
the
locks
and
streams
them
out
to
kind
of
a
completely
separate
system
like.
I
I
think
like
right
now
you
push
and
if
you
get
an
error
from
cf
push
you're
kind
of
lost
at
where
to
look
next
and
then,
if
you
have
scale,
it
becomes
really
difficult
to
find
out
why
that
error
occurred.
Especially
if
it
just
says
some
generic
error
message
like
package
failed
to
upload
or
something
like
that,
which
I've
seen
quite
a
bit
in
the.
I
A
A
I
guess
also
why
we
like
at
scale,
have
been
facing
and
continue
to
face
issues
with
like
logregator
as
kind
of
a
built-in
aggregation
system
in
kind
of
classical
foundry,
and
I
guess
from
from
our
experience,
we
would
have
loved
to
to
kind
of
just
take
all
the
locks
and
do
as
little
log
processing
in
cloud
foundry
itself
as
possible
and
kind
of
allow
external
systems
to
to
do
all
the
heavy
lifting.
But
that's
at
least,
as
I
said,
our
experience
from
from
a
wash-based
board.
I
Yeah
we
have
a
bosch
base
deployment
as
well,
that's
fairly
large
and
we
collect
all
the
from
logger
creator
and
ship
it
off
to
log
stash
as
well,
and
that's
where
we
do
most
of
the
heavy
lifting
is
in
log
stash.
I
think
something
similar
using
fluentd
on
kubernetes
and
operators
can
choose
where
to
ship
their
logs
using
fluid
d
since
there's
a
ton
of
plugins.
For
that
already.
I
think
that
would
be
a
great
first
step.
A
Cf
and
probably
also
if
I
look
into
the
kubernetes
space,
I'm
not
sure
if,
like
okay
yeah
on
on
the
metric
sides,
maybe
but
on
on
the
logging
site,
I
don't
see
kind
of
a
complete
standardization.
But
I
see
just
a
bunch
of
solutions
that
people
use
there
on
on
the
metric
side
of
the
house.
I
guess
prometheus
is
kind
of
what
most
people
choose,
but
yeah.
H
E
To
a
publicly
visible
github
repository,
so
we
we'd
love
for
people
to
take
a
look
at
it
and
like
comment,
but
it's
also
particularly
named
as
an
explorations
repo.
So
don't
get
too
scared.
If
you
see
something
that
looks
like
sub-optimal
or
whatever
that's
the
purpose
of
it
is
we're
we're
just
trying
to
sort
of
get
some
stuff
down
and
start
exploring
it
so
everything's
malleable,
but
you
know
it's
also
available
for
everyone
to
take
a
look
at.
So
that's
just
what
I
wanted
to
point
out
before.
C
For
those
of
us
not
following
the
projects,
as
close,
perhaps
we
should
are
things
still
very
much
in
an
exploratory
kind
of
finding
our
way
in
spiking
sort
of
phase
and
have
any
vendors
committed
to
commercializing
a
case-based
distribution
of
cloud
foundry
yep.
E
I
am
probably
not
the
right
person
to
talk
about
any
commercialization
of
this
stuff,
since
I
try
to
focus
my
efforts
on
a
lot
of
the
open
source
space
and
making
sure
that's
in
good
shape.
But
at
this
point
basically,
we
want
to
see
what
that
world
looks
like
so
because
we've
been
focusing
on
cf
for
kate's
and
like
working
as
a
like
a
cloud
foundry
on
kubernetes
and
we
get
it
in
relatively
stable
shape.
We
are
now
able
to
devote
a
little
bit
more
attention
to
thinking
like
okay,
so
going
forward.
E
What
might
the
world
look
like
if
we
decided
to
sort
of
change
some
of
these
things
up
and
you
know
sort
of
don't
get
stagnant,
keep
exploring
if
that
makes
sense.
E
Tim,
do
you
have
any
any
thoughts
you
want
to
offer.
B
No
that
well,
you
just
said,
resonates
with
me.
Nothing
to.
A
If
not,
I
guess
we
can
close
a
little
bit
earlier.
Thank
you
very
much
for
now
and
I'll
send
out
the
call
for
next
time,
and
I
believe
angela
already
made
an
offer
to
to
kind
of
follow
up
on
the
progress
of
the
investigation
next
time,
so
we'll
check
it
from
there
thanks
everybody
and
have
a
great
day
cool
thanks.