►
Description
The Fedora Project recently announced the availability of the Fedora Docker Layered Image Build Service. The Fedora Cloud WG has been the primary maintainers of this project on GitHub. But now the service is available in dist-git as official components of Fedora. From there we will extend an invitation to all Fedora Contributors to maintain Docker Layered Image Containers for official release by the Fedora Project. Currently this effort is to enable the Fedora Cloud/Atomic Working Group goals of targeting Fedora Atomic Host as a primary deliverable to power the future of Cloud. This is also to enable the Fedora Modularity work be delivered as Containers in the future as Fedora becomes fundamentally more modular in nature.
The Fedora Layered Image Build System is built using a combination of open source projects. The main elements are: Docker, Koji, OpenShift Origin, Atomic Reactor, and OSBS Client.
More background on the announcement here: https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/
A
Well,
hello
and
welcome
everybody
to
another
Vulcan
ship
Commons
briefing.
This
is
the
last
briefing
of
2016.
It's
been
an
epic
year
and
they're
having
a
wonderful
speaker
today,
one
of
my
favorite
people,
Adam
Miller,
who
was
one
of
the
key
folks
on
the
OpenShift
team
for
many
years
on
the
outside
and
helping
us,
get
it
up
and
running
and
has
moved
over
to
fedora,
and
he
is
going
to
talk
to
us
about
the
Fedora
image
builder
service.
A
Today,
one
of
my
most
anticipated
things
so
without
further
ado,
I'm
gonna,
let
Adam
introduce
himself,
take
it
away,
we're
going
to
have
his
presentation
and
then
we'll
open
it
up
for
Q&A.
Afterwards.
If
you
have
questions
in
the
chat
post
them
there.
Just
remember
the
speaker
can't
see
the
chat
while
he's
talking
and
demoing.
Don't
take
it
away
out.
A
B
build-in
in
there
will
actually
discuss
various
differences
between
container
image,
base
images
and
layered
images
and
instances
those
images
how
to
become
containers.
Those
kinds
of
things
I
want
to
quickly
define
a
release
engineering
just
because
that
will
kind
of
provide
perspective
around
why
the
system
was
designed.
B
The
way
it
was
and
why
the
way
it
is
and
have
certain
attributes
of
the
system
and
why
they
were
chosen
that
way
and
then
we'll
actually
talk
directly
about
the
doctor
image
build
service,
the
building
blocks
it
was
built
on
top
of
which
is
openshift,
a
utility
called
OS
PS,
which
OS
PS
client
upstream.
The
way
that
that
special
kind
of
provides
a
special
use
case,
a
pre
prescribed
recipe
for
how
to
use
openshift
directly
such
that
you
can
kind
of
turn
it
into
a
build
service.
B
B
So
really
quick
before
we
get
into
containers.
If
there
is
anything
there,
any
questions
that
pop
up,
maybe
in
the
chat
or
otherwise,
if
Diane
I,
don't
know
if
who
all
on
the
on
the
blue
jean
sessions
has
the
ability
to
interrupt
me,
but
please
feel
free
to
interrupt
questions.
If
that
would
prove
helpful.
It.
B
Awesome
wonderful
feel
free
to
hop
in
and
and
well
if
there
was
a
dialog
that
we
can
generate
great,
okay,
so
really
quick.
What
are
containers?
This
is
actually
something
that
kind
of
goes
back
and
forth
and
unity
talk
to.
But
at
the
end
of
the
day
there
is
a
kind
of
formal
definition
around
operating
system-level
virtualization.
B
So
the
cannot
the
concepts
not
new
and
I
posed
to
argue-
and
there
are
a
few
others
out
in
the
community
too,
opposed
to
argue
this-
that
the
original
container
was
the
chroot.
If
anybody's
remember
with
Brian
Cantrell
great
speaker,
you
know
as
a
huge
lineage
and
solaris
and
all
those
kinds
of
things,
and
nowadays
Lou
Moss,
but
he's
great
talk.
B
That
kind
of
echoes
some
of
this
and
and
has
very
interesting
citations
back
into
the
history
of
computer
science,
but
basically
the
idea
of
lying
to
a
program
about
its
reality
such
that
you
can
have
a
context
of,
or
you
can
have
an
instantiation
of
that
program.
You
know
one
time
thread
and
the
context
of
the
world
around.
It
is
different
than
the
reality
of
the
system
below
it.
And
you
know
it's
a
really
primitive.
B
You
basically
just
say
this
is
this:
is
your
root
filesystem,
even
though
it's
not
actually
the
root
filesystem
of
the
system
that
it's
it's
running
on
top
of
and
it'll
ask
many
sophisticated
features
that
we
get
later
in
life
copy
and
write
file
systems,
quota
enforcement
rate,
limiting
any
kind
of
constraint
for
resources
and
those
kinds
of
things.
So,
just
really
quick
for
those
who
aren't
familiar
freebsd
had
a
more
sophisticated
technology
called
jails.
Then
there
was
linked
to
these
servers:
lair
zones,
obz
LXE,
both
linux,
visa
and
ovz.
B
While
they
were
running
on
linux,
they
never
made
it
in
in
maine
ups.
They
never
made
an
upstream
and
never
made
it
in
in
wide
adoption.
Alex
C
is
where
things
got
really
interesting
and
for
those
not
familiar
LX
e
stands
for
Linux
containers
and
because
acronyms
are
fun,
there's
not
actually
a
third
word.
It's
just
the
end
of
the
word
Linux
and
it
basically
just
a
user
space
set
of
tools
that
would
wrap
curl
name
spacing
in
C
group.
B
So
these
were
things
are
provided
by
the
kernel
and
the
a
couple
of
years
leading
up
to
2008.
If
these
capabilities
were
implemented
in
the
kernel
and
that
actually
gave
us
the
ability
to
do
many
of
these
sophisticated
features
that
we
wanted
in
2011
system,
D
wrote
and
spawn
containers.
They
originally
were
created
just
to
test
system
D,
so
they
didn't
have
to
reboot
computers
all
the
time
to
just
actually
test
the
the
init
system
and
why
that
gets
interesting.
B
I'll
I'll
tell
you
that
so
Intel
13
cloud
releases
docker,
so
doc
cloud
was
used
to
be
the
company
that
is
now
known
as
dr.
Incorporated.
They
originally
based
their
implementation
on
LXE
has
since
been
replaced
by
lib
container
and,
and
nowadays
it's
you
know,
it's
built
on
top
of
one
sea
and
container
being
those
kinds
of
things.
B
It's
not
it's
not
quite
as
monolithic
in
nature,
so
2014
for
us
releases
rocket
rocket
originally
was
a
implementation
of
their
specification
and
their
container
image,
and
it
was
built
on
top
of
system
VN
spawn,
and
that
was
very
interesting
because
then
somebody
took
you
know
what
was
originally
kind
of
this
primitive
thing
that
added
necessary
to
keep
the
technology
and
extended
it
to
be
more
broad
use
case
and
2015.
This
was
so
the
history
lesson
kind
of
comes
to
a
point.
B
Here
is
the
open
container
project
now
known
as
the
open
initiative,
it's
kind
of
culmination
of
a
lot
of
different
technology
technology
companies,
Allen
ecosystems,
coming
together
to
try
to
standardize
on
container
formats
in
the
runtime,
such
that
any
of
any
person.
Company
OpenSocial
community
project
could
build
a
set
of
tooling
or
an
implementation
that
would
produce
container
images
and
runtimes.
That
could
then
run
on
any
other
implementation
of
the
specification.
B
So
don't
fifteen
Runcie
came
out.
This
was
the
standalone
tool
for
spawning
containers
in
the
OCP.
This
was
donated
to
the
community
by
docker
and
and
then
they
can,
and
just
two
more
recently
in
a
nerdy
again
was
was
created
as
the
thing
that
will
allow
you
to
run
many
run:
sea
cooling,
container
implementation
or
container
runtimes
under
other
that,
so
the
thing
is
running
more
modern
versions
of
thinking.
There
were
a
lot
of
birds.
B
Valerie's
chances
are,
you
are
running
an
OC
I
specified
continuing
and
it
just
kind
of
being
handled
by
various
technologies
over
the
hood
and
and
those
are
the
building
blocks
for
what
we
get
to
now.
What
we
consider
Linux
containers
and
also
docker
being
the
de
facto
standard,
the
most
popular
thing
out
in
the
ecosystem,
these
days
for
for
the
build
pipelines
at
a
minimum
and
then
beyond
that
many
people
are
also
using.
This
is
the
runtime
that
is
what
Fedora
target
originally
from
the
community
space.
B
That's
what
our
users
are
using,
so
what
you
want
and
then
that's
what
the
the
build
pipeline
is
most
familiar
with.
There's
been
a
lot
of
really
interesting,
tooling,
coming
around
that.
You
know
because
system
not
just
offer
files
specifically,
but
you
know
Hanksville
container,
there's,
there's
the
ability
to
build
through
through
rockets.
B
You
know
chorus
to
the
Rockets,
app
sea
and
all
these
things,
though,
because
the
fact
that
they're
all
interchangeable,
it's
just
I-
think
CI.
We
have
a
lot
of
cohesiveness
in
ecosystem,
so
doctor
being
the
most
popular
one
indoors,
users
space.
This
is
what
we
target
originally
and
so
docker
itself
has
a
client-server
model.
There
is
the
docker
engine,
which
is
the
daemon
kind
of
single
point
of
entry.
Has
language
bindings,
it
is
a.
It
is
an
API
that
can
be
accessed
locally
or
remotely
in
this.
B
Conceptually
is
a
thing
that
we
need
understand
is
that
containers
are
instances
of
images,
and
this
is
very
similar
to
how
infrastructure,
as
a
service
cloud
environments,
have
images
and
then
instances
or
those
images,
and
you
create
instances
based
on
image.
So
in
docker
space
images
are
building
standard
way,
using
adopter
file
and
for
fedoras
context
as
well
as
mental
institutions.
B
There
is
SELinux
support
upstream
and
docker
that
was
provided
by
mr.
Gannon
mr.
Dan
Walsh.
He
is
kind
of
known
in
the
community,
as
mr.
su
Linux
has
has
been
kind
of
the
curator
of
that
for
many
many
years
now,
still
a
lot
of
pluggable
backends
for
isolation
beyond
doing
SEO
like
sandboxing
and
those
kind
of
things,
and
that
extends
out
to
the
the
storage
networking
and
those
other
things
you
can
kind
of
change
your
back-end.
For,
for
what
gives
you?
B
What
provides
your,
your
storage
location
and
your
networking,
those
kind
of
things
so
conceptually
there's
a
difference
between
a
base,
original
layer,
damage
and,
and
that
needs
to
be
defined,
because
what
our
build
system
that
we're
creating
that
we've
created
that
is
now
available
to
fedora
contributors
is
is
four
layered
images,
so
I'm
sorry
I
was
getting
feedback.
Somebody
some
of
these
like
bustling
or
something
can
we
mute?
Oh,
come
on,
okay,
awesome!
Thank
you!
B
So
container
container
layered
images
will
basically
be
built
by
the
greater
community
and
then
a
base
image
itself
traditionally
comes
from
the
distribution.
Much
like
the
operating
system
releases
are
so
if
you
see
like
an
ISO
image
to
install
an
operating
system
out
in
the
out
in
the
world
and
you
download
it-
you
install
it
that
is
normally
going
to
come
from
the
project.
The
distribution
projects
release
engineering
team
they're
going
to
have
a
process
in
place
that
will
send
that
through
QA
of
some
sort
they
will
go
through
validation.
B
It
will
have
you
know
a
process
puts
in
place
that
you
then
have
you
know,
sign
and
verified
and
I'm
sorry,
I'll
kind
of
artifact
you'll
assign
verified
artifact
that
comes
out
that's
kind
of
the
released
entity.
Well,
the
the
base
layers,
the
the
base
image
for
for
docker
for
containers
in
general
is
going
to
be
very
similar
to
that.
That's
something
that
you're
going
to
see
come
from
distributions
directly,
and
this
is
this-
is
no
different
for
fedora.
A
B
B
B
B
Well,
we
can
start
by
having
building
blocks
for
one
times
of
dynamic
programming,
languages
or
or
even
just
build
tooling
for
compiled
languages,
so
we
can
have
Python
in
Ruby
and
nodejs
and
PHP
and
all
those
things
as
a
as
a
layered
image
built
on
top
of
the
base
image
and
then
other
images
that
would
be
built
or
for
other
software
components.
For
other.
B
B
We
don't
have
to
duplicate
storage,
for
the
base
image
we'll
have
to
duplicate
the
build
and
all
those
things
on
the
end
systems
who
don't
have
to
have
that
carried
multiple
times
and,
and
it
kind
of
just
gives
a
nice
nice
way
of
managing
the
relationship
between
the
layers.
Instead
of
wanting
to
encapsulate
all
that,
and
it
also
kind
of
leads
back
to
the
microservice
architecture,
the
idea
that
each
container
should
do
one
thing
and
and
provide
only
as
much
functionalities
necessary
to
perform
that
one
thing.
So,
where
do
I
want
to.
B
We're
going
to
want
to
try
and
and
mirror
that
along
along
the
way
this
we
can
lose
there.
We
go
so
just
really
quick
dockerfile
for
those
who
aren't
familiar
the
first.
The
dockerfile
is,
is
kind
of
a
little
syntactic
sugar
on
top
of
a
shell
script,
there's
a
handful
of
directives
that
are
available
and
they
mean
different
things,
but
at
the
end
of
the
day
it
has
the
flexibility
of
a
shell
script.
B
You
can
do
all
kinds
of
things
to
what
becomes
your
container
image
should
be
run
stanzas
and
those
are
going
to
just
be
shell
commands
that
are
executed
within
the
context
of
a
layer
on
the
build.
So
the
first
line
is
from
and
that's
going
to
tell
your
image
where
to
build
from,
and
that's
going
to
say
that
is
going
to
be
my
base
image
that
I've
build
on
top
of
and
your
base
image
does
not
have
to
actually
be
a
base
operating
system
image
it
can
or
a
based
distribution
image.
B
It
can
be
another
layer,
so
you
can
build
on
top
of
those
layers.
So
this
one
just
started
directly
from
fedora
and
you
can
specify
maintainer.
So
something
goes
wrong.
Somebody
can
look
in
the
the
metadata
and
nowhere
report
issues
and
those
kind
of
things,
and
then
we
can
actually
run
as
part
of
the
build
process.
So
we
can
run
commands
that
will
perform
actions
and
the
the
items
in
all
caps
are
on
the
on
the
left
or
are
kind
of
defin
defined.
B
You
can
also
add
very
interesting
storage,
things
and,
and
there's
just
a
lot
of
there's
a
lot
that
you
can
accomplish
in
the
dockerfile
that
will
provide
a
very
nice
default
setup
and
deployment.
Also,
there
are
kind
of
wrapper
programs
on
the
ecosystem
that
we
use
labels,
so
you
can
apply
labels
they're,
wrappers
out
an
ecosystem
that
will
use
label
data
to
actually
perform
an
action.
When
you
run
that
container
in
certain
contexts
so
label
data
can
be
used
inside
of
OpenShift.
So
you
can
specify
certain
labels.
B
So
it's
very
flexible,
it's
very
powerful
usual
all
you
can
do,
but
the
main
thing
I
want
to
point
out
here
was
the
from
line
and
and
the
fact
that
all
these
things
will
run
inside
of
the
context
of
the
the
image
itself
that
will
I'm
sorry
yeah.
So
it
creates
a
an
instance
of
the
image
which
will
then
run
inside
of
the
container,
and
then
it
will
kind
of
be
safe
back.
B
B
So
this
is
Fedora
HPD
and
then
you
could
put
a
colon
and
then
some
tag
and
that
tag
is
kind
of
similar
to
I
get
tagged
for
anybody's
familiar
with
git
versioning.
However,
the
trick
there
is
that
it's
it's
common
practice
to
change
the
these
tags,
to
change
what
you
know,
what
hash
value
they
point
to
so
while
that
does
happen
sometimes
and
get
it's
generally
frowned
upon
here.
It's
it's
common
practice,
so
just
note
that
the
thing
that
attack
points
to
will
sometimes
change,
namely
the
latest.
B
Let's
move
on
to
release
engineering.
What
is
release
engineering
effectively?
It's
just
making
a
soft
production
pipeline
that
is,
reproducible,
auditable,
definable
and
deliverable,
and
just
as
a
note,
it
should
be
automated
to
the
best
of
possibility.
There's
a
very
nice
formal
ask
the
most
formal
definition.
I
was
able
to
find
five
for
aesthetic
from
Google
and
I
won't
read
that
you
get
a
little
bit
lengthy,
but
it's
it's.
B
It's
very
well,
very
well
defined
and
if
anybody's
interested,
please
feel
free
to
read
that
moving
on
openshift,
so
a
bunch
of
Commons
I
assume
everybody
here
is
familiar
with
openshift,
but
I
like
to
kind
of
just
run
through
this,
for
the
sake
of
making
sure
that
I've
covered
all
the
bases
of
the
things
that
will
go
into
our
boat
system.
So
for
those
who
are
not
familiar,
openshift
is
an
open
source
content
container
orchestration
platform
and
there
are
two
components
or
I
guess
two
main
pieces
of
the
project.
B
We
focus
directly
on
oppa,
the
origin
and,
and
we
have
participated
upstream
list
of
odd
origin,
as
well
as
with
their
installer,
the
osha
danceable
installer
for
various
things,
to
try
and
and
make
sure
that
we
can
enable
object.
Origin
on
fedora,
though,
of
this
diagram
I,
want
to
focus
directly
on
the
green
section,
most
literally
on
the
left
side.
I
guess,
second
from
the
bottom
to
build
automation.
B
This
is
the
piece
that
we're
really
interested
in
nope,
not
yet
sorry,
so
open
shift
has
a
concept
of
a
build
they're,
just
kind
of
this
primitive
type.
This
rest
api,
endpoint
for
a
build
and
and
what
that
is-
and
there
are
different
strategies
for
those
builds
and
one
of
those
strategy
types
is
custom.
So
for
what
we
do
in
fedora
for
layered
image
builds
dueling
is
we
provide
a
custom
build
strategy
such
as
we
can
define
how
we'll
run
what
it
will
run?
B
You
know
kinds
of
triggers
or
actions
that
it
will
respond
to
those
sorts
of
things
and,
what's
very,
very
powerful
about
this-
is
that
it
has
given
us
as
much
flexibility
as
we
ever
could
have
asked
for,
as
well
as
the
ability
do
very,
very
rapidly
scale
our
build
infrastructure.
So
once
this
is
all
set
up
at
the
point
in
which
we
decide,
we
need
more
capacity
thanks
to
the
open,
shipped
ansible
playbook
repository.
B
We
just
need
to
add
a
few
systems
to
our
inventory
file
and
re,
execute
our
our
ants
will
play
voc's,
and
then
it's
just
done,
but
what's
really
cool
is
actually
so
OS.
Bs
client
is
what
defines
that
build
a
strategy,
custom
type
and
it's
it's
effectively
a
a
template
for
that
build
combined
with
a
Python
API
that
lets
us
kind
of
tie
that
into
a
lot
of
other
things.
So
for
those
not
familiar
most
of
Fedor's
infrastructure
is
written
in
Python.
B
So
we
were
we're
very
grateful
to
have
have
those
kinds
of
things,
so
I'm
gonna
go
and
go
through
a
little
bit
and
then
we're
gonna
kind
of
round
back
to
that,
but
again,
because
this
is
the
ownership
commons
briefing
I
suspect.
Most
people
are
familiar
with
with
the
next
couple
of
slides,
but
we're
just
gonna
kind
of
run
through
them
quickly.
So
openshift
is
again
it
can
contain
our
orchestration
platform.
It's
built
on
top
of
kubernetes.
For
those
who
didn't
know,
the
mystery
has
been
unveiled
so
open,
shipped
participates
heavily
upstream.
B
What
goober,
Nettie's
kouhei's
is
the
bassist
OpenShift
adds
a
lot
of
functionality
on
top
of
it
for
build
pipelines.
Ci
integration,
application,
lifecycle
management
are
those
kinds
of
things,
but
at
its
at
it's
very
you,
know
very
broad
overview.
The
main
infrastructure
architecture
is
very
similar
because
of
the
fact
that
open
ship
is
built
on
kubernetes,
though
this
is
basically
the
breakdown.
You
have
a
client
to
talk
to
a
master
over
a
REST
API.
Then
the
master
has
a
schedule
that
talks
to
nodes
your
containers
run
inside
of
a
thing
called
pods.
B
B
So
as
a
bunch
of
advanced
features
and
in
the
build
component
is
what
we
are
directly
interested
in.
Also
very
nice,
REST
API
command
line
interface
ID
integrations
web
UI
admin
dashboard.
Those
kind
of
things
the
triggers
in
the
builds
are
very
interesting
to
us
because,
right
now
we
have
automated
rebuilds
happening
or
sorry
automated
rebuilds
are
being
written
upstream
and
we
are
going
to
use
a
combination
of
our
custom,
build
strategy
and
which
of
triggers
to
cause.
B
That's
happened
and
I'll
explain
a
little
bit
more
about
that
in
a
minute,
so
docker
layered
image,
build
service
is
built
using
a
handful
of
components,
so
open
ships,
origin,
which
we
just
covered
atomic
reactor
to
a
couple
in
a
minute,
Oh,
SBS,
client
API.
Again,
we
touch
briefly
but
we'll
talk
about
again
in
a
minute
and
then
a
registry,
some
registry
of
some
sort,
which
is
where
we
will
have
candid
images.
Stable,
updates.
B
Those
kind
of
things
in
Fodor's
implementation
will
actually
split
this
out
wave
two
registries,
but
the
USPS
command
line
is
how
you
would
then
talk
directly
to
OpenShift
a
again
because
of
those
python
api
is
and
and
with
our
specified
wrapper
around
this.
This
custom
build
type
I'm
sorry
discussing
build
strategy
gives
us
the
ability
to
then
provide
a
command
line
that
allows
end-users,
who
want
to
build
container
images.
A
very
focused
entry
point
into
into
the
what
has
effectively
become
a
build
system
by
by
using
these
different
pieces
together.
B
Atomic
reactor
is,
is
actually
a
tool
that
allows
you
to
build
and
pretty
sure,
okay,
so
those
be
at
first
and
then
alright,
sorry,
so
a
bunch
of
build
service.
So
this
is
where
we
take
advantage
of
the
old
shift
built
in
primitive
for
the
custom
strategy,
and
we
provide
our
template
of
buildconfig
that
thing
gets
populated
by
by
the
USPS
client.
We
lie
on
open
ship,
for
all
our
scheduling.
Build
tasks
is
what
I
saw
earlier
for
scalability
those
kind
of
things
whenever
we
want
to
expand.
B
It's
it's
quite
simple
that,
with
the
way
that
the
whole
system
has
been
built,
this
presents
us
with
a
defined
component
to
to
developers
and
builders.
The
USBs
itself
enforces
the
inputs,
so
this
rounds
back
a
little
bit
to
the
concept
of
release
engineering
and
why
we
built
the
system
this
way,
instead
of
just
kind
of
letting
it
be
the
Wild
West,
so
SPS
actually
does
input.
Sanitization
and
enforcement
and
fedoras
fedora
system
itself
is
even
a
little
bit
more
lockdown
than
the
upstream
LSPs
and
I'll
explain
the
whole
as
well.
B
But
we
can,
we
can
say
we're
the
git
repo
for
the
source
file
comes
in
the
gate,
commits
and
all
bills
are
centrally
log
and
then
the
build
route.
So
inside
of
OS
PS,
the
each
build
happens
on
top
of
a
build
repair
container
and
what's
what's
very
interesting
about
that
is,
that
is
where
atomic
reactor
runs
and
I'll
talk
about
Tomic
doctor
in
a
moment,
but
atomic
reactor
actually
performs
the
build
itself
and
atomic
reactor
has
plugins
and
and
how
it
has
a
lot
of
interesting
features.
B
But
inside
of
the
build
route,
where
the
build
actually
happens,
that
is
firewall
constrained,
we
can
have
unprivileged
container
runtime
with
excellence
enforcing
and
the
inputs
are
sanitized.
So,
in
the
event
that
somebody
was
to
try
to
I,
don't
know
curl
for
those
familiar
with
the
coral
command-line
utility
on
new
york-style
systems
allows
you
to
basically
just
grab
a
URL
and
whatever's
at
the
end
of
the
URL
and
in
a
common
paradigm.
That's
been
floating
around
for
a
bit.
B
Is
the
idea
that
you
should
just
curl
thumb
web,
the
URL
and
pipe
its
output
directly
to
a
shell,
and
just
do
that
as
root?
And
that's
your
install
process
and
that's
fine.
It's
it's
fast!
It's
easy
and
a
lot
of
people
have
have.
You
know,
had
great
success
with
that.
The
kicker
there
is
from
an
auditable
dual
chain
aspect:
that's
that's
not
an
attribute
we
desire,
because
what
happens
if
that
endpoint
disappears.
B
We
don't
really
have
a
good
understanding
of
what
those
things
it
did
unless
we
have
somehow
stored
their
install
process
script
and
whatever
artifacts
it
installs
somewhere
and
it
looks
like
cache
or
or
in
some
kind
of
an
archive
so
that
we
can
then
audit
later,
then
we
have
to
version
it
and
we
have
to
almost
try
and
police
the
Internet
and
that
just
gets
unwieldy.
So
for
a
lack
of
a
better
term,
we
have
kind
of
curated
content
such
that
it
has
been
deemed
okay
to
use,
and
we
have.
B
We
already
have
that
kind
of
audit
pipeline
that
that
trail
of
information
about
it
and
know
that
it's
been,
you
know,
direct
and
patched.
You
can
see
the
ease
and
all
those
those
kinds
of
things,
so
we
make
sure
that
all
inputs
are
vetted
so
from
there
open.
Shipped
image
streams
are
uses,
input
sources
for
the
builder.
So
when
the
image
streams
get
updated,
they're
automatically
pulled.
B
I'm
sorry
I'm
reading
a
comment
and
the
thing
oh
cool,
okay,
we
might
want.
Okay,
we
might
sorry
there's
a
comment
in
the
chat.
Somebody
said
that
they
don't
have
something
quite
as
automated
yet
but
yeah
migrating
somebody
for
the
plumbing
of
Mary
DB
active
in
Q
and
unison,
which
is
other
than
their
app,
but
could
be
interesting
to
kind
of
chat,
about
approaches
and
see.
If,
if
maybe
we
can
share
lessons
learned
and
offer
improvements,
one
another
okay,
so
from
there
utilizes
open
trip
triggers
to
spawn
rebuild
actions.
B
This
is
not
yet
in
production
it's
currently
being
developed,
but
we
have
the
ability
do
set
trigger
actions
inside
of
OS
vs
such
that,
if
a
layered
image,
so
let's
say
the
base
image
in
our
case,
would
be
fedora
and,
let's
say
for
25,
which
is
our
latest
stable
release.
If
we
did
a
update
to
put
our
25
s,
base
topper
image,
because
G
Lipsy
have
some
just
messy
security
vulnerability
and
we
had
to
then,
if
you
an
update
for
well
inside
of
us.
Yes,
it
would
notice.
Okay,
hey
the
base
image
was
updated.
B
Then
we
should
find
out
what
layered
images
use
that
as
a
from
field
and
then
rebuild
all
those
and
then
take
all
of
those
and
find
out
what
layered
images
require
those
and
rebuild
all
of
those.
So
in
on
the
back
end
of
the
system,
you
should
be
able
to
just
update
the
anywhere
anywhere
in
the
stack
of
layered
images,
and
it
will
just
cascade
rebuild
those
things
so
that
next
time,
when
your
end,
users
or
your
end
systems
go
to
pull
those
images
to
get
fully
updated,
fo
be
updated.
B
Stack
of
layered
layered
images
such
that
they're.
There,
then
their
container
instances
when
they're
running
are
all
all
completely
fashion,
updated
without
the
need
to
go
around
and
run
DNF
update
all
over
the
place
because
effectively
that
that
gets
done
inside
of
the
system
so
atomic
reactor,
so
atomic
reactor
I
kind
of
alluded
to
slightly.
But
it
is,
it
is
very
powerful
single
pass
talker
build
tool
and
it
automates
all
kinds
of
things.
I
have
a
short
list
here.
B
It
does
much
more
than
SP
series
to
kind
of
kind
of
big-ticket
items
for
what
doors
using
it,
for
it
allows
you
to
push
images
to
register
when
successfully
built.
You
can
inject
yum
Edenic
repositories
inside
the
docker
file.
So
if,
for
any
reason
you
need
a
customer
posit
ori
that
will
provide
the
the
the
information
it's
looking
for
so
for
fedoras
contacts.
This
is
an
internal
local
mirror
of
all
of
the
doors
repos
where,
as
external
users,
don't
necessarily
need
that.
B
But
it's
it's
the
exact
same
content,
that's
available
on
the
public
mirrors,
but
this
is
a
system
that
is
inside
the
protected
network,
and
you
know
the
highly
auto
dated
environment
that
the
builds
actually
take
place
in
that
needs
to
be
exposed
into
the
docker
file
some
way
into
the
build
environment,
but
without
the
need
for
maintained,
dr.
files
to
actually
have
to
supply
that
information
and
then
figure
out
a
way
to
remove
those
those
repositories
at
the
end
of
their
build
process.
Those
kind
of
things
we
can
then
change
the
oh.
B
We
can
also,
in
similar
fashion
change
the
base
image
from
in
your
doctor,
file
to
whatever
and
and
the
idea
there
again
is
with
internal
registries.
We
can
then
allow
people
to
keep
public
public-facing
registries
has
their
from
there
from
stanza,
and
then
all
that
happens.
Basically,
the
the
baseline
URL
is
is
replaced
on
the
internal,
so
you
can
say
from
fedora
or
from
registry
tap
for
project
org,
splash
fedora
and
then
the
internal
registry
inside
the
build
system.
It's
actually
replaced
substituted
and
it's
all
the
same
because
we
have.
B
We
have
checked
some
validation
all
the
way
through.
So
we
can.
We
can
verify
that
we
are.
We
were
using
the
right,
the
right
images
that
are
also
available
externally
Match
registry
available
inside
that
isolated,
build
root,
run
simple,
that's
not
supposed
to
be
a
new
bullet
point
and
run
simple
tests
after
an
image
built.
So
in
the
event
that
you
know
an
image
is
built,
we
can
actually
run
tests
internally
with
atomic
reactor
and
then
also
there's
a
lot
of
plugins
available.
B
The
templated
build
specification
for
our
our
openshift,
build
a
custom,
build
strategy
and
there's
documentation
on
how
to
customize
that,
if
you
want
to
add
a
new
plugin,
you
can
add
a
new
plugin
and
just
change
the
config
for
like
site,
specific
and
implementations
of
this,
without
the
need
to
actually
modify
the
global
configuration
on
kind
of
things,
and
so
we
can
do
gating
of
updates
as
well.
This
isn't
an
attribute
of
a
atomic
reactor
there's
an
attribute
of
SBS.
So
when
builds
are
done,
they
land
in
effectively
a
candidate
registry
or
a
candidate
tag.
B
You
can
do
either
it's
just
a
configuration
option.
You
just
kind
of
tell
the
system
if
you
want
to
have
a
tagging
strategy
or
if
you
have
different
registry.
So
when
the
builder
done
they
land
in
candidate
registry
and
then
you
can,
at
your
discretion,
tag
and
move
images
around
between
different
registries,
so
Fedora's
implementation
a
little
bit
more
complicated.
But
that
is
because
we,
we
add
in
a
lot
of
different
systems,
and
this
is
actually
a
somewhat
stripped-down
version
in
at
the
end
of
my
presentation.
B
B
This
will
seem
very
natural
and
in
the
RPM
standpoint,
this
kit
is
where
you
put
your
spec
file
in
your
patches
and
then
your
checksum
reference
to
the
the
source
code
that
you
use
and
the
source
code
is
uploaded
to
looks
like
cash
and
then
reference
inside
of
the
build
system
and
to
build
an
RPM.
You
would
issue
the
command
fed
package
build
well
in
the
instance
of
containers.
We
will
have
our
docker
file
inside
of
disk.
B
It
will
have
our
service
and
it
scripts
those
kind
of
things
tests
documentation,
and
then
we
will
do
a
fed
package
container
build
and
much
like
RPM
builds
happening
code.
The
container
builds
will
then
happen
in
Kochi.
It's
with
the
exception.
That
container
builds
technically
don't
happen
in
Kochi
there's
a
functionality
in
Kochi
called
content
generators,
and
that
means
that
any
external
system
can
actually
generate
the
actual
content.
B
So
we
will
do
our
builds
via
Kodi
coachable
and
scheduled
them
in
OS
PS,
o
SBS
will
do
the
build
and
you'll
notice.
Two
arrows
going
up
out
of
us.
Ps
to
the
registry.
Andy
Koji
Koji
will
store
the
single
file,
representation,
flattened
version
of
that
image.
Os
PS
will
also
upload
the
resulting
image
to
our
registry
implementation
and,
like
I
mentioned
before,
Fodor
has
two
registries.
We
have
registry
of
flora.
Project
org
and
candidate
registry
got
further
project
that
org
both
of
them
are
publicly
available.
B
It's
just
that
the
candidate
image
candidate
registry
is
where
images
land
as
soon
as
we're
done
building,
so
they
can
immediately
be
tested,
and
we
will
be
downloadable
by
the
the
broader
community.
They
want
to
participate
in
the
testing
and
then
once
validated
they
are
moved
over
to
the
stable
and
we'll
release
them.
B
So
just
get
so
distro
get.
Each
branch
is
a
fedora
release,
also
in
the
future.
That
will
be
known
as
for
a
generational
core,
as
we
move
towards
the
flora,
modular
modularity
project
and
and
that
kind
of
grand
vision
of
breaking
the
outbreak
system
down
is
something
modular
and
and
also
to
note,
modules
will
be
distributed
in
in
multiple
ways.
B
One
of
those
ways
will
actually
be
container
images,
so
this
system
will
be
used
to
produce
those
things
that
will
kind
of
become
core
building
blocks
of
the
next
generation
of
fedora,
so
fed
package
for
packaging.
Maintainer
helper
tool
managed
to
disc
it
branches
and
shaped
bills.
Those
kinds
of
things
Kouji,
so
I
mentioned
before
coaches,
authoritative,
build
system
live
use.
The
images
DVD
ISO
is
everything
everything
is
built
in
here
and
then
now
we're
now
we're
adding
the
container
builds.
B
A
Right,
the
I'm
not
seeing
any
real
questions
in
the
chat
room
here.
Folks,
if
you
would
like
I,
will
unmute
you
all
and
you
have
a
question
you
can
come
on
and
meet
yourself
and
do
that
so
I'm
thinking
maybe
run
through
your
there's.
My
goodness,
could
you
have
more
references?
I,
don't
think
so.
You.
B
B
A
B
Okay,
that
was
my
follow-up
question
is
how
its
font
size,
because
it
is,
it,
is
very
large
on
on
my
screen.
I
was
hoping
to
be
good
enough
for
folks
on
the
video
okay.
So
if
you
notice
my
my
current
path,
it's
in
my
my
home
directory
I
have
I'm
a
layout
for
flight
package,
because
v
package
is
now
namespace.
So
so,
if
I'm
sorry
biscuit
is
now
namespace
but
I
executed,
it
I
probably
should
name
the
directory
disk
and
I
think
about
it.
Anyways.
B
B
B
Okay,
that
our
pre-staged
okay,
so
in
here
you
will
find
we
have
our
atomic
install
atomic
run
atomic
uninstall,
and
these
are
just
small
scripts
that
do
things
for
the
atomic
command
for
like
I
mentioned
before.
It
is
a
wrapper
and
there's
also
a
docker
file.
So
if
we
just
go
ahead
and
look
at
the
doctor
file
or
any
editor
of
your
choosing,
I
use
whatever
you
find
productive
and
there's
a
handful
things,
you'll
notice
here.
B
First
off,
we
have
our
bugs
little
component
because
we
need
to
know
where
to
find
this
thing
in
Bugzilla,
and
we
have
our
name
so
you'll
know
something
about
the
name:
there's
F
G
C,
and
that
is
fedora
generational
core,
and
that
is
also
so
that
is
actually
inherited
from
the
parent
image.
So
this
is
something
that
we
have
in
our
Sidora
guidelines
for
container
images,
and
that
is
how
we
namespace
those
things
in
our
registry
and
then
also
we'll
provide
context
for
what
the
base
underlying
Fedora
generation
or
Fedora
release
that
you
know
this.
B
This
correlates
to
then
we
have
our
version,
which
is
then
pulled
from
that
environment
variable
our
release,
which
is
you
know,
half
pulled
from
the
release
environment
variable
and
then
the
other
half
of
the
disk
tag.
Again.
This
tag
is
inherited
by
the
base
image
and
for
those
familiar
with
building
rpms.
This
is
the
same
idea.
B
It's
just
that
docker
does
not
have
a
mechanism
similar
to
rpm
macros,
so
we
kind
of
just
gonna
move
things
around
and
implement
it
with
environment
variables
and
then
apply
it
to
label
so
that
it's
it's
persistent
with
with
the
metadata
that
docker
carries
around
with
the
with
the
image
in
the
end,
because
we
can
then
use
that.
So
you
will
see
here,
we
have
you
know
some.
B
So
we
are
going
to
as
that's
involved
in
for
our
project,
we're
going
to
develop
guidelines
around
adding
functionality
for
both
the
atomic
replicas
and
as
well
as
as
well
as
open
shift,
because
from
the
standpoint
of
enabling
containers
on
the
system,
atomic
install
is
the
direction
I
go,
but
from
enabling
containers
in
a
scaled
environment.
Openshift
is,
is
kind
of
the
the
direction
that
fedora
as
a
project
is
going
as,
as
you
know,
a
fellow
open
source
project
that
that
we
are
working
as
much
as
we
can
with
upstream.
B
So
we'll
see
a
little
bit
more
of
that
unfold
as
we
move
forward,
but
those
those
labels
are
able
to
actually
kind
of
coincide
with
one
another,
because
there's
no
name
conflicts
or
anything
on
that
which
is
just
all
in
the
stride
we
gotta
gotta,
get
it
get
it
done
as
we're
able
to
so
anyways.
So
we
can
make
edits
to
this
and
then,
let's
just
bump
it
a
little
bit,
and
then
we
could
do
with
that
package.
Commit.
B
This
will
schedule
it
out
there,
and
this
will
take
anywhere
from
two
to
five
minutes
to
run
depending
on
how
intensive
the
task
it's
doing.
However,
already
did
one
appear
just
so
that
I
already
would
have
it
done
so
I
ran
the
full
package
container,
build
it
created
this
task
that
we
watched
it
and
then,
in
the
end,
we
popped
out
with
a
Koji
build
metadata
import,
as
well
as
a
set
of
repositories
that
can
be
accessed
from
and
you'll
notice.
There's
there's
many
and
the
reason
for
that
is.
B
We
want
to
allow
users
to
have
as
much
granularity
as
they
want.
So
the
first
one
is
unique
identifier
and
that
is
purely
used
in
the
sense
of
iterative
testing
for
for
every
single
build
and
not
necessarily
builds
that
could
be
candidates
for
release,
but
every
single
build.
So
we
have
an
idea
inside
the
the
system
called
a
scratch
build
and
it's
effectively
a
throwaway
build,
doesn't
need
an
actual
version
applied
to
it,
but
we
need
to
build
in
so
we
can
test
it.
It
will
only
be
given.
B
It
will
only
be
given
this,
this
label
I'm
sorry,
this
tag
in
the
repository
and
it
will
not
receive
any
of
the
other
ones
this
one
here
and
all
of
these
are
live,
I
mean.
If
anybody
cares
to
type
this
out
and
your
command
line,
you
can
you
can
go
ahead
and
dock
or
pull
these
these
images
now
and
play
with
them.
B
So
then
we
have
the
full
version
release
and
this
tag
identifier,
and
that
is
for
testing
the
actual
release
candidate
builds.
We
want
to
make
sure
identify
them
all
the
way
down
to
release
number
those
kind
of
things,
and
then
we
have
major
release:
identifiers,
I'm,
sorry,
major
version
identifier
without
the
release.
So
if
somebody
out
in
the
ecosystem
just
cares
about
what
you
know,
release
version
or
I'm,
sorry
version
number
125.
B
But
it's
not
concerned
with
what
lease
of
that
so
doesn't
they're
not
really
worried
about
whatever
patch
level
it's
on,
but
they
want
the
latest
of
that
version,
no
matter
what,
then
they
can
reference
reference
that
and
then
the
latest
is
just
the
default.
You
want.
The
latest
version
release
of
whatever
this
component
is.
That
is
being
distributed
as
a
as
a
document,
so
we
will,
you
know,
for
grins,
just
go
ahead
and
do.
B
B
Okay,
free
fox
time,
so
one
thing
I
said
I
mentioned
with
Proctor
project
is
it
is
a
it's
a
very
pleasant
web
UI
that
gives
you
all
forward
all
kinds
of
fun
functionality
and
nice
graphs
and
metrics,
and
things
to
interact
with
your
your
Linux
systems.
It
can
manage
containers,
it
can
manage
system,
storage,
command,
container
storage-
you
can
actually
interact
with
networking
and
I
think
can
actually
do
application,
skilled
application
deployment
on
both
kubernetes
and
OpenShift
for
those
kinds
of
things.
B
B
What's
looking
yeah,
we
should
get
that
cool,
so
this
is
for
the
results
system,
koji,
defer
protocol
or,
if
anybody's,
not
familiar,
really
quick,
you
could
do
to
do
there.
We
go
so
stay
close
build
container.
So
this
is
the
parent
task
and
the
reason
that
there's
a
parent
and
child
task,
because
right
now
today
we're
only
targeting
x86
64
processor
architecture,
because
that
is
primarily
what
upstream,
docker
and
most
OCI
compliant
runtimes
target
directly.
However,
we
do
produce
alternative
architecture
base
images
in
fedora.
B
We
will
later
be
adding
more
architecture
more
architectures
to
to
this
as
well,
namely
PowerPC
and
ARM
arm,
both
32-bit
arm
v7
and
arm
aar
64.
So
that's
that's
something
that
we
aim
to
target
there,
so
each
build
will
actually
happen
on
on
all
supported
architectures
later
in
life,
and
that's
why
there's
parent
and
then
filed?
B
Okay,
so
we'll
go
ahead
and
oh
really,
quick,
show
results.
This
is
what
we
saw.
There
are
a
list
of
repositories
and
that
kind
of
thing
so
we'll
go
ahead
and
go
into
the
create
container,
and
this
will
again
give
us
our
results
repositories.
Those
kind
of
thing
task
ID,
but
the
incremental
log
and
the
reason
it's
title
incremental
is
it
is
actually
updated.
Incrementally
you
can
tail
it
in
the
web,
browser
and
it'll
kind
of
scroll
and
offset
those
kinds
of
things.
B
But
this
is
the
the
log
file
and
it's
very
verbose
and
it's
very
verbose
on
purpose
and
so
I'll
just
kind
of
slowly
scroll
through
here
and
I.
Don't
expect
anybody
on
the
video
to
either
understand
what
the
log
file
is
telling
you
or
necessarily
be
able
to
read
it,
because
it's
a
lot
of
text,
it's
scrolling
relatively
quickly,
but
the
idea
is
just
that.
We
have
a
lot
of
information
and
we'll
notice
here.
This
is
our
doctor
file
that
we
saw
earlier,
except
here
we
have
the
SHA
'some.
B
So,
like
I
said
earlier
in
the
presentation
that
we
actually
do
check
some
verification
during
the
build.
That's
what's
being
done
here,
so
we're
doing
checksum
verifications
that
I'm
just
pulling
from
some
arbitrary
named
URL,
and
then
here
you
see
it's
actually
doing
the
install
portion.
The
you
know
this
here
should
be
pretty
familiar
for
anybody.
Who's
done
a
young
install
or
a
DNF
install
package
on
the
RPM
based
system,
and
then
all
the
the
plugins
down
here
run
and
it's
doing
fun,
stuff,
okay,
so
very
verbose,
logging
incremental
logs,
though
something
goes
wrong.
B
B
So
technically,
this
doesn't
have
rpms,
because
it's
our
archive
or
it's
artifact-
that
comes
out
as
a
tarball,
but
we
can
actually
go
into
the
info
of
this
tar
ball
and
that
tar
block.
So
if
you
download
it,
you
can
do
a
docker
import
and
it
will
give
you
a
resulting
image,
but
the
name
of
the
image
will
be
with
what
the
checksum
on
it.
So
this
this
is
all
the
information
about
it.
So
this
is
all
kinds
of
information
about
the
layers
involved.
There
checksums
the
get
URL
that
it
came
from
to
get
hash.
B
B
So
right
now
today,
the
only
things
that
Fedora
allows
into
container
images
are
rpms.
We
hope
to
expand
that
later,
but
we
need
to
find
a
good
way
to
curate
all
sorts
of
other
content.
You
know
rubygems
PIP,
installs,
decals
pairs,
nodejs
NPM
everything,
and
we
just
need
to
find
a
good
way
to
kind
of
curate
that
content.
So
we
can.
We
have
a
trusted
verified
source
of
those
things,
instead
of
just
kind
of
opening
the
floodgates
to
the
Internet,
but
we
have
this
manifest,
so
we
can
go
through
this
manifest
and
you'll
see.
B
This
is
one
through
fifty
one
hundred
seventy
eight.
So
there
178
rpms
installed
in
that
image
and
what's
great
about
this,
is
it
allows
us
the
ability
to
go
back
and
if
we
need
to,
we
can
recreate
our
pilot
or
even
just
these
packages
and
rebuild
this
image
from
the
checksums
in
the
previous
pages
metadata
and
reproduce
the
exact
same
image
such
that
we
can
verify
and
audit
everything
that
goes
into
it
in
the
event
that
we
ever
needed
to.
And
that,
in
a
nutshell,
is
the
demo.
A
A
For
those
of
you
are
listening,
I'll
grab
the
slides
from
him
and
post
this
in
blog
that
openshift
comm,
shortly,
probably
not
until
after
the
Christmas
shut
down
and
break
holiday
thing
that
we
do
here
at
Red,
Hat
we'll
be
back
the
first
week
of
January
and
I.
Think
that's
when
our
our
blog
web
editor
will
have
this
up
and
running,
but
I'll
make
the
the
video
available
to
you
guys
privately
in
case.
You
want
to
review
this
over
your
holiday
break,
because
you
know
it
is
the
night
before
Christmas
kind
of
reading
here.
A
So
thank
you
so
much
Adam
for
for
doing
this
today,
I'm
looking
forward
to
seeing
some
discussion
about
how
other
people
are
implementing
their
build
services
and
seeing
if
we
can
learn
from
each
other
and
make
some
best
practices
around
this,
and
maybe
even
have
them
reuse
some
of
the
work
or
just
use
the
work
that
you
guys
are
doing
in
Fedora
lab.
So
thanks
again-
and
we
really
appreciate
you
taking
the
time
today-
you
have
a
great
holiday,
absolutely.