►
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
Okay,
welcome
everybody
to
the
distribution
demo
for
March
23rd
2023..
What
we're
going
to
look
at
today
is
in
relation
to
a
proposal
to
replace
the
use
of
the
busy
box
image
itself
with
the
gitlab
base
image
effectively.
All
we
really
use
busy
box
4
is
specifically
doing
some
init
container
patterns,
which
almost
always
consists
of
just
copying.
Files
around.
A
There
are
some
more
complex
items
that
we
have
to
care
about,
and
there
are
Upstream
charts
that
we
may
or
may
not
be
able
to
just
drop
in
like
that.
But
at
least
we
can
look
at
hours.
A
A
First,
we
needed
to
make
sure
that
the
gitlab
base
image
was
actually
produced
and
tagged
on
the
same
one
that
it
was
included
into
the
final
images
listing
so
that
we
knew
about
it
and
tracked
it
that
we
had
it
included
with
metrics
and
that
it
was
actually
a
part
of
the
sync
images
AKA
part
of
the
release
process
itself.
A
A
I
get
a
result:
I
have
a
published
version
file
that
matches
and
surprise
I
do
get
a
result,
so
we
are
indeed
publishing
this
along
with
everything
else,
so
that
much
is
good
now.
The
next
item
we
have
here
is,
you
know:
we'd
have
to
make
sure
that
release
tools
is
updating
whatever
that
image
is
so
that
we're
following
the
same
thing,
however,
recently
we've
made
it
so
that
the
helper
images
also
follow
the
same
tag
on
the
CNG.
A
A
So
a
rightful
thing
was
that
Hussein
mentioned
at
the
time
of
the
issue
is
that
we
have
to
be
careful
about
switching
things
over
now.
The
concern
is
that
we
have
these
set
config
scripts
that
are
built
in
to
get
lab
based,
so
that
we
don't
have
to
have
them
into
every
single
image
in
if
you're
running
them
through
Docker.
A
You
replace
that
through
the
entry
point
when
we
turn
around
and
do
the
exact
same
thing
as
a
part
of
the
gitlab
charts,
all
we
really
need
to
do
is
make
sure
that
we're
setting
command
for
whatever
that
is
so
that
we
can
override
that
entry
point
Behavior,
because
most
of
the
time
we
legitimately
just
need
to
run
a
whole
bunch
of
walk.
This
directory
copy
this
file
from
here
to
there,
and
only
really
in
the
registry
chart
itself.
Do
we
have
to
worry
about
the
complexities
of
the
init
pattern?
That's
present
there.
A
A
Now,
what
we
basically
do
here
is
construct
what
the
image
is
from
BusyBox
itself,
nothing
horribly,
complicated,
but
effectively.
We
just
have
a
means
of
pulling
in
what
the
busy
box
repository
is
and
then
having
the
localized
version
for
a
Neato
or
whatever
else,
and
then
coalescing
that
into
a
name
and
tag
right,
standard
patterned
effectively.
A
Now
this
did
not
previously
take
into
account
tag
suffix,
because
we
weren't
actually
tagging
our
own
BusyBox
images
to
replace
this
outright.
We
probably
want
to
basically
clone
BusyBox
image
because,
as
we
do
this
portions
at
a
time
we'll,
we
won't
necessarily
want
to
clearly
replace
every
instance
at
once.
So
we
could
roll
this
from
gitlab
busy
box
image
to
gitlab
base
image
as
we
go
along.
A
A
B
A
A
As
long
as
we
were
to
set
the
busy
box
image
repository
to
the
correct
or
newer
name,
it
would
essentially
just
drop
itself
right
in
the
complexity
like
I
said,
is.
How
is
that
then
used
as
a
part
of
the
various
deployments,
the
ones
that
we're
going
to
care
about?
Most
I
already
know
about
so
I'm,
going
to
look
at
code,
charts
registry
templates
deployments.
A
A
A
So
the
immediate
concern
that
was
raised
and
was
accurate
from
the
saying
that
we
make
sure
that
we
get
around
the
such
config
pattern
by
making
use
of
the
command
Behavior
appears
for
at
least
almost
every
instance
of
a
knit
container.
We
seem
to
already
have
the
setting
of
command
so
I'm
going
to
make
something
simple
here
into
revtech
RN.
A
A
That
has
that
and
that's
on
the
migration.
So
that's
there,
Italy
has
configured
sh
sh
sh
got
an
sh
this
one's
a
little
different
because
of
the
line
item
behaviors
looks
like
we
wanted
to
make
it
easier
for
us
to
identify
specifically
what
was
going
to
fire
through
Arguments
for
that
one,
because
we
have
to
do
something
slightly
different:
hey
opportunity
to
dry
a
little
bit
here.
A
A
A
And
then
we
have
now
mind
you.
This
is
our
our
Fork
of
minio.
If,
if
future
looking,
we
do
switch
to
a
different
midi
o
provider
chart.
Obviously
this
will
change
some
things,
but
we
have
to
look
and
make
sure
that
we
can
get
the
same
scripting
patterns
in
place
for
it
then
we're
looking
at
the
registry.
We
already
know
that
we
have
that
and
even
their
necessary
jobs,
so
on
First
Look,
it
looks
like
we
really
don't
have
to
worry
about.
A
Ensuring
command
is
in
place
because
it
seems
to
be
in
place
for
all
charts.
So,
let's
take
the
simplest
possible,
let's
see
what
happens
route
and
just
set
the
BusyBox
image
repository
to,
instead
of
being
based
on
BusyBox
to
be
based
upon
gitlab
base
and,
of
course,
set
a
tag.
That's
going
to
actually,
you
know
exist
because,
unlike
BusyBox,
we
do
not
tag
latest
and
we
have
not
tagged
latest.
Quite
some
time
on
purpose
feel
free
to
ask
if
anybody
ever
wants
to
know
why
we
don't
tag
latest
summary
is
don't
do
that.
A
A
A
Unsurprisingly,
we're
seeing
web
service
and
sidekick
in
paused,
States
I
say
pause
the
net,
because
if
I
were
to
go,
look
at
what's
actually
going
on
we're
currently
and
the
dependencies
in
it
container
and
it's
waiting
for
the
the
database
to
be
fully
initialized.
A
A
A
So,
at
least
from
that
standpoint,
it
really
was
as
simple
as
setting
a
tag
and
changing
the
image
now
to
be
fair.
I
also,
don't
have
absolutely
everything
turned
on
and
I
didn't
necessarily
look
at
any
of
our
other
charts
that
we
depend
on
that
may
or
may
not
have
BusyBox
to
be
fair.
Those
are
the
primary
ones
that
we're
going
to
care
about
are
redis
and
postgresql.
A
Both
of
these,
as
a
particular
instance,
is
those
customers
that
care
most
about
the
attestation.
For
each
of
these
images
should
not
be
running
these
in
production
anyways.
It's
not
that
we
don't
say
that
they're
impossible
to
run
in
production.
It's
we
don't
provide
them
as
dependencies
of
this
chart
to
be
production
instances,
we
don't
test
them
as
production
instances,
because
we
give
guidance
that,
depending
on
your
load,
we
can't
predict
it
in
a
reliable
fashion.
A
A
I
don't
have
grafana
turned
on
I,
don't
have
Prometheus
turned
on,
so
I
can
look
at
one
of
those
in
a
production
CI
deployment
to
see
what
it
uses,
but
all
of
our
charts
actually
fire
up
without
an
issue.
The
only
one
I
need
to
look
at
is
short
skit
lab
charts
to
get
pages.
A
Anywhere
we
can
base
off
the
existing
work
that
we
did
to
change
all
the
other
helper
images
over.
What's
the
benefit
right,
the
issue
talks
to
it
a
little
bit
but
like.
Let
me
explain
this
to
everybody
else.
That
may
not
be
exactly
familiar.
A
There
are
multiple
ways
in
which
a
given
kubernetes
can
be
configured
to
pull
images
if
you
happen
to
make
use
of
gke
as
an
example
and
you're
using
a
managed
cluster
versus
gcp
and
then
deploying
a
cluster
onto
it
through
Cube
spray,
or
something
like
this
gke
by
default.
Serializes
all
image
pools.
A
Thus,
if
we
pull
that
to
do
the
init
containers,
everything
that
comes
after
it
actually
goes
faster
because
we've
pulled
everything,
we
don't
have
to
make
more
API
calls
and
when
it
goes
to
pull
the
next
image,
because
every
image
on
the
Node,
that
is
a
gitlab
image,
will
share
that
as
a
base
image.
Every
single
pole
actually
gets
faster.
A
B
A
A
A
Jason
Yep
this
is
this
is
relatively
simple:
straightforward
work
with
a
little
bit
of
care.
We
can
make
it
happen
super
quickly
and
it
will
benefit
everybody.
So
thanks
everybody
for
watching
and
listening
and
if
you're
interested
feel
free
to
take
a
poke.
We
shall
see
you
around
bye.