►
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).
B
A
B
So
the
first
question
that
I
would
ask
to
clarify:
does
the
user
always
deploy
first
and
then
enable
when
we're
talking
about
deploying
what
are
we
talking
about,
that?
That
could
mean
two
things
you're,
either
in
deploying
managed
apps
to
your
cluster
like
Prometheus
or
you're,
deploying
your
own
application,
I
think
what.
B
Is
that
you
could
do
it
in
you
could
do
it
either
way
so
the
user
on
scenario
a
to
deploy
their
app
and
say
hey,
you
know
what
would
be
cool
some
metrics
about
my
app.
Let
me
put
some
metrics
of
in
my
class
early
medias
or
whatever,
and
then
do
it
after
or
they
there
could
be.
You
know
very
organized
and
say:
I'm
gonna
put
all
the
things
I
need
in
place
first
and
then
I'm
gonna
deploy
one
app.
So
there's
no
really
one
way
to
do
it.
A
B
So
that's
in
a
more
like
non
startup
kind
of
way
right
where
you're,
seeing
it's
an
enterprise,
customer
and
they're
requesting
something
from
a
DevOps
engineer
and
the
DevOps
engineer
gives
them
kind
of
a
platform
to
deploy
yeah.
In
that
case,
it
could
be
like
that,
so
it
is
possible
that
the
user
may
want
to
enable
monitoring
before
deploying
yeah,
that's
totally
possible,
so
yeah,
both
I
guess
the
the
answer
is
both
depending
on
the
team.
That
means
her
I
think
that
small
teams
and
small
startups
are
kind
of
deployed.
B
A
B
A
B
B
Yeah
I
would
say
that
it
kind
of
fits
in
in
that
anything
that
you
need
for
operation
or
observability
kind
of
follows
the
same
job
to
be
done
flow
all
right.
So,
let's
say:
hey
I
have
my
app,
but
now
I
want
to
secure
it.
So
I
want
HTTPS.
So
you
go
to
your
cluster.
You
find
an
app
that
matches
your
purpose
and
you
install
it
monitoring
it's
kind
of
the
same
way.
B
If
you
deployed
your
app
and
now
you
want
to
get
some
metrics
for
health
or
stuff
like
that,
then
the
flow
is
kind
of
the
same
and
for
the
second
use
case
that
we
talked
about
where
it's
kind
of
a
DevOps
engineer
setting
this
up
for
you
kind
of
the
same
all
right,
you
first
set
up
all
the
requirements
and
the
flow
is
kind
of
the
same
now.
The
requirements
specific
routine
may
vary
right
because
not
every
team
is
going
to
want
to
have
like
a
new
cluster
runner
or
not.
B
Every
team
is
gonna
want
to
have
you
know,
I,
don't
know
some
other,
like
certain
matters
right
like
an
AWS
customer
may
probably
be
using
something
else.
Other
than
third
manager,
so
they
probably
have
a
different
flow.
That's
outside
of
good
luck
for
that,
but
yeah
I
would
say
those
operators
jobs
to
be
done.
I'll
follow
kind
of
the
same
flow,
so
they
fit
in
with
the
other
configuration
use,
cases
I
would
say
almost
one-to-one
I
would
say
just.
B
A
B
Full,
like
you,
cannot
get
the
full
service
experience
outside
I
was
saying
that
yes,
so,
for
example,
in
Canada.
Sorry,
can
you
hear
me
yes,.
B
I
was
saying
that,
for
example,
with
Canadian
functions,
if
you
want
to
get
the
full
experience
with
monitoring
included,
that
shows
you
how
many
times
your
function
has
been
invoked
or
you
want
to
see
yeah,
so
that
requires
Prometheus.
In
addition
to
que
native
rights,
ok
native
provides
you
with
the
ability
to
do
things.
Then
Prometheus
provides
you
with
the
ability
to
see
things
you.
B
A
And
where
would
I
would
we
envision
this
K?
Maybe
monitoring
on
a
project
level
or
on
the
cluster
level
on
the
manage
applications
level.
B
Right
now
it's
right
now
it
happens
wherever
your
function
lives.
So
if
your
function
lives
on
your
project
and
you'll
see
them
there
right
now,
if
I
set
up
a
group
level,
cluster
I
can't
really
set
up
individual
functions
of
the
group
level.
They
have
to
be
set
up
at
the
project
level,
so
it
will
always
be
viewed
from
the
project
level
where
it's
were
you
to
play
a
function,
but
the
cluster
itself
may
have
been
deployed
to
a
group
to.
A
B
So
I
I
think
that
the
only
main
difference
here,
the
short
answer
is
no,
nothing
is
different.
You
follow
the
same
steps.
We
see
a
lot
of
self
manage.
Users
are
deploying
clusters
on
their
infrastructure,
so
they
don't
have
a
way
to
easily
add
the
cluster
to
their
project
right
where,
as
if
you
create
a
cluster
from
good
lab,
it's
a
couple
of
clicks.
B
So
the
experience
is
different
for
self-managed
customers,
in
that
they
have
to
kind
of
log
in
to
the
command
line
of
the
cluster
and
gather
the
credentials
from
the
cluster
like
the
API,
URL
certificates,
the
token
and
then
plug
them
in
that's
I
would
say
the
only
difference
in
adding
the
cluster,
but
as
far
as
steps
to
monitor
it,
it's
same
yeah
there's
nothing,
that's
different.
Okay,.
A
When
we
move
to
the
CI
model
for
installing
manage
apps,
this
is
a
kind
of
warn.
Will
it
open
up
opportunities
for
us
to
automate
the
process
of
installing
promethease
ingress
in
an
elastic
stock
elasticsearch
agus,
for
example,
would
it
make
it
possible
to
install
all
apps
necessary
for
duplication
monitoring
to
make
it
possible
to
view
metrics
and
loads
automatically
when
deploying
an
application?
Do
you
see
any
issues
with
that
approach?
Yeah.
B
So
the
short
answer
is
that
we
have
that
opportunity.
Today
we
wanted
to
install
all
of
those
apps
automatically,
there's
nothing
stopping
us
from
doing
it
today.
There
will
be
nothing
stopping
us
from
doing
it
when
we
move
to
the
CI
model,
so
that
the
reality
is
that
not
every
user,
that's
using
the
kubernetes
integration
is
using
get
lab,
managed
apps.
So
it
would
be
kind
of
a
very
heavy-handed
assumption
of
that
we
would
be
making
of
saying
hey.
B
If
you,
you
know,
add
your
cluster,
then
then
it's
immediately
that
you
want
to
use
killer,
managed
apps
and
that's
not
the
case.
So
we
have
a
lot
of
customers,
especially
on
enterprise
customers
or
I'm
working
more
concerned
with
security.
Then
don't
use
gitlab
managed
apps
because
of
the
approach
that
we
have,
where
you
know
the
credentials
that
you
give
good
lab
or
cluster
wide
and
people
don't
like
that.
Yeah.
B
A
B
Some
there's
this
other
flow,
where
your
software
development
team
already
had
a
kubernetes
practice,
and
you
were
already
using
kubernetes.
You
already
have
patterns
for
namespaces
and
applications
and
things
like
that
and
then
you
add
the
cluster
to
get
lab,
because
you
want
to
see
things
like
deployments
and
deploy
boards
and
pod
logs
and
web
terminals
and
use
all
of
these
cool
features.
B
But
good
luck
doesn't
recognize
the
fact
that
there
are
already
apps
installed
in
cluster,
and
you
know
to
be
quite
honest-
it's
quite
hard
because
the
approach
and
the
patterns
that
people
follow
for
that
and
maybe
wildly
different
right.
We
have
a
very
opinionated
approach
of
installing
those
apps
in
a
particular
namespace,
deploying
your
app
to
a
particular
namespace
things
like
that.
B
So
yeah
I
would
say
that
if
you
have
an
existing
kubernetes
practice,
we
have
an
opportunity
to
kind
of
recognize
what
apps
are
already
installed
in
your
cluster
and
show
that
state
in
the
in
in
in
the
kubernetes
page.
And
let's
say
that
would
require
for
you
to
follow.
You
know
some
Naumann
clay,
sure
that
we
give
you
about.
Abs
have
to
be
installed
in
this
namespace
and
you
have
to
follow
this
and
that
and
then
we
could
recognize
what's
already
installed
in
your
cluster.
B
So
yeah
we
have
an
issue
out
there
for
kind
of
querying
cluster
state
and
show
you
what
we
found
in
your
cluster,
like
you
already
have
Prometheus
you
already
have
and
yeah
the
the
the
other
thing
is
you
point
out
is
that
there
are
people
that
may
already
have
committees
installed
and
they
use,
like.
You
know,
different
instances
of
Prometheus
for
different
things.
That's
what
they
want
to
use
for
their
app.
They
don't
want
to
deploy
per
cluster
with
get
left.
They
just
want
to
use
what
they
have
on
their
existing
infrastructure.
B
B
A
A
A
Okay,
so
I
think
that
you
could
comment
separately
in
the
mural
from
looking
at
the
flows.
Do
you
see
any
important
gaps
or
anything
that's
incorrect?
We
might
have
identified
one
flow.
That's
missing
two
integrations
to
add
Prometheus
and
oh
that's
more
relevant
to
the
last
point,
and
can
you
think
of
any
other
missing
use
cases
or
user
flows?