►
Description
co-chairs: Diane Mueller & Rob Szumski (Red Hat)
A
So
we
have
what
looks
like
a
big
agenda
today,
but
it
being
the
last
of
the
year
and
just
shortly
before
the
holidays
and
in
the
middle
of
other
people's
holidays,
then
it'd
be
interested
to
see
how
many
people
we
have
twelve
people
on
the
call.
B
A
And
I'm,
hoping
that
the
gentleman
Alexander
Perlman
from
Capital
One
will
show
up
because
he
was
also
asking
for
some
time
to
talk
about
the
desk
operator.
So
why
don't
we
kick
it
off?
Rob
you
and
I,
given
a
an
update
on
things
going
on
in
the
operator
framework
and
we'll
see
if
Joe
Lanford
shows
up
and
can
give
us
an
operator
SDK
after
that
sure.
B
Yeah
I'll
combine
my
I'm
gonna.
Do
the
operator
hub
IO
update,
as
well
as
the
framework
update
and
so
we'll
start
with
operator
hub
IO
I'll
share
my
screen
and
go
through
I
was
looking
through
some
of
the
PRS
since
we
last
map,
which
is
I
think
roughly
a
month
ago,
a
ton
of
activity.
So
let
me
get
my
screen
share
and
I'll
walk
you
off
three.
B
Some
of
these
all
right,
so
what's
interesting,
is
if
you
look,
I
was
just
looking
through
30
days
ago,
we're
on
page
four
here,
which
is
pretty
awesome,
so
that
means
we've
got
I,
think
they're
25
per
page.
So
that's
like
a
hundred
ish
PRS
and
you
can
see
it's
a
bunch
of
folks
updating
versions
and
changing
channels,
and
things
like
that
and
adding
new
operators
so
picked
a
few
of
these.
That
I
thought
were
interesting.
B
B
Let's
see
the
next
one
is
the
container
security
operator.
This
is
really
cool.
This
is
an
opera.
I,
don't
think,
is
much
detailed
in
the
actual
PR
that
integrates
with
the
Claire
security
scanner.
So
if
you
install
this
on
a
cluster
and
then
have
you'll
get
your
containers
scanned
with
Claire,
which
is
an
open-source
scanner,
and
so
this
looks
at
some
of
the
different
packages
you
have
in
the
operator
image
or
the
operand
images
you
have
running
and
then
flags
known
vulnerabilities
about
them,
which
is
pretty
cool.
B
B
B
So
I
just
want
to
point
that
out
that
you're
getting
pretty
complicated,
invisible,
which
is
awesome
if
you've
ever
looked
at
kubernetes,
are
back
for
like
a
deployment
and
there's
the
scale
sub
resource
same
kind
of
thing,
you
might
want
to
grant
somebody
access
to
scale
a
deployment
but
not
to
modify
its
configuration.
For
example,
that's
also
good
for
scoping
down
our
back
for
like
an
auto
scaler,
so
that
you
don't
do
granted
access
to
the
whole
thing.
B
Let's
see
next
one,
so
the
this
fellow
Christopher
that
kind
of
on
an
individual
effort
made
the
Amazon
service
operator
kind
of
the
first
version
of
that
his
current
code
has
been
archived,
but
there
is
a
newer,
more
official
one
from
Amazon
that
will
get
updated.
So
I
just
wanted
to
call
that
out
is
doing
like
a
graceful
removal
aback
and
then
we're
gonna
get
the
diamond.
B
Next
up,
big
update
to
crunchies,
post
press
operator
and
hope,
Postgres
is
really
popular,
so
they've
got
a
major
version
of
this
and
this
thing
is
getting
better
and
better
every
day.
So,
if
you
haven't
checked
it
out,
it's
really
awesome.
I
would
encourage
you
to
look
at
that
for
any
Postgres
needs
that
you
have
joins.
You
know
our
large
catalogue
of
databases,
I
think
databases
are
probably
the
largest
one
category
that
we
have
coverage
for
in
the
operator
community.
B
So
that's
really
great
check
that
one
out,
if
you
haven't
already
next
up,
is
a
new
one.
Api
cast
I
think
I
was
looking
into
this.
This
is
a
part
of
the
Red
Hat
3
scale
product
and
set
of
open
source
projects.
I
just
want
to
flag
about
something
new
I
haven't
looked
into
it
too
closely,
but
I
think
it's
an
API
management
tool,
ooh
another
one
for
the
crunchy
operator,
I
flagged
this
one
because
they
are
properly
using
their
channels,
so
they've
moved
one
of
their
versions
on
to
their
stable
Channel.
B
This
is
something
that
you
can
control
through
your
cluster
service
version
file
and
the
other
packages
that
are
inside
of
your
operator
bundle.
So
I
just
want
to
encourage
folks
to
think
about
their
channel
strategy,
and
you
don't
hear
at
crunchy
has
a
few
different
channels
so
that
they
can
manage
what
their
customers
are
doing,
and
you
know
allow
them
to
get
newer
versions
of
the
operator
on.
You
know
like
a
pre-release
channel
or
something
like
that.
This.
B
Channel
because
that's
how
the
lifecycle
manager
works,
but
adding
another
is
a
benefit
to
you
to
get
some
feedback
as
well
as
your
customers
to
get
something
that
is
a
little
more
stable,
alright
enough
of
PRS,
let's
look
at
some
real
ones
and
operator
how
they're
alive.
So
this
is
a
new
one.
To
me
this
is
an
IBM
bucket
operators.
B
This
allows
you
to
make
see
IDs
for
our
CRS
for
instances
of
storage,
buckets
on
IBM,
pretty
cool
you
can,
you
know,
do
encryption
and
things
like
that
at
the
same
time,
so
it's
not
just
simple
crud,
so
I
thought
that
was
pretty
cool.
Just
wanted
to
call
that
one
out
another
one
is
the
IBM
cloud
operator.
This
is
more
than
just
buckets
it's
doing
bindings
for
the
whole
entire
IBM
cloud.
Catalog.
If
you
want
to
check
that
out,
you
know
all
the
different
services
they
have
on
there.
It
does
require
an
IBM
cloud
account.
B
This
kind
of
follows
with
I
think
that
we've
got
the
Amazon
one
like
I
just
mentioned
that
we're
gonna
change
the
new
repo.
For
that
we've
got
this
IBM
one
there
is
I.
Think
Microsoft
has
an
arc
operator,
that's
coming
out,
which
would
be
pretty
cool
and
I
think
there
might
be
rumors
of
a
Google
one
as
well.
So
all
your
clouds
are
kind
of
covered
for
doing
cloud-based
management,
but
in
kubernetes
CRTs,
which
is
really
cool,
and
the
last
one
I
have
is
this
IBM
CSI
plugin.
B
So
we've
got
a
number
of
other
storage
providers
like
port
works
and
storage
LS
a
few
others.
This
joins
another
one.
The
reason
I
call
this
out
is
I
love
the
plug-in
model
of
kubernetes,
with
CNI
and
CSI,
and
CRI
for
storage,
networking
and
container
runtime.
So
I
think
operators
make
a
great
great
use
case
for
managing
those
plugins,
and
you
know
installing
configure
them
correctly.
Just
want
to
call
that
out
that
you
know
there,
we've
got
a
bunch
of
them.
Another
one
joins.
B
So
if
you
haven't
looked
at
some
of
these,
if
you
have
storage
needs
or
networking
provider
needs,
there's
probably
an
operator
out
there
for
you,
so
that
was
the
main
update.
I
have
on
things
going
on
in
the
community
like
I
said
ton
of
great
PR
is
a
lot
of
activity.
A
lot
of
folks
updating
operators
and
getting
them
out
to
your
hands
so
keep
it
up,
and
thank
you
for
everybody.
That's
adding
these
we're
viewing
them
so.
A
B
A
Think
it's
it's
probably
a
hundred
if
we
get
all
those
PR
requests,
reviewed
and
I'm
an
actor
but
doubting
we're
gonna,
get
them
all
by
Christmas
as
people
drop
off
for
holiday.
So
thanks
again
everybody
for
all
your
efforts
and-
and
this
is
pretty
good-
if
there's
any
questions,
throw
them
in
the
chat
and
I
don't
see.
Is
there
someone
from
the
SDK
side
of
the
house
here
and
give
an
update
from
the
SD
operator?
Sdk
sig,
you
know,
Joe
Lanford
said
he
would
I,
don't
see
Shawn
on
the
call.
A
B
Least
a
brief
update,
I
know
that
we're
planning
out
the
helm,
three
work
and
others
some
PRS
that
have
already
been
submitted
and
that's
being
polished
up.
So
that's
pretty
exciting.
As
you
know,
the
helm
three
has
been
released
for
a
little
bit,
so
you
know
you'll
be
able
to
use
that
same
technology.
You
know
the
tiller
list
installed
it
we've
kind
of
had
for
a
while
Helms,
not
catching
up.
B
One
thing
to
note
is
that
I
don't
think,
there's
any
change
required
to
your
charts,
so
you
can
use
charts
that
were
made
a
long
time
ago,
or
it
may
just
now
that
those
can
be
used
by
the
helm
operator
very
easily
and
the
other
thing
I
know
there's
a
ton
of
work
going
on
and
continues
to
be
going
on
with
the
testing
framework
and
the
the
scorecard
and
other
tests
that
we
have.
You
can
see
that
some
of
the
scorecard
stuff
was
mentioned
in
those
PRS.
B
That
I
was
showing
that's
because
it's
being
used
to
test
out
these
operators
and
so
we're
just
going
underway
on
that.
No,
the
big
thing
for
2020
is
to
add
the
ability
for
folks
to
provide
their
own
tests
into
the
scorecard.
So
when
you
bundle
up
your
operator
and
putting
some
tests
that
either
this
work
are
going
to
use,
your
customers
can
use
any
other.
You
know
platform
that
wants
to
use
those
to
verify
them
can
use,
which
would
make
the
whole
thing
a
whole
lot
safer
and
more
resilient.
B
A
E
A
E
Great
yeah,
I
guess
I've
seen
some
some
roadmap
information
that
talks
about
you
know
the
Quai
app
registry
going
away
and
and
operator
operators
being
you
know
that
metadata
being
packaged
in
docker
images
and
that
sort
of
thing
so
I
was
wondering
if
you
could
comment
on
you
know
when
we
would
start
to
see
that
kind
of
stuff
for
just
for
our
own.
How
do
we
move
forward
kinds
of
things
if
that's
changing
yeah.
B
B
So
this
means
that
you
can,
you
know,
store
them
in
any
OCI
compliant
registry
as
well
as
do
things
like
if
you
have
an
offline
cluster
or
you
want
to
build
your
own
custom
catalogs.
This
unlocks
a
much
much
easier
experience
for
that,
and
so
that's
what
I
think
I'm
really
excited
about
is
using.
This
bundle
format
unlocks
the
ability
to
do
a
really
simple
debt
and
test
of
custom
catalogs
just
between
you
and
a
cluster
without
any
intermediary.
B
E
E
D
C
B
Official
sub
projects,
which
I
think
sounds
great,
this
kind
of
picks
up
from
the
last
meeting
we
had
live
from
coop
con
where
he
was
there
in
person
with
some
of
his
team
talking
about
Kudo
and
those
tools,
but
I
don't
see,
I
think
I
just
wanted
to
make
sure
he
had
a
some
sort
of
update
before
we
ended
2019
here,
buddy
I
think
2020.
All.
A
Right,
you
know
I'll,
do
I'll
reach
out
to
Sean
and
see
if
he
if
they've
talked
but
I,
know
we're
talking
pretty
closely
with
that.
So
that
would
be
a
good
thing
to
pull
in
as
a
sub-project
and
to
help
they
also
have
some
great
testing
capabilities
so
definitely
incorporate
them
into
the
community.
If
we
can
all
right
don't
go
back
to
here.
The
next
update
is
really
another.
Almost
non
update,
we've
pretty
much
answered
all
of
the
questions,
except
for
one
last
one
on
the
CNCs
PR
or
proposing
the
operator
framework
for
incubation
consideration.
A
There's
one
more
question
that
needs
answering
there
on
the
thing,
but
there
is
a
TOC
meeting
early
I
think
it's
the
first
week
of
back
in
January
I'm
gonna,
see
if
we
can
try
and
get
to
a
vote
for
the
TOC
on
operator
framework.
So
we
can
move
this
forward,
but
that's
pretty
much
just
waiting
for
final
approval
or
due
diligence
final
say
from
the
sig
app
delivery
sig
so
that
we'll
get
a
space
on
the
TOC
agenda
again
to
call
for
a
vote.
That's
moving
forward.
Slowly,
but
surely
any
questions
about
that?
A
Let
me
know
and
try
and
answer
those
for
you,
but
other
than
that
it
is
moving
which
is
not
as
fast
as
I
would
like,
but
probably
as
fast
as
its
supposed
to
next
up
I
had
a
review
and
update
front
on
the
kubernetes
client
from
jeff
mccormick,
and
you
know
also
asked
to
have
a
discussion
around
the
java
and
python
client
so
Jeff.
If
you
want
to
share
your
screen
and
talk
a
little
bit
about
those
two
topics.
That
would
be
great
so.
D
D
You
know
I
just
throw
out
there
that
these
two
client
libraries
look
pretty
good
as
a
potential
starting
point.
If
somebody
wanted
to
go
down
that
path,
I
know,
probably
a
lot
of
people
already
knew
about
these
I
think
Shawn
me
and
him
talked
about
it.
He
knew
about
these.
He
thought
the
Java
when
might
not
support,
watches
but
I
think
that's
recently
been
added.
D
So
I
just
wanted
to
add
this
to
the
notes
for
this
group
as
to
very
I
think
good
candidates
that
people
could
maybe
bass,
operator,
SDK
stuff
on
and
I
posted
the
link
out
there
to
the
to
the
chat
session
as
well.
That's
really
all
I
had
on
this,
but
I
did
want
to
kind
of
point
people
to
this,
and
maybe
people
could
start
poking
on
these
and
doing
a
little
bit
deeper
investigation
on
them
to
see.
If
that
really
these
make
really
since
to
build
on
top
of.
D
D
First
of
all,
you
need
these
kind
of
client
libraries,
so
I
guess.
The
question
is
that
needs
to
be
resolved.
You
know
the
next
year
time
frame
is:
are
these
libraries,
the
ones
that
you
would
use
you
know?
Is
this
the
starting
point?
So
to
me
they
seem
like
really
good
starting
points,
and
you
know,
since
these
are
both
supported
by
the
API
machinery
sig,
they
seem
to
both
support,
watches
but
I
think
the
group
as
a
whole
might
need
to
do
some.
D
You
know
again
deeper
dives
on
this,
but
to
me,
if
you
can
decide
hey,
these
are
the
climb
API
bindings
or
the
client
API
is
to
go
with
kind
of
takes
that
off
the
table
as
a
decision
you
know,
and
then
you
can
start
thinking
about
building
something.
On
top
of
these.
Your
with
these
things
so
I
think
that
kind
of
decision
needs
to
be
made,
probably
early
sometime.
If
people
want
to
go
down
that
path,
you
know
but
I
think
these
are
good.
Starting
points
is
what
I'd
say.
D
A
Anyone
else
have
another
two
cents
on
this,
or
did
we
start
a
thread
on
this,
perhaps
on
the
Google
group
and
see
if
there's
any.
The
attendance
is
a
little
low
today,
thinking
that
maybe
we
could
push
that
as
a
conversation
on
the
the
Google
group
and
then
when
everyone
comes
back
to
the
holiday,
we
can
have
a
wider
discussion
about
that
if
it
doesn't
get
resolved
on
the
mailing
list.
D
B
A
C
Add
maybe
just
another
half
cent
if
I
could
or
you
guys
can
decide
it
was
worth
maybe
after
I'm
done,
regardless
of
which
comments
obviously
did
get
used
here.
The
next
step
in
a
bigger
picture
is
coming
up
with
something
that
is
filling
the
role
of
what
control
or
runtime
does
in
the
NGO
world
and
there's
a
as
complex
as
control
runtime
can
feel
at
times.
C
It
really
does
boil
down
to
just
a
couple
of
rather
like
simple
high
level
things
problem
areas
that
it
has
to
tackle
so
that,
at
the
end
of
the
day,
whether
you're
in
go
or
Python
or
Java
or
anything
else,
we
want
people
to
be
able
to
implement
a
reconcile
function
than
most
of
their
time
there.
So
if
there
is
interest
in
moving
forward
with-
let's
say,
for
example,
Python
and
Java
they'd
probably
be
worthwhile
to
get
all
of
those
people
together
and
do
some
behavioral
overview
of
what
is
controlling
I'm
doing.
C
What
do
we
like
about
that
particular
I've
library
in
the
framework
that
it
brings,
and
that
would
be
a
great
jumping-off
point-
I
think
for
figuring
out
how
to
create
similar
things
in
other
languages,
so
that
we
can
have
some
kind
of
similar.
The
experience
obviously
can
be
a
very
tailored
to
each
language
and
the
idiosyncrasies
of
them,
but
some
kind
of
similar
thinking
and
philosophy
about
how
to
build
controllers
across
the
board
and
be.
A
A
Right
so
we
do
have.
There
was
an
interesting
thread
on
the
Google
Group
about
the
DoD's
of
the
u.s.
DoD's
use
of
operator
registries
and
jizya.
Richie
is
on
the
call
right
now
and
I'm
sort
of
impromptu,
because
I
don't
think
Alexander
crowman
from
Capital
One
with
his
desk
operator,
showed
up
we'll
see,
shouts
out
right
now.
So
what
I
thought?
Maybe
Jose?
If
you
want
to
take
a
few
minutes
and
explain
what
it
is
you're
doing
there
with
registries
and
operators
and
give
us
a
quick
update.
F
Yeah
sure
yeah
thanks
for
giving
me
the
chance.
So
to
give
some
background
on
all
of
it.
The
DoD
is
published
a
dev
sac
office,
reference
design
that
uses
kubernetes
as
their
dev
psych
ops
platform
to
move
forward,
and
the
Air
Force
has
been
pretty
big
involved
in,
and
that's
the
United
States
Air
Force,
of
course,
and
the
one
of
the
things
that
they've
developed
as
a
part
of
this
whole
program
is
their
do
decentralized,
artifact
repository
and
that's
just
docker
containers.
F
Essentially
that
have
been
gone
through
all
the
requirements
of
the
DoD
and
that's
publicly
available
out
there.
You
can
go,
find
it
and
dig
it
up
and
I
can
share.
Link
system
is
interested,
but
what
they
hadn't
yet
put
together
at
this
point
is
the
same
sort
of
thing
specifically
for
operators,
though
the
I
work
for
salute
who's
put
together.
F
You
know
as
a
part
of
the
deaths,
a
cop's
reference
design,
so
we're
just
getting
started
on
what
all
that
looks
like
exactly,
but
we
had
it
publicly
announced
in
appreciate
all
the
work
that
everybody
else
does.
That
gives
us
a
platform
to
do
that
kind
of
stuff.
So
on
to
the
hey
thanks,
everybody
so
I
appreciate
what
you
guys
all
do
and
thanks
for
the
chance
to
just
share.
A
A
Thanks
for
that
update
I'm,
just
trying
to
look
here,
I
had
a
few
other
people
who
had
things
but
I
do
not
see
them
on
the
call
so
shorts
not
around.
Today
he
was
going
to
give
an
update
on
ansible
stuff
I'm,
not
quite
sure
what
that
was
an
Alexander
Froman
from
Capital
One
there's
also
the
proposal
on
the
compostable
integration
in
the
SDK
operator.
I,
don't
know
if
you
want
to
cover
that
off
today,
Rob
or
you
want
to
hold
that
for
the
next
meeting.
A
A
Third
Tuesday,
that
would
be
the
21st
of
January.
If
no
one
objects
to
that
I
think
by
then
everybody
ought
to
be
back
from
holidays
and
that
is
pre
going
off
to
other
places,
but
yeah.
The
next
meeting
will
be
January
21st.
If
all
the
stars
align
so
I'm
gonna,
let
everybody
have
a
half
an
hour
back
to
their
days
and
then.
B
B
Off,
if
that
sounds
interesting
to
them,
go
for
it,
okay,
so
just
to
level
set
on
the
problem.
So
you
have
a
bunch
of
operators.
They
all
come
from
either
like
open
source
provided
community,
and
then
they
listed
on
docker
hub
or
quite
a
bio
or
a
Red
Hat
registry,
or
some
other
artifactory
registry,
whatever
it
is.
So
when
we
talk
about
disconnected
or
air-gap
clusters.
B
Basically,
if
you
want
to
use
those
operators,
you
need
to
get
both
those
images
into
your
controlled
network
environment,
as
well
as
the
specifications
for
how
to
run
them
in
this
case
is
CSB.
But
if
you
were
doing
like
an
offline
helm
chart,
you
would
still
need
to
get
that
chart,
plus
the
images
that
it
uses
into
the
cluster.
That's
what
we
talked
about
with
air
gaps,
mirroring
disconnected
whatever
you
want
to
call
that
whole
thing.
B
So
the
strategy
that
we're
taking
is
for
folks
to
include
the
images
that
their
operators
require
inside
of
their
CSV,
such
that,
if
you
have
a
tool
like
scope,
EO
that
copies
container
images
around
it
knows
what
container
images
to
copy
in
the
world
of
openshift
we're
doing.
This
for
the
platform
itself,
as
well,
so
to
do
an
offline
install.
B
You
know
you
might
need
4050
container
images
depending
on
you
know,
what's
going
on
and
you
copy
those
into
a
registry,
and
then
you
rewrite
all
those
references,
instead
of
being
those
public
clay
or
artifactory
or
dr.
Hogan
references
to
reference
like
registry,
you
know
my
company
comm,
which
is
accessible
to
your
disconnected
environment,
and
so
the
using
the
new
packaging
format
we
were
talking
about.
B
That
is
a
container
image
is
really
important
for
this,
because,
once
again,
all
you're
doing
is
mirroring
container
images
much
easier
than
having
to
deal
with
any
other
format,
because
you
know
you
can
use
any
registry.
You
can
set
up
your
own.
The
question
here
was
about
the
built-in
internal
open
ship
registry.
You
can
use
all
of
these,
doesn't
matter
what
you
can
do
as
long
as
the
environment
can
pull
those
container
images.
B
B
So
the
idea
would
be
that
you're
getting
the
same
shot
so
you're
getting
the
same
image
just
coming
from
a
different
host
name,
and
so
your
operator
needs
to
support.
You
know
in
air
quotes
templating
that
in
it's
really
just
reading
an
environment
variable
with
a
default
address.
That
would
be
your
public.
You
know
from
clay
or
dagger,
copper
or
whatever
reference
to
that
image
that
make
sense,
and
then
you've
got
your
catalog,
that's
built
as
a
container.
So
you
mirror
that
as
well
and
then
load
that
into
the
cluster.
E
E
I
guess
what
I
was
wondering
I
mean
we've
been
trying
to
go
through
this
and
verify
how
all
this
works.
There
have
been
running
into
a
few
things.
Maybe
we
don't
understand
so
I
mean
in
general.
We
were
thinking.
You
know
that
if
this
I
think
the
idea
here
is
that
if
you
had
an
operator
that
provisioned
something
that
required
an
image
that
was
referenced,
say
in
Quetta
I/o,
you
wouldn't.
D
B
So
there's
basically
two
ways
to
do
this.
The
most
correct
way
is
rewriting
those
references
when
you
build
the
catalog
just
because
it's
gonna
be
the
most
proper
way,
I'm
kind
of
the
fallback
or
the
easiest
way
to
do
this
without
modifying
anything,
is
to
use
that
image
content
source
policy.
Now
this
is
an
open
shifts
property
where
you
can
redirect
where
container
images
are
coming
from.
B
So
once
again,
like
I
mentioned,
the
shah's
are
gonna
match
you're,
getting
the
same
container
image,
but
at
the
container
runtime
level,
you're
saying
hey,
you
know
when
you
used
to
go
to
clay
dot
iot
to
get
this
go
to
this
other
registry
and
instead
and
that's
kind
of
at
the
runtime
level.
So
you
just
you're
basically
doing
like
a
live
swap
of
the
host
name
and
it's
using
there.
The
one
drawback
to
this
is
that
it
does
require
the
container
runtime
to
for
the
machine
to
be
rebooted
to
fully
pick
up
that
change.
B
I,
don't
know
enough
about
why
cryo
requires
this
or
like
what's
happening,
where
the
the
whole
machine
needs
to
be
reset
in
order
for
that
to
happen,
and
so
that
is
the
one
downside
to
that.
But
if
you,
if
you
do
that,
if
you
register
all
these
at
one
time,
then
you're
only
kind
of
updating
once
and
then
you're
good
to
go
versus.
If
you
have
the
catalog
that
rewrites
all
these
references,
you
know
you're
just
doing
it
kind
of
the
more
proper
way.
So
you
don't
have
to
do
that
image,
content,
source
policy
object.
E
D
D
B
E
G
B
G
C
C
B
C
B
That's
one
thing
I
was
going
to
mention
is
so
this
new
addition
to
the
CSV,
where
you
declare
what
objects
you're,
what
operand
images
you're
using?
It
means
that
you
can
mirror
and
create
all
these
objects
at
once
so
you're
not
doing
this
you're
not
doing
500
rolling
restarts
or
whatever
you
would
load
the
500
objects
in
at
once
and
then
do
one
restart.
B
B
So
I
think
we're
finalizing
the
guidelines
and
writing
up
some
some
documentation
on
this
right
now,
but
I
think
it's
basically
done.
The
issue
is
going
to
be
that
every
single
operator,
father
is
gonna,
need
to
go
through
and
do
that.
You
know
because
some
of
these
are
templated
like
directly
in
go
code
and
that
just
needs
to
be
manipulated
a
little
bit.
So
it's
in
that
CSV
instead.
B
So
unfortunately,
it's
like
we're
on
the
timeline
of
you
know
the
entire
community,
but
hopefully
we'll
hit
the
the
major
ones,
and
you
know
the
folks
that
are
popular
and
are
now
selling
their
operators
are
gonna
want
to.
You
know
work
at
these
disconnected
environments,
so
hopefully
we
won't
take
too
long.
I,
don't
really
have
an
estimate
there.
Okay
have.
E
B
That's
effectively
with
the
image
content
source
policy
of
doing
is
that
that
the
runtime
level
versus
the
kubernetes
layer
I,
think
if
you
wouldn't
do
a
PLC
of
that
I
think
that
would
be
kind
of
interesting
to
look
at
I'm
sure
somebody
on
the
the
Red
Hat
side
has
come
up
with
why
we
went
this
route
instead,
but
I
know.
Maybe
this
was
already
just
a
feature
of
the
container
runtime,
and
so
we
just
went
with
it,
but
it
would
be
an
interesting
thing
to
try
as
well
yeah.
B
And
then
we've
got
the
platform
layer.
You
need
to
have
a
registry,
that's
outside
the
cluster,
so
you're
not
using
the
internal
Openshaw
registry,
because
it
needs
to
bootstrap
the
platform
itself.
So
it's
common
for
folks
to
have
like
a
central,
artifactory
or
clay
instance
that
you
know
then
they're
running
a
number
of
clusters
against
I.
Think
that
is
the
envisioned
thing
for
the
disconnected
install
and
now
the
operators
can
be
a
little
bit
different
because
you
could
do
that
after
the
fact.
B
B
At
least
for
the
operators,
where
you're,
because
the
idea
is
you're
you're-
probably
not
going
to
run
one
of
these
clusters-
you're
going
to
run
several
of
them
and
so
by
storing
the
both
the
platform
containers
in
one
spot,
as
well
as
the
operator
and
operand
containers
in
one
spot,
you're
kind
of
vetting
and
copying
them
once
and
then
no
one
has
to
deal
with
it.
Then
you're
loading
in
custom
catalogs
or
these
image
content
source
policies
that
point
to
that
central
registry.
G
G
G
Exactly
so,
you
have
to
use
a
tool
like
scope,
you
or
OC
pod
image
mirror
to
be
able
to
copy
the
images
from
registry,
the
registry
to
preserve
the
manifest
and
the
digest.
Since
it
looks
like
that,
this
image
content
source
policy
only
supports
digest
redirection,
mirroring
the
support
tags,
and
so
a
one
piece
that
it
has
to
be
included
in
that
somehow
is
confer
is
tending
to
fat
manifest
across
deployment.
In
addition
to
just
the
architecture
specific
manifest,
has
anybody
thought
about
that
at
all
I.
B
Know
folks
have
thought
about
this
at
a
high
level:
I,
don't
I'm,
not
tracking
it
closely
enough
to
be
able
to
speak
to
it,
but
I
know
that
you
know
we
do
want
to
support
different
architectures
in
general
across
everything
that
we
do.
Operators
included,
but
yeah
I,
don't
I,
don't
know
if
I
can
speak
to
that.
One
thing
that
I
will
add
is
I.
Think
in
on.
B
If
you're
a
certified
operator
I
know
our
we
have
a
verification
pipeline
that
those
go
through
I,
think
that
was
gonna
audit
act
to
their
current
values
at
the
time
of
the
certification,
and
so
that
you
can
use
this
mirroring
process
correctly,
and
that
would
be
where
it
would.
You
know
append
that
Shawn
replaced
the
tag
inside
of
your
CSV.
B
G
B
G
G
That's
going
to
allow
you
to
make
the
air-gap
you
know:
saving
mirroring
loading
whole
thing,
real,
simple
and
because
I've,
if
you
look
at
your
documentation,
because
there's
that
there's
a
lot
of
that
data,
that
seal
gonna
be
in
the
in
the
CSV
files,
we're
going
to
be
able
to
facilitate
that
mirroring
much
more
easily,
especially
for
heterogeneous
kinds
of
things,
as
it
was
towards
all
out.
So
what
I'll
probably
do
is,
in
the
beginning
of
next
year,
I'm
going
to
try
to
get
this
whole
concept
for
you
guys.