►
From YouTube: 20200226 - Image Builder Office Hours
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
Hello
and
welcome
to
the
Wednesday
February
26th
edition
of
the
image
builder
office
hours,
a
sub-project
as
a
cluster
lifecycle,
just
a
reminder
that
this
meeting
is
recorded
and
will
be
posted
up
to
YouTube
later,
and
it
also
abides
by
the
kubernetes
community
guidelines.
So
in
general,
please
bx9
to
one
another
with
that
said,
please
go
ahead
and
add
yourself
to
the
attending
list.
If
you
are
attending
live
I've
linked
that
in
the
same
track,
and
if
you
have
any
topics
that
you'd
like
to
bring
up,
please
add
them
to
the
agenda
as
well.
B
B
So
there
is
a
V
zero
one,
zero
tag
now
and
that
just
allows
people
to
end
documentation
to
point
to
a
stable
repo,
especially
for
consumers
of
the
cluster
API
builder,
and
one
of
the
other
big
reasons
I
wanted
to
get
that
in
is
if
we
ever
make
further
progress
with
with
moshus
work,
to
create
CLI.
That's
going
to
change
the
experience
dramatically
so
I
wanted
at
least
have
something
that
we
could
branch
around
or
maintained
until
we
were
ready
to
switch
that
so
that
has
been
done.
Finally,.
B
Beyond
that,
yeah
I
didn't
have
any
much
else
to
add
to
the
agenda
except
yeah.
I
was
gonna,
always
ensure
you
know
what
Justin's
typing
right
now
he
had
a
bit
of
a
proposal
around
doing
some
consolidation,
but
since
he
shared
it
with
us,
a
couple
couple
of
us
privately
first
I,
wasn't
sure
if
he
was
wanting
to
bring
it
up
here
yet
or
not.
Yeah.
C
B
C
I
mean
it's
not
a
it's
just
like
I
think
we
mentioned
it
in
some
other
meeting
this
week.
The
idea
is
just
like
investigate
when
I
was
look
at
the
unification
like
I
saw
that
docker
dig
did
seem
to
be
the
the
common
or
docker
containers
or
images.
I
shouldn't
say
seem
to
be
the
common
ground
that
all
of
us
could
work
with.
In
that
Packer
can
write
to
docker
and
config
ADM.
C
I
think
Tim
Sinclair
brought
up
the
minor
snafu
of
Windows,
which
made
me
cry
a
little,
but
yes
I.
That's
that
was
sort
of
the
idea
that
is
in
that
dock.
So
if
you,
if
you
have
time
to
look
at
it,
that's
great
otherwise
I
would
also
just
share
it
with
I'll
just
share
with
a
group
and
put
a
link
in
their
meeting
minutes.
You.
D
So
I'll
be
relooking
at
that
CLI
and
I
think
we
can
kind
of
break
it
down
so
that
we
actually
make
everybody
happy.
So
if
we
separate
out
basically
the
idea
of
executing
some
stuff,
creating
an
image
and
and
actually
the
the
the
framework
for
doing
so
into
into
different
phases
and
then
feed
into
each
other,
I
think
we
can
support
most
combinations
so,
for
example,
what
I'm
calling
an
engine.
So
you
would
support,
let
say
taka,
daka
and
qmu
as
an
engine.
So
those
are
kind
of
the
three
ways
that
we're
thinking
about
that.
D
We
then
build
in
an
abstraction
for
image,
handling
and
convolution
so
that
you
can
go
from
docker
to
qmu
to
AWS
or
qmu
to
GCE,
so
that
you
can
kind
of
mix
and
match
them.
So
I
can
start
with
a
docker
and
landed
on
AWS
so
start
with
a
dock
and
landed
on
on
an
OVA
or
vSphere
or
I
can
start
with
a
pakka
image
and
depending
Packers
a
bit
of
the
the
funny
one,
because
you
I
don't
know
what
they
export
options
are
from
from
the
different
clouds.
I
think
some
of
them.
D
You
can
export
the
images.
I,
don't
know,
I
haven't
done
much
too
much
research,
but
for
that
we
can
always
say,
restrict
the
input
and
output
image
formats
if
you're,
using
Packers
in
your
camera
are
limited
to
ISO
and
OVA,
or
ami
and
AMI,
and
on
kind
of
Nixon
to
trench
the
the
formats
and
then
in
the
middle.
D
We
plug
in
basically
three
ways
of
executing
stuff,
which
is
shell,
ansible
and
configure,
and
we
plug
it
in
and
then
we
provide
the
bits
for
during
the
cuban
air,
these
stuff
out
of
the
box,
and
then
let
people
mix
and
match
what
they
want
to
do
so.
Take
a
docker
image
to
the
kubernetes
bits
and
whatever
it
is
whatever
that
is
add
on
a
shell
script
and
ansible
script
and
config
admins
script,
script
or
whatever
combination
before
or
afterwards
and
then
omit
something
do
something
with
it.
D
B
D
So
we
implement
that
and
then
going
from
a
disk
image
to
AWS
is
not
such
a
difficult
thing
or
disk
image
to
OVA
or
disk
image
to
vSphere.
So
each
one
of
these
individual
things
is
solved
some
way.
We
just
need
to
bring
it
all
together
and
make
it
make
sure
the
workflow
extendable
so
that
you
can
plug
and
play.
C
Make
sense,
I,
think
I
agree
with
that
and
I
think
like
building
up
the
small
like,
as
you
say,
UNIX
philosophy
like
the
individual
tools
and
I.
Don't
know
well
do
about
the
things
that
are
impossible
like
you
can't
directly
take
a
or
it's
I,
don't
know
it's
certainly
much
harder
to
take
an
EVs
or
an
ami
and
get
it
into
like
download
it
locally.
But
it
is
possible.
D
B
Question
yeah
I
mean
for
me
when
it
comes
to
anything
to
do
with
the
CLI.
It's
something
I've
expressed
interest
in
and
I
have
brought
it
up.
What
kind
of
my
priority
deciders
in
the
past
and
I?
Don't
think
it's
something
that
would
happen
in
the
next
few
weeks,
but
it
is
within
scope
like
there's
a
vision
of
like
yes,
the
resources
need
to
go
to
that
I
know.
One
of
the
first
things
that
I'd
want
to
see
is
a
little
bit
more
of
a
document.
B
You
know
not
not
a
cap
but
like
something
that
kind
of
outlines
how
those
pieces
go
together,
and
there
was
a
previous
version
of
that
that
Tim,
st.
Claire
and
some
others
worked
on
I'll
try
to
dig
that
up
if
nobody
remembers
it,
but
this
sounds
very
much
the
same
thing:
dividing
it
up
into
stages
and
being
able
to
pick
what
then
processor
in
that
stages.
D
What
we
can
do
is
that
you
can
work
on
the
encapsulating,
the
Packer
plus
ansible,
into
a
docker
image
that
makes
it
a
little
bit
more
consumable
so
specifically
like
dependencies
and
things
like
that.
So
if
we
make
the
the
way
of
executing
Packer
using
a
docker
image
and
then
all
we
doing
is
providing
as
part
of
the
the
release
process,
we
could
release
a
docker
image
with
the
bundle
danceable
scripts
that
that
mod
actually
helped
us
quite
a
bit.
B
C
C
So
like
creating
an
image,
I
guess:
well,
the
docker
build
to
create
an
image
which
I
think
it's
not
terribly
complicated,
then
like
docker,
am
I
or
docker
to
disk
image
and
disk
image
am
I
and
publishing
the
ami
and
replicating
the
ami,
which
is
currently
locked
to
improve,
deploy,
but
there's
absolutely
no
reason
for
that
to
be
the
case.
So.
D
C
Make
break
those
down
as
like
little
commandlets
or
whatever
we
want
to
call
them
like
if
we
have
some
some
place
to
put
them
in,
but
I
can
imagine
us
building
up
like
a
toolbox
of
these
things
in
Kobra,
much
like
oh
yeah
right
exactly
but
like
there.
Lots
of
these
little
ones
and
I
can
certainly
work
on
those
and
whether
it's
four
or
five,
and
it
might
be
that
the
number
changes
so
I
go
to
build
it.
But
I
can
certainly
work
on
that.
Yep
sounds
good.
A
And
I
probably
don't
have
any
development
resources
that
I
can
contribute,
but
I'm
more
than
happy
to
provide
feedback
on
Docs
and
and
especially
test
things
out,
as
we
start
getting
to
the
POC
stage
as
well,
because
I'm
still
currently
building
all
the
images,
especially
for
the
AWS
provider.
So
it's
relatively
easy
for
me
to
spend
something
up
test
it
and
verify
that
it
works
as
we
expect
cool
Jason.
What
do
you
think
if
all
this
image
is
Packer
or
yeah
we're
using
Packers?
So
the
Packer
scripts
that
are
currently
in
repo.