►
From YouTube: Kubernetes SIG Apps 20191216
Description
Led by: Matt Farina
Co-hosts(s): Janet Kuo, Adnan Abdulhussein
Demo:
- Application Navigator - https://github.com/kappnav - Chris Vignola
- Addon Discovery - https://github.com/njhale/addon-discovery - ecordell/nhale
Discussion:
- CronJob test flake: https://github.com/kubernetes/kubernetes/issues/86179#issuecomment-566133712
- A design doc to move cronjob to GA is being developed by folks at Google
A
Welcome
to
the
December
16th
2019
kubernetes,
sig,
apps
I
will
go
ahead
and
share
the
agenda
and
notes
into
chat
here
for
everybody
to
follow
along
at
home.
I
think
the
one
announcement
that
we
have
is
that
due
to
the
holiday
season,
well,
there's
low
turnout
for
this
meeting
today
and
we
are
not
meeting
again
in
two
weeks
just
due
to
the
proximity
of
holidays
and
so
many
folks
not
being
around.
So
that's
the
one
announcement.
Did
anybody
have
any
other
announcements.
A
B
B
B
A
B
B
B
Okay,
so
quick
background
on
this
about
a
year
or
so
ago.
So,
first
of
all,
my
name
is
Chris
Vignola
I
work
for
the
IBM
corporation
and
we
have
been
doing
a
lot
of
work
on
the
kübra
with
the
kubernetes
platform
in
in
the
last
couple
of
years,
or
so
like
so
many
other
vendors
in
the
industry
and
for
some
of
the
customer
use
cases
that
we
were
interested
in
addressing
for
our
customer
set.
B
We
we
observed
that
the
the
need
for
an
application
concept
to
provide
some
aggregation
of
resources
and
provide
a
higher
level
abstraction
for
users
to
interact
with
their
applications
on
the
kubernetes
quad
level
would
be
a
good
thing
and
right
about
the
time
we
started
to
do
that.
We
came
upon
the
the
application
CRD
that
that
that
this
body
had
created
and
and
looks
just
like
what
we
needed,
and
so
rather
than
invent
something
on
around.
You
opted
to
use
the
application
CRD
for
what
we
were
doing
and
we
started
it.
B
You
know
IBM
as
a
mixed
record
of
doing
open
source
and
closed.
You
know
and
proprietary
and
and
while
there
are
a
number
of
things
like
eclipses
and
things
like
that,
that
we've
done
in
the
open,
this
was
something
that
we
started
not
in
the
open
and
as
we
moved
along
with
it,
it
occurred
to
us.
It
would
be.
B
You
know
much
smarter
to
to
do
this
piece
of
work
in
the
open,
and
so
we've
moved
it
to
to
the
open
and
it's
out
on
github,
it's
called
K
at
NAB,
and
so
I
wanted
to
show
you
what
we've
done
with
the
application,
with
the
use
of
the
application,
see
Rd
just
kind
of
get
your
guys.
Thoughts
on
you
know
is
this
interesting
beyond.
You
know
what
what
what
IBM
created
for
for
for
its
own
self-interest?
B
Initially,
it
doesn't
have
any
utility
beyond
that
and
if
so,
we'd
like
to
talk
to
y'all
about
that
further
we're
interested
in
your
reaction.
Generally,
you
know,
regardless
of
whether
there's
you
know
a
broader
applicability
for
this
for
this
code,
and
you
start
with
just
I've,
got
two
slides:
I'll
show
you
a
demo,
okay,
so
just
architectural
II.
B
You
know
UI
based
interface,
of
course,
and
we've
got
two
two
pods
three
containers,
essentially
so
there's
a
UI
there's
a
back-end
for
front-end
pattern
to
facilitate
the
UI
and
those
backing
the
api's
happen
to
be
shared
by
a
controller
that
we
wrote
now
wanted
to
call
that
out
specifically
that
we
we
we
opted
to
build
our
own
controller,
because
there
were
some
things
that
we
wanted
to
do
that
we're
not
in
the
the
controller.
That's
that's
in
the
the
cig
project.
B
In
fact,
we
started
early
enough
with
this
that
the
controller
and
the
sinc
project
was
really
just
a
shell
at
the
time.
So
we
didn't
even
pick
up
the
shell.
We
just
you
know
we
had
a
cello
around.
We
worked
from
there.
I
have
seen
that
the
the
application
SIG's
application
controller
has
has
evolved.
B
Since
we
first
looked
at
it,
you
know,
but
we
we
built
a
fair
amount
of
code
into
this
one
that
we've
got
I'll,
show
you
what
it
does,
okay,
so
let's
go
and
look
at
the
app
navigator,
we're
running
this
on
open
shift
at
the
moment.
So
here
we
see
the
three
three
pod
types
that
we've
got
and
let's
see
three
controller:
oh
yeah,
we
have
an
operator,
I
didn't
show
that
on
the
slide
and
then
the
app
navigator
itself.
So
nothing
fancy
if
you
think
about
the
application
CRD.
B
B
Yet
alright,
and
so
we
were
to
I'm
gonna,
add
an
application.
We
have
a
sample
we
like
to
use
called
stock
trader
and
what
happens
is
when
it
gets
started.
When
we
add
the
application
you'll
see
that
stock
traders
at
the
top
it
status
indicates
problem.
That's
because
the
the
deployments
for
stock
trader
require
one
replica
and
we
don't
have
any
replicas
yet
so
it's
system.
This
is
a
high-level
way
of
the
system.
B
The
system
of
the
application
navigator,
informing
that
you
know
that
normal
operational
statuses
has
not
been
achieved,
but
you
see,
even
while
speaking,
that
the
the
visualization
changed
we
went
from
red
to
green
as
the
pod
started,
and
it
stock
trader
achieved
its
it's
a
its
operational
policy
and
then
it
this.
This
visualization
is
alphabetical
by
name
so
once
it
went
into
normal
state,
he
got
pushed
down
to
the
bottom
here:
okay,
so
bubbles
up
higher-level
status
indicators,
like
you,
saw
a
moment
ago
problem
got
bubble
to
the
talk
to
try
to
catch
your
attention.
B
What
you'll
see
is
a
list
of
components
that
are
gathered
together
based
on
the
label
selector
in
the
application
CRD,
and
so
nothing
particularly
surprising
about
that
either.
Now
we
indicate
the
of
course,
the
the
name
kind,
cetera
of
the
components
that
match
the
label
selector
as
you'd
expect
again
this
concept
of
status,
which
I
will
go
into
a
slightly
more
detail
in
just
a
moment.
I've
got
one
slide
on
that
I'm
kind
of
be
done
repeats
here
as
well.
B
There's
an
action
menu
on
the
side
and
I
want
to
tell
you
about
that
as
well.
That's
number
one
of
our
distinctives
here,
there's
some
configurability
that
I'm
going
to
tell
you
about,
and
since
it's
displayed
in
front
of
you
there's
an
oddity
here
but
might
strike
you
as
an
oddity
that
I
want
to
clarify
this
kind.
B
The
kind
is
deployment
right,
as
opposed
to
say
service
and
it's
suffix,
with
dot
Liberty
we've
devised
a
convention
whereby,
when
it
comes
to
deployments,
we
add
an
annotation,
we
can
add
an
optional
annotation
that
further
designates
what
kind
of
deployment
we're
talking
about,
and
that
has
a
relationship
to
these
action
menus
which
I'll
show
you
in
just
a
moment.
Okay,
so
that's
the
distinguish
a
say:
a
liberty
deployment,
that's
open,
Liberty
from
open
Liberty,
do
some
Java
stuff
from
say
a
nodejs
deployment.
B
You
know
a
ruby
deployment,
golang
deployment
or
what-have-you
okay.
The
reason
that
then
is
useful
is
because,
when
you
consider
the
two
distinctives
that
that
cap
nav
on
adds
to
the
general
application
CRD,
we
have
this
concept
of
a
normalized
application
component
status.
Okay,
so
we
map
kubernetes
resource
status,
to
a
simplified
status
of
green,
yellow
and
red
and
that's
to
provide
kind
of
a
you
know,
easy
to
view,
normalized,
high-level
abstraction
of
status
and
it's
calculated
by
the
application
controller
and
stored
away
into
the
and
to
the
appropriate
resources
as
annotations.
B
Secondly,
so
that's
first
succinct
and
the
second
distinctives
configurable
action
menus.
You
can
think
of
these
as
day
two
operations.
These
are
hierarchical
in
nature,
so
they're
kind,
it's
specific,
so
you
can
have
a
set
of
actions
for
deployment
versus
pod
versus
service
versus
you
know
a
custom
resource,
etcetera
and
there's
the
opportunity
also
supported,
for
instance,
level
override.
So
you
can
actually
extend
the
available
actions
for
a
kind
at
an
instance
level,
so
I
might
have
say
a
kind
of
deployment
that
that
has
specific
supports
specific
actions
that
other
deployments
do
not
support.
B
We
also
use
that
that
sub
kind
mechanism,
where
you
saw
a
deployment
Liberty
in
a
similar
way,
so
that
Liberty
deployments
can
have
actions
that
are
distinct
from
nodejs
deployments,
which
are
distinct
from
Ruby
deployments,
etc,
and
these
are
dynamic
they're
delivered
through
config
Maps.
If
we
were
to
do
this
again-
and
we
might
make
this
change
anyway,
but
we
deliver
these
in
config
Maps.
Initially
we
weren't
too
sharp
with
CRTs.
When
we
first
started
in
hindsight
geez,
he
should
probably
should
have
been
CR
DS,
but
we
didn't
do
it
that
way.
Initially.
B
B
B
B
Sorry
about
that,
so
I
clicked
that
action
and
took
them
to
this
error
page
and
the
reason
that
it
did
is
because
the
function
is
looks
because
the
function
is
trying
to
draw
it
as
big
requires
looks,
requires
Ravana
darn
it
so
I
keep
clicking
okay,
and
so
we,
the
action
as
we
defined
it,
is
designed
to
recognize
when
a
required
capability
is,
is
or
is
not
present,
and
we
not
present
redirect
to
enter
a
page,
and
so
that's
what
it
did
here.
Okay,
and
to
give
you
a
sense
of
what
these
actions
are
like.
B
Okay,
so
here
we
have
yeah,
so
they're
delivered
in
config
maps
right,
and
so
we
define
these
actions,
and
each
action
has
a
number
of
things
about
it
that
describe.
You
know
how
to
place
it
into
the
menu
and
then
a
pattern
driven
approach
for
how
to
form
the
URL
alright.
So
we
have
these
substitution
operators
that
we
defined
that
play
a
role
in
creating
the
fully
formed
your's
limited
added.
B
So
this
is,
you
know
an
open
source
project,
that's
out
there
and
we,
you
know
we're
we're
open
to.
You
know
community
development,
there's
a
CLA
to
sign
and
that
sort
of
thing
and
that's
what
we've
got
Matt.
So
we
wanted
to.
Let
you
guys
know
that
we've
made
use
of
something
that
you've
built
and
that
we've
extended
it
in
a
particular
way
and
yeah.
A
B
Primarily
to
two
capabilities
on
first
capability
is
this
matter
of
calculating
this
so-called?
We
refer
to
it
as
a
normalized
status,
where,
regardless
of
the
resource
kind
right
each
resource
client
has
you
know
its
own
definition
of
status.
We
map
that
to
a
a
red,
yellow,
green,
normal
sorry
problem,
warning
normal
rendering
and
then
roll
that
up
roll,
the
component
level
of
that
up
to
the
application
level.
Okay,
to
provide
a
high-level
visualization
of
those,
my
application
working
as
expected,
or
is
it
experiencing
some
type
of
problem?
B
B
B
Yes
and
it's
delivered
in
a
config
map,
okay,
and
so
we
dynamically
grab
that
right.
We
did
it
that
way
so
that
you
could
we'd
have
a
way
to
both
override
pre-built
mappings,
as
well
as
provide
mappings
for
nuke
lines.
You
know
a
CRTs
are
added
additional
config
Maps
could
be
delivered
by
the
CRT
owner,
for
example,
to
define
the
status
mapping
and
we
have
a
default
that
default
mapping
that
covers
everybody.
But
it's
it's
a
pretty.
It's
a
pretty
ignorant
mapping
for
any
resource
that
doesn't
provide
an
explicit
mapping.
B
B
B
Their
status
has
rolled
up
to
produce
the
the
status
for
the
application
itself.
Basically,
it's
the
the
the
most
severe
status
of
a
component
is
rolled
up
to
become
the
status
of
the
application.
So,
for
example,
any
component
of
stock
trader
was
read,
thought
trader
would
show,
is
read
same,
you
know,
yellow,
yellow
and
then,
when
everything
is
well
called,
the
components
are
green.
Then
the
application
shows
us
green
or
you
know
normal.
Okay.
B
B
You
know
running
code,
okay
and
that
what
we
then
do
is
when
the
controller
sees
a
deployment
or
stateful
set.
That
has
that
label
it
goes
and
it
automatically
creates
an
application
instance
and
and-
and
then
there
are
some
defaults
regarding
the
label,
matching
that
you
know
the
the
name
of
the
application.
There's
defaults
to
the
deployment
name,
it
defaults
say
a
label
selector.
B
All
of
that
solver
ridable
defaults,
a
component
kinds
lists
all
of
that
silver
rideable,
and
so
we
we've
seen
certain
operators
that
deploy
applications
and
they'll
typically
deploy
out
like
a
deployment,
a
service,
an
ingress
or,
and
maybe
a
config
map
or
what-have-you
right.
A
set
of
resources
that
are
part
of
that
now
part
of
that
you
know
that
overall
deployment
and
and
and
so
we've
got
a
couple
of
cases.
B
Our
best
example
is
the
open
Liberty
operator
from
open,
Liberty
IO
that
has
a
predictable
labeling
scheme
that
he
uses,
use
the
app
label
and
all
the
resources
that
it
creates.
It
sets
the
deployment
name
as
the
app
label
value
on
all
those
resources,
and
so
that's
the
case
where
we
we
updated,
that
that
open
source
project
to
auto
create
the
application.
B
A
Okay,
yeah-
and
this
makes
sense,
so
you
know
being
able
to
actually
have
interfaces
like
this
and
do
these
kinds
of
things
when
Antoine,
who
originally
was
one
of
the
people
who
conceived
the
whole
application
CRD
a
few
years
ago.
This
being
able
to
do
this
kind
of
thing
was
one
of
the
things
he
envisioned
being
able
to
visualize
it
install
it.
Do
things
in
different
ways
and
different
tools,
interacting
being
able
to
build
more
complicated,
yep.
A
You
eyes
on
it.
This
was
some
of
the
stuff
that
he
envisioned
so
I
appreciate.
Seeing
it
when
it
comes
to
installing
this
system
is
the
idea
that
the
user
would
be
a
cluster
administrator
or
could
it
just
be
a
developer
working
in
the
cluster?
It
says
cluster
wide,
we're
different
departments
may
say:
I
want
to
use
it
and
a
different
one
doesn't
who
may
use
the
same
cluster,
or
is
this
kind
of
meant
to
be
a
cluster
wide,
install
tool,
yeah.
B
That's
a
great
question
yeah,
so
we
built
it
so
that
while
it
requires
cluster
admin
authority
to
install
you
can't
install
as
many
instances
of
it
as
you
like,
and
we
did.
Oh,
you
asked
about
the
controller
right
so
and
are
you
tweaking
my
memory?
So
one
of
the
things
that
we
did
along
the
way
was
not
only
support
it
as
a
namespaced
deployment.
B
But
so
it's
not
it's
not
a
cluster
scope
thing,
but
also
make
it
possible
to
to
specify
to
partition
each
instance
of
the
app
navigator
such
that
that
each
instance
has
a
set
of
namespaces
that
it
that
it
sees
okay.
So
you
can
partition
the
cluster
up
team
wise
so
that
you
know
team
a's,
namespaces
versus
team
b's,
vs
team
sees
and
each
team
could
have
its
own
app
navigator.
So
we
we
did
build
that
in
as
well.
B
Another
thing
regarding
namespaces
that
we
did
along
the
way
Matt
was
by
default.
The
app
navigator
looks
for
components
for
an
application
only
in
the
same
namespace
as
the
application
itself,
the
more
that
we've
worked
with
clients,
doing
micro
service
based
cloud
native
type
applications
and
striving
to
have
some
number
of
shared
services
that
they
share,
not
only
the
the
code
but
the
running
instance.
B
We
saw
a
need
for
applications
to
be
able
to
buy
the
application
owners
choice,
reflect
as
part
of
the
applications
set
of
components,
even
these
shared
components
that
exist
in
other
namespaces,
and
so
we
provided.
We
implemented
an
annotation
to
allow
the
application
owner
to
designate
that
my
application
owns
components
right
as
per
my
label
selector,
not
only
in
my
you
know
in
in
my
applications,
namespace,
but
also
in
these
other
namespace
in
southern
name,
space
or
namespaces,
to
enable
components
to
be
reflected
as
part
of
the
component
list
as
well.
A
B
B
Does
work
on
vanilla,
kubernetes
we
use
mini
cube
as
our
litmus
test
for
that
and
that's
one
of
our
install
environments
and
that's
documented
on
the
by
the
cab,
nav
katnappe
readme
fact.
Some
of
our
developers
only
use
mini
some
of
the
guys
that
are
working
on
cabin
abs.
Only
do
the
development
on
mini
food,
okay,.
D
Now,
okay,
this
is
one
of
the
things
I
I
and
other
developers
hit
up
against.
A
lot
is
trying
to
export
our
entire
application
definition
like
I've
cobbled
a
bunch
of
stuff
together,
let's
say
like
so
I
install
a
piece,
then
I
install
another
piece
using
like
apply
or
maybe
I'll
use
OCE.
Maybe
I'll
use
OC
new,
app
right
and
and
put
a
bunch
of
new
pieces
into
my
namespace
that
are
part
of
an
application.
Yes,
is
there
a
way,
then,
to
export
the
export
them
that
architecture
and
then
import
that
into
another
kubernetes
cluster?
D
B
That's
a
great
question,
so
let
me
respond
by
first
saying
that
that
is
has
has
not
been
an
explicit
use
case
that
we
were
trying
to
solve.
Okay,
however,
in
listening
to
you
describe
it,
it
occurs
to
me
that
that
that
indirectly
we
we
may
have
created
a
way
of
doing
that.
Okay,
so
I
mentioned
that
auto
create
capability.
B
So
it
would
be
true
that
if,
if
you
were
doing
what
you
just
described,
they
created
deploy
me
create
some
other
resources.
If
let's
say
that
one
of
the
deployments
that
you
created,
you
specified
this
auto
create
label,
and
then
let's
say
that
you
just
paid
a
little
bit
of
attention
to
how
you
labeled
the
rest
of
the
resources
that
you
were
adding.
If
you
followed
a
and
if
you
put
the
same
label
name
and
value
on
each
of
them,
the
result
would
be
that
you
would
have
with
cap
nav
installed.
B
The
result
would
be
that
an
application
CR
had
been
created
on
your
behalf
and
that
if
you
then
dumped
the
definition
for
that
you
know
as
gamal
or
based
on
whatever
through
controlled
death,
you
would
have
sort
of
the
blueprint
for
your
application,
at
least
this
to
the
extent
that
an
app
that
the
application,
CRD,
you
know,
represents
a
blueprint
it
it
doesn't.
It
doesn't
in
the
sense
right
that
it
lists
explicitly
your
resources
right.
It
does
sub-label
selector,
but
you'd
have
the
application
CR
for
your
application
built
automatically.
D
B
D
The
alt
state
the
use
case
and
then
maybe
the
question
and
the
question
will
flow
from
that
I
as
a
developer
have
put
together
an
application
in
a
namespace.
It
may
be
the
entire
namespace.
It
may
be
part
of
the
namespace,
but,
like
I
didn't
do
I,
you
know
I
use,
maybe
OC
new
app
I
used
to
or
maybe
apply,
I
wrote
some
yeah
mole.
I
did
some
stuff
I
added
a
database
I
added
an
app
server
I
defined
that
I
needed
some
persistent
volume
claims
basically
I
defined
the
entire
architecture
of
my
application.
D
A
Okay,
so
it's
the
custom
resource
based
on
the
the
CRD
and
I.
Think
Janet.
Am
I
right
saying
that
the
answer
is
no,
it
gives
you
a
description
of
the
application.
It
gives
the
ability
to
query
what's
running,
but
it
does
not
that
the
customer
research
does
not
contain
every
other
resource
of
everything
that
needs
to
be
installed.
So
it
doesn't
contain
all
the
details
to
recreate
the
deployments
or
stateful
sets.
You
would
need
to
export
the
custom
resource
for
the
application,
along
with
any
other
resources
deployments.
D
So
some
feedback
from
an
application
developer.
That's
not
that
helpful
to
me,
then.
The
biggest
problem
I
face
right
now
is
in
dev.
I,
create
an
architecture
and
I
want
to
move
that
entire
architecture
to
testing,
or
vice
versa.
Like
my
my
Ops
people
create
an
architecture
for
me,
I
want
to
spin
that
up
on
my
dev
cluster
so
that
I
have
the
exact
architecture.
I,
don't
know
of
anything
that
I've
seen
in
the
kubernetes
place.
That
does
that
right
now
and
it's
a
pretty
large
gap.
D
A
E
A
D
A
D
A
No
I
I
actually
think
that
that's
a
really
good
idea
so
I'll
take
that
back
to
the
helm.
Folks,
if
you
didn't
know
I'm
one
of
the
hell,
maintainer,
x',
okay
and
so
I
will
definitely
take
that
back,
because
I
think
that
is
an
awesome
idea
of
being
able
to
do
that.
I
know
people
and
I
think
the
content
ask
folks
Katie,
not
gonna,
try
to
butcher
her
last
name.
Okay
I
gave
a
presentation
on
this
at
coop
con
this
last
November
about
how
they
are
able
to
do
some
of
this
stuff.
A
D
It
was
something
that
I've
asked
the
openshift
team
for
four
years,
because
it's
something
that
I'm
you
know:
I
want
to
move
between
spaces
I
want
to
recreate
it's,
not
my
entire
app
in
a
namespace
and
it's
just
net
it
and
the
way
that
developer
features
got
prioritized.
It
never
got
prioritized,
and
so
it's
really
it's
a
gaping
hole,
I
think
in
the
ecosystem.
For
from
a
developer's
perspective.
Oh
oh.
D
A
B
You
yeah
presently
no
there's
a
little
bit
of
configurability
around
the
the
status
in
terms
of
coloration
and
the
status
labeling
like
the
word
normal,
but
we
haven't
taken
it
any
further
than
that.
The
algorithm
for
the
roll-up
is
is
is
is
cooked
in
so
it
yeah
it's
not
currently
possible
to
map
that
differently.
A
E
A
The
the
CNC
F
has
spun
up
several
special
interest
groups
that
aren't
for
kubernetes,
but
are
there
to
support
to
the
TOC
and
the
work
of
the
TOC
evaluating
projects.
Helping
people
understand
the
space
things
like
that,
and
one
of
the
very
first
cigs
they
created
was
something
called
cig.
App,
delivery
and
I
think
this
would
be
really
good
to
share
there
as
well
to
help
them
visualize
and
see
the
stuff
in
the
space.
They
do
overlap
with
us
a
little
bit
here,
but
they
go
into
other
places
as
well.
A
A
A
E
Hi
is
that
any
better?
Much
thank
you?
Okay,
great
so
hi
I'm,
Evan,
Cordell
I'm
from
Red
Hat
working
on
open
shift
and,
in
particular
the
operator
lifecycle
manager
also
on
the
call,
is
Nick
Hale
who's
on
the
same
team,
we've
been
doing
a
bunch
of
work
with
the
cluster
add-ons
group
and
we've
been
looking
at
how
to
represent
add-ons
on
a
running
cluster
in
kubernetes.
One
of
the
things
that
has
come
out
of
that
has
been
a
little
proof-of-concept
project
that
we've
been
calling
add-on
discovery.
E
It
shares
a
lot
of
things
in
common
with
the
sick,
apps
applications,
CID
and
controller,
and
so
we
kind
of
just
wanted
to
share
it
here,
get
some
thoughts
about
where
this
fits
with
respect
to
the
application,
CID
and
sort
of
just
discuss
how
we
can
move
forward,
whether
it
should
remain
separate,
whether
we
should
work
on
combining
them
or
if
their
opinions
are
about.
Our
approach
that
that
we
should
rethink.
E
E
One
of
the
things
we're
looking
at
is:
how
do
we
take
this
set
of
resources
that
are
all
disparate?
Every
single
add-on
has
different
resources
and
different
statuses,
and
how
do
we
present
those
to
a
cluster
administrator
in
a
way
that
they
can
take
actions
on?
So
this
is
sort
of
the
idea
there.
The
basic
the
basic
approach
is
not
is
different
in
one
big
way
from
the
cig:
apps
I'm.
Sorry,
the
application
CID
approach
in
that
users
don't
actually
create
these
objects
themselves,
so
this
is
also
interestingly
I
didn't
know.
E
Is
we
collect
up
what
objects
make
up
the
admin
so
in
this
example,
a
CID,
a
deployment
and
a
excuse
me
and
a
cluster
role
binding,
and
then
we
also
aggregate
the
conditions
that
they
have
on
each
of
those
resources.
So
this
can
help
actually
discover
what
the
status
of
the
objects
that
you're
looking
at
are.
E
G
Pretty
much
is
the
controller
running,
it
is
dynamically
watching
discovery
and
all
new
resources
there.
So,
like
there's
the
caveat
that,
like,
as
you
add
new
series
to
the
cluster,
it
will
pick
them
up,
but
this
could
be
kind
of
dangerous
as
the
cluster
grows.
Large
and
new
resource
types
are
added,
but
part
of
what
I
did
here
was
create
that
label
on
all
the
resources
that
make
up
this
particular
controller,
so
it
itself
is
listed
on
as
an
add-on
to
the
cluster.
G
If
we
take
a
look
at
it,
we
can
see
basically
all
the
different
components
that
make
it
up
and
then
it
is
again
extracting
that
status
conditions
dynamically
if
it
finds
something
under
the
status
of
resource
that
kind
of
matches
this
pattered
and
has
these
things
in
it,
then
it
fills
out
the
rest
of
the
fields
there.
If
I
wanted
to
create
some
new
thing
or
perhaps
add
a
node
tag
on
discovery
for
some
reason,
I
could
just
label
it
there.
G
If
I
wanted
to
create
a
new
operator,
let's
say
no
discovery
or
something
no
doubt
on
probably
better
I
can
do
that.
You
can
see
that
new
added
on
has
been
found
and
even
though
it's
completely
different
type,
it
did
pick
up
all
the
conditions
that
are
there.
We
can
do
something
a
little
bit
more
complex,
I
actually
have
OLM
here
as
a
customization,
and
the
only
thing
that
it's
doing
is
adding
the
label
that
is
OLM
operators
more
complicated.
G
A
Does
anybody
else
have
questions?
I
do
have
a
question
to
start
so
the
demo
here
was
very
command-line,
driven
and,
and
you
walk
through,
creating
some
of
the
different
things
kind
of.
Where
do
you
envision
this
say
three
and
six
months
because
I
see
you're
collecting
metadata
on
the
the
add-ons
here,
but
what's
the
goal
and
how
do
you
want
to
expose
it
or
use
it
things
of
that
nature?
So.
E
I
think
one
of
the
goals
is
to
try
and
have
a
common
way
to
talk
about
add-ons
controllers
operators.
All
these
things
look
very
similar
applications
as
well
with
a
similar
language,
and
one
of
the
roadblocks
to
that.
So
thus
far
has
been
getting
everyone
to
agree
to
write
single
objects,
and
so
this
kind
of
makes
it
so
that
you
don't
have
to
agree
to
write
a
single
object.
E
E
A
A
A
You,
let
me
take
silence,
there's
nothing
alright.
So
thank
you
for
that
presentation
and
I
look
forward
to
us
following
up
more
and
having
some
more
conversations
on
it.
The
the
one
last
item
was
there
is
and
I
headed.
This
was
the
last
minute
thing
that
came
in
this
morning.
There
is
a
flicky
issue.
Although
much
I
said
he
was
going
to
get
on
it
first
thing
in
his
morning,
but
we
do
have
a
flaky
issue,
a
test
flaking
kubernetes
that
was
reported
to
us
as
part
of
cron
job
you.