►
From YouTube: 20191115 Mailroom on k8s demo
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
B
C
C
A
A
A
A
A
Basically,
in
the
case
ETL,
we
added
a
function
that
generates
a
new
home
value
files
that
get
appended
has
the
last
one.
So
those
values
as
president's
is
over
everything
else
and
that's
it.
So
this
is
what
we
are
doing.
On
top
of
that,
we
decided
to
publish
as
an
artefact
this
file
so
that
we
can
inspect
that
the
result
of
the
beta.
Let's
take
a
look
at
this
on
ops,
so.
A
Variables,
okay:
this
is
recorded,
but
so
I'm
not
going
to.
If
you
want
okay,
so
now
I'm
going
to
start
a
pipeline.
That
should
just
tell
us
that
nothing
changes,
because
these
are
the
variables
that
are
already
deployed.
The
persons
are
already
applied.
So
we
can
run
a
pipeline
on
my
branch,
which
is
this
one.
A
A
A
D
A
It's
we
really
lose
control.
Over
sleeping
those
I
mean
we
brought
a
piece
of
software.
Even
it's
just
a
simple
shell
script
that
handle
from
from
variables
to
to
to
values.
We
can
write
a
simple
script
that
commits
this
so
at
the
point
is:
what
are
we
trying
to
do
here?
Because
are
we
thinking
that
we
want
to
run
this
on
a
schedule
and
then
independently?
A
We
change
the
values
and
is
upgrade
the
same
as
a
chess
server
is
running,
and
then
you
have
Jeff
clients
that
just
picking
up
changes
and
upgrading
the
fleet,
because
I
got
this
impression,
so
we
yeah
we
were
discussing
this
yesterday.
We
kind
of
have
this
feeling
that
we
are,
let's
say,
losing
control
over
the
process
or
maybe
just
because,
for
instance,
we
are
not
sure
we
can
trigger
a
pipeline
with
variable
just
for
a
single
environment,
because
otherwise
could
have
been
nice
to
see
as
soon
as
we
build
the
package
CNG.
A
Sorry,
no
change
in
in
the
charts
trigger
a
pipeline
that
upgrades
the
variable
didn't
I
mean
that
runs
the
deployment
with
the
they
operated
version.
What
we
are
I
mean
what
I
understood
from
this
is
that,
indeed
we
are
thinking
about
this
muscle
process
that
runs
continuously
and
make
sure
it's
kind
of
building
kubernetes
on
top
of
kubernetes.
First,
you
have
communities
that
has
a
state
and
apply
communities
itself,
it's
just
an
Orchestrator.
A
It
has
a
state
of
the
deployment
and
if
it
something
changes,
you
just
skim
the
things
and
replace
them,
and
this
is
the
same
thing,
because
we
have
our
CI
script
job
that
runs
every
5
minutes
every
hour,
whatever
as
a
known
state
of
the
system,
and
if
this
n
apply
is
the
state
to
the
to
the
Glasser.
In
that
case,
so
I.
C
About
specific
yeah
I
had
some
specific
complaints.
One
is
that
it's.
The
primary
concern
for
me
is
that
we
lose
a
bit
on
the
promotion
aspects
of
the
pipeline
if
we
have
different
variables.
In
other
words,
it's
really
nice
to
be
able
to
bump
the
version
and
then
sort
of
see
the
pipeline
go
from
staging
some
cases
canary
and
then
production.
C
If
we
are
setting
versions
and
variables,
we
kind
of
lose
that
promotion.
A
now
of
course,
like
I
mean,
ideally,
we
would
be
CI
CD
right
and
we
would
be
setting
the
version
in
the
repository
and
then
that
version
would
be
promoted
through
the
stages.
Now,
if
we
set
it
in
a
variable,
you
would
have
maybe
this
same
variable
for
all
environments,
and
you
would
just
set
that
and
I
don't
know
it's
just
like.
C
You
still
have
that
promotion
right,
because
when
you
set
the
variable,
then
the
pipeline
would
run
and
it
would
run
one
stage
at
a
time
and
you'd
be
able
to
see
it.
But
it's
just
like
a
lot
nicer
if
it's
committed
to
the
repository
and
I
and
I'm
not
really
seeing
the
benefits
of
having
to
set
that
I
see
I
variable,
except
for
the
ability
to
trigger
the
pipeline
and
with
the
variable
set
I
think
that's
originally.
C
What,
where
this
came
from
right
is
that
we
want
to
trigger
this
pipeline
as
early
as
possible
as
soon
as
the
CNG
image
is
available,
and
it
seems
a
bit
nicer
to
do
it.
This
way,
then
to
actually
use
the
API
to
like
commit
the
file
to
the
repository
and
then
trigger
it
right.
It
was
just
like
you
just
trigger
him.
You
set
the
variable
name
and
the
trigger
I
I.
Don't
know,
though,
like
it
feels
it
still
doesn't
really
feel
right
to
me.
D
Okay,
a
couple
of
items
there
I
understand
the
variable
is
not
super
transparent.
This
is
why
we
can
also
discuss
how
can
we
get
whatever
was
added
to
the
variable
committed
wherever
so,
if
you
want
to
skip
that
step
of
adding
it
to
a
variable
and
just
committed
it
directly,
that
is
absolutely
fine.
If
you
I'm
speaking
I'm
saying
universally
you
not
any
one
individual
by
the
way,
if
you
consider
that
you
have
any
sort
of
confidence
by
looking
by
you
yourself
committing
a
thing
and
then
looking
at
the
pipeline
and
seeing
it
roll
out.
D
If,
if
that's
what
I'm
understanding
from
this
discussion,
then
I
don't
agree
with
that,
because
we
want
to
build
a
system
that
will
alert
us
and
not
the
system
that
we
will
have
to
monitor
ourselves
and
look
at
the
pipeline
every
single
minute,
so
I'm!
Fine,
if
variable,
is
not
the
shortest
solution.
D
Don't
want
a
single
Essery
or
a
back-end
engineer
to
go
in
here
and
be
able
to
commit
themselves
unless
we
have
urgent,
like
we
have
edge
cases
right
like
I'm,
not
going
to
discuss
those
but
one
a
fully
automated
system
that
will
be
triggered
from
the
all
the
way
up
stream
right.
It's
like
someone
committed
or
merged
something
into
master
in
get
lab.
D
That
should
build
an
image
that
should
be
a
CNG
image,
so
production
ready,
docker
image
that
once
that
is
done,
that
should
trigger
a
commit
or
a
variable
or
whatever
we
built
in
here.
That
will
then
roll
it
through
the
staging
roll
it
to
other
non
production
environments
and
then,
finally,
we
should
have
a
gate
where
this
does
not
go
to
production
without
us,
knowing
about
it,
whether
that
is
true
logging
somewhere
in
the
audit
log
that
hey
this
is
going
to
happen.
D
A
I
do
agree
that
you
I
mean
I,
don't
want
to
babysit
in
the
system
forever.
We
are
still
kind
of
used
to
it,
because
we
don't
trust
the
system
that
we
have
right
now,
but
we
can
see
the
difference
with
little
a
team
right
now.
It's
it's
lumpen
I
mean
it's,
it's
a
new
word
for
them
and
we
had
no
major,
oh
okay,
new
and
no
major
problems
so
far.
Knocking
on
wood,
but
so
I,
add
I,
do
agree
on
this,
but
inspect
ability
is
something
important.
C
You
know
in
the
case,
workloads
project
now
I
understand
the
downsides
of
this
I
know
that
charts
takes
a
long
time
to
build
and
it's
not
cheap.
But
in
the
world
where,
let's
say
a
charts
version
bump
was
cheap
and
like
it
happened
within
like
a
minute
or
something
like
that,
then
you
can
envision
a
situation
where
you
have
a
new
image
of
registry
and
C
and
G
that
automatically
triggers
a
version
bump
in
charts
and
then
that
triggers
Cades
workloads
Gillick
on
with
the
charts
version
bump
right.
D
D
D
D
They
are
fine,
so
if
that
becomes
our
trigger
point
for
actually
this
level
of
calm
deployment,
sure
absolutely
we
don't
have
to
bridge
it
as
long
as
we
don't
have
to
do
anything
manual
ourselves
and
we
can
find
a
way
to
build,
alerting
for
ourselves
on
comm
and
like
in
our
pipelines,
built
any
sort
of
gates
that
we
need
to
ensure
that
production
doesn't
just
get
things
without
our
control,
or
at
least
our
knowledge
doesn't
have
to
be
controlled.
So.
C
Enough
for
that,
the
problem
is
it
significantly
slows
us
down
until
we
break
charts
out
break
the
sub
charts
out
of
the
Omni
chart
repository
right,
because
you
know
a
simple
version
bump
of
registry
is
going
to
require
tests
of
all
of
the
charts
to
do
all
of
the
you
know,
integration
tests
that
they
have
in
that
project
before
we
can
deploy.
If
registry
was
broken
out
into
its
own
chart,
then.
B
C
So
I
guess,
there's
like
three
scenarios.
One
is
is
that
we
just
take
the
version
bump
with
the
version
of
the
home
truck
we
have
and
we
hope
it
works.
The
other
scenario
is
that
registry
chart
is
split
out
so
that
at
least
you
have
compatibility
between
the
registry
version
and
the
chart
specific
to
registry
right,
like
the
configuration
of
registry
in
the
chart,
at
least
that
will
be
compatible
and
then
the
third
option
is
like
to
make
sure
everything
is
compatible,
which
is
the
Omni
chart
approach.
I,
guess,
that's
the
that's!
C
The
safest
way
is
just
to
like
let
em
each
RB
or
omnibus
chart
or
the
charts
repo
be
the
source
of
truth
for
all
the
app
versions,
and
we
just
wait
until
that
full
test
is
completed
and
then
we
deploy
I
mean
that's
sort
of
what
we
do
now
for
omnibus
my
biggest
concern
about
doing
the
registry.
You
know
image
bump
without
with
like
an
old
version
of
charts.
Is
that
there's
something
specific
in
the
registry
sub
chart
that
hasn't
been
tested
yet
against
the
red
night
registry
version
right.
D
D
Lose
another
thing
yeah.
So,
let's,
let's
agree
on
one
set
of
terminology
here,
because
we
are
mixing.
We
have
a
potential
of
mixing
things
up.
We
have
a
current
chart.
Let's
call
that
the
Omni
chart
right.
It
has
everything
we
have
individual
charts,
we'll
call
them
individual
charts
and
they
are
part
of
the
ami
chart
right
and
then
we
have
the
canonical
repositories
of
various
github
components.
What's
called
an
canonical
repository,
so
get
labs
Italy,
whatever
else
right,
so
the
option
of
Omni
chart
being
our
source
of
truth.
D
We
can
do
certain
things
in
that
chart
and
make
it
in
the
Omni
chart
and
make
it
better
than
what
omnibus
is
right.
Now
we
can
test
things
individually
there
as
well,
by
saying,
for
example,
every
time
there
is
a
bump
in
registry
we
trigger
a
pipeline
that
will
be
registry,
enabled
equals
one,
and
that
will
only
run
the
build
of
the
registry
and
whatever
else
they
write
like,
we
can
specify
it
that
way,
and
instead
of
having
the
option
of
let's
split
it
all
up,
we
have
the
option
by
default.
D
All
of
these
things
run
in
unison,
but
you
have
the
control
options
of
saying:
I
just
want
these
parts
to
run
certain
set
of
tests
or
build
an
image
or
whatever
or
trigger
something
in
my
repository.
So
we
can
do
that
if
you
want
to
and
theoretically
that,
should
bring
the
Omni
charts.
Slash
individual
charts
like
that
mid
Browns,
that
we
are
looking
for
yeah.
C
That
that's
an
it
sounds
like
the
best
option
and
you're
you're
totally
right
like
we
could
have
like
in
the
pipeline.
It
could
be
only
changes,
the
subdirectory
get
run
a
subset
of
tests,
and
that
would
make
it
a
lot
faster
or,
if
there's
a
version
bump
for
the
app
version
for
registry.
It
only
runs
registry
stuff,
and
this
is
to
me
the
ideal
and
then
and
then
what
would
happen
I
think
would
be
after
those
tests
run,
then
we
would
bump
the
version
like
charts
would
be.
C
D
C
D
Actually,
you
know
what
this
is
recorded.
I
can
I
can
see
the
recording
after
the
fact.
So
let's
say
we
agreed,
you
could
have
just
literally
like
taken
everything
you
wanted
right
now,
but
let's
say
we
agreed
because
I
think
I
understand
the
concept
that
we
are
discussing
here
and
I
think
we
are
in
agreement.
D
So
maybe
maybe
let's
let's
go
down
that
route
and
let's
investigate
that
and
let's
see
what
benefit
it
gives
us
I
agree
with
you
all
that
variables
is
less
transparent
and
it's
it's
easier
to
do,
but
it's
definitely
less
transparent
and
doesn't
doesn't
allow
us
the
controls
that
we
need
or
the
gates
at
least
that
we
need.
So
thanks
for
doing
that,
POC
I
think
it
was
very
much
worth
it
to
expose
these
things,
even
though
we
could
have
guessed
it
already
cool.
B
The
only
thing
I
wanted
to
mention
I
create
an
issue
for
this
to
track,
but
the
dev
registry
was
a
thing
there.
There's
a
bug
that
on
DJ
and
Jason
were
working
on
that
prevented
the
mailroom
registry
from
having
an
updated
version
of
the
image.
So
during
local
testing
I
found
out,
I
was
still
pulling
the
old
version
of
the
image
that
did
not
include
certain
changes.
D
B
B
D
D
Yeah,
basically,
for
you,
another
question
would
be
socialized
this
with
the
rest
of
the
department
so
discuss
this
with
sree
sree
invite
them
into
the
conversation
there
or
familiarize
them
at
least
and
we'll,
let's
put
next
week,
Tuesday,
let's
say
next
week:
Tuesday
as
our
cut
over
and
time
for
this
you
all.
Okay
with
that.
C
So
there
were
maybe
a
couple
issues
that
I
thought
you
would
wait
on
before
going
into
production.
What
is
this
is
updating
the
app
version
an
average
chart
during
the
release.
C
C
C
D
D
B
C
D
Would
I
would
suggest
so
because
I
want
to
get
this
out
of
our
queue
as
fast
as
possible,
so
that
we
can
work
on
this
other
thing
that
is
way
way
way
more
important,
because
any
changes
with
sidekick
that
we
want
to
do
next.
We
can't
do
until
we
actually
have
this
in
step
with
what
we
do
in
production
right
now,
because
any
sort
of
def
inversions
between
what
we
have
deployed
with
omnibus
and
what
we
would
have
deployed
with
charts
in
sidekick
could
actually
cause
an
outage.
D
Whoo
all
right
so
repetition
here
jarv,
is
going
to
ensure
that
readiness
review
is
ready
and
that
the
rest
of
the
reliability
teams
are
invited
to
these
prior
to
us
doing
the
cutover
next
week,
I'm
going
to
go
and
chase
the
distribution
team
to
ask
the
issue
that
you
linked
1,
6,
6
8,
to
ensure
that
we
have
some
movement
on
it.
I'm
gonna
say
this
is
p2,
not
p1
for
sure
it's
not
blocking
us
from
anything,
but
it
could
cause
issues.