►
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
So,
let's
start
so
in
this
week's
demo,
I'm
trying
to
show
you
the
the
idea
of
building
omnibus
images
based
on
repeatedly
cng
images
based
on
omnibus
software
definitions
that
we
have.
I
already
left
a
comment
on
the
distribution
of
demo
notes,
which
points
to
the
repository
that
we
are
using
in
this
demo.
A
This
is
the
repository
I
called
it
omnibus
cng
for
the
lack
of
a
better,
but
it's
fairly
simple.
It
has
builder
images.
We
take
the
omnibus
to
the
builder
images,
pretty
much
similar
to
what
we
do
at
the
moment
for
building
the
image
building
the
omnibus
packages
grab
the
artifacts
and
just
deploy
those
artifacts
in
basic
images.
This
is
what
happens
generally,
it's
fairly.
It's
very
simple.
A
A
A
The
ubi
builder
image
is
literally
stacking.
The
ubi
builder
ubi,
ruby,
ruby,
uk
lab
ruby,
ubi
and
gitlab
go
ubi
on
top
of
each
other,
with
a
minor
addition
of
omnibus.
As
a
dependency
I
do
not.
I
did
not
use
the
rfr
fork
of
omnibus.
I
used
the
omnibus
jam
for
simplicity
of
the
installation,
but
this
can't
change
as
well.
A
Nothing
particular
happens
in
these
images.
I
only
want
to
show
you
a
small
patch
that
I
did
in
ubi
images.
I
manually
tweaked
the
hi
entries.
This
is
what
omnibus
uses
to
determine
the
packager,
so
I
kind
of
hacked
omnibus
to
make
sure
that
it
cannot.
It
does
not
use
rpm,
builder
or
deviant
builder.
There
is
a
another
fallback,
packager
called
makeself,
which
is
basically
a
shell
script
and
a
targeset
payload
and
a
post
installer
script,
and
that's
it
it's
for
the
platforms
that
omnibus
cannot
build
the
package.
A
B
A
A
A
A
A
A
So
the
tweaks
I
had
to
do
some
tweaks
about
license
finder
here,
because
I
really
couldn't
make
it
work
in
these
builder
images.
Some
gems
aren't
really
right.
So
I
just
commented
those
parts
also
because
I'm
using
the
standard
gem,
not
the
fork.
I
had
to
comment
some
of
the
directives
of
the
omnibus
dsl
to
make
sure
that
it
passes
so.
A
A
A
Yeah
so
it
opened
the
system,
so
I'm
going
to
show
you
the
docker
files,
so
this
thing
starts
keeps
building
and
you
eventually
grab
the
package
and
I'm
going
to
show
you
how
the
docker
file
works.
So,
let's
take
a
look
at
the
docker
files.
This
is
the
uvi
microphone.
This
is
a
distributed,
stacker
file
and
what
I
did
it
has
a
two-stage
for
the
distrolus.
I
use
the
cluster
as
a
build
for
the
build
phase.
A
A
So
you
might
need
to
figure
out
what
to
do
with
the
systems
that
don't
have
glc,
because
for
currently
omnibus
is
built
with,
with
a
pretty
large
for
for
pretty,
like
ready,
they're
ready
to
use
distributions,
rather
than
a
very
stringed
down.
Take
down
distributions
like
to
done,
which
is
there
will
be
some
changes
in
omnibus
okay.
This
is
a
step.
Okay,
we
have
the
package,
I
guess
it
will
be
done.
A
A
A
So,
let's
take
a
look
at
a
better
look
at
omnibus,
so
everything
actually
copied
from
the
current
omnibus.
I
added
the
projects
for
specific
final
images
that
I
want
and
in
software
definitions
I
haven't
only
commented
out
to
things
that
are
very
problematic
for
building
a
particular
license
finder.
A
I
also
added
another
software
definition,
which
is
basically
a
software
definition
for
cng,
but
I
expect
people
have
to
add
more
software
definitions,
for
example,
for
cng
specific
servers
like
gitlab,
locker,
compilate
or
anything
else
that
we
are
using
and
we
will
get
through
the
some
of
the
challenges
later.
But
this
is
the
software
definition
that
I'm
using.
A
A
Okay,
we
have
the
extremist
image
as
well.
Let's
see
if
this
one
is
running
as
well.
Yes,
so
with
that,
we
have
two
images:
two
versions
of
the
images
from
omnibus
this
is
for
gitlab
ruby.
Now,
let's
take
a
look
at
a
more
practical
example,
which
is
italy.
Italy
is
more
complicated
for
a
few
for
for
reasons.
A
A
A
A
A
A
C
A
A
About
the
kittery
image,
let's
take
a
look
at
the
stacker
file
for
github
image.
I
couldn't
really
use
the
bear,
only
the
output
of
the
omnibus
for
two
reasons,
one
the
custom
user,
which
needed
to
be
created
because
it
uses
a
particular
user,
not
any
non-root
user,
and
the
second
reason
was
that
it
requires
some
other
dependencies
that
we
do
not
build
in
omnibus
and
ps.
D
A
So
but
these
defenders
had
to
be
installed,
so
this
is
one
thing
to
keep
in
mind
if
you
want
to
have
a
completely
self-contained
image
without
any
external
dependency
that
is
coming
from
any
repository,
they
can
be
deployed
across
different
platforms,
then
we
will
probably
have
to
also
add
these.
Some
of
some
sufferers
are
cng
specifics
and
are
not
built
as
part
of
normal
omnibus,
so
part
of
it
is
still
there,
and
I
had
to
do
some
tweaking
as
well,
because
we
have
this
particular.
A
B
B
A
A
B
A
C
A
A
C
C
A
C
B
D
A
A
B
A
A
C
D
A
A
A
B
C
B
C
C
C
B
B
A
A
B
A
C
C
A
B
A
A
This
is
the
shell
script.
This
shell
script
is
too
much.
We
can
have
our
own
packager,
which
is
basically
a
targey
z
file
and
a
post
installed,
but
this
is
what
it
does.
This
is
shella
script
with
authorities,
it
payload,
which
can
also
run
a
post
script
post,
install
the
screen.
So
basically,
you
probably
want
something
similar.
C
C
B
C
A
C
A
So,
going
back
to
your
initial
conversation
about
output
of
omnibus,
I
think
we
should
have
multiple
projects
because
collecting
the
requirements
of
a
particular
module
like
italy
from
the
full-blown
omnibus,
requires
a
lot
of
work
in
terms
of
identifying
what
those
dependencies
what
those
files
are
and
what
is
needed.
Actually,
so
we
need
to
go
and
filter
out
the
output
of
omnibus
per
module,
as
opposed
to
having
separate
packets
separate
for
different
modules,
which
bundles
everything
that
is
needed
as
dependencies
into
one
particular
output.
A
So
that's
that's
one
of
the
things
that
we
can
consider
the
second
thing
about
omnibus
and
adding
dependencies
some
of
the
dependents.
Actually,
as
this
I
can
think
of
jlpc,
that's
that's
a
must-have.
We
can't
go
around
it
and
if
you
want
to
use
a
base
image
based
on
uvi
micro
or
any
any
other
base
image,
we
need
to
have
glpc
or
dql
or
in
something
equivalent.
C
So
unless
we're
building
we're
taking
only
the
red
hat,
aligned
versions,
both
building
on
rel
and
using
the
glibe
c
from
ubi
at
an
exactly
matched
version,
we
can
highly
expect
that
stuff
will
explode
in
weird
ways,
and
this
does
actually
align
believe
it
or
not.
It's
a
problem
in
go
to
where,
though
it
generally
makes
statically
compiled
binaries,
but
it
it
avoids
being
fully
static
when
using
certain
components
that
are
by
default
in
c,
go,
and
it
will
then
use
ldd
for
those
components
where
it
reaches
out
to
system
libraries.
C
There
was
a
case
recently
I
was
working
with
will
and
he
like.
Oh,
this
should
work
and
I'm
like
yeah,
but
you
didn't
compile
a
static
and
your
empty
image
doesn't
have
like
it
might
have
actually
literally
been
glebc,
and
now
that
was,
he
was
actually
missing.
The
ld
linux
system,
library,
so
he
couldn't
get
anywhere.
He
tried
to
run
the
program
and
it
said,
file
does
not
exist.
C
A
I
am
using
ubi
for
build
images
as
well
exact,
same
version,
I'm
not
using
red
hat
for
the
build
image
for
the
builder,
so
to
be
sure
that
the
the
software
is
going
to
run
in
the
exact
same
environment
that
it
was
built,
not
the
exact
same
environment
but
as
similar
as
the
base
image
that
it
was
built.
Open.
C
Right
so
right
now,
I'm
I'm
talking
about
bending
beyond
this
work
like
we
can
use
omnibus
as
a
toolkit,
but
using
the
get
lab
omnibuses
output,
its
libraries,
which
that
pipeline
currently
doesn't
have
any
awareness
of
ubi.
What
I'm
saying
that's
where
we
have
the
problem
with
we
build.
You
know
seven,
eight
images
of
both
variations
for
many
distributions,
but
when
we
turn
around
and
do
use
those
cash
they're
going
to
be
built
against
those
versions,
so
we
have
that
concern.
A
Yeah,
that's
that's
correct.
The
way
that
I
I
I
was
envisioning
it
is.
That
was
that
we
built
this.
We
use
these
builder
images,
close
builder
images
and
have
spa
spawn
new
pipelines,
but
sharing
build
cash
between
the
current
omnibus,
in
particular,
for
ubi
could
be
a
bit
challenging
here
and
not
to
mention
that
if
you
want
to
expand
the
same
practice
to
arm
images.
C
So
it
is
a
viable
example
of
look.
We
can
interact
the
omnibus
into
the
results
of
the
containers
right
effectively,
we're
just
re-homing
we're
changing
where
the,
where
things
are
compiled
and
we're
rehoming
where
they
are
in
the
current
setup
versus
the
future
setup
right.
So,
instead
of
being
served
gitlab
whatever
it
goes
back
to
the
opt
and
get
lab
embedded.
A
A
A
We
ideally,
we
won't
have
any
tucker
image,
it's
going
to
be
generated
based
on
the
omnibus
output,
and
you
need
to
address
the
changes
that
are
re-homing
and
changing
the
configuration
passes
in
in
chart,
so
I'm
not
sure
how
we
can
really
implement
it.
While
we
are
also
delivering
a
working
solution,
every
release.
C
No,
we
require
yeah
because
it's
either
used
as
part
of
spawn
up
right,
some
of
our
initiation
or
initialization
bits
of
our
own
container
orchestration
right
now
uses
shell
and
second,
there
are
entire
application
bits
that
actually
assume
that
they
can
call
a
shell
script.
One
of
those
instances,
for
example,
was
was
reminded
me
today.
We
have
file
hooks
where
you
literally
put
something
in
there
and
on
such
and
such
events.
It
runs
by
and
actually
executes
the
hook.
A
C
C
A
Yes,
but
for
example,
if
you
want
you
are
opting
in
for
compilate
and
gitlab
logger
and
trying
to
push
it,
make
it
more
pervasive
across
all
the
images
that
we
have.
For
example,
in
this
scenario,
compilate
and
gitlab
loggers
will
become
omnibus
software
definitions
that
are
included
in
cng,
but
not
the
final,
the
actual
omnibus.
To
realign
us-
and
I
tried
it
it
can
be.
Can
we
can
accommodate
that
you
can
have
software
definitions
that
are
not
really
used
in
a
project,
so
it
doesn't
impact.
B
C
We
can
show
that
we,
this
is
how
you
would
use
an
omnibus
definition
to
do
this,
but
there's
a
lot
of
backing
questions
of
how
do
we
do
it?
How
do
we
actually
do
it?
Can
we
share
build
cache?
Can
we
just
take
the
artifact
out
of
the
other
one
which
ways
to
actually
implement
it?
So
I
think
the
next
steps
are.
Are
that
break
down
the
rest
of
the
the
research
items?