►
From YouTube: OKD Working Group 2021 02 02 Full Meeting Recording
Description
OKD Working Group 2021 02 02
Full Meeting Recording
https://okd.io
A
B
C
C
Well,
tim
had
the
main
presentation
that
he
was
going
to
give
and
I
think
it's
probably
pretty
quick.
We
also
have
a
demo,
but
I've
got
a
repo
with
that
demo
in
it
with
instructions
to
run
it
as
well.
So
if
we
don't
have
time
to
run
through
that,
we
can
just
paste
the
link
and
anybody
interested
and
take
a
peek
there.
So
I
think
that
should
be
doable.
A
Okay,
because
we
have
a
a
lot
on
our
agenda
today,
so
my
vetting
is
here
good,
I'm
there
and
in
the
link,
is
the
the
attendance
thing.
So
if
you
can
do
that,
what
we're
going
to
try
and
do
today
is
because
I
know
we
set
you
up
to
to
do
a
talk
on
this
because
I
like
to
have
people
give
this
because
we're
going
to
try
and
give
updates
from
different
projects
here
that
intersect
with
okd.
A
And
what
I
might
try
and
do
is
get
you
guys
to
do
your
stuff
up
front
in
the
first
10
minutes
or
so
and
then
so
we
can
use,
because
I
just
wanted
to
introduce
you
and
your
topic
to
the
the
group
and
then
you
can
give
everybody
the
resource
links
and
then
we'll
move
into
the
triage
vadim.
Does
that
sound
reasonable
to
you
today.
D
A
Okay,
so,
okay,
well
that
changed
my
plan
for
the
day
so
cool.
Let
me
just
swap
back
out
here
for
a
minute,
then
start
scaring
the
screen.
So
all
right.
Well,
let's
get
started
then
so
one
of
the
things,
my
top
of
my
list
today
was
to
do
the
open,
okd
issues
triage
list,
because
I
wanted
to
see
if
we
could
minimize
the
77-
and
I
saw
this
morning
when
I
woke
up,
it
was
down
to
73..
A
So
that's
a
good
good
thing
and
I
wanted
to
thank
john
fortin
for
stepping
up
and
helping
out
this
past
couple
of
weeks
and
and
making
that
happen.
Vadim,
you
wanna
give
a
quick
update
on
what
what's
going
on
with
closing
some
of
them
and
what
the
status
of
the
release
is
and
then
we'll
go
into.
The
ansible
collections
talk
quickly.
D
D
D
A
So
that's
that's
awesome
news,
so
I
did
notice
that
a
lot
of
people
stepped
up
and
did
some
closing
and
commenting
on
the
issues.
So
thank
you
all
for
that.
Were
there
any
outstanding
questions.
If
we
can
do
this
part
of
the
day
quickly,
then
we'll
get
it
done
from
the
any
of
the
issues
that
people
had
posted.
B
Copy
mirroring
issue
where
the
mime
type
is
wrong,
so
that's
been
fixed
in
the
library
and
now
we
just
have
to
get
that
into
into
the
builds
into
our
image
builder.
So
yeah,
I'm
not
sure
if
there's
a
pr
open
for
that
already,
but
that
is
going
to
trickle
down.
Eventually,
I'm
yeah
we're
just
not
there
yet.
B
E
D
E
A
D
We
have
nightlys
and
eventually
we
will
be.
We
will
release
those
night
listeners
stable,
we're
pretty
far
from
that
like
at
least
a
couple
of
weeks
far
all
right,
but
it
would
be
really
great
if
we
did
this
during
ocp
release
candidate
testing,
so
that
fixes
from
mokidy
and
the
issues
we
had
would
be
prioritized
and
would
be
counted
as
if
they
were
hit
in
oct.
D
F
A
All
right,
if
if
jamie
is
offering
to
do
a
little,
perhaps
a
recipe
or
write
up
on
deploying
how
to
test
with
the
nightlys
for
four
seven
I
can
do
some
outreach
for
us,
maybe
create
a
postcard
in
the
link
and
and
do
some
socializing
of
that
we
want
to
get
that
test
and
and
then
we
can
figure
out.
You
know
how
how
you
want
them
to
just
to
add
the
issues
and
if
we
tag
them
as
four
seven
issues
or
that
would
be
we'll
get
that
updated.
A
And
so,
if
you
give
me
a
release,
link
and
and
that
jamie,
then
I
can
send
it
out
on
mailing
lists
and
other
places.
Let's
see
if
we
can
get
that
going,
joseph's
asking
what
are
the
most
important
fancy
features
in
ocp,
47,
yeah
vadim,
that's
kind
of
what
I
mean.
I
think
this
was
a
stably,
a
stably
release.
D
A
A
A
G
A
I
B
B
One
thing
I
wanted
to
say
with
regards
to
docs
I'd
like
to
really
implore
each
and
every
one
of
you
to
participate
yourself
in
in
the
improvement
of
those
stocks.
It's
all
open
source,
it's
in
the
openshift
docs
repository.
If
you
see
something
like
we,
we
still
refer
to
three
point
x,
or
you
know
that
there's
our
course
mentioned
in
on
that
page.
It
should
be
f
cause
for
okd.
B
Please
feel
free
and
go
ahead
and
open
the
vr
yours
that
that
just
makes
it
so
much
easier
for
for
all
of
us
here
at
redhead,
because
obviously
it's
the
same
amount
of
time
we
we'd
have
to
spend
on
that
and
we
yeah
it's
not
a
high
priority.
So
obviously,
if
you
ask
us
to
do
that,
we're
probably
not
going
to
do
it
right
away.
That
might
cause
frustration
and
you
can
work
around
that
by
doing
it
yourself.
B
A
So
the
the
other,
the
other
side
of
the
coin
too,
is
our
onboarding
and
contribute.
You
know
how
to
contribute
in
the
contributed
contribution
ladder.
Content
on
the
site
is
pretty
weak
as
well
and
amy
merrick
who's
on
the
call-
and
I
sat
last
week
and
did
sort
of
a
quick
audit
and
run
through
of
what
what
what
was
missing
to
make
it
really
easy
for
people
to
get
started
and
do
some
low
hanging
fruit
stuff.
A
So
I
am
going
to
say
that
maybe
every
other
tuesday,
when
we're
not
meeting
here
this
hour,
I'm
going
to
sort
of
dedicate
to
working
on
the
contribution
and
the
onboarding
stuff
in
this
in
the
site.
So
if
other
people
want
to
join,
let
me
know
and
I'll
just
invite
you
to
this
blue
jeans,
and
we
can
just
hack
and
work
our
way
through
that,
because
that
is
vadim.
You've
done
some
amazing
stuff.
Getting
you
know
helping
people
get
stuff
there,
but
there's
some
very
basic
stuff.
A
That's
missing
and
if
you
go
to
there's
a
wonderful
site
that
I've
been
reviewing,
that
that
I'm,
I
have
a
fantasy
that
ours
will
be
as
good
as
it
is
called:
porter
dot,
sh
it's
one
of
the
new
cncf
projects
and
they
have
great
documentation
there.
So
I'm
gonna,
try
and
mimic
some
of
that
stuff
and
with
a
little
coaching
help
from
amy
who's
on
the
call
here.
So
thanks
again
amy,
and
so
anyone
who
wants
to
do
that
kind
of
work
with
me.
J
So
I
joined
the
meeting
after
testing
okd
in
the
past
months,
and
I
I
come
from
the
oval
community,
which
is
kind
of
different
community
than
the
okd
one,
and
the
first
thing
that
I
saw
trying
to
get
into
okd
is
that
it's
kind
of
difficult
for
a
user
to
to
get
user
content
from
from
the
web.
If
you
have
any
trouble
and
you
try
to
search
for
a
solution
on
the
web,
you
don't
find
anything
so.
C
Choosing
to
use
slack
for
both
community
support
as
well
as
development,
is
all
that
knowledge
is
locked
up
and
not
available
for
the
broader
for
the
for,
for
everyone
else
to
you
know,
take
a
dive
in
and
to
learn
from,
and
that's
that's
really
unfortunate,
and
that's
one
of
the
reasons.
I've
been
I'm
kind
of
unhappy
that
we
use
slack
for
all
this
stuff
because
it's
it's
so
closed
and
it's
not
it's
not
fair
to
everyone
else.
Who
wants
to
be
able
to
learn
from
this
stuff.
A
E
K
K
K
K
Yeah,
that's
why
I
think
I'm
at
two,
so
I'm
always
losing
buttons
and
features
for
that
reason,
because
I'm
like
wait.
Oh
that's
on
zoom,
not
on
google.
Oh
that's
blue
jeans,
yeah
anyway.
Sorry,
so
I
wanna
start
here
I'll
fabian
introduce
himself
then
so,
I'm
tim
out
and
I'm
a
senior
product
manager
on
the
ansible
team.
K
I
was
actually
with
the
original
ansible
company
and
I've
been
along
for
the
ride
to
red
hat
and
then
to
ibm
and
I've
been
working
on
how
ansible
can
integrate
with
and
help
automate
things
happening
in
the
container
native
space.
So
one
of
the
things
being
from
you
know,
working
for
red
hat
is
that
we
looked
into
once.
We
started
this
effort,
how
we
could
start
to
help
automate,
what's
happening
in
okd
and
what's
happening
in
openshift
clusters.
K
So
what
I
was
presenting
here
was
like
the
1-0
that
we
came
up
with
initially
and
how
it
came
together
and
I'm
going
to
try
to
just
speed
through
this
there's
a
lot
of
went
on
here
and
we
could
go
a
whole
lot
deeper,
finding
put
together
a
demo
if
we
have
time
for
it.
If
not,
we
can
provide
the
code.
So
I
like
to
say:
that's
that's
my
background.
C
C
Just
have
like
better
sort
of
like
full,
like
application
to
infra
level
integration,
so
that
people
who
are
using
ansible
in
their
like
traditional
I.t
things
can
kind
of
more
easily
transition
to
the
kubernetes
space
without
having
to
up
end
all
their
tooling
logging
monitoring,
etc
and
I'll
cut
it
there.
So
we
have
time
for
the
whole
presentation.
K
Right
thanks
bobby
yeah,
so
the
first
thing
I
should
mention,
if
it's
not
apparent
by
who's
presenting
to
you,
is
that
this
was
a
joint
effort
between
the
ansible
team
and
the
openshift
team.
Fabian
was
one
of
the
engineers
that
came
over
and
worked
with
us
in
developing
this,
and
we
had
some
of
our
own
people
from
the
ansible
team
working
together
on
this.
So
this
is
truly
a
joint
effort
that
happened
out
there.
So
just
diving
in
I'm
gonna
like
say
I'm
gonna
speed
through
this.
K
So
what
we're
talking
about
here
is
one
of
those
collections
that
is
specific
to
working
with
okd
and
openshift
here
so,
like
I
said
just
to
review
that
then,
and
so
so
this
is
to
focus
on
the
unique
capabilities
of
okd
and
openshift
systems.
We
also
have
another
collection,
which
has
been
now
renamed
kubernetes.core
and
that
provides
the
baseline,
kubernetes
and
helm3
automation
capabilities
out
there.
K
On
top
of
that,
then
you
would,
you
would
pull
from
the
community
okd
collection,
a
couple
other
side
notes
if
you
go
out
and
start
researching
this,
that
you
might
become
confused
or
or
or
wonder
about,
is
camino
okd
is
the
upstream
of
a
collection
called
redhat.openshift
and
that
that
is
the
supported
offering
that
we
put
together
and
put
out
there
to
customers.
So
it's
one
in
the
same.
It's
just
one
once
the
the
downstream
and
once
the
upstream
of
that
content.
K
Another
quick
side
note
is
originally
our
kubernetes
content
started
off
as
a
community
effort
and
was
called
community.kubernetes
we're
going
through
the
process
of
changing
the
name
and
migrating
the
repo
things
like
that,
so
they're
they're,
essentially
the
same,
but
the
community.kubernetes
is
going
away
for
marketing
and
business
reasons,
and
it's
going
to
be
called
community
kubernetes.com
all
right.
So
that
was
just
a
little
background.
So
you
know
what
you're
looking
at
here.
K
So
let's
talk
about
what
is
in
this
collection,
so
so
what
we
did
when
we,
when
we
pulled
together
this
effort
last
summer,
to
make
something
that
was
supportable,
that
we
put
full-time
resources
on
we
worked
together
with
is
we
we
looked
at
the
what
was
in
that
community
kubernetes
collection
and
said
all
right?
We
need
to
break
this
into
two
parts,
because
what
had
happened
is
it
was
just
done
through
community
contributions
coming
in
and
it
was.
K
It
was
mostly
baseline
kubernetes,
but
some
openshift
specific
features
had
rolled
in
and
then
we
were
getting
kind
of
complaints
from
both
sides,
people
that
were
trying
to
use
opd,
openshift
and
saying
hey.
This
is
missing,
and
then
there
were
people
on
the
baseline,
kubernetes
crowd
coming
to
us
and
saying
hey.
What
is
this
stuff?
K
That's
in
here
that
it's
operating
different
than
it
should
so
we
decided
the
best
thing
to
do-
was
then
to
to
split
this
stuff
out
into
their
own
collections,
so
that
they
could
both
move
and
focus
on
each
other's
communities
better,
rather
than
trying
to
find
this
like
middle
ground.
So
that
was
the
the
one
of
the
first
big
things
that
fabian
and
other
engineers
took
on.
K
So
one
of
the
things
that
was
a
little
interesting
that
we
went
through
is
ansible's
added
name
spaces
and
we
decided
to
make
use
of
that,
and
so
we
had
the
kate's
module
that,
like
I
said,
handled
the
baseline
kubernetes
declarative
apis.
So,
rather
than
create
a
a
totally
different
named
one,
we
decided
to
use
the
kate's
name
again,
because
there
you
don't
have
to
do
it
fully
qualified
like
like
I've
shown
here.
K
It
would
make
it
a
lot
easier
for
people
to
move
or
or
port
their
playbooks
between
baseline
kubernetes
and
then
moving
to
openshift
in
that
regard,
because
then
they
would
just
have
to
switch
what
name
space.
They
were
pulling
that
module
from
so
there's
a
little
side,
note
more
advanced
thing,
and
then
we
created
a
few
modules.
So
this
is
an
area
that
we
were.
We
went,
did
a
quick
survey,
and
so
what
are
the
most
common
things?
K
A
K
Yes,
as
long
as
yes,
there
should
be
no
no
issue
there.
You
just
have
to
be
put
a
little
bit
of
care
into
how
you're
managing
your
name
spaces.
If
you
do
it
fully
qualified,
like
I
showed
back
here,
you
would
have
to
do
a
search
and
replace,
but
you
don't
have
to
do
it
this
way
and
I
would
recommend
not
doing
it
this
way.
K
F
C
K
A
K
Yeah,
that's
more
of
an
we've
done
it
for
awareness
and
also
clarity
when,
when
you're
dropping
in
a
single
task
to
document
something
you
don't
see,
all
the
other
stuff
you
could
have
done
at
the
command
line
or
in
the
playbook
declaration,
and
people
may
get
confused
over
time.
As
you
have
modules,
with
the
same
name
appearing
in
different
collections
entirely
that
it
was
it's
just
for
clarity
of
that
type
of
documentation.
K
A
K
C
C
A
C
Yes,
now
I
can
read
it:
okay,
all
right.
Let's
see,
this
is
gonna,
be
a
little
rough
okay,
so,
basically,
first
I'll
just
run
through
what
the
image
stream
changes
that
we
did
and
essentially
what
we
did
was
we
made
it
so
that
operator,
authors
who
were
using
deployment,
configs
or
deployments
with
image
streams
had
this
issue
where,
because
they
specified
an
image,
it
would
their
operator
and
and
the
openshift
controllers
would
constantly
wrestle
over
the
image
field.
C
So
that's
one
of
those
nice
changes
and
it's
kind
of
difficult
to
see
what's
going
on
with
with
the
size,
but
this
is
just
basically
letting
you
know
that
the
industry
has
probably
been
created.
This
is
like
you
know
what
it
is,
what
the
status
of
it
is
now
we're
creating
the
deployment
config,
and
this
is
mostly
just
show
you-
the
resources
being
used
with
these.
Mostly
it's
just
you
just
send
it
the
raw
yaml
the
same
as
the
cli
utilities,
basically
deployment.
C
C
It's
the
python
one,
it's
just
spinning
up
an
http
server
so
that
we
can
make
sure
that
our
requests
work
and
then
here
we're
going
to
issue
this
partial
update,
it's
a
patch.
So
it's
targeting
this
hello
world
dc
deployment
config
we
just
made
with
just
the
small
bit
that
we
want
to
change.
Ansible
will
use
that
to
create
a
patch
request,
telling
it
to
replace
the
python
image,
but
we're
already
using
the
python
image.
C
So
nothing
should
change
and
we
can
see
here
that,
in
fact
the
task
was
marked
as
ok,
not
changed,
which
means
that
no
actual
change
was
made
in
the
kubernetes
api,
and
you
know
the
nothing's
going
to
be
redeployed
and
if
you
were
in
an
operator
context,
you
wouldn't
just
be
spinning
now
forever
in
an
infinite
loop,
spinning
up
hundreds
and
hundreds
of
deployment
configs
over
the
course
of
minutes,
which
is
what
users
were
hitting
before.
So
here
we're
doing
the
same
thing:
creating
a
deployment.
C
C
So
we
created
the
deployment
reference
unit
stream
and
then
here
we're
going
to
do
a
similar
thing
just
issue.
A
partial
patch
only
update
the
image,
which
should
do
absolutely
nothing,
and
indeed
it
does,
and
we
can
also
see
that
the
actual
image
that
is
being
used
is
the
one
set
by
the
image
stream
rather
than
the
one
set
by
the
user,
and
we
were
able
to
detect
and
avoid
and
unnecessary
update
that
there.
C
C
You
can
do
either
inline
or
files
on
disk
it'll
work,
fine
right
away,
and
then
here,
rather
than
having
to
craft
the
route
definition
by
hand,
we
have
this
open
shift
route
module,
which
is
the
same
basic
functionality
as
the
route
specific
features
in
openshift
and
oc
expose,
as
well
as
oc,
create
route
but
re-implemented
with
python,
though
it
integrates
with
the
ansible
code
better.
So
we
can
see
like
with
this.
C
We
just
specified
the
service
we
wanted
to
expose
with
the
namespace
we
wanted
to
expose
it
in
and
it
was
it
created
this
route
spec
based
on
that
it
parsed
the
target
forwards
from
the
service.
You
know
all
the
things
that
users
would
expect
and
we
can
see
hit
that
url,
that
the
content
we
get
back
is
the
hello
openshift
from
that
hello,
openshift,
container
clean
up
that
route
and
then
I'm
gonna
skip
through
most
of
these.
C
I
mostly
just
added
them
in
here,
for
you
know,
if
anyone's
interested
in
wanting
to
go
through
to
see
all
the
different
things
they
can
expose,
but
you
can
create
routes
with
custom
names.
You
can
create
routes
with
different
termination
policies
that
allow
insecure,
don't
allow
and
secure,
or
you
know,
have
redirection
basically
everything
that
you
could
do
with
openshift
create
route
or
openshift
expose.
C
That
create
cigarette,
this
created
the
identity
provider,
and
now
we
create
the
user,
create
the
cluster
role
binding.
This
task
is
using
one
of
the
modules
from
the
community
of
communities
soon
to
be
kubernetes.core
collection,
in
order
just
to
get
information
about
the
cluster.
What
apis
it
supports,
what
you
know,
what
host
and
connection
cert
file
like
all
the
different
information
about
what
the
cluster,
what
cluster
we're
connected
to
and
how
we're
connecting
to
it.
So
now
we'll
issue
this
login
command.
C
I
C
C
C
C
C
C
We're
going
to
just
use
this
basic
case
info
module
to
list
all
the
pods
in
the
testing
namespace,
which
is
the
namespace
that
we
were
running
those
initial
industry
tests
in.
So
we
can
see
that
that
user-
hopefully
yes,
that
user
does
have
the
permissions.
So
we
we
logged
in
as
that
user
and
the
user's
permissions
were
properly
configured
to
list
all
those
pods
that
we
defined
in
that
in
that
previous
playbook
and
then
just
the
last
one
here.
C
So
this
is
just
basically
the
openshift
process,
oc
process
subcommand,
but
you
know
accessible
via
a
module,
so
you
can
either
you
can
target
local
templates.
You
can
target
templates
in
the
cluster.
You
can
either
render
them
and
get
the
list
of
rendered
resources
back,
which
you
can
then
store
and
then
create
by
hand
in
the
cluster,
or
you
can
just
say
you
know,
rent
like
render
and
then
create
all
the
resources
in
a
single
task.
C
C
Ignore
those
warnings,
yeah,
basically
pretty
straightforward
and
then
here
same
basic
thing,
but
we're
just
letting
the
module
handle
creation
as
well,
and
it's
just
gonna
basically
run
the
same
logic
and
since
it's
the
same
template
with
the
same
parameters,
it
actually
shouldn't
really
result
in
any
actual
work
being
done,
yeah.
So
all
right,
and
then
this
is
the
last
little
bit
of
the
demo.
C
So
this
is
demoing
the
inventory
and
connection
plugins,
and
what
this
basically
allows
you
to
do
is
if
you
just
configure
that
you
want
to
use
the
okd
that
openshift
inventory
plugin
it
can
basically
just
when
ansible's
starting
up
it
will
query
the
cluster.
You
can
trim
it.
You
can
have
multiple
clusters
in
in
your
inventory.
You
can
have
multiple
namespaces
or
all
namespaces,
but
basically
it
will
go
out
to
all
the
different
pods
and
add
them
to
the
ansible
inventory
as
targetable
hosts.
C
C
If
it
failed,
it's
probably
it
looks
like
it
was
a
build
image,
so
it
failed
because
it
was
not
a
an
image
that
had
python
in
it.
I
think,
but
we
can
see
here
that
we
had
our
hello
world
deployment
image
and
our
hello
world
dc
container
and
our
hello
world
dc
container,
the
ones
that
we
defined
in
that
initial
image
stream
example
that
are
in
the
testing
name,
space
like
they
both
were
found
discovered
and
we
were
able
to
reach
out
and
get
information
from
them.
C
C
So
we
can
see
there
on
both
of
those
two
hosts
that
it
found
that
were
successful.
The
test
environment
was
defined
and
its
value
is
what
we
set
it
to,
and
then
this
is
just
showing
that
you
can
also
then
use
the
the
copy
and
flirt
modules
to
copy
content
back
and
forth
between
the
cluster
and
the
host
and
retrieve
file
content
and
assert
that
that
content
is
the
same.
C
Except
I
skipped
one
of
those
tasks
but
yeah,
that's
basically
it
that's
the
demo.
I
had
prepared
apologies
for
the
the
choppiness
of
it
at
the
times,
but
basically
we're
just
trying
to
make
it
so
that
the
experience
of
using
ansible
to
automate
your
workflow
is
got
like
all
the
same
functionality
as
as
using
bash,
but
with
all
the
niceness
of
using
ansible
like
idempotence,
you
saw
there
my
demo
crashed
a
couple
times.
I
was
able
to
run
through
it
without
everything
being
changed
and
constantly
redeploying
or
anything
so
yeah.
K
Yeah,
so
thanks
thanks
bobby
it
was,
that
was
great.
Hopefully,
it
got
across,
like
all
the
different
things
that
you
can
do
to
to
automate
and
cut
down
on
all
the
command
line
stuff.
You
would
have
to
do
in
manual,
work
and
repetitive,
work.
Every
time
you
would
deploy
a
cluster
or
do
anything
the
the
the
big
question
that
we
have
for
for,
for
you
is
besides
using
it
trying
out
seeing
how
we
did
in
our
our
1-0.
K
Is
you
know
what
could
we
do
next?
What
do
you
want
to
see
in
this
next
there's
there's
a
lot
of
areas
that
we
didn't
touch
on
and
the
question
we
kept
asking
ourselves
was
well.
Would
that
be
useful,
well,
which
one
of
these
is
a
priority,
which
one
is
not
that's
the
type
of
feedback
that
we're
looking
for?
We
got
a
good
core
set
of
feedback,
mostly
from
from
red
hat
consultants
and
a
couple
other
people.
K
We
knew
in
the
community
that
were
doing
work
with
ansible
and
openshift,
and
they
gave
us
that
initial
batch
of
use
cases
and
we've
essentially
covered
them
all
right
now,
so
we're.
Where
do
we
go
next?
So
that's
the
feedback
we'd
love
to
hear
for
those
of
you
who
are
interested
like.
I
will
give
this
deck
to
diane
to
to
send
around,
but
these
are
some
of
the
repos
of
the
content.
K
You
were
looking
at
starting
with
fabian's
the
demo
code
that
he
was
just
running
through
and
and
the
repos
where
we're
developing
the
collections
we've
been
talking
about
and
then
there's
a
bunch
of
blog
posts.
If
you
want
to
go
deeper
and
and
read
about
this
stuff
in
in
more
detail,
maybe
more
elegantly
than
I've
been
speaking
about
it.
So
that
is
all
that
we
had.
A
Well,
that
sounds
good
it.
I
think
we
could
use
some
feedback
from
the
community
on
maybe
some
maybe
more
useful
examples.
The
example
was
good
fabian
that
that
was
bad,
but
just
how
people
would
use
this
in
in
production
and
so
joseph
and
other
folks
who
are
doing
that
your
feedback
will
be
most
welcome.
B
C
No,
so
the
content
there
was
mostly
focused
on
just
kind
of
like
providing
those
basic
building
blocks
kind
of
the
foundational
work
in
order
to
allow
us
to
build
more
things.
On
top
of
that,
but
collections
do
allow
you
to
currently
distribute
roles
and
I
believe
in
the
future,
it's
planned
to
allow
you
to
distribute
playbooks
as
well,
and
so
the
hope
is
that,
as
we
sort
of
build
this
out,
get
more
community
involvement,
get
some.
You
know
better.
Subject
matter
experts
I
deal
a
lot.
C
You
know
working
with
operators
with
the
kubernetes
api
and
low-level
components,
and
things
like
that.
I
have
less
experience
with
sort
of
higher
level
cluster
administration,
and
so
that's
definitely
like
we.
We
would
love
to
have
playbooks
and
roles
in
or
that
would
enable
users
to
like
very
easily
automate
those
tasks.
But
you
know
that's
sort
of
like
now
is
the
point
where
we
go
out
to
the
community
and
and,
like
you
know,
look
for
people
who
who
know
about
that.
C
Don't
necessarily
need
to
do
all
of
it,
but
if
they
have,
you
know,
requests
for
features
like
that
documentation.
Maybe
some
like
getting
started
places
like
that.
Those
would
all
be
very
useful
things
for
us
to
see
pop
up
in
that
repo
in
order
to
help
us
prioritize
and
also
in
order
to
help
us
understand
what
exactly
those
cluster
administration
tasks
are
and
how
we
can
help
automate
them.
C
H
Wait
so
I
I
just
hopped
on
maybe
halfway
through
the
thing.
Sorry
well,
okay!
Well,
I
was
actually
going
to
ask
something
on
your
behalf.
Sorry,
I
guess
now
that
you're
here
you
can
ask
yeah
yeah
they're
they're
speaking
specifically
to
like
cluster
administration.
One
of
the
things
that
has
you
know
been
a
pain
point
in
deploying
new
and
newer
new
clusters.
Fresh
clusters
is
like
the
simple
things
like
approving
certificates
and
stuff.
Like
that,
I
didn't
see
anything
specifically
in
your
demo
about
like
those
sorts
of
like
one-off
kind
of
deals.
H
It
was
more
about
like
making
gambles
and
pushing
gambles
into
places,
and
I
know
you
can
sort
of
hack
the
existing
kubernetes
plug-in.
You
can
do
some
stuff
and
like
write
some
ansible
magic.
That
would
be
really
brittle,
but
we're
supporting
workflows
like
that,
like
maybe
specifically
certs,
because
that
is
such
a
pain
point-
would
be
really
cool
to
see.
C
When
you
can't
use
the
ipi
style
orchestration
like,
for
example,
at
work,
we
have
an
open
stack,
that's
sufficiently
old,
that
the
ipi
cannot
orchestrate
it,
and
so
we
have
to
do
upi-based
deployments
and
it
would
be
very
nice
if
upi
wasn't
a
pain
to
do
and
a
lot
of
this
comes
from.
We
previously
orchestrated
using
ansible
for
openshift
3x,
and
there
is
basically
no
automation
path
for
openshift
forex
for
a
upi-based
deployment
and
that's
sort
of
like
that's.
A
K
K
It's
like
the
installer
gets
you
so
far,
but
then
it
gets
you
to
a
point
where
you
need
to
do
additional
things
to
make
that
cluster
useful
and
those
things
are
probably
very
specific
to
what
you're
trying
to
do
with
that
cluster,
that
it's
hard
for
an
installer
to
capture
it
all.
And
then
it's
doing
all
those
repetitive
tasks,
and
I
don't.
K
H
Huge
pain
on
upi,
like
I,
your
what
you're
describing
is
exactly
my
experience.
I
have.
I
have
basically
a
bash
script
and
the
first
half
of
the
bash
script
is
use
the
installer
to
get
the
cluster
going
and
the
second
half
is
slam
yaml
file
after
yaml
file
into
it.
In
order
to
get
it
to
a
point
where
I
can
actually
use
the
thing
in
the
right
order,
with
sufficient
amount
of
retries
with
some
blind
hope
and.
B
I'd
just
like
to
I
think
point
out
here
is
that
this
ansible
project
is
probably
not
meant
for
installing
the
cluster.
At
least
that's
not
the
focus
or
it
shouldn't
be,
because
I
think
there
was
a
a
decision,
an
informed
decision
made
not
to
repeat
the
installer.
We
had
in
origin,
three
point
x,
so
yeah,
I'm
not
sure
how
much
you
want
to
focus.
No,
no,
no.
H
It's
not
it's
not
nice
if
things
like
that
could
be
more
like
I'm
not
asking
for
another
open
shift.
Ansible
like
we
had
for
3x
right.
That
was
that
was
its
own
special
variant
of
pain,
but
I
think
I
think,
for
this
kind
of
stuff
it
would
be
nice
if
the-
and
I
guess
this
is
one
of
those
things
where
we
will
just
have
to
sort
of
play
with
it
as
a
as
a
community
and
figure
it
out.
H
But
there's
a
lot
of
these
sort
of
like
the
cert
approval
things
like
that,
and
I
would
think
making
it
a
little
bit
more
templated
in
terms
of
like
deployment.
Configs
would
also
help
a
whole
bunch
just
for
like
making
it
quicker
for
people
to
spin
up
their
own
ansible
playbooks,
because
right
now
it
is
highly
highly
manual
to
write
all
of
the
animals
out
in
ansible,
and
I
think
you
guys
are
already
getting
there.
But
yeah.
C
You
can
confirm
the
cert
being
valid
without
the
ipi.
Just
fine,
if
you
know
what
the
master
cert
is
and
that's
part
of
your
playbook
or
whatever,
like
we
have
a
copy
of
this
of
the
parent
cert
inside
the
bash
script,
and
it
just
checks
that
to
see
if
that's
what
it
was
derived
from
and
that's
again,
that's
stupid
and
manual
and
horrible.
C
But
it
is
still
it
is
not
throwing
your
hands
up
in
the
air
and
saying
upi
is
impossible
to
automate
is
basically
the
wrong
approach
for
making
this
successful,
because
I
can
promise
you
almost
100
percent
of
all
small
use.
Workloads
are
going
to
be
upi
because
a
none
of
the
ipis
work
just
zero
of
them
work,
and
so
you
can't
say
upi
is
effectively
unautomatable
like
you
have
to
start
looking
at.
B
Yeah,
let
me
jump
in
here
again.
I
think
that
again
is
a
huge
opportunity
for
the
community,
for
you
neil
to
step
up
and
contribute
some
playbooks
there.
I
think
yeah
with
upi.
Obviously
we
prefer
everybody
to
use
ipi
it's
much
easier.
We
have
a
much
clearer
picture
of
the
the
cluster
we
we're
getting
in
the
end
that
is
kind
of
what
we're
aiming
for
right.
B
So,
if
you
use,
if
you
have
to
use
upi,
if
that's
your
only
option,
then
so
be
it,
but
we
can't
really
account
for
all
the
different
there's
just
vastly
different
setups
there,
and
so,
if
you
have
one
that
you
think
is,
has
a
broad
enough.
You
know
it
is
applicable.
It
is
applicable
in
a
in
a
big
number
of
cases.
A
Yeah
so
guys
we're
we're
also
ready,
for
that
would
be
great
we're
at
the
end
of
the
hour,
which
is
what
happens
to
us
every
week
and
so
yeah
neil.
If,
if
there's
a
broad-based
one
that
we
could
do
to
solve
a
group
of
them
or
at
least
get
a
good
recipe
done,
that
would
be
a
great
contribution
to
get
started
and
maybe
working
with
the
ansible
collections
folks
to
get
it
tested
and
will
be
a
good
good
thing
to
do.
C
Yeah,
I
know
it's
work
and
it's
it's
not
that
it's
work.
I
don't
care
about
that
part.
My
fundamental
problem
is
that
the
way
that
the
open
shift
installer
has
been
has
been
designed
is
that
it's
either.
I
know
all
the
things
or
I
know
none
of
the
things.
That's
not
an
acceptable
path
for
making
it
a
true
successor.
You've
got
to
be
able
to
make
the
installation
process
more
composable.
I
would
love
it
if
the
ipi
steps
that
are
part
of
openshift
installer
were
just
pieces.
I
could
invoke
separately
and
I
could
say
well.
C
This
piece
doesn't
apply
in
my
stuff
and
I
can
just
call
the
rest
of
it
do
second
stage
through
ipi
and
first
stage
through
myself
like
that
is
not
even
possible.
There's
no
plugable
back
ends
like
this
is.
There
is
no
avenue
to
make
this
better.
As
far
as
I
can
tell
other
than
writing
all
the
crap
from
scratch
over
and
over
and
over
again
and
that's
frankly,
not
good.
B
And
that's
my
problem.
Obviously
we
do
test
upi
in
an
automated
vi
setup
and
if
that
were
you
know
more
agnostic
to
to
the
underlying
platform,
I
guess
you
could
use
that
everywhere,
but
that
is
that
just
works
on
rci,
because
it's
set
up
for
that
and
with
upi
you
just
have
to
each
time
adapt
it
to
the
environment
you're
setting
it
up
in
so
it's
it
is
difficult
to
account
for
all
of
that
and
if
you
want
to
account
for
all
these,
you
know
options.
B
Then
you
end
up
with
something
like
the
ansible
installer
in
okd
free.
So
you
know
there
is
some
trade-off
to
be
made
here
and
I
think
we're
definitely.
You
know
if
you're
able
to
use
ipi
it's
much
easier
that
way,
and
you
should
do
that.
Obviously,
that's
not
going
to
help
anybody
who
isn't
able,
but
still,
I
think
I
want
to
just
highlight
that
the
ipi
install
workflow
works
really
really
well
and
much
better
than
in
openshift
3.0.
A
And
there's
a
little
conversation
on
the
side
that
I
want
to
encourage
sandro
to
continue
to
have
offline,
maybe
on
the
the
google
mailing
list
that
we
have
to
continue
this
conversation,
because
we
are
out
of
time
today.
It's
a
good
and
it's
a
healthy
conversation
to
have
neil
so
we'll
keep
poking
it
and
making
the
install
look
better.
L
You
know,
like,
I,
don't
want
to
say
an
interface
or
an
api,
but
something
they
could
write
to
to
make
it
easier
for
providers
to
plug
into
that,
and
it's
not
the
exact
same
thing
that
like
neil
and
sri
are
talking
about,
but
it's
kind
of
in
the
same
area.
I
think
you
know
yeah
it's
going
that
direction
so.
C
I
mean
if
that
existed.
If
that
existed,
there
is
a
much
easier
path
for
even
me
to
orchestrate
within
our
internal
infrastructure,
because
things
are
kind
of
special
because
of
reasons,
but
but
it's
still
a
cloud
infrastructure
platform.
It's
still
openstack
right
right,
it's
a
software
defined
fabric,
so
I
should
be
able
to
do
that,
but
there's
just
no
avenue
to
plug
those
things
in.
L
Right
so
I've
been
the
long
and
the
short
is
it
doesn't
exist.
It's
very
much
a
an
idea
right
now,
but
people
are
thinking
about
this
idea
and
we're
especially
thinking
about
it
in
terms
of
how
do
we
open
up
the
installer
so
that
we
could
allow
more
platforms
to
write
to
the
installer
without
needing
to
go
through
this?
L
You
know
huge
process
of
creating
a
machine,
api
implementation
and
then
reviewing
that
and
then
getting
it
into
the
installer
and
then
reviewing
you
know,
there's
a
lot
of
chicken
and
the
egg
problems
that
go
on
here.
So
I've
just
given
you
a
little
window
into
the
sausage
factory
here
of
kind
of
things
that
I've.
C
L
A
Not
quite
yelling,
but
it
is
neil
it.
It
is
not
to
say
that
your
concerns
aren't
heard
or
anything
it's
just.
We
yeah
trying
to
figure
out
how
we
can
move
from
the
community
point
of
view
as
well
to
get
some
content
or
some
basic
stuff
started,
even
if
it's
a
stub
to
move
this
forward,
and
if
you
and
sri
have
that
bandwidth
to
even
get
there,
that
would
be
helpful
so
and
and
yes,
your
passion
is
totally
fully
taken.
Well,.
C
Yeah,
both
of
us,
I
think,
are
wanting
to
clean
up
the
the
upi
stuff
that
we
did
and
make
that
kind
of
publicly
available
on
the
openshift
org
somewhere
as
a
cookbook
or
whatever,
but
like
the
it
highlight.
I
just
wanted
to
highlight
the
general
problem
that
we
have
where
these
kinds
of
things
are
just
difficult
to
create
and
then
maintain,
because
the
underlying
architecture
of
openshift
installer
is
so
hostile
to
this
kind
of
stuff,
and
that's
that's
something
that
really
needs
to
be
rethought.
A
Yeah
well
rethinking
for
a
the
next
meeting,
I'm
going
to
reiterate
and
I'll
put
a
note
out
on
the
google
group
about
if
people
want
to
come
and
talk
about
docs
next
tuesday.
At
this
same
time,
I
think
what
I
want
to
use
is
the
other
week
to
do
doc's
work
and
have
conversation
about
how
to
move
that
forward.
So
I
will
do
that
and
yes-
and
we
do
want
to
invite
neil
to
as
many
team
meetings
to
keep
spurring
people
on.
A
A
Thank
you
for
coming
on
our
youtube
channel
and
if
you
want
to
redo
it
fabian
and
timothy
as
a
like
a
little
short
briefing
or
I
can
just
edit
out
your
stuff
into
a
short
little
video
clip,
I
mean
fabian.
If
you
want
to
redo,
maybe
your
demo
I'll
happy
to
re-record
it
or
have
you
re-record
it
and
share
that
out
with
the
universe
as
well.
A
So
thanks
for
all
of
your
work
and
hopefully
we'll
get
you
some
there
and
openshift
commons
content,
I
always
want
openshift
commons
content,
but
I
want,
I
think
I
want
this
sooner
than
I
can
schedule
a
an
ama
briefing
on
it
because
I
think
I'm
booked
out
until
the
end
of
march
now
so
yeah
so
fabian.
If
ping
me
on
in
google
chat,
if
you
want
to
re-record
or
if
you're,
okay
with
me
using
it,
as
is
I'll
I'll,
just
snip
it
out.