►
From YouTube: App Runtime Platform Working Group [Mar 2, 2022]
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
Everyone
welcome
to
our
march
app
runtime
platform
working
group
meeting.
I
had
a
look
at
my
docs
to
make
sure
I
said
the
right
name
of
the
working
group.
It's
good
to
see
you
all
here.
We
have
a
couple
of
things
on
our
agenda.
Thank
you
you're
again
and
jeff
for
adding
your
items.
I
love
it
when
I
am
not
the
only
one
adding
items
to
the
agenda,
I
put
two
little
things.
First,
they
should
be
pretty
fast.
A
One
of
the
things
that
I
brought
up
is
that,
because
of
ivan
and
mikey's
leaving
over
the
past
few
months,
leaving
our
community
that
currently
diego
is
now
a
vmware,
only
working
group
and
I
think
for
a
while
logging
in
metrics
has
been
a
vmware
only
working
group.
So
if
you
do
not
work
for
vmware-
and
you
know
anyone
who
would
like
to
start
to
work
towards
enjoy
joining
these
sorry,
not
working
group
they're,
like
approver
list,
know
anyone
who
wants
to
join
the
approvers
or
work
towards
you
know
getting
there.
B
Yeah,
so
I
think
lsap,
I'm
currently
in
the
team
who
took
over
the
local
data
and
also
we
are
starting
looking
into
something,
but
they
have
not
yet
contributed
a
lot.
Of
course.
We
would
like
to
bring
somebody
in
as
an
approval,
but
we'll
be
a
little
bit
scared,
because
it's
a
very
complex
beast
and
nobody
really
says
I
want
to
review
full
requests
and
take
responsibility
currently,
but
in
principle
we
would
like
to
bring
us
into
a
position,
then
not
true.
A
Yeah,
but
that's
the
other
thing
I
talked
to
the
working
to
the
toc
about
yesterday-
is
that
currently
the
there's
some
kind
of
set
standards
of
what
it
means,
what
you
have
to
do
to
become
an
approver.
I
think
right
now.
It's
review
30
prs,
which
does
not
make
sense
for
every
area,
and
so
I've
been
talking
to
them
about
changing
that
up.
So
I'm
sure
we
can
work
together
to
find
something
that
wouldn't
take
more
than
a
year
of
full-time
work
to
do,
but
yeah,
that's
great.
A
If
you
want
to
nominate
someone
or
someone's
from
the
team
to
like
start
working
towards
that,
you
can
reach
out
to
me
and
probably
ben.
B
A
Good,
the
other
thing
is:
let's
see,
updates
on
github
teams,
pr
workflows,
those
to
cprs
are
finally
being
merged
in,
and
I
know
stefan
and
jeff
you
volunteered
to
help
put
these
into
place
so
that
we
will
officially
start
doing
pr
workflows
everywhere,
we'll
get
everyone
the
right
permissions
I've
been
out
for
the
past
month,
so
I
have
not
come
up
with
you
since
you
volunteered
to
do
that,
but
I've
also
seen
that
ruben
who's
part
of
a
different
working
group.
A
Maybe
the
infrastructure
working
group-
maybe
bosch
working
group-
he's
been
doing
a
lot
of
automation
around
this.
So
he's
been
converting
our
like
working
group
doc
in
the
community
github
into
yaml,
so
that
his
automation
can
just
pull
it
in
and
do
stuff.
So
there
might
be
some
yeah
collaborating
we
can
do
with
rubin
but
I'll
reach
out
to
both
of
you
soon.
A
C
So,
just
to
give
you
a
little
background,
I'm
working
in
a
logging
team
at
sap,
where
we
several
servers
to
relevant
here,
are
the
platform
logging
for
cf
and
also
application
logging,
so
the
service
that
is
given
to
customers-
and
I
started
with
the
troublesh
or
maybe
just
to
give
you
a
short
heads
up.
So
we
can
then,
for
example,
have
like
not
all
of
the
four
golden
signals,
but
three
of
them
so,
for
example,
error
rates
calculated
based
on
on
those
go
router
access.
C
I
was
yeah
and
I
think
we
can
do
a
lot
here
and
then
my
idea
even
went
further
by
looking
at
those
troubleshooting
error
responses,
and
there
is
some
table
below
where
I
already
like,
contributed
to
fixing
some
formatting
issues
where
it
said.
C
Okay,
if
you
have
a
certain
status
code
and
something
written
in
the
cf
error
field,
then
you
can
say
whether
the
source
of
the
failed
request
is
from
the
platform
or
the
client
or
application,
and
my
idea
was
if
we
could
like
add
more
information
here
and
then
end
up
with
something
like
a
pie
chart
saying:
okay,
the
customer
sees
their
requests.
Failed-
and
we
could
be
even
that
transparent,
saying,
okay,
that
that
was
due
to
your
app
being
failing,
or
that
was
due
to
the
platform,
and
so
that's
like
my
wish.
C
My
idea
not
sure
how
far
we
can
get
there.
I'm
not
sure
how
much
it
would
make
sense.
So,
on
the
one
end,
I
think
it
would
make
sense
for
us,
in
the
from
the
platform
view
to
see
for
the
failed
requests
like
the
percentage
cost
by
ourselves
and,
on
the
other
hand,
to
make
things
transparent
for
the
customers.
C
I
started
from
like
fixing
the
the
formatting
of
the
documentation
and
also
came
up
with
like
some
ideas,
but
where
I'm
simply
not
sure
and
not
the
expert,
because
I'm
not
coming
from
the
depths
of
cf,
but
rather
from
a
logging
service
or
logging
perspective
yeah.
Maybe
then
it's
your
turn
to
comment
on
it
and
if
I'm
here
at
the
right
place
to
share
this
idea.
D
D
Okay,
so
I
see
you're
trying
to
track
some
of
these
four
golden
signals.
I
like
hearing
that
I've
been
you
know,
hearing
and
looking
into
this
sort
of
stuff
for
a
while
now
and
I'm
wondering
why
you
decided
to
try
and
track
these
using
the
access
logs
rather
than
exposing
metrics
or
working
to
a
metrics,
more
metrics,
looking
side
of
things.
C
That's
partly
because
we
work
or
just
like
our
starting
point
is
the
elk
stack.
We
could
include
metrics
there.
We
are
working
also
in
that
direction.
D
It's
easier
short
term
to
work
towards
matching
on
error
on
access
locks.
Is
that
what
I'm
getting.
C
Yeah,
so
if
you
have
only
a
short
period
of
time
or
like
we're
talking
about
days
here,
then
you
can
like
really
drill
down
into
each
and
every
request
you
can
like
see
from
those
failed
requests,
who's
doing
what
and
I
recently
demonstrated
internally
some
of
those
dashboards
and
that
would
have
to
check
what
can
be
shared
in
this
round.
To
be
honest,
but
you
can
really
drill
down
here
and
also
for
the
customers.
They
like
get
their
locks
and
they
get
what
they
can
see.
C
But
if
you
can
also
get
the
metrics,
for
this
would
be
nice
as
as
well,
but
I
would
like
still
keep
the
logs
and
as
a
source
of
or
where
you
can
drill
down
much
deeper
and
you
can
like
also
see
like
which
paths
have
been
requested.
What
were
the
parameters,
and
so
that's
like
a
very
rich
source
of
information,
and
you
can
have
like
the
same
dashboards
you
built
with
metrics,
but
a
very
impressive
drill
down.
On
top
of
that.
C
D
C
B
Also
in
the
table,
you
see
it's
either
application
or
platform
error
502,
and
it
was
always
for
us
everything
patrick
can
maybe
have
take
over,
because
he
has
more
experience
in
the
meantime
difficult
to
to
discuss
with
application
owners
if
it's
a
platform
or
an
application
issue,
for
example,
if
connection
could
not
be
established
with
the
application,
was
it
because
the
application
was
overloaded
or
because
there
was
something
in
the
platform,
so
maybe
here
it
would
be
also
interesting.
C
Maybe
I
can
share
so
in
that
yeah,
where
I
fixed
something.
I
saw
that
we
had
a
lot
of
certificates.
It's
not
valid
errors.
C
Where
I
assumed
okay,
if
that's
like
this
x
x,
5
0
9,
that
might
be
then
also
a
platform
issue,
because,
like
all
the
x
509
errors
were
platform
related,
but
yeah.
B
E
But
during
just
one
question
from
my
side,
so
what
exactly
are
you
expecting?
You
want
this
table
more
complete
with
all
the.
E
C
When
I
looked
at
it,
it
hasn't
changed
for
a
while,
and
I
would
assume
simply
new
arrows
popped
up
in
the
meantime
because
of
code
changes,
but
I'm
not
sure
so.
I
just
looked
at
it
and
saw
like
the
real
content
changes
sometime
back,
I
think
more
than
a
year
and
simply
wanted
to
get
back
to
you.
Maybe
you
cannot
do
much
more
than
this,
but
maybe
you
can
I
I
don't
know.
I
I'm
also
not
aware
about
your
level
of
knowledge
for
this
and
it
can
be
easily
set
for
those.
C
I
could
maybe
make
a
list,
and
you
then
just
rate
if
it's
platform
app
or
unknown
and
from
what
I
can
see
internally
so
with
like
big
landscapes,.
C
And
I
would
just
try
to
extract
something
from
it.
I'm
also
not
sure
how
much
you
want
to
invest
on
it
and
if
you
have
like
higher
prior
items,
which
would
be
also
fine,
I
just
want
to
bring
up
the
topic
and
see.
C
What
do
you
think
about
it
and
if
we
can
improve-
and
if
this
like
goal
of
like
then
like
final
pie
chart
is
realistic,
saying
who's
who's
responsible
for
the
failed
requests
would
be
also
fine.
If
we
can
then
can
say
it's
either
app
or
platform
or
like
unknown,
and
but
we
are
like
more
complete
on
the
list.
A
Yes,
I
definitely
see
the
need.
I
know
how
hard
it
can
be
to
look
at
these
error
logs
and
try
to
figure
out
what's
going
on,
so
I
definitely
hear
that
problem.
My
guess
is
you're
right.
This
hasn't
been
updated
and
it's
hard
to
update
right
because
it's
like,
oh,
we
have
it's
not
like.
We
know
of
every
error,
that's
going
to
come
up
it.
We
would
have
to
remember.
As
you
know,
we
see
them.
A
A
One
of
the
things
that
I
I
like
the
idea
of
a
pie
chart
and
I
like
the
idea
of
adding
unknown,
because
one
thing
I'm
always
worried
about
is,
like
stefan
said,
there's
some
things
that
can
be
either
like
in
your
pr
right
now
it
talks
about.
Do
you
mind
going
to
the
pr
tab?
What
just
went
over,
which
one
no
endpoints
right,
that
could
be
a
user,
a
dev
forgot
to
add
a
particular
endpoint,
and
so
it's
I
would
call
that.
A
It
may
be
an
app
fault
that
the
endpoint
was
not
added
or
it
could
be,
go
around
or
drop
all
of
its
routes.
Something
went
wrong
with
the
platform
and
you
know
a
platform
issue,
and
so
my
worry
is.
A
A
little
bit
of
you
know
we
expose
things
to
our
end
customers
and
then
our
customers,
saying
like
oh
there's,
all
these
platform
issues
and
opening
support
tickets.
You
know
when
they
see
oh
platform
issues.
As
you
know,
you
know.
75
of
these
are
platform
issues,
but
I
do
like
the
idea
of
an
unknown
or
like
an
either
category
for
for
some
of
them.
A
A
C
So
we
don't
need
to
add
that
to
the
log,
because
we
then
can
parse
and
interpret
it
in
the
dashboards.
But
if
you
would
add
it
to
the
logs,
that's
also
an
idea
to
improve.
C
C
Dogs
dogs
would
be
sufficient,
but
yeah
for
sure
you
would
write
the
locks.
That
would
be
very
nice
service.
So
I'm
not
stopping
you
from
doing
that.
A
C
Not
yet
so
we
first
wanted
to
verify
that
this
issue
would
make
sense,
because
it
was
not
100
sure,
but
they
can
and
start
an
issue
and
then
like
post,
like
typical
errors,
I
see
I
also
have
like
from
the
big
landscapes.
I
think
you
could
overview
what
are
like
the
the
pressing
and
most
common
error
messages.
I
see
there,
which
are
not
in
the
list.
A
That
sounds
really
great,
especially
because,
as
a
you
know,
a
vmware
employee.
We
don't
have
our
own
managed
tasks,
and
so
we
don't
have
a
realistic
environment
that
we
can
get
into
easily
and
grab
logs
from.
So
any
logs
from
a
real
environment
would
be
really
helpful.
C
A
That
sounds
really
really
great.
When
you
create
the
issue,
you
can
post
it
in
the
working
group
channel
in
slack.
C
A
That
I
think
you're
invited
to
now
I
will
find
it.
I
was
had
to
do
after
this
in
interest
of
time.
I'm
gonna
say
thank
you
year
again.
This
is
great,
I'm
so
glad
you
came,
I'm
so
glad
you
found
our
working
group,
I'm
so
glad
you
came
presented
and
I'm
gonna
hand
it
over
to
jeff
to
talk
about
dynamic,
asgs.
F
Cool,
so
I
just
wanted
to
give
an
update
on
where
our
work
on
it
is
largely.
F
F
F
So
if
you
want
to
poke
around
and
try
it
out
and
see,
if
you
find
any
problems,
please
please
do
once
we
get
the
next
release,
cut,
we'll
probably
have
a
pr
into
cf
deployment
that
will
enable
this
fully
and
then
I
was
also
asked
about
app
specific
asgs
and
looking
into
that-
and
it's
not
something
that's
currently
on
our
radar,
because
I
don't
know
that
we
have
a
lot
of
customers
asking
for
it.
F
A
C
I
just
wanted
to
ask
what
asg
stands
for.
Probably
this
is
known
to
everyone
in
the
round,
but.