►
From YouTube: 2022-08-23 Delivery:Orchestration team demo - 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).
A
Listen
so
welcome
everyone,
so
I've
dropped
this
in.
I
will
try
and
set
these
up
as
sort
of
regular
calls
based
on
team
size.
We
can,
I
think,
for
now
we
can
handle
emia
americas,
which
would
be
around
this
sort
of
time-ish,
and
we
could
have
one
earlier
in
the
day
for
an
apac
emea
overlap,
as
the
team
grows
mira
you
and
graham
can
think
about
whether
it
makes
sense
to
additionally
bringing
an
america's
apac.
A
If
you
want
to
kind
of
cover
the
third
area
and
we
can
stagger
those
out
over
the
month,
so
hopefully
that
will
also
remove
just
admin
overhead
we
can
get
them
set
up.
We
can
just
get
the
schedule
rolling
and
then
we
don't
have
to
keep
being
planning
these
things.
Then.
So
I
repurposed
the
agenda
that
we
had
for
the
previous.
A
There
have
been
a
couple
of
sort
of
ad
hoc
calls
that
have
taken
place
already
around
self-serve
and
kind
of
very
much
the
things
that
now
as
orchestration
we're
thinking
of
so
I've
just
repurposed
this
agenda,
so
that
we
can
keep
everything
in
the
same
place.
A
But
my
intention
is
that
we
have
this.
As
a
sort
of
rolling
meeting
so
that
it's
not
dependent
on
one
particular
person,
anyone
can
be
the
host
run.
The
meeting
get
the
recording
and
just
upload
it
in
the
right
place
and
everyone
else
can
just
help
with
note-taking
and
like
taking
actions
and
things
like
that.
So
very
much
collaborative
space
for
us
to
to
use
as
as
is
useful,.
A
I
actually
don't
know,
but
it's
it's
a
good
question
like
if
someone
wants
to.
I
actually
have
no
idea
if
that's
a
possibility,
but
if
someone
wants
to
review
that
look
at
these
numbers
that
could
be
yeah.
That
could
be
a
great
great
question.
A
So
my
suggestion,
if
there,
if,
unless
there
are
any
better
ones,
is
just
to
briefly
discuss
around
epic
773,
so
our
analysis
issues
not
so
much
as
an
update,
but
just
as
a
what
would
be
useful,
other
particular
bits
of
information.
We
should
discuss
right
now
or
do
we
know
what
the
next
steps
are
to
get
the
issues
through
to
completion.
C
Yeah,
I
do
have
a
question
about
that.
Epic.
I
have
been
working
on
getting
all
the
details
for
italy
and
I
have
put
a
lot
of
comments
in
my
issue
and
I
still
there
are
some
open
questions
more
related
to
finding
granular
details,
but
I'm
still
not
sure
about
what
will
be
the
outcome.
I
have
seen
that
matt
has
been
preparing
some
diagrams,
but
that
should
be
the
outcome
for
every
issue.
Should
we
prepare
like
a
picture
of
all
the
processors?
Should
we
document
that
somewhere?
C
A
D
A
D
There's
a
couple
of
things-
I
guess
so.
The
the
first
thing
is
definitely
on
the
documentation
side
of
things
having
as
comprehensive
an
idea
of
all
the
individual
steps
that
these
different
component
teams
have
to
go
through
for
deployments
for
releases
for
doing
security
and
patches
as
well.
D
So
we
sort
of
end
up
with
you
know
a
lot
of
this
written
down
and
ideally
sort
of
created
in
both
sort
of
a
written
and
a
visual
medium
as
well.
So
it
makes
it
easy
for
us
to
easy
for
us
to
reference
and
sort
of
help
a
little
bit
with
people
on
boarding
into
delivery
in
the
future
as
well,
so
that
we
can
we've
got
a
good,
a
good
point
of
reference
to
make
it
a
little.
I
guess
accessible
for
people
with
that
absorb
business
information,
a
couple
of
different
formats.
D
So
that's
definitely
one
nice
part
of
this
verb
for
an
outcome.
The
second
part
of
it
is
really
analyzing
what
the
differences
are
between
all
these
different
components.
Processes
because,
like
italy,
have
their
their
whole
thing
sort
of
to
for
themselves
really
which,
which
is
very,
very
different
to
all
the
components.
Kaz
is
very
different
and
the
page
is
very
different,
like
kaz
in
its
own
right
is,
relatively
speaking,
quite
straightforward.
There's
probably
some
crossover
with
what
happens
with
pages.
You
know
the
audience
version,
files,
etc,
etc.
D
So
what
I'm
really
interested
in
discovering
by
the
way,
if
my
ac
is
too
loud,
just
just
shout
out
and
I'll
turn
off,
I
don't
think
my
headphones
are
filtering
out,
so
yeah,
so
ideally
trying
to
figure
out
what
the
differences
are
between
each
of
those
components,
with
the
idea
being
that,
if
we
account
for
those
we
sort
of
have
a
better
foundation
that
we
can
use
to
build
on
the
idea
of
exactly
what
self-serve
looks
like
because
elsa
might
not
look
identical
for
every
single
team
out
there.
D
But
I
want
to
say
like
this
is
where
we
want
to
get
to
with
self-serve,
but
that
might
not
be
completely
appropriate
or
applicable
to
all
component
teams.
If
say,
they
don't
match
up
with
what
our
definition
of
what
a
component
should
do
in
order
to
even
sort
of
hook
into
these.
These
procedures
in
the
first
place,
see
if
that
makes
sense,
so
those
are
kind
of
the
two,
the
two
outcomes
that
at
least
I'm
looking
at
for
for
this
epic.
C
Thanks,
I
really
think
we
should
document
that
because,
as
we
have
seen,
the
knowledge
seems
to
be
spread
in
everyone's
head
without
like
a
central
piece
in
which
everything
is
documented.
I
do
worry
that
documentation
might
be
very
exhaustive,
for
example,
for
italy
I
have
found
out
that
the
process
is
very
long.
It's
very
complicated
and
all-
and
just
in
my
comment,
my
comment
is
very
very
large
and
I
do
have
respect
for
graeme's
for
reading
it
all
because
it
was
a
lot.
C
So
if
we
were
on
boarding
people-
and
we
were
saying
like
hey,
this
is
a
italy
process-
just
have
a
read
at
it,
I'm
not
sure
if
that
is
going
to
be
like
well
a
good
idea,
because
it
is
way
too
much
to
observe
in
just
one
set.
So
perhaps
we
can
think
of
something
else
or
some
another
strategy
to
try
to
grasp
the
idea
or
something
more
friendly.
B
We
also
have
to
consider
that
this
is
just
recommended,
as
is
doesn't
mean,
I
mean
one
of
the
things
that
matt
said
is
that
this
guy,
but
this
is
about
comparing
finding
the
gaps
between
the
processes,
because
what
I
can
see,
look
in
those
processes,
the
one
that
I
remember,
that
one
that
I
don't
remember
and
that
I
don't
know
how
they
worked
is
that
they
are
showing
the
the
age
of
the
component.
B
Then
we
try
to
implement
much
more
automation
for
them,
which,
in
the
happy
path,
is
perfect
because
it
just
gives
them
kind
of
master
deployment.
But,
on
the
other
hand,
it's
really
hard
to
understand
what
is
happening,
why
things
are
breaking,
and
even
myself
reviewing
the
comments
from
graham's.
I
figured
out
that
we
are
creating
stable
branches
on
rc42.
B
While
I
was
sure
that
this
is
not
the
case,
and
indeed
there
are
comments
in
the
code
base
saying
that
this
is
not
happening
indeed
is
happening,
so
this
is
not
a.
This
is
not
great,
and
company
is
growing.
Many
new
teams
are
being
added
to
the
product
with
new
ideas
for
building
new
components,
and
we
need
to
find
somewhere
to
point
them
say
this
is
how
it
should
look
like
if
you
want
to
get
all
the
best
and
goodies
that
we
can
provide
you
and
so.
A
We
should
document
it,
but
let's
also
be
aware
we
are
about
to
change
the
whole
thing,
so
I
mean.
Maybe
not
everyone
get
any
less,
though,
because
I
think
they
will
follow
later
right.
I
think
they're
a
really
useful
kind
of
review
component,
but
I
can't
see
an
easy
way
to
change
the
gitly
deploy,
certainly
not
early,
so
I
mean
I
I
personally
am
fine.
A
If
the
issues
for
now
are
our
documentation
and
we
get
those
so
that
the
description
reads
really
well
and
is
easy
for
us
as
orchestration
to
reference
and
then
we
perhaps,
as
things
settle
down
a
bit
more
like
say,
for
example,
when
we
change
kaz's
deployment
process
as
part
of
that
work
to
do
the
change,
we
also
give
them
the
documentation.
They
need
to
understand
that
piece,
so
we
kind
of
build
it
out
for
them
or
something
like
that
might
give
us
some
some
way.
A
I
guess
of
concluding
these
issues
without
having
to
do
a
stack
of
documentation,
work.
A
C
Yeah
there
are
some
upper
questions
for
grains
when
I
kind
of
scan
his
latest
comments
and
he's
asking
about
very
specific
stuff
like
where
is
this
comment
generated
like
what
repository
is
the
one
that
is
generating
this,
and
I,
I
think
I
have
the
answers
from
now.
C
I
also
interviewed
two
guitarity
members
and
it
was
useful
to
understand,
like
their
point
of
view,
okay
and
yeah.
B
Yeah
also,
we
need
to
to
think
that
easily
is
not
the.
I
mean
it's
the
perfect
example
of
how
we
should
not
do
this,
because
they
got
forced
into
the
new
process
so
going
forward.
We
should
find
sponsorship
for
team
that
are
willing
to
get
into
something
that
is
better
for
both
of
them
instead
of
just
saying,
this
is
how
we're
going
to
do,
because
it
was
terrible
for
us
to
manage,
so
we
decided
to
implement
some
automation
for
them,
but
was
kind
of
a
one-sided
decision.
D
So
that's
that's
right
in
music
that
we're
not.
We
don't
we're
not
specifically
working
with
the
team
until
q4,
correct.
A
Yes,
so
both
the
cas,
the
team
for
cows
so
configure,
and
the
team
for
registry
package
have
both
requested
that
we
collaborate
with
them
in
q4
that
fits
with
their
kind
of
team
scaling
plans
and
their
other
projects.
So
we
can
certainly
do
stuff,
but
in
terms
of
actually
like
us
expecting
like
as
having
any
chance
of
moving
them
as
close
to
self-serve,
as
we
can
like.
Yes,
they're
not
available
to
work
with
us.
D
Yeah,
so
I
wonder
if,
even
though,
like
myra
the
stuff
that
you've
got
on
gitly
is
just
really
really
good
and
it's
fantastic
to
have
all
that
written
down.
We
need
to
know
all
that
sort
of
stuff
as
well.
I
think
that's.
The
thing
is,
even
though
this
this
documentation
is
sort
of
really
catching
how
things
exist
at
a
point
in
time
and
you're
right
like
it
is,
it
is
so
much
and
particularly
being
so
relatively
new
to
give
up
I
get
about
halfway
through
my
eyes,
glaze
over
as
I
get
completely.
D
I
just
can't
get
completely
lost
in
the
complexity
of
everything
that
is
going
on
there,
and
I
agree
completely
that
there
is
so
much
there
that
if
somebody
was
on
boarding
into
delivery,
just
went
hey
quickly.
There
read
that
stuff,
it's
impossible
to
absorb
it
all
in
one
go.
Maybe.
D
My
my
proposition
would
be
we
say,
we're
okay,
with
the
amount
of
information
that
we've
collected
around
gitly.
For
now
we
already
have
cars,
and
we
have
pages
graham's
doing
a
much
much
much
deeper
dive
into
everything
that
happens
specifically
with
pages
when
it
comes
to
releases,
particularly
around
the
monthly
releases,
including
things
that
the
chat
up
commands
are
running
and
all
the
rest
are
going
like
very,
very
blow-by-blow.
A
No,
you
might
be
right,
yeah,
yeah,
no
you're,
certainly
right
matt,
just
as
a
I
guess,
a
com-
I
guess
a
like
one
thing
I
personally
find
really
interesting
about
italy
is-
is
the
it's
almost
the
gitly
experience
like
their
team's
experience,
and
I
think
some
of
it
comes
from
what
alessio
is
saying
about
them.
Having
been
forced
in
the
other
thing
is
a
little
bit
to
do
with
actually
the
specifics
of
how
things
are
set
up
or
where
certain
alerts
go.
A
So
I
think
they're
a
really
interesting
use
case,
just
as
we
start
looking
at
cars
and
registry
and
pages,
what
are
the
things
that
we
can
take
or
other
things?
Maybe
we
can
take
from
italy
where
we're
like
okay,
so
we
need
to
watch
for
this,
like,
I
think,
we're
already
hearing
a
load
like
onboarding
documentation
is
really
tough,
so
that
feels
like
a
really
good
problem.
We
should
solve
right
before
we
go
and
on
board,
I
don't
know
heap
of
developers
into
deployments.
What
does
this?
A
What
does
documentation
need
to
look
like
in
order
to
onboard
is
one
for
example
problem,
but
maybe
there
are
other
things
that
we
can
see,
so
I
think,
probably
just
to
give
a
little
bit
of
q3.
Okay,
our
focus
like,
I
think
what
we
need
to
do
in
q3,
around
cads
and
pages
in
particular,
I
could
feel
free
to
auckla
I'm
wrong.
My
impression
from
earlier
conversations
is
they're
quite
well
understood
and
it's
quite
straightforward-
to
actually
bring
them
into
our
existing
auto
deploy
and
our
existing
release
processes.
A
But
what
we
perhaps
don't
have
a
really
good
plan
for
is
what
happened
next
and
based
on
what
we
know
about
getting
other
kind
of
common
pieces
of
work.
We
should
focus
on,
or
are
there
things
we
can
actually
do
to
set
those
components
up
because,
like
you're
saying
matt,
you're
exactly
right,
the
cows
registry
pages
should
all
end
up
being
very,
very
similar
it'll
be
interesting
if
they're
not,
but
they
should
be
theoretically.
At
least
they
should
be
quite
similar.
B
There
is,
though,
an
extra
there
are
two
extra
complex
items
from
gitly
that
will
be
helpful
in
the
in
the
conversation
for
cast,
and
the
other
one
is
one
is
just
common
to
everyone.
That
is
the
one
of
the
pain
point
that
we
realize
from
this
implementation
with
gizly
for
the
development
team
is
that
it's
really
hard
for
them
to
track
down
when
the
automated
component
bump
is
not
working
so
thinking
through
this
when
we
do
the
other
component,
this
is
something
we
should
be
aware
of,
and
and
so
this
information
came
from
italy.
B
The
other
information
specific
to
italy,
which
is
important
to
cast
as
well,
is
that
there
is
a
dependency,
so
both
getaly
and
cass
are
exposing
a
rubygem
as
part
of
their
development
process
that
gives
ruby
on
rails
application
access
to
the
the
grpc
endpoints.
So
the
definition
of
the
services
and
all
the
proxy
objects
to
do
remote
codes
now
gitly
changed
this
very
often
as
this
as
by
design
is
an
rpc
implementation
over
git,
so
they
are
actively
working
on
that
cass.
As
far
as
I
know,
talking
with
the
one
of
the
main
developer
changed.
B
Only
once
in
the
course
of
the
last
year,
so
they
did
a
good
work
up
front,
but
they
just
had
to
review
one
of
their
apis,
so
they
changed
it
only
once
that
being
said,
this
is
a
extra
complexity,
but
it's
extremely
important,
because
when
we
do
release
management
for
them,
there
is
a
point
in
time
where
they
may
willing
to
bump
the
the
interface
without
actually
releasing
the
the
the
component
itself
for
the
broader
audience
and
what
we
have
done
for
gitly
is
this
developers
can
autonomously
declare
rcs
so
they
can.
B
They
can
tag
rcs
through
automation
that
we
provide
and
when
we
do
version
bump
for
the
we,
when
we
release
for
them,
we
are
actually
also
taking
care
of
changing
some
files.
That
is
defining
this.
The
version
of
this
interface
so
that,
if
they
want
they
can
publish
the
the
the
gem
that
is
defining
the
grpc
interface
either
by
doing
another,
see
themselves
and
publishing
it
to
ruby,
gems
or
afterwards
publishing
something
that
we
tagged
has
say,
14
something.
A
That's
interesting,
I
think
those
are
almost
the
pieces
which
I
think
will
be
really
I
don't.
I
don't
have
an
idea
of
how
we
pull
these
out
like.
I
think
it
could
be.
Super
simple,
like
I
wonder,
if
maybe
there's
another
issue
on
this
epic
or
just
something
where
we
start
to
pull
out
almost
the
common
things,
because
it
sounds
like
for
something
like
that
we
almost
have
a.
There
is
a
like
gem
publishing
thing
right.
A
Be
a
prisoner,
the
document
or
whatever,
and
then
we
start
to
build
up,
so
we
have
like
okay.
Kaz
is
a
component
that
is
of
this
type.
They
also
need
the
gem
publishing
thing
and
they
add
it
on
registry.
Isn't
that
registry?
Is
this
other
thing
and
we
can
start
almost
I'm
in
my
head.
I've
super
simplified
that
down
to
just
like
we
have
kind
of
components
that
we
modularly
build
up
to
say:
okay,
this
component
has
this
thing.
I
think
italy
has
some
that
we
could
reuse.
A
It
has
some
pieces
that
we
wouldn't
reuse
around
it's
about
its
vms.
You
know
it's
got
some
complexity.
It's
got
a
lot
of
dependencies
on
its
ordering
of
deployments
and
things,
but
I
wonder
if
there's
a
way
where
we
actually
can
start
to
say
here
are
the
common
pieces
we
can
see
and
here
as
the
components
these
are
the
common
components
they
they
are
making
use
of.
A
A
I
expect
that
the
configure
team
will
be
ready
earlier
than
registry
the
package,
so
cows
will
probably
be
a
component
that's
available
for
us
to
collaborate
on
sooner.
I
think
it's
also
simpler,
so
it's
kind
of
got
two
benefits
to
it
being
the
component.
We
really
address
first,
so
I
think
if
we
don't
get
time
to
do
full
analysis
with
registry
now,
that
might
also
be
fine.
B
There
is
another
thing
that
came
to
my
mind
now
that
we
are
discussing,
so
we
are.
B
We
are
looking
at
this
from
the
point
of
view
of
deploy
and
releases,
but
there
is
an
important
bit
that
goes
into
quality
engineering
productivity.
I
don't
know
who
owns
those
things,
which
is
the
test
and
pipeline
at
the
at
the
project
level.
So,
and
this
goes
back
with
the
team
of
how
do
we
do
version
bumping
and
version
alignment,
because
I
don't
know
if
we
are
collecting
this
in
the
issues
that
we
are
working
on
right
now,
but
basically
some
of
the
components
are
being
built
from
sources
within
git
lab
pipelines.
B
B
I
don't
know
if
we
are
built,
I
think
we're
building
elasticsearch
indexer,
which
is
another
component
that
we
ship,
but
it's
just
a
binary
that
gets
into
the
image,
but
it
lives
into
another
repo
and
it
has
the
same
problem
about
tagging.
Releasing,
and
things
like
that.
So
my
point
is
that
on
one
side
with
looking
at
what
happens
at
the
end
of
the
process,
we
target
we
deploy,
we
release
and
we
deploy.
B
But
some
of
those
things
have
problems
tied
back
before
then,
which
is
we
need
to
bump
ahead
of
time,
because
we
need
to
run
the
integration
test
within
the
product,
and
this
is
central
to
the
problem
of
self-serve
deployment
as
well,
because
if
we
are
moving
the
so
this
is
about
build
reproducibility
on
one
side,
because
you
have
a
given
commit
on
on
gitlab
repo
today
tells
you
the
everything
is
in
there.
A
Would
it
make
sense
to
try
and
put
together
a
I'm,
almost
thinking?
This
is
starting
to
look
a
bit
like
a
matrix
right,
where
we
almost
have
common,
say
I'm
going
to
use
my
highly
technical
term
of
pieces
and
we
try
and
get
a
list
of
what
those
might
look
like
now.
It
might
be.
A
What
would
be
those
almost
component
like
building
blocks
that
we're
using
and
how
many
of
those
three
components
are
sharing
those
processes
and
how
many
are
using
a
different
one,
and
I
wonder
if
we
could
almost
then
start
to
build
out
a
table
where
we
have
ticks
and
things
just
on
a
separate
issue
to
start
to
really,
because
I
think
what
would
be
so
useful
is
to
be
able
to
overlay
these
three
issues
that
we've
got
almost
and
be
like.
A
Okay,
they're,
like
here's,
the
diff
of
these
three
issues
right,
like
they're
all
the
same,
except
for
these
pieces
or
or
some
way
of
actually
showing
where
they
they
start
to
vary
from
each
other
and
what
it
might
even
show
up
is
some
fairly
small
things,
because
I
know
one
thing
graham
has
mentioned
a
few
times
is
things
like
version
number
format,
so
it
could
just
be
that
it
simply
starts
to
expose
those
things
where
we,
we
don't
have
a
great
lot
of
formatting
and
standardization
over
pieces
of
these
processes,
even
if
they're
largely
very
similar.
B
This
again
open
up
another
problem
which
is
not
entirely
owned
by
us,
which
is
that
we
align
with
version
files
from
distribution.
A
A
That's
it
yeah
yeah
and
that's
absolutely
fine,
like
I
think
what
I've
kind
of
I
think
we
need
to
kind
of
keep
clear
on
these
analysis
issues
is
we're
not
necessarily
saying
we'll
fix
everything
and
change
everything.
Oh
very
much
like
what
is?
How
does
it
look
like?
What
is
the
landscape
we're
working
with
and
from
there?
Hopefully,
we
can
start
to
pick
off
what
we
actually
want
to
go
and
tackle.
A
So,
just
in
the
last
couple
of
minutes
right,
so
I
know
that
there's
a
heap
of
stuff
I've
tried
to
put
some
notes
on
the
agenda,
so
you
can
reference
I'll,
get
the
recording
up
as
well
on
the
playlist
in
case
you
want
to
re-watch,
but
just
as
a
a
kind
of
summary,
does
it
sound
like
a
reasonable
thing
that
we
will
try
and
it
sounds
like
italy.
A
We've
got
almost
concluded
and
perhaps
we
just
check
in
on
some
wrapping
up
some
pieces
there
and
then
try
and
get
to
the
point
where
perhaps
we
use
that
as
a
basis
for
kind
of
creating
a
another
issue
which,
on
the
same
epic,
which
has
a
kind
of
here,
are
the
elements
of
deployment
and
releasing
we're
seeing
from
italy.
And
can
we
actually
map
onto
that
cards
and
pages?
And
if
we're
not,
do
we
have
some
extra
analysis
that
we
need
to
do
for
those
two.
B
I
just
want
to
leave
a
comment
that
I
found
an
old
epic
that
we
were
working
long
time
ago,
which
was
about
our
deploy
for
components.
There
is
a
table
there.
There
are
some
information,
so
I
don't
know
how
much
of
this
is
still
up
to
date.
But
probably
it's
just
reviewing
the
prior
work
and
this
will
help.
A
Awesome
yeah.
That
would
be
great
yeah.
I
think
if
we
have
something
like
this,
perhaps
it'll
be
a
little
bit
more
extended
with
the
extra
stuff
we've
got,
but
I
almost
think
like
we
could
almost
link
off
right.
I
wonder
if
we
could
almost
have
something
like
you
know
where
we've
got
like
testing
get
up,
it's
just
a
concept,
and
you
know
publishing
gems
as
a
concept,
and
we
could
just
start
building
that
up.
Maybe.
A
A
Okay,
not
overwhelming
thing
I'll
I'll
see
if
I
can
put
together
a
little
bit
of
a
structure.
It'll
be
super
high
level,
because
I
I'll
try
and
do
it
before
I
head
out
tomorrow,
but
I'll
just
put
in
a
high
level,
maybe
pull
in
some
of
the
bits
that
I've
been
thinking
about.
We
can
see,
then,
if
it
looks
like
it's
going
to
be
useful
enough
to
to
want
to
expand
out
to
cover
the
other
components
and
in
the
meantime
matt.
A
Would
you
mind
taking
an
action
and
just
having
a
figure
out
and
maybe
just
working
with
myra.
I
assume
it's
not
here
to
just
see
if
we
can
figure
out
like
what
does
the
end
of
the
gitly
issue.
Look
like,
because
I
think
if
we
can
figure
that
one
out
that
was
the
furthest,
the
head,
that
maybe
gives
us
the
end
of
cards,
and
it
gives
us
the
end
of
pages
as
well,
so
that
they
match
up.