►
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
Oh
Thank
You,
Maria,
I'm
gonna,
say
this
dove
and
I'm
pretty
sure.
You'll
agree
with
me:
I
think
the
logging
capability
was
in
get
lab
for
customers.
Applications
is
owned
by
the
APM
team,
so
they
should
be
the
primary
driver
and
what
I
don't
want
to
do
is
slow
down
their
efforts
and
the
things
that
they
need
to
accomplish
in
order
to
increase
the
scope.
A
I
think,
it's
probably
fair
to
say,
Victor's,
not
on
the
call
but
Daniel
that
the
improvements
that
you're
talking
about
around
logs
are
not
as
a
higher
priority
for
your
teams
as
the
other
improvements
that
doe
dove
in
the
APN
team
are
working
on
and
if
that's
the
case,
I
just
wanted.
One
thing
that
can
that's
not
a
good
success
pattern
at
gate
lab
is
if
we
try
to
bundle
everybody's
work
together
and
build
a
bunch
of
dependencies,
so
I
wants
to
make
sure
we're
assigning
the
like
primary
ownership
of
this
is
on
those
team.
A
A
The
other
question
I
will
ask
about
the
research:
is
dove
I?
Don't
the
the
fact
that
you're
in
the
APN,
the
research
like
tasks
that
is
linked
here
is
about
validating
the
maturity
level.
When
we
plan
to
move
it
to
viable
I,
don't
know
how
heavy
a
lift
that
is
from
a
UX
research
perspective
or
you
would
expect
it
to
be
from
like.
Are
you
doing
this
to
understand
the
users,
or
is
this
the
pure
maturity
level,
verification
effort.
C
As
Maria
mentioned,
Amelia
already
did
use
the
research
I
think
even
before
I
join
I.
Remember
that
I
was
going
to
that
user
Richard,
which
was
pretty
good.
So
we
have
a
good
understanding
with
what
users
need
in
terms
of
monitoring
for
logs
that
specific
issue
you
mentioned
such
issue,
you
mentioned
I,
think
I.
Think
Andre
also
can
shed
some
light
because
he
is
running.
This
research
is
more
about
validating
the
user.
Experience
and
note
the
user
needs.
D
D
A
E
A
I
know
that
that
process
is
not
as
far
as
I
understand,
super
well
defined,
but
maybe
we
can
go
around
to
the
other
groups
and
Victor's
not
here
to
represent
Canada
but
Daniel.
If
you
can
talk
about
any
user
research
that
you
were
interested
in
and
how
users
interact
with
logs
for
the
items
was
listed
for
you,
yeah.
B
So
really,
the
only
piece
that
we
did
here
was
to
research,
the
user
for
pot
logs,
and
we
couldn't
pat
him
good
idea
of
who
was
looking
at
those
logs
and
that's
kind
of
the
extent
of
the
research
that
we've
done
when
it
comes
to
logs.
One
thing
that
I,
don't
I'm
not
fully
familiar
with
how
it
works
today
is
how
users
are
accessing
the
elastic
logs
today,
but
I
could
imagine
that
it's
probably
not
from
the
same
place
where
they
access
pod
locks
today.
B
C
B
Imagine
no,
the
one
that
is
installed
in
cluster,
that
is
aggregating
blocks
for
my
application,
as
it's
running
right.
So
I
think
that
gitlab
maintainer,
x'
orchid,
lab
admins
will
probably
want
to
see
logs
for
get
lab
elastic.
But
if
I'm,
a
software
team,
if
I'm
a
software
developer
and
I
put
elastic
in
my
cluster
I,
would
imagine
that
it's
aggregating
all
the
logs
for
how
my
app
is
running
and
when
I
encounter
a
problem
or
I
want
to
research.
An
issue
I
probably
want
kind
of
a
centralized
place.
B
Thing
do
blogging
and
I
think
that
pot
logs
right
now,
it's
gonna
be
only
clear
an
example
that
we
have
I,
don't
know
where
the
elastic
locks
are
being
surfaced
and
get
wet
if
at
all,
so
I'm,
just
saying
it'd
be
nice,
since
all
of
those
things
have
to
do
with
how
my
app
is
running
to
have
them
in
a
centralized
place.
Yes,.
C
C
A
C
A
C
But
but
yeah
I
mean
this
is
exactly
what
we
are
working
on
today
and
we
have
a
pretty
good
understanding
of
what
are
the
next
features
that
we
would
like
to
put
inside
to
add
to
the
to
that?
To
that
view
to
the
centralized
view-
and
we
will
also
want
to
combine
that
with
the
ability,
because,
right
now,
as
you
mentioned,
we're
I
mean
for
the
developers
only
so
we
are
just
exposing
the
load
of
the
apps,
but
what
about
the
gitlab
manager,
not
only
elasticsearch
primitives,
or
maybe
things
that
we
install
for
security.
C
C
A
A
C
F
A
And
that
makes
sense,
I
guess
the
research
issue
to
suggest
that
blogging
is
at
viable
I.
Imagine
is
going
to
generate
a
lot
of
new
things
for
us
to
do
to
polish
that
experience
that
we're
just
it's
a
little
bit
strange
to
call
it
viable
because
it's
kind
of
like
the
new
MVC
for
this
pot
Explorer
experience,
although
we've
had
that
pod
or
the
log
trailing
thing
for
a
while
I,
just
when
I
think
about
douve
your
team's
efforts
around
logging,
I,
don't
know
if
it's
gonna
I.
A
C
F
C
C
Approach
but
I
really
wanted
to
understand
an
answer.
It
could
be
from
a
user
today
they
don't
care
okay.
Maybe
this
is
really
something
that
not
sure
we
can
actually
do
something
if
they
will
say
immediately,
but
it
will
be
good
to
understand
because
from
things
that
I'm
getting
on
logging
specifically,
this
is
something
that
there
is
like
a
huge
debate
between
like
the
POE
elasticsearch
that
would
like
structured
load
and
the
poor
look
funnel
okay,
which
is
like
this
product.
This
is
like
an.
C
And
I
think
it's
it's
really
interesting
to
understand
how
users
navigating
today,
to
notes,
because
today,
most
most
users
actually
just
jump
into
the
notes,
probably
directly,
even
not
from
incident
I
mean
unless
they
have
like
consolidate
solution
today,
the
most
common
solution
of
success
and
if
there
are
using
metrics
with
any
other,
they
probably
are
moving
between
two
screens.
But
I
only
wants
to
better
understand
if
they
are
reacting
from
to
an
incident
and.
C
F
C
F
C
C
C
C
F
D
Yeah
for
sure,
I
think
at
least
the
second
point
you
mentioned
we
can,
we
can
add
to
the
viable
and
discussion
about
the
elastic
or
graph
Anna
style
or
the
type
of
looks.
This
is
more
for
it's.
In
my
opinion,
we
should
do
different
kind
of
research.
It
wouldn't
be
interviews
but
something
quantitative
where
we
would
get
plenty
of
answers
that
we
can
make
decisions
but
yeah
that
will
help
us
to
make
decisions,
but
we
can
discuss
it.
I
will
discuss
it
separately
from
from
this
issue.
Other.
A
F
A
B
But
really
that
came
from
an
internal
need
of
you
know
we're
trying
to
dog
food
as
much
as
possible.
We
came
across
a
problem
with
the
Application
Firewall.
You
know
initially,
when
we
first
encountered
that
problem.
We
don't
we
didn't
know
what
it
was.
So
it
would
have
been
helpful
to
just
see
those
things
right
on
the
screen.
I
haven't
gotten
any
reports
from
external
users,
kind
of
wanting
that
same
functionality,
but
it
may
be
one
of
those
things
where
people
are
already
used
to
going
outside
of
good
lab
to
fetch
those
logs.
B
A
C
I
do
consider
this
there's
like
a
dog
fooding
opportunity,
so
I
do
see
value
when
having
this
as
an
extension
of
our
solution.
I
think
that
the
conversation
mainly
revolves
around.
Where
are
we
going
to
expose
them?
The
same,
plum
Explorer
that
we
have
today,
but
there
are
some
technical
challenges,
especially
because
of
the
way
we
are
deploying
elasticsearch
the
cluster
level,
and
we
want
to
expose
all
the
namespace
and
who
is
going
to
see
this
because
normally
those
probably
something
like
restricted
in
terms
of
and
so
I
think.
C
My
concern
here
is
that
if
we
would
split
it,
then
eventually
we
will
have
to
separate
like
two
separate
code
base
that
we'll
need
to
maintain,
and
if
we
evolve
one
log
Explorer,
then
we
need
to
evolve
another
one
to
be
very
hard
to
share
the
same
code
base.
So
this
is
where
the
conversation
is
more
about.
You
know,
I
think
it's
important.
It's
a
good
opportunity,
as
I
mentioned,
for
the
funding,
but
that's
my
concern
is
that
and.
C
Because,
right
now
we
are
deploying
elasticsearch
on
the
cluster
level
to
explain
that,
so
we
are
doing
it
on
the
cluster
level
and
we
are
allowing
the
user
to
select
the
environment
in
one
of
the
top
down.
Now,
environment
is
actually
a
named
States
and
to
deploy
to
expose
the
get
lab
manager
up.
We
need
to
expose
the
get
load
manage
namespace,
and
where
do
we
do
that?
And
how
are
we
going
to
dictate?
C
Which
I
mean
we
can
we
can
find
ourself
in
a
project
that
the
namespace
does
not
belong
to
to
that
same
project?
It
sits
in
another
project,
although
it's
in
the
same
cluster.
So
that's
basically
the
that's
basically
the
debate.
How
are
we
going
to?
How
are
we
going
to
select
the
namespace
and
and
what
the
team
offer
they
said?
C
Okay,
if
we
put
it
in
another
place,
we
can
completely
change
the
UI
of
the
selectors
and
have
instead
of
environment,
will
have
namespace
and
that
way
we
will
solve
the
problem
with
the
restriction,
both
with
the
instruction
and
the
and
the
visit
and
the.
Why
of
the
of
the
log
Explorer.
There
is
an
issue:
I
can
make
it
the
issue,
but
all
this
discussion
that
we
had
I
had
a
suggestion
on
how
we
can
do
that
and
at
least
engineer
that
I
spoke
woody
said.
If
you
need
to
think
about
it.
A
Still
want
to
go
tight,
though,
could
I
challenge
that
your
suggestion
of
the
way
we
need
to
prove
it
is
is
more
expansive
than
the
immediate
pain
point,
which
is
we
need
to
surface
wife
logs,
because
the
defending
could
choose
to
surface
wherever
they
need
to
the
laugh
logs.
If
the
last
the
search
is
installed,
they
can
use
the
same
design
component
for
the
log
explorers
they
need
to,
but
they
can
choose
to
solve
that
specific
use
case.
A
However
they
need
to,
and
then
we
can
encounter
or
confront
the
managed
app
one
when
we've
done
the
research
and
have
had
the
time
to
pursue
it,
it
seems
like
the
only
thing
that's
driving
us
to
want
to
solve.
That
today
is
the
need
to
display
the
wife
logs.
If
that's
the
case,
we
should
let
them
go
figure
out
a
solution
to
do
that.
Yeah.
C
A
C
C
So
the
back
end,
it's
a
compass
and
be
the
same.
We
will
share
the
same
codebase
in
the
back
end.
The
concern
that
I
have
is
on
the
font,
and
this
is
where
we
want
to
get
the
feedback
form.
We
want
to
get
the
feedback
on
eventually
want
to
get
the
feedback
on
the
fondant
we
will.
We
will
find
out,
you
know
what
kind
of
logs
they
want
to
display
and
surface
okay,
we'll
take
one
two,
three
iteration
we'll
get
the
feedback,
that's
it
and
then
we
need
to
start
evolving
the
Explorer
okay.
C
What
type
of
filter
you
want
to
have?
What
type
of
search
you
want
to
see,
visualization
and
so
on?
Alerting
I
mean
so
many
things
we
can.
We
can
work
on
and
that's
that's
the
only
concern
that,
if
we'll
have
like
two
separate
project,
they
will
start
drifting,
everyone.
You
know
each
for
their
own
side
and
you
know
it
will
basically
be,
but
not
so
I'm
saying
user
friendly
and
we
won't
be
dog
fooding.
Also
I.
C
A
What
I,
what
I
want
to
make
sure
we're
not
doing
is
that
dialogue
seems
like
we're
we're
suggesting
we
should
take
non
prioritize
leaps
in
configure
for
exposing
managed
apps
and
the
log
explore
for
exposing
this
like
separate.
How
do
we
look
at
managed
apps
altogether
when
the
immediate
pain
point
and
driver
of
it
seems
to
be
the
defending
who
really
needs
to
display?
Well.
F
E
C
Should
we
engage
the
Phantom
and
ask
them
if
they
can
do
that
by
themselves?
Do
we
want
to
do
like
no
more
thinking
around
whether
we
want
to
do
that?
The
this?
Actually
it's
funny,
because
it's
it's
a
bit
coming
back
to
the
need
for,
like
technical
discussion
like
I,
think
I'll
lead,
because
I
think
one
of
the
one
of
the
challenges
that
we
have
the
project
level
cluster
level
namespace.
C
How
would
you
expose
it
that
was?
That
was
a
discussion
that
happened
since
day.
One
is
we
deploy
the
elasticsearch
as
we
plan
to
deploy
the
last
Excel
and
I
feel
like
that
I'm
missing,
I'm
missing,
like
a
detailed
discussion.
Maybe
we
have
a
solution,
that's
what
I'm
saying.
Maybe
we
have
a
solution
that
we
just
don't
see
and
it
can
be
solved
through
the
log
Explorer
and
maybe
the
Phantom
can
have,
but
maybe
we
can
leverage
the
same
and
same
capability
that
we
have
today.
I.
A
Think
it's
worth
a
discussion
with
I
think
there's
strong
technical,
lead
and
PM's
on
the
defense
side,
though
I
don't
know,
if
that's
the
core
making
sure
Adrian
and
Lucas
Charles
is
the
technical
lead
on
the
defense
side
and
Sam
ker
as
the
PM
just
coordinating
a
discussion
between
them
and
the
design
designers
on
the
log
side
and
I.
Don't
know
if
defend
has
a
design
I
think
they
do.
That
would
be
good
to
coordinate
that
between
them.
A
What
what
what
I
did
here
earlier
in
this
conversation
is
that
the
more
pressing
research
need
is
this
verification
of
viable
and
I
would
think
that
will
generate
a
lot
of
future
roadmap
for
the
team
just
in
continuing
to
iterate
and
improve
the
experience
of
the
vlog
Explorer.
That's
shipped
for
the
first
time
here
this.