►
From YouTube: OKD Release Process Vadim Rutkovsky Red Hat
Description
2021-03-20
Narrator: Vadim Rutkovsky (Red Hat)
from OKD Working Group's OKD Testing and Deployment Workshop
https://www.okd.io/blog/2021/03/16/save-the-date-okd-testing-deployment-workshop.html
http://okd.io
A
B
So
our
final
step
in
the
release
process
is
uploading,
the
binaries
of
installer
and
oc
to
github,
but
in
order
to
make
it
happen,
we
first
need
to
build
it
from
the
source
code
and
as
everything
else,
things
are
happening
in
the
organization
called
openshift,
where
the
code
for
both
succp
and
okd
being
created
for
those
who
are
not
familiar
with
semicrimes
ocp
stands
for
openshift
container
platform.
That's
a
product
which
red
hat
officially
supports,
provides
a
subscription
to
the
clients
and
okd
is
a
community
distribution
which
is
related
to
ocp
as
well.
B
It
contains
several
simple
things.
First
of
all
is
the
dockerfile,
because
all
pieces
of
okd
and
ocp
are
container
images,
so
this
terrafile
explains
how
to
build
it.
We're
building
from
scratch,
then
we
copy
the
files
in
the
manifest
and
label
this
image
as
an
operator.
That
means,
as
chara
has
explained
previously,
everything
in
okd
and
ocp
is
based
on
operators.
So
we
have
a
top
level
operator
called
cluster
version
operator
which
all
it
does
is
applies
all
the
pieces
to
your
cluster
and
they
assemble
into
an
open
shield
release.
B
B
When
the
openshift
console
is
started,
and
it
finds
this
configuration,
it
applies
to
okd
branding
and
in
the
help
message
you
would
have
a
different
documentation
based
url.
So
all
those
changes
we're
looking
into
are
built
by
ci.
You
can
see
we
get
green
marks,
meaning
it
has
passed
and
everything
is
done
via
the
pull
requests.
B
B
Origin
48
image
stream
as
a
base,
because
all
of
the
images
we
make
release
from
are
in
fact
stored
in
the
shift
itself
and
they
are
stored
in
the
form
of
the
image
stream
tags.
So
we
use
4a
as
a
base,
build
branding
image
tag
it
back
into
the
temporarily
stable
image
stream
and
we
don't
run
any
particular
tests
because
it's
just
one
single
config
map
and
we
immediately
promote
it
back
to
4a
image
3.
B
Build
the
image
we
have
submitted
run
some
tests
if
they
are
present,
for
instance
in
other
repos,
who
might
have
additional
end-to-end
verifications
for
aws
same
test
for
aws,
but
an
upgrade
test
and
use
a
previous
state
and
a
new
release
with
this
image,
gcp,
vsphere
and
so
on
and
so
forth.
Depending
on
what
kind
of
repo
that
is,
and
once
we're
done,
it
would
promote
it
as
an
official
image
in
the
48.
B
So
the
whole
release
parts
are
stored
as
a
part
of
image
stream
in
our
ci
and
once
we're
done,
the
ci
would
also
track
that
image
stream
and
would
be
building
new
releases
out
of
that
meaning
you
would
be
able,
if
would
be,
able
to
compile
them
into
one
single
image
which
refers
to
a
bunch
of
other
images
and
fetch
some
metadata
from
them.
For
instance,
if
we
would
use
oc
atom
release
info
command
on
some
release
images,
we
would
be
able
to
extract
urls
to
each
particular
comets.
B
This
image
has
been
built
from,
as
you
can
see
on
this
picture,
for
instance,
and
since
ci
can
do
that,
so
that
users
can
also
create
their
own
release.
Payloads
based
on
the
payloads,
we
released
already
replacing
some
particular
images
with
the
fixes
they
would
like
to
test
or
some
changes
they
would
like
to
to
have
performed.
B
B
Now
it
builds.
The
difference
between
the
previous
release
shows
that
two
new
images
have
landed
based
on
the
metadata
they
contain.
We
can
also
build
links
to
the
pluto
quest
which
have
caused
this
change,
and
someone
supports,
and
these
nightly
images
can
eventually
be
promoted
to
stable.
For
instance,
this
latest
47
release
used
to
be
a
nightly
release
with
the
same
date
and
in
order
to
perform
stable
release,
we
have
a
small
instruction.
B
B
All
the
rest
is
done
by
ci
itself,
which
automatically
updates
the
update
graph
runs
additional
tests,
and
we
can
see
that
users
from
the
previous
releases
can
upgrade
and
what's
the
best
result
for
that,
since
the
rookie
is
slightly
different
from
okity
or
osap,
as
it
uses
different
images.
In
some
cases,
we
also
have
a
different
issue
tracker.
We
use
open
shift
issues
to
track
okay,
specific
problems,
however,
since
most
of
the.
B
Images
we're
using
from
ocp,
for
instance,
console
is
copied,
as
is
from
ocp,
so
any
kind
of
ui
issue
you're
hitting
would
be
reproducible
on
ocp
as
well.
That
means
you
would
file
a
proper
ocp
image,
because
you
will
be
sure
that
it
happens
for
ocp
as
well,
and
you
would
get
direct
developer
attention
to
to
fix
it
and
once
we're
there.
We
also
request
you
to.
B
Let
me
pick
one
of
my
favorite
ones
speak
the
closed.
We
also
ask
you
to
provide
a
log
bundle
so
called
where
a
lot
of
logs
from
the
failed
installation
or
broken
cluster
itself.
That
archive
should
contain
all
the
logs
for
us
to
find
out
what's
happening
well,
which
part
do
we
need
a
fix?
How
or
what's
missing.
B
And
after
we're
done,
we're
also
uploading
the
client
tools
to
github
and
send
a
message
to
okd
working
group
to
to
reiterate
in
the
end,
okay
is
a
community
distribution.
That
means
all
the
images
we're
listing
here,
have
their
github
repos,
meaning
you
can
rebuild
them,
think
of
them
replacing
parts
and
collaborate
with
us
to
make
it
better.