►
From YouTube: 2022-08-03 GitLab.com k8s migration (EMEA/AMER)
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
Hello,
everybody,
I
guess
we
are
complete-
almost
complete,
I'm
gonna
do
the
honor
today,
since
ark's
car
break
is
out,
so
today
is
22nd
of
august.
The
third-
and
this
is
gonna,
be
the
kubernetes
migration
demo
and
we
have
no
demo,
but
we
are
gonna
have
plenty
of
discussions.
A
So
ahmad
do
you
wanna
verbalize?
Maybe
your
your
first
point.
B
B
And
the
remaining
thing,
also
the
dashboard
and
the
metrics
I
will
have
a
talk
today
was
with
jenny
to
explain
like
the
like.
Where
are
the
stuff
and
like
stuff
like
that,
but
it's
also
like
almost
closed.
I
think,
because
steve
and
sean
updated
them
last
month.
I
think
there
is
only
one
remaining
issue
which
is
adjusting
the
deployment
according
to
the
metrics
and
thresholds
we
have
so
I
will
tackle
this
in
the
next
couple
of
days.
Basically,.
A
Thank
you
ahmad.
So
this
is
the
the
adjusting
the
deployments
based
on
the
on
the
metrics
is
the
last
issue
that
we
have
on
the
so
and
then
we
can
declare
the
home
parking
migration
fully
fully
closed.
Yes,.
B
A
Perfect,
thank
you
very
much.
That's
also
a
great
achievement,
another
great
achievement
on
to
the
kubernetes
migration.
Thank
you
for
all
the
work
you've
done
on
that.
Thank
you.
I'm
going
to
verbalize
for
scarbeck
that
today
wasn't
able
to
attend
so
skarbek
started
to
prepare
some
issues
for
our
new
okrs,
just
to
be
for
everyone
to
be
up
to
speed
on
that.
A
Our
okrs
are
around
the
cluster
increasing
cluster
flexibility,
and
this
is
like
it's
going
to
be
my
our
main
objective.
This
main
objective
is
going
to
have
two
main
exit
criteria,
so
two
key
results.
The
first
one
is
going
to
be
the
one,
the
developed
capabilities
that
will
be
our
production
cluster
within
a
week,
and
we
already
have
an
epic
for
that
that
was
created
last
night.
A
In
addition
to
that,
whether
one
of
the
other
key
result
is
gonna,
be
the
one
to
develop
the
capability
to
utilize
clustering
spacing,
and
this
is
gonna,
be.
It
should
bring
us
a
step
closer
to
the
capability,
also
to
fulfill
certain
deployments,
and
this
is
also
the
topic
that
we
should
it
was.
It
was
in
today's
demo
because
we
want
to
understand
how
we
want
to
tackle
the
problem
and
scarbec
created
this.
This
issue
that
we
want
to.
We
want
to
review
now.
A
A
I
guess
there's
a
lot
of
information
now
to
discuss
in
an
issue
like
this
looks
like
anyone
has
any
idea
about,
maybe
how
we
can
start
to
tackle,
maybe
understanding
how
which
changes
we
need
to
do
to
the
repo
to
be
able
to
enable
success
deployments.
I
guess
this
is
also
trying
to
understand
how
we
can
separate
various
things
that
we
can
deploy
independently
and
structure
in
ci
to
not
be
a
bottleneck
or
managing
our
workloads
on
the
various
cluster
for
any
given
team.
C
So
I'll
start
with
a
pretty
naive
question,
because
obviously
I'm
not
familiar
with
every
cicd
pipeline
and
stuff,
but
given
our
current
structure,
have
we
discussed
kind
of
having
a
directory
structure
based
on
teams
or
some
sort
of
organizational
structure
that
binds
or
groups
several
teams
together?
Stuff
like
that.
C
D
C
A
service
usually
is
owned
by
a
team
right
and
basically
I
was
kind
of
thinking.
Maybe
we
can
group
services
by
teams
or
by
the
group
entity
that
these
teams
belong
to
right
stuff
like
that,
and
then
obviously
I'm
talking
with
the
sense
that
I
don't
really
know
how
our
pipelines
are
currently
formatted.
But
we
can
do
it
via,
like
groups
of
teams.
A
I
think
the
question
here
is
more
like:
if
we
use
this
approach,
can
we
still
deploy,
deploy
them
like
independently
one
of
the
others,
even
if,
even
if
they
belong
to
the
same
to
the
same
team
or
not,
because
maybe
there
are
some
components
that
they're
not
going
to
be
updated
for
whatever
reason
or
something
like
that,.
B
C
That
are
not
like
dependent
on
each
other,
but
kind
of
grouped
in
a
way,
and
with
with
our
back
that
allows
the
teams
to
control
the
pipelines,
it
would
be
under
their
ownership
and
also
ours.
If
we
want
to
intervene
with
that
process
right,
nothing
like
that.
A
Yeah,
that
would
be
probably,
I
think,
a
good
approach.
I
think
this
is
like
also
something
that
probably
would
align
on
a
very
long
term
vision
of
offering
this
platform
as
a
service
where
we
will
be.
You
know
we
can
offer
this
capability
underneath
and
they
can
just
define
a
manifest
of
what
a
service
is
and
how
we
want
to
be
released
and
so
on,
and
then
they
can
have
ownership
of
the
pipeline
that
we
actually
probably
can
create
for
them
that
they're
gonna,
and
they
only
can
anything,
contribute
to
those.
B
I
wanted
to
say
something
like
along
with
what
jenny
said.
I
think,
graham
also
like
suggested
something
like
that
on
the
long
term.
D
B
The
git
lapcom
into
like
separate
groups
like
or
owners
of
services
so
and
then
like
building
the
ci
cd
around
these
components,
to
basically
deploy
them.
I
think
the
hardest
part
would
be
like
the
auto
deploy,
I'm
not
sure
how
this
gonna
work
with
the
auto
deploy.
I
can
because,
like
I
think,
right
now,
we
have
everything
in
one
repo
and
we
build
everything
from
this
repo.
Like
forget,
lapcom,
the
charts
I
mean.
E
A
E
B
Because,
yes,
with
auto
deploy,
I
think
we
have.
We
are
deploying
to
kubernetes
in
one
part
of
the
auto,
deploy
right
and
with
this
we
have
everything
in
one
repo
for
kubernetes,
all
the
charts
are
combined
in
just
one
repo.
B
So
breaking
this
into
separate
triples,
I
think,
would
be
like
challenging
to
add
to
the
auto
deploy
like
because
it's
gonna
be
like
separate
repositories
and
separate
charts.
So
adding
this
to
one
in
one
go,
I
think,
is
gonna
be
like
a
challenge.
E
A
For
sure
nobody
know
what
it
is.
Okay,
I
think
also
if
we
go
into
the
direction
of
this
organizing
the
cluster
in
that
way.
Yes,
we
have
a
problem
of
deploying
into
this
cluster
and
trying
to
understand
if
we
can
deploy
like
servicing
components
like
independently
or
each
other
and
like
with
different
ownership
of
the
pipelines
and,
obviously,
at
the
end
of
the
namespaces.
A
I
think
also
if
we
want
to
start
to
go
a
step
forward,
we
need
to
understand
also
how
we
can
expose
metrics
belonging
to
these
known
to
these
namespaces
directly
to
the
product
and
service
teams
that
they
can
use
for,
like
taking
informed
decisions
like
deployment
and
rollbacks.
A
I
guess
this
is
a
bit
still
like
defining
when
we
are
going
to
find
a
structure
about
organize
our
cluster.
I
think
this
is
not
going
to
be
probably
an
exit
criteria
to
look
at
the
metrics,
but
we
also
need
to
understand,
at
least
if
the
current
organization
is
going
to
give
us
later
on
the
right
level
of
we
can
provide
with
the
organization.
A
We
are
proposing
the
right
level
of
visibility
and
we
I
mean
observability
into
those
namespaces
to
the
teams
that
they're
going
to
be
the
customers
of
those
namespaces
or
actually
the
owners
of
business
spaces.
Maybe
this
is
something
where
we
should
start.
We
could
start
thinking
in
the
next
in
the
next
weeks,.
B
Yeah,
it's
going
to
be
interesting
actually
to
see
how
every
separate
group
want
to
deploy
one
component
because,
like
this,
is
like
what
we
want
to
achieve
right,
like
self-service
deployment
at
some
point
so
away
from
the
auto
deploy,
of
course.
So
this
is
going
to
be
interesting
to
see
how
we
will
tackle
this,
so
they
can
deploy
one
component
at
a
time.
A
E
I
think
the
that
observability
product
that
we
acquired
has
a
lot
of
stuff
for
specifically
for
kubernetes
the.
A
A
I
I
guess
that
actually
on
the
ops
trace
world
is
actually
to
be,
is
actually
probably
one
of
their
use
cases
right
exactly
through
the
pipeline
from
gitlab
and
offering
like
metrics
through
that.
So
that's
that's
a
good
point.
Maybe
it
was
going
to
be
a
good
exercise
of
of
dog
fooding
when
we
get
there
we
need
to
understand.
We
still
need
to
provide
probably
structure
to
that,
but
I
think
it's
going
to
be
a
good,
a
good
starting
point.
Definitely.
A
How
these
would
change
in
asuna
scenario,
where
multiple
components
would
probably
try
to
concurrently
deploy,
even
if
in
different
namespaces.
I
think
this
is
probably
coming
down
to
the
restructuring
ci.
I
guess,
but
there
will
be
still
some
checks
to
be
implemented,
that
we
don't
have
maybe
two
components
deploying
at
the
same
time,
because
maybe
you
can
have
two
engineers
they're
getting
a
deployment
on
this
input
in
the
same
name,
space
or
yeah.
D
A
Don't
know
how
these
I
think
these
are
probably
a
first
word
problem
that
we'll
have
to
tackle
later
on
when
we
have
a
bit
more
clarity
on
that.
D
C
So
I
guess
another
brief
topic
that
I
wanted
to
bring
up
is
sorry
in
the
beginning
of
the
problems
or
in
the
middle
of
the
problem
statement.
It
says
that
a
lot
of
the
components
are
under
one
namespace
called
gitlab
and
the
other
one
is
under
another
namespace
called
dash
gitlab.cn
canary
right
yeah.
C
So
I
was
thinking
more
like
that
sounds
like
something
that
we
should
be
able
to
differentiate
via
labels
instead
and
have
we
ever
had
a
discussion
surrounding
namespaces
based
on,
say,
like
services,
slash
organization,
slash
teams,
stuff,
like
that.
C
Because
I
think
that's
also
another
step
forward
towards,
I
think
skarvik
and
I
are
on
the
same
page
here
where
you
know
we
give
these
teams
like
their
own
name,
spaces
ownership,
and
then
that
will
help
like
us.
Empower
them
to
yeah.
Take
take
that
ownership
of
their
services
and
their
name
space.
A
Yeah,
so
I'm
I'm
not
sure
if
there
was
this
discussion
like
previously
had,
I
think
so
they
start
the
hood
and
starts
where
we
are
now
with
the
cluster
is
the
results
of
what
was
created
at
the
beginning
with
immigration
and
what
was
actually
working
for
gitlab
at
the
time,
and
then
there
was
been
probably
an
increase
in
complexity
and
load
in
the
cluster,
because
more
and
more
services
migrated
into
that.
A
So
I
don't
think
that
they
will
probably
say
we
were
some
discussion,
but
so
far
I
don't
think
no
one
saw
the
direct
need
try
to
move
into
namespaces
I
mean
actually
at
the
end,
the
name
space
in
in
in
kubernetes
is
actually
a
kind
of
a
visual
cluster
right,
so
everyone
can
just
take
ownership
and
be
admin
of
that
particular
namespace
and
in
space
only
so
we
can
actually
work
in
the
direction
and.
D
A
Fully
agree
there,
but
I'm
not
sure
if
there
were
previous
thoughts
around
how
do
these
could
be
organized.
I
mean
I'm
also
here
since
three
months
and
a
half,
so
I'm
I'm.
D
A
Okay,
can
I
ask
you,
please
to
add
all
your
thoughts
that
we
spoke
about
that
today
in
the
in
the
in
the
discussion
issue
and
just
rise
them
up
there.
So
we
have
a
single
source
of
truth
where
we
can
go
discussion,
and
but
it's
already
like
a
good
start,
and
it's
good
that
you
we
start
to
discuss
about
these
things
and
see
how
we
can
shape
these
this
in
a
bit
in
a
better
way.
B
One
last
thing
I
think,
like
starbuck,
will
watch
this
so
and
graham
as
well.
One
thing
is
the
shared
secrets
and
the
secrets
in
general
how
we
going
to
tackle
them
with
name
spacing
because
you
know
like
there
are
like
namespaces,
are
isolated,
so
accessing
like
secrets
from
one
name
space
to
the
other,
is
gonna,
be
a
challenge.
D
B
D
B
So
this
is
one
thing
also.
We
need
to
think
about.
A
I
cannot
tell
you
where
it
is,
but
I
think
I
think
I've
seen
some
issues
that
is
actually
there
were
some
progress
there
and
it
was
also
kind
of
a
poc
working,
but
definitely
probably
it
would
be.
It
makes
sense
to
start
to
understand,
also
in
which
state
they
are
and
which
is
their
timeline
and
roadmap.
Because
I
mean
we
don't
probably
want
to
do
the
work
twice,
because
if
we
need
to
start
to
solve
the
secrets
problem
by
ourself
within
multiple
namespaces,
what
are
we
doing?
Are
we
duplicating
the
secrets?
A
How
we
do
keep
that
we
do
keep
them
and
seeing
so
a
lot
of
things
to
solve
is
also
also
by
this
way
by
itself
is
a
is
a
huge
project.
So
I
think
it's
something.
That
is
a
definitely
a
great
entry
requirement
that
we
should
double
check
on
these.
D
A
C
Yeah,
probably
so,
probably
down
the
road,
we'll
probably
talk
about
the
secret
management
as
well
as
yeah.
If
we
do
go
to
this
namespace
way,
then
I'm
thinking
of
like.
C
Yeah,
we
probably
need
to
think
about
like
where,
like
some
share
secrets,
are
going
to
be
right
and
stuff
like
that,
and
also
arvik
can
get
very
complicated.
E
A
A
So
I
I
really
encourage
you
to
write
everything
down.
I
to
the
notes
is
in
our
document
shared
document.
So
if
you
need
some
input
to
add
your
thoughts
again
into
the
issue,
but
please
add
all
your
thoughts
that
we
discussed
today
into
the
issue
appearing
they
are
definitely.
There
are
already
extra
discussion
points
that
we
can
bring
up
and
we
can
just
keep
the
discussion
there,
but
already
these
could
help
us
also
to
define
some
some
areas
and
define
a
bit
better
with
the
scope
that
we
want
to
bring
this
right.