►
From YouTube: OpenShift Commons Image Builder SIG #4 : Fedora Container Build Service and Fedora Cloud explained
Description
Adam Miller, (aka @Maxamillion) Senior Software Engineer at Red Hat is the Fedora Release Manager and leading the charge on the Fedora Container Build Service. He is going to give us an walk-thru and overview of the Fedora Container Build Service and a intro to the Fedora Cloud initiative. Special Guest appearance from Matthew Millar, Fedora Community Lead.
We are planning on bi-monthly meetings depending on the group’s schedules and interests.
For the latest information on OpenShift 3.1 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally.
The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
A
What
I'd
like
to
ask
is
that
if
you
have
questions,
ask
them
in
the
chat
on
let's
Adam
and
Matthew
get
through
this
presentation
in
the
top,
and
then
we
can
have
a
conversation
afterwards
since
we're
recording
this
for
posterity.
It
will
be
posted
up
rather
quickly
on
our
YouTube
channel
and
you
can
find
more
information
at
the
baggage
of
Commons
on
site,
46
comments
at
openshift
or
FC,
and
you
look
for
interests
in
the
menu
and
you
can
put
whatever
you're
interested
in
whether
it's
image
builders
operations,
education
and
perhaps
propose
another
state.
B
So
for
starters,
what
is
Fedora
cloud
so
once
upon
a
time
Fedora
as
a
distribution
kind
of
had
one
thing
we
had
one
deliverable
that
we
we
created
a
single
iso,
installer
I
was
a
date
just
giant
hulking
DVD
that
had
all
kinds
of
configurable
options
in
those
kind
of
thing
and
as
part
of
so
actually
matt
miller.
Who
is
on
a
call?
Who
is
the
photo
project
leader
that
I
pulled?
It
probably
should
have
taken
one
with
the
introduced,
but
so
let's
do
that
now
Matt.
C
I,
don't
even
know
what
I
all
the
things
I
do
are,
but
yeah
I
am
the
project
leader
and
I.
Guess
the
main
thing
I
do
is
try
and
build
community
consensus
around
what
we're
doing
and
where
we're
going
and
then
try
and
keep
everybody
on
the
same
page
about
all
that.
So
this
was
definitely
one
of
the
things
that
came
up
as
I
additions,
idea
where
I
tried
to
to
help
Shepherd
the
project
into
an
ex
the
next
generation
of
where
we
want
to
be
for
fedora
for
the
future.
B
Right,
so
that's
kind
of
what
brings
us
to
this
is
there
was
an
initiative
to
create
three
editions:
there's
workstation
server
and
cloud
and
fedora
cloud
is
one
of
the
additions
and
it
targets
cloud
infrastructures
and
that's
a
little
bit
vague
on
purpose,
because
there
are
multiple
kinds
of
cloud
infrastructures,
there's
infrastructure,
service
platforms
of
service
and
then
soft.
It's
a
service.
B
So
what
we
produce
is
an
addition
and
it's
a
image
that
can
be
run
in
different
environments
as
well
as
the
basis
for
the
platform
to
actually
spin
up
clouds,
and
the
cloud
working
group
is
a
subset
of
the
foot
or
community
that
works
to
deliver
the
cloud
technologies
and
those
kind
of
things,
and
there
are
two
relative
links.
One
is
actually
where
to
get
the
cloud
content
and
that
will
include
you
know
being
able
to
spin
it
up
on
infectious
service
environments
like
Amazon,
as
well
as
download
images
to
import
into.
B
If
you
have
an
on-premise,
those
kind
of
things
and
then
the
Fedora
project
of
our
wiki
page,
you
see
there
is
actually
about
the
cloud
working
group.
What
we
do
when
we
meet
things
that
were
current
initiatives,
were
working
on
and
kind
of
what
we're
doing
in
that
realm.
So
one
of
these,
the
pretty
hot
topics
in
in
the
world
of
cloud
right
now
is
containers
and
kind
of
a
front-runner
and
in
that
world
is
probably
almost
unanimously
going
to
be
docker.
B
So
one
of
the
things
that
we're
focusing
on
right
now
and
we're
release
engineering
and
cloud
kind
of
intersect
is
delivering
a
platform
upon
which
the
door
contributors
can
build
and
maintain
docker
images
and
of
reproducible
and
auditable
fashion,
and
what
that
means
is.
If
you
provide
the
same
set
of
inputs,
we
should
be
able
to
prove
that
we
have
the
same
set
of
outputs,
and
this
for
various
reasons
in
release.
B
Engineering
is
very
desirable
and
it's
something
that
we
are
working
to
do
and
the
solutions
in
place
and
I'll
kind
of
go
through
it
in
a
demo.
But
one
of
the
main
goals
that
we
had
was
to
keep
the
process
very
similar
to
how
the
door
contributors
today
create
and
maintain
rpms
in
the
history
of
the
project.
The
primary
build
artifact
that
came
out
of
our
build
system
was
our
pm's.
B
We
didn't
have
anything
else
and
as
we
move
forward
or
trying
to
make
the
build
system-
and
our
process
is
more
more
modular
nature
more
flexible
to
allow
us
to
deliver
new
things
in
the
future.
So
today
we're
working
on
docker.
You
know
next
up
we're
probably
going
to
be
working
on
other
container
technologies,
as
well
as
new
application
technologies
such
as
flat
pack
for
those
familiar
with
that
project.
B
So
we
just
kind
of
want
to
move
into
the
world,
and
this
also
again
kind
of
goes
back
to
the
Fedora
that
next
initiative
that
talks
about
trying
to
make
components,
the
operating
system
more
flexible
and
allowing
certain
components
to
exist
in
different
life
cycles
and
those
kinds
of
things.
So
we
want
to
kind
of
kick
start
that
here
the
Fedora
dr.,
Laird
image,
build
service
and
I'm,
probably
just
going
to
call
it
the
image
build
service,
it's
not
the
most
inventive
of
names,
but
it's
district'
descriptive.
So
he's
me
drinking
coffee.
B
It's
a
build
system
that
will
automatically
rebuild
layer,
it
images
and
what's
important
about
that,
is
actually
first
define
what
a
layered
images.
So
in
dr.
space,
there
are
two
kinds
of
images:
there's
a
base
image
and
there's
a
layered
image
and
the
base
image
is
created
from
kind
of
a
special
directive
cult
from
scratch,
and
you
simply
build
the
base
image
effectively
natura
and
provide
a
root
filesystem
to
dr.
such
that.
It
can
then
use
that
as
the
basis
for
other
containers.
B
Well,
these
layered
images
need
to
be
maintained
in
some
way
and
that's
what
this
build
system
and
as
well
as
the
pipeline
in
general,
like
there's
a
lot
of
components
and
I'll
show
that
in
a
moment
how
they
all
tie
together
and
everything
that's
going
on
this
automatic
rebuild
is
if
something
the
base
layer
changes.
So,
let's
say:
there's
a
G
lipsy
update
or
some
security
vulnerability
somewhere
in
the
stack
of
dependencies
that
one
of
the
layered
images
relies
upon.
B
Delay
ER
that
is
dependent
upon
and
then
all
dependent
layers
will
be
rebuilt
automatically
by
the
system,
such
that
the
next
time,
somebody
on
the
Fedora
community
or
do
a
dr.
pol
on
the
image
that
they
were
using.
They
would
get
this
new,
updated
new,
updated
layered
image
and
the
the
big
goal
behind
that
and
actually
open
shift.
B
So
the
next
thing
is
the
build
components
built
on
top
of
open
shift
v3
and
the
reason
that
we
were
we
use
open
ship
III
is
the
concept
of
the
image
streams
allowed
for
creating
this
dependency
graph,
as
well
as
the
relationship
to
define
when
things
need
to
be
rebuild
it
beyond
that.
You
know
open
shift
in
general,
with
with
the
custom,
build
types.
B
Allow
us
to
have
a
lot
of
flexibility
in
what
we
can
actually
do,
and
we
created
it
on
top
of
should
be
three
and
then
tied
it
into
all
the
Fedora
infrastructure,
again
going
back
to
maintain
the
consistency.
So
this
is
the
architecture
and
I
know
it's
it's
kind
of
a
lot
going
on
and
I
will
try
my
best
to
distill
it
down
to
something
is
consumable
so
on
the
far
right.
B
There
is
a
box
that
says
Fedora
layer,
2
image
maintain
errs
so
in
the
world
of
Fedora
right
now,
they're
fodor,
RPM
maintained,
errs
and
often
called
package
maintain
errs
in
the
future.
There's
going
to
be
different
kinds
of
maintainer
for
different
kinds
of
artifacts,
rpms
being
one
of
them.
Now
with
layered
images,
we
will
have
layered
image
maintain
and
these
will
be
the
people
that
will
maintain
things
like
the
dockerfile,
the
apt,
the
application
in
initialization
scripts,
any
kinds
of
documentation,
as
well
as
tests
that
are
needed.
B
B
So
you
will
see
in
the
demo
when
I,
when
I
kind
of
work
through
this
you'll
see
there's
an
F
24
branch
which
will
specify
the
door
24,
and
we
can
this
way
gate
different
versions
and
different
modifications
for
new
features
or
new
enabled
components
in
newer
versions
as
well
as
allow
for
keeping
you
know,
sanity
between
releases
in
a
traditional
rpm
sense.
This
would
be
where
you'd
have
your
spec
file
and
your
source
listings
as
well
as
your
patches,
and
you
would
commit
them
to
get.
B
You
can
do
so
much
like
you
do
in
your
general
get,
but
there's
also
a
command-line
tool.
That's
a
helper
that
assists
and
things
so
for
likes,
which
branch
you
can
display.
What
branches
are
available
to
see?
How
many
versions
of
the
douro,
the
item
that
you're
working
with
supports
and
that
command
line
tool
is
called,
fed,
PKG
or
fed
package?
If
you
follow
the
arrow
from
this
box
that
we're
looking
at
you
can
see,
fed
package
container
build
and
container
build.
Is
the
directive
that
tells
fed
package
that
this
is
a
container.
B
It
is
a
layered
image
build
and
it
needs
to
be
handled
as
such,
whereas
if
you
were
to
be
building
and
RPM
it
would
just
do
it
would
just
be
a
Fed
package
build
and
one
thing
to
quickly
note
about
disk.
It
is
our
get
layout.
We
actually
had
to
modify
the
gate
layout
as
add
functionality
into
fed
package
to
handle
the
difference
between
layered
images
and
RPM
files,
and
mostly
just
because
in
the
past
there
were
only
RPM.
The
only
thing
you
ever
had
to
deal
with
was
our
p.m.
B
who
is
the
only
artifact
that
we
delivered.
So
we
now
have
what's
what
we
are
just
calling
name
spaces
where
name
spacing
disk
it
such
that
it
correlates
to
the
artifact
that
we're
delivering
so
rpms
is
now
a
namespace
and
it
is
the
default
namespace.
If
you
don't
specify
that
is
the
default
and
that
it,
the
reason
is,
is
for
backwards
compatibility
and
then
we've
also
added
docker.
B
So
the
Fed
package
container
build
command,
will
then
kick
off
to
the
next.
It
will
kind
of
follow
the
line
to
the
next
box,
and
this
is
koji.
Koji
is
fodor's
build
system.
The
build
system
is
what
has
been
used
forever
to
build
rpms
to
build
our
live
images
to
build
our
ISO
DVD
installers.
All
of
our
cloud
images,
the
Q
mu
raw
q,
cow
to
those
kinds
of
things
and
Koji
depends
on
a
lot
of
other
technologies
to
kind
of
satisfy
all
these
different
things.
B
It's
not
an
all-encompassing,
do
everything,
but
it's
it's
the
control
point.
It
has
the
database
back-end
that
stores
all
of
the
information,
and
it
maintains
metadata
about
the
distribution
such
that
we
can
produce
like
things
like
yum
repositories
directly
out
of
the
contents
have
been
built
inside
of
it.
So
this
is
where
the
container
built
plug-in
is
installed,
and
this
is
where
we'll
do
we
will,
instead
of
actually
doing
the
builds,
we
offload
it
and
we
then
we
also
do
rpm
built
there.
B
I
just
realized
that
I'm
missing
an
arrow
directly
from
Koji
down
20
SB
s
and
I
apologize
for
that,
but
in
the
bottom.
For
me,
in
the
bottom,
you
see
a
box
called
OSP
s,
and
this
is
the
open
shift
build
system,
and
that
is
an
upstream
project
that
is
actually
OS.
It's
been
renamed
to
SBS
client,
mostly
because
it's
more
accurately
representing
what's
happening.
Open
shift
is
the
build
system.
Open
shift
provides
all
the
primitives
that
are
required.
B
B
These
be
isolated
from
things
like
the
internet,
so
we
have
to
be
able
to
specify
specifically
what
content
sources
it
can
access
in.
The
main
reason
for
this
is
let's
say
that
somebody
wanted
to
put
in
their
dockerfile
a
curl
pipe
to
grip
from
somewhere
in
the
internet
that
doesn't
install
some
software
now.
B
This
might
not
be
malicious
in
nature,
but
it
does
remove
the
ability
to
audit
or
reproduce,
because
that
thing
on
the
internet
could
disappear
or
what
results
from
that
thing
in
the
internet
will
change
or
it
could
be
malicious
and
intent
and
people
are
injecting
you
know
so
much.
Somebody
has
decided
to
inject
some
now
some
bad
payload
into
the
image
that
would
then
color
our
users
issues
so
from
there.
Oh
SBS
interacts
with
our
registry
and
for
those
who've
used
docker.
This
should
be
very
commonplace
in
terms
of
something
you
interact
with.
B
Most
people
interact
directly
with
the
docker
hub,
which
is
probably
the
largest,
the
most
popular
doctor
registry
in
the
world.
But
what
we're
going
to
do
is
have
a
fedora
host
registry
and
there's
actually
going
to
be
a
couple
of
them.
There
will
be
the
intermediate
build
registry,
and
then
there
will
be
production
registry
and
enter-
field.
Red-Billed
registry
is
where
all
the
build
will
land.
B
So
if
somebody
wanted
to
pull
a
build
that
has
just
been
created
so
that
they
can
test
some
feature,
they
are
absolutely
able
to
do
that
as
soon
as
the
build
lands
they
pull
that
down
and
run
their
tests
on
it.
This
also
allows
for
our
automated
CI
to
do
the
same
thing
to
pull
that
image
as
soon
as
it
was
created
and
any
performed
tests
on
it
and
then
the
production.
B
What
we're
planning
to
do
in
the
425
cycle
is
actually
have
every
two
weeks
do
production
releases
of
all
currently
available,
layered
image
builds
and
that
will
be
based
on
automated
testing.
So
for
all
of
the
images
that
have
passed
out,
man
testing,
they
will
get
a
release,
they
will
have
a
new
update,
push
to
that
production
registry
and
people
can
pull
that
from
registry
Ecuador
project
org,
which
doesn't
exist
today.
That
is
that
it's
in
the
works.
B
B
So
another
thing
to
note
is
when
we
push
to
registry
out
for
public
adored,
for
the
production
registry
will
also
be
mirroring,
that
content
up
to
the
docker
hub,
so
that
people
who
are
just
used
to
using
the
hub
or
maybe
aren't
using
fedora
directly
and
don't
know
about
specifically
our
registry
and
those
are
the
things
and
they
found
Fedora
through
doing
a
search
on
the
hub.
We
want
to
make
sure
that
they're
also
getting
the
latest
content
and
that
any
very,
very
large
nutshell
is
the
layered
image
build
service
so
dem
on
time.
B
For
those
not
familiar,
cockpit
is
a
web
interface
admin
portal
for
linux
servers
and
it
can
do
multi-node
multi
hose
it
can
manage
clusters,
it
can
do
Coover
Nettie's.
It
can
manage
to
offer
all
kinds
really
interesting
things
and
when
what's
injuring
about
it
beyond,
that
is
that
it
by
default,
can
run
out
of
a
docker
image
itself.
So
this
will
be
something
that
we
are
going
to
deliver
as
a
layered
image,
build.
B
Initially
so
what
we
showed
earlier
was
that
we
have
this
thing
called
disk
it,
and
this
is
what
I'm
looking
at
here.
This
is
actually
a
git
repository
that
has
so,
let's
do
a
bed
package
which
branch
we
have
different
branches,
so
we
have
the
door
24
and
master
and
master
is
raw.
Hi,
fedora
24
is
branched
and
it
actually
looks
like
somebody.
So
it's
nothing
else
to
note
as
I'm
actually
working
in
stage.
This
is
not
in
production.
Yet
so
fedora
infrastructure
has
a
staging
environment
in
a
production
environment.
B
We
kind
of
fiddle
an
experiment.
In
stage
it
looks
like
somebody's
messing
with
the
concept
of
a
vast
future
where
filler
or
26
exists
already,
but
anyway,
let's
do
something
right,
so
so
what
I
would
do
as
a
maintainer
of
a
docker
file
or
a
docker
layer?
Image
is
do
certain
things
in
the
doctor
file.
B
So,
let's
just
bump
the
release
by
a
small
increments
and
then
I
can
actually
do
a
cutback
age
mint
with
a
message
bump
Louise
for
demo,
and
then
we
can
do
it
fled
back
to
push,
and
this
is
going
to
push
out
to
again
get
so.
The
output
here
should
look
very
familiar
for
those
who
are
familiar
yet
we
will
then
do
a
actually
on
YouTube.
You.
B
Do
a
Fed
package
of
container
build
and
this
is
going
to
go
off
and
I
like
what's
on
the
diagram
before
this
will
send
a
message
out
to
Koji
and
schedule
will
build.
That
will
then
happen
out
in
the
environment.
Now
this
is
going
to
take
a
few
minutes,
so,
instead
of
staring
at
this
output,
I've
actually
pulled
up
a
old
build
that
already
was
done
for
cockpit
and
it
was
successful.
B
So
what
you
see
here
is
that
we
have
our
get
SCM
URL,
as
well
as
the
exact
checks
on
the
the
actual
commit
message
that
we're
trying
to
pull.
This
will
specify
the
exact
commit
that
we
sent
as
the
build,
which
provides
our
input
into
the
build
system,
and
then
this
is
a
parent
task,
and
this
parent
task
will
handle
multiple
architectures
right
now
we
only
have
x86
64
enabled,
but,
as
dr.
oz,
dr.
gets
more
widespread
support
for
other
architectures.
B
B
B
B
B
The
gnomes
are
just
version
and
then
latest
and
that
will
be
pushed
to
latest.
So
we
can
actually
go
over
here
and
do
a
doctor
pull
on
that
image
and
it
will
pull
it
down.
I've
already
downloaded
it.
It's
free,
it's
free
cash
on
machine
just
for
the
sake
of
of
having,
but
what's
interesting
about,
that
is
the
atomic
command
and
this
might
get
off
in
the
weeds.
But
for
anybody
atomic
is
a
command
wrapper
for
many
things.
Docker
and
it
correlates
do
project
atomic,
but
we
can
atomic
run
that
come
out.
B
If
I
go
to
I,
don't
go
into
for
rpm,
just
because
one
I
make
it
full
circle.
I
could
do
a
bed
package
and
I'll
do
a
scratch
build,
which
is
an
unofficial
build.
But
this
will
again.
This
is
actually
an
RPM
build
and,
as
we
can
see,
the
output
here
is
very
similar
to
what
we
saw
with
the
container
build
and
the
command
was
very
similar
and
it's
just
the
same
workflow.
And
here
again
we
have
this
Koji
task
that
has
been
created
and
you
can
actually
exit
that
time
to
stare
at
it.
B
But
we'll
see
here
that
this
is
all
of
the
you
know:
dr.
speck
files
within
our
p.m.
the
service
unit
file
for
systemd
and
those
kind
of
things,
so
the
workflow
is
very
similar
and
it's
just
meant
to
provide
a
really
good
experience
for
people
in
photo
or
who
want
to
contribute
doc
earlier
damages
and
anybody
who's
interested.
B
Add
a
couple
that
we
had
discussed
during
during
the
presentation
of
this
page,
but
you
can
see
the
on
what
the
fifth
one
down
for
a
project
at
org
plus
we
keep
join
that
provides
information
without
actually
doing
the
Tor
project,
how
to
get
involved,
how
to
contribute
code
and
content
and
anything
that
we're
working
on
here
at
the
right.
Polly
is
related
to
the
part
of
the
cloud
group.
He
changed.
Dr.
B
leered
image,
build
the
layer,
docker
image
field
service,
I
goofed,
when
I
edited
that
and
she's
lived
on
our
fedora
doctor
registry,
which
is
our
playing
action,
build
scale
that
registry
and
other
items
in
the
area,
as
well
as
the
upstream
projects
for
the
technologies
that
we
are
actually
using
to
deliver.
The
vallejo
village
built
service,
so
I
at
this
time,
I'm
going
to
stop
sharing
my
screen.
A
Actually,
can
you
I'm
going
to
ask
you
to
go
back
to
do
on
your
screen
and
ask
the
question
from
a
community
point
of
view
on?
One
of
the
things
that
I'm
interested
in
is
is
getting
lots
of
the
different
open
source
projects
to
create
containers
that
they
can
use
to
run
on
openshift
and
images,
and
the
slide
that
you
had.
We
had
the
fedora
image
maintain
errs
whatever
that
tag
was.
A
Indicators,
explain
to
me
a
little
bit
more
about
that
role.
So,
for
example,
if
I'm
someone
like
on
the
open
source
project
lead
for
Maria
DB
or
in
the
example
you
used
as
cockpit
who,
in
some
fedora
perspective,
would
you
expect
to
maintain
that
image
when
the
next
release
is
out?
You
expect
someone
from
the
project
project
on
Gloria
DB,
to
have
someone
assigned
to
be
the
four-layered
image
maintainer
and
be
part
of
the
Fedora
community,
or
how
is
how
are
you,
envisioning
people
using
this
so.
B
This
is
kind
of
twofold:
it
can
go
either
direction
somebody
from
an
upstream
community
so,
for
example,
the
cockpit
team
upstream
does
actually
have
something
designated
to
doing
their
pocket.
Rpm
builds
and
then
they
will
again
later
for
the
they're
layered
image
build
containers.
However,
they
completely
may
do
that.
B
The
the
person
that
actually
manages
that
these
days
is
a
bot
that
they
wrote,
but
on
the
flip
side,
most
of
the
RPM
content
that
goes
into
Fedora
today
is
actually
maintained
by
specific
pedure
RPM
maintained
errs
and
they
are
generally
people
who
are
users
of
a
technology
and
maybe
are
involved
with
upstream
in
some
form
or
fashion,
and
they
will
kind
of
take
on
the
responsibility
and
by
and
large
I
would
say,
90.
Probably
ninety
percent
of
those
people
are
just
volunteers.
B
It's
thing
to
say
it's
something
to
do
in
their
free
time,
because
they
are
passionate
about
that
particular
piece
of
software
and
their
fans
of
what
we
do
in
fedora
and
our
contributors
to
fedora
and
help
make
the
distro
as
well.
As
you
know,
all
the
things
in
the
closet
or
ease.
So
it
could
go
either
way.
B
If
somebody
is
somebody
in
the
afternoon,
community
would
like
to
designate
somebody,
because
it's
something
that
they
would
like
to
engage
with
the
fair
project
on
and
actually
have
their
content
in
the
fidor
registry
and
the
Fedora
build
pipeline.
As
an
official,
you
know,
participation
from
the
upturn
project.
That
was
great.
It's
not
a
requirement.
I
mean
we
also.
We
have
a
wish
list.
B
B
B
So
when
software
upstream
is
updated,
people
who
are
involved
in
the
federal
project
in
correlation
with
that
software
would
get
notified
about
it.
So
it's
not.
It's
not
like
a
direct
will
direct
manual
process
such
that
somebody
in
the
community
needs
to
constantly
monitoring
that
upstream
software
for
for
release.
They
can
elect
to
get
notifications
about
it.
B
Currently,
if
you
can
see
on
the
screen
here,
we're
monitoring
of
you
know
just
over
ten
half
thousand
upstream
projects
the
moment,
and
it
should
be
noted
that
anybody
can
create
an
account
and
log
in
them
and
add
things
to
this,
but
so
lets.
You
know,
for
example,
so
marry
a
DB
since
we
since
we're
talking
about
mary
TV,
we'll
just
we'll
go
ahead
and
do
that
one
so
Mary
DB
is
actually
already
monitored
and
its
latest
versions
are
reported
upon
and
we
can
actually
see.
B
Apparently
you
know
60
point:
five
million
messages
have
been
received
and
stored
in
this
in
this
service
and
we
can
actually
just
monitor
the
feed
and
if
you
kind
of
want
to
see
all
the
things
going
up
door,
you
don't
kind
of
fly
by
or
you
could
limit
your
search
down
and
there's
discussions
of
how
you
can
do
that.
But
if
you
wanted
to
perform
searches
event
against
a
to
grepher
for
messages
in
needed
by
release
monitoring
to
come
query
what
the
latest
you
know,
version
of
things
are
in
a
programmatic
way.
B
B
Basically
simply
you
know:
do
a
Santa's
ation
check
make
sure
that
you
know
what
was
done
in
the
automated
fashion,
didn't
cause
any
issues
and
then
actually
submitted
an
official
update,
and
what
I
would
like
to
do
is
something
very
similar
to
this,
but
for
dr.
layered
image
builds
so
that
if
a
maintainer
wanted
to
participate
but
didn't
want
to
have
a
large
time,
commitment
in
you
know
in
the
normal
cycle,
obviously
sometimes
think
will
happen
to
a
major
eruption
releases
that
will
have
nonfat
whole
changes
and
it
will
fire
a
little
bit
more.
B
A
There
is
one
other
question
in
the
chat
and
it's
Jorge
is
asking
it
and
I
think
you're
kind
of
answering
it
and
oak
in
a
way,
and
it's
our
the
docker
image
updates
timeline,
aligned
with
fedora
releases
and
updates.
So
what
I
take
from
all
this
automation
you
have
is
that
when
the
base
Fedora
image
changes,
that's
going
to
trigger
a
lot
of
imagery
building
as
well.
Yes,.
B
We
have
a
system
called
though
d
and
bo
Diaz,
the
foot
or
update
system.
This
currently
today
only
handled
rpms.
We
are
going
to
add
the
functionality
for
this
to
also
handle
docker
images
and
in
the
initial,
offering
docker
images
that
come
out
of
fedora
will
only
be
comprised
of
dr.
herb,
Fodor
rpms
in
the
future.
We
want
to
kind
of
loosen
that
constraint
and
allow
for
all
kinds
of
things
we
put
a
doctor,
not
just
rpms,
but
in
initial
it
will
be
just
Dora
p.m.
so
there
will
be.
B
The
plan
is
that
there
will
actually
be
a
relationship
between
a
docker
images,
a
docker
image
and
the
RPMs
that
are
that
it
is
comprised
of
and
when
an
update
for
rpms
that
are
in
the
list
that
a
layered
image
is
comprised
of,
gets
updated.
That
should
trigger
serious
events,
and
one
of
those
events
will
be
a
new
rebuild.
Then
there
will
be
an
automatic
entry
in
Bodie
and
Bodie
will
then
trigger.
What's
called
tasket
Ron.
B
B
There's
a
lot
of
things
they
can
do
so
what
we'll
do
is
Bodhi
will
set
up
this
thing.
There
will
be
a
message
sent
across
the
Fed.
The
Fed
message.
Bus
and
casket
Ron
will
pick
that
up
and
say:
hey
I
need
to
run
tests,
it
will
run
tests
and
it
will
submit
back
to
the
update
entry
pass
or
fail
and
if
it
passes,
then
there
will
be
a
new
doctor
image
release
and
that
will
be
tied
to
the
RP
at
the
fedora
p.m.
content,
and
that
is
the
long-term
goal.
B
Now
the
amount
of
development
effort
that
is
required
for
that
is
not
small,
so
in
the
short
term,
in
the
Fedora
25
time
frame,
what
we
are
going
to
do
and
note
that,
like
foot
over
24,
comes
out
in
a
week
or
two
depending
on
blocker
bugs
so
fit
over
25
is
you
know
the
next
six
months
time
from
in
terms
of
development
effort.
So
in
that
time
we
are
just.
B
We
are
going
to
set
up
an
automated
system
that
will
key
off
of
fed
messages
and
those
kind
of
things
to
kick
off
automated
tests
and
much
of
the
groundwork
for
this.
But
the
release
schedule
is
just
going
to
be
a
static
two
weeks,
so
every
two
weeks
there
will
be
a
new
cut
of
all
of
the
images,
with
the
caveat
of
that
being
anything
security
related.
B
So
if
there's
a
a
critical
security
thing,
if
you
know
I,
don't
know,
pick
take
your
latest
CD
that
has
its
own
website
logo
and
t-shirt
and
music,
video
and
and
if
the
next
one
of
those
happens,
we
will
absolutely
address
that
immediately
and
we
will
push
out
updates.
But
in
terms
of
just
standard
you
know,
bug
fixes
new
versions
feature
releases,
those
kinds
of
things:
it's
just
going
to
be
a
standard
two
weeks
until
we
have
all
of
the
work
done
into
the
update
system
to
handle
this
so.
B
We
would
like
that
to
happen.
I,
you
know.
Who
knows
what
will
happen
in
the
grander
scheme
of
the
world
in
what
Tim
you
want
from
from
whom?
But
no
we
would
love
for
that
to
happen,
and
basically,
what
we're
trying
to
do
is
deliver
the
best
that
we
possibly
can
with
the
latest.
You
know
cutting
edge
or
leading-edge
technology
that
we
that
we
can
and
just
kind
of
to
round
back
the
open
shift
point.
B
A
lot
of
what
I
focus
on
is
kind
of
the
release,
engineering
back
and
work,
because
that's
what
I'm
involved
in
in
my
day-to-day
and
that's
kind
of
what
I
guess
always
comes
to
mind.
First,
when
I
start
discussing
these
things,
but
in
the
fidor
working
group.
That
is
something
that
we
want
to
do
and
under
the
umbrella
of
the
upcoming
Fedora,
nish
or
I'm.
Sorry,
the
Fedora
incubator
project.
B
We
have
a
new
goal
of
actually
kind
of
targeting
openshift
as
our
as
our
container
runtime
platform
for
things
that
the
Fedora
working
group,
the
footwork
model
of
users,
will
kind
of
focus
on
around
Multi
multi
container
services
and
scaled
out
deployments
those
kinds
of
things,
and
so
we
do
we.
We
actually
have
plans
to
kind
of
start
a
more
formal
relationship
with
the
upstream
of
object,
origin
and
try
to
provide
something.
A
B
Well,
and
actually
just
just
a
quick
note,
last
week
we
had
the
fedora
cloud
working
group
activity
days
in
and
we
had
a
you
know
a
little
over
a
dozen
of
us
meet
and
and
just
kind
of
do
sprints
and
work
on
things
and
have
hackfest,
and
during
those
times
we
were
actually
fortunate
up
to
grab
a
few
people
from
the
open
shift
up
through
development
community
kind
of
proposed.
What
we
want
to
do
and
and
see
if
there
was
anything
from
that.
That
would
be
useful.
B
So
one
of
things
we
want
target
actually
is
doing
a
full
containerized
deployment
of
openshift
origin
on
top
of
fedora
atomic
host,
which
is
a
whole
different,
rabbit
hole
to
go
down.
But
if
anybody
is
familiar
with
fedora
atomic
host,
that
is,
that
is
a
target
for
for
what
the
floor
flat
working
group
wants
to
ship
as
the
primary
deliverable
in
the
future,
as
we
kind
of
believe
that
that
kind
of
thing,
the
more
the
more
immutable
infrastructure
style
of
deployments
in
the
cloud
spaces
kind
of
the
future.
A
C
Yeah
I've
been
silent
because
Adams
been
doing
a
terrific
job
and
pretty
much
has
said
everything
I'd
like
to
say
so.
I
didn't
have
much
to
add.
I
guess
one
of
the
things
up
as
a
follow
up
to
the
cloud
fad
meeting.
I
actually
just
posted
something
to
the
fedora
cloud
mailing
list,
which
you
can
get
to
think
from
that
second
wiki
link
they're,
seeing
on
the
screen,
and
it's
posted
something
about
the
future
of
fedora
and
put
our
cloud
and
open
shift
and
where
we're
going
to
go
with
that.
A
Alright,
well
we'll
see
if
we
can
gather
some
forces
behind
it.
It
sounds
to
me
like
it's
going
to
be
one
of
the
go-to
places
for
getting
images
as
well
and
in
the
not-too-distant
future.
So
thank
you
very
much
for
all
the
work
that
you've
been
doing.
It's
hugely
appreciated
and
I'm
glad
to
hear
some
of
the
open
shift
origin
engineers
jumped
on
that
working
hack
hackathon
day
to
help
you
out.