►
Description
Join OpenShift's Developer Experience experts for our regularly scheduled program filled with cloud native, Kubernetes, and OpenShift tips and tricks for developers.
This show demonstrates features and capabilities that are still under development. They might end up looking different when released.
A
Hello
good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
the
developer
experience
office
hours
here
on
openshift
tv,
I
am
chris
short
executive
producer
of
openshift
tv.
I
am
joined
today
by
a
bevy
of
my
fellow
red
hatters
that
are
in
the
developer,
experience
and
advocacy
realms,
but
the
most
important
of
them
all
figuratively,
is
serena
from
the
future
doi
or
nichols
which
your
name
is
different
again.
A
On
serena
from
the
future
is
here
with
us,
which
means,
as
always,
everybody
that
the
things
that
you
see
on
this
show
might
not
end
up
in
the
product
in
the
way
that
you
see
them
or
at
all
or
in
some
different
product
or
some
project
somewhere
that
we
just
create
an
operator
for
who
knows
it's
all
in
the
future,
and
we
don't
know
what
the
future
always
ends
up.
Looking
like
in
the
end
serena,
would
you
like
to
introduce
yourself
to
everybody
sure.
C
A
D
A
E
F
A
A
A
B
A
Like
opt-in,
don't
you
you're
not
required
to
do
it,
but
we
really
appreciate
your
feedback.
It
does
get
baked
into
the
product
from
this
show,
like
we
use
feedback
from
this
show
to
help
us
make
this
product
better,
so
yeah,
we
are
all
about
you
right
now.
So
what
do
we
got
on
tap
today?
It's
something
fancy!
I
hear
yeah.
B
B
Right-
and
I
think
one
and
peter
will
talk
through
a
lot
of
this,
but
I
think
one
of
the
interesting
pieces
is
that
a
lot
of
the
times,
the
vulnerabilities
that
you
have
might
be
aligned
with
the
base
image,
which
is
something
that
as
the
developer,
you
can't
fix
right
right.
So
how
much
of
that
information
do
you
want
to
see
versus?
You
know
what
you
can
fix
versus
what
you
can't
fix
and
those
type
of
questions
and
topics
are
the
things.
B
F
Thanks
so
I
figured
I'd
start
by
showing
what's
in
the
container
security
operator
today,
I
think
some
of
the
functions
I'm
showing
is
added
as
early
as
I
think,
4-3
and
then
also
in
4-4.
So
I
figure
I'll
touch
on
that
and
then
also
show
how
to
set
that
up
in
your
cluster,
but
just
to
start
so
this
particular
cluster
we're
looking
at
here
just
to
mention.
So
this
has
the
clay
container
security
operator
already
installed.
So
that's
why
it
has
this
functionality
available.
F
So
some
things
I
want
to
highlight
that
that
enables
is
I'm
now
over
in
the
administrator
view
on
the
cluster
dashboard.
We
call
it
and
there's
this
image
vulnerability
status
here
and
what
that
status
does
today
is
it
gives
you
an
overview
of
any
vulnerable
container
images
that
are
on
your
cluster
today
and
what's
worth
noting
so
far,
is
that
these
are
all,
as
serena
mentioned,
in
the
base
images,
so
it
mentions
those.
It
mentions
how
many
namespaces
they
impact.
F
Also-
and
each
of
these
also
contains
a
link
to
the
quay
image
registry
or
commander
registry,
where
you
can
see
it,
so
you
can
also
go
over
there
if
you
would
want
to
see
it
in
the
quay.io
ui,
but
going
back
to
the
ocp
console.
If
we
take
a
look
at
one
of
these.
So
in
the
details,
there's
a
summary
for
this
particular
one,
so
you
can
see
there's
95
vulnerabilities
here
it
breaks
them
down
by
severity,
there's
a
little
metadata
here
and
then
it
lists
out
all
these
vulnerabilities.
F
So
that's
sort
of
the
baseline.
What
we
have
today,
as
I
said,
I
think
this
is
in
four
three
and
four
four,
this
this
feature
was
available
and
so
now
we're
looking
forward
to
in
the
future.
We
can
do
to
further
enable
a
developer
to
get
more
insight
into
also
these
base
images,
but
also
the
the
app
dependency
vulnerabilities
that
they
might
be
more
interested
in.
D
F
F
So
any
image
that
comes
from
clay
is
what's
being
analyzed
here,
so
claire
is
already
running
so
any
image.
Basically,
that's
kind
of
the
the
prerequisite
is
that
these
images
have
to
come
from
clay.
So
that's
we
sort
of
tried
to
highlight
that
and
pop
over
just
so
you're,
not
under
the
impression
that
absolutely
every
image
on
your
cluster
is
being
scanned
in
this
way.
If
that
answers
the
question.
D
D
F
C
A
C
C
Cool
yeah
nice
to
see
claire
being
used
and
having
it
fully
automated
claire
is
open
source,
so
you
could
also
access
some
of
this
information
by
using
claire
directly
via
the
command
line
or
or
some
other
means,
and
then
splicing
it
back
in.
But
this
is
really
cool
to
have
it
all
fully
integrated
and
ready
to
go
cool
to
see
this.
C
Yeah
and
saves
me
from
having
to
build
a
ui
to
expose
it
to
the
folks
that
need
access
to
it
so
yeah
I
I
was
just
not
trying
to
downplay
the
value
here
more
just
trying
to
highlight
that
part
of
what's
being
used
under
the
scenes
or
behind
the
scenes
is
the
claire
binary,
and
some
of
that
is
open
source
work
that
you
can
look
up
on
your
own.
If
you're
interested
in
how
that
operates.
F
F
So
now
we
are
in
the
realm
of
future,
so
even
I
I
forgot
that
I
have
this
stamp
up
your
design
concept,
not
for
implementation,
so
that
might
even
give
you
a
sense
of
just
how
early
this
is,
but
just
to
set
this
up.
Now
we
are
over
in
the
developer
perspective
in
the
console
and
we're
over
on
the
project
tab.
So
we're
looking
at
this
one
particular
project
called
andrew
and
what's
new
here.
Is
this
status
that
similar
to
what
we
just
looked
at
on
the
cluster
dashboard
for
an
admin?
F
Is
the
image,
vulnerability
status
and
there's
also
this
vulnerabilities
tab,
which
would
have
the
complete
list
of
vulnerable
images
for
this
particular
project,
but
to
take
a
look
at
this
popover?
This
is
definitely
where
I'm
interested
in
getting
any
feedback
on.
So
please
let
it
rip.
You
won't
hurt
my
feelings.
A
F
Yeah,
well,
it's
something
that
we're
we're
on
yeah.
These
are
definitely
absolutely
not
accessible
in
icons
at
this
point,
so
we're
working
on
we're
working
on
a
new
set
of
icons
that
represents
severe
severity,
universally
right,
some
of
the
ones
we're
working
on
kind
of
look
like
maybe
like
a
battery
charging.
So
like
it's
like
nuggets
that
fill
so
you
can
visibly
tell
without
color
what
the
severity
level
is.
But
that's
a
great
point.
So
I
appreciate
that
and
definitely
open
any
feedback
like
that.
A
Yeah,
like
that's,
that's
why
we
have
the
feedback
form
out
there,
for
you
all
is
to
give
us
that
kind
of
feedback
right,
like
any
feedback,
is
good
feedback
like
even
if
you're
like.
Oh,
I
hate
the
fact
that
it
says
the
image
container
id
and
not
the
image
name.
Well.
Okay,
that's
good!
That's
good
info
to
have
right
like
we
want
that.
F
Yeah,
exactly
that's
precisely
what
we're
looking
for,
but
yeah,
so
just
to
compare
this
to
what
we're
looking
at
at
the
cluster
level
of
note
is
that
this
is
only
in
one
project.
So
there's
no
where's
at
the
the
cluster
level
saying
how
many
namespaces
these
particular
container
images
appeared
on
and
we're
vulnerable
in.
So
we
don't
have
that
we
just
have
they're
vulnerable
in
this
project.
So,
as
you
mentioned,
we're
just
showing
the
id
here,
and
that
was
something
we
were
curious
about
exactly
how
to
represent
these.
F
That
would
be
most
useful,
whether
the
id
actually
is
useful
or
not,
but
yeah
so
just
to
break
it
down.
So
similarly,
it
has
the
severity
for
each
one.
You
can
see
it
says:
there's
12
vulnerable
containers
and
that's
what
the
12
is
here:
there's
a
breakdown
by
severity
and
then
there's
the
fixable
container
images,
and
then
it
mentions
that
there's
nine
of
those,
so
that's
to
say
that
nine
of
those
12
have
vulnerabilities
in
them
that
you
could
actually
fix.
F
And
then
we
still
have
the
link
out
to
the
quad.io
interface.
So
I
think
this
works
I'll
click,
this
just
to
show
that
you'd
still
be
able
to
be
linked
out
here
and
at
this
level
we're
thinking
that
both
those
base,
level
and
app
dependency
vulnerabilities
would
appear
here
as
well.
So
maybe
that's
the
most
key
thing
that
probably
I
haven't
actually
settled
out.
F
B
Nice,
so
that
that's
the
kind
of
feedback
you're
actually
looking
for
too
right,
peter
like
right
now
like
is
this
tool
tip
or
the
overview
that
you're
seeing
in
this
tool
tip.
Is
that
what
you
want
to
see
as
the
developer?
Or
do
you
want
it
kind
of
broken
down
from
it
from
a
different
viewpoint?
I
think
precisely-
and
I
don't
know
if
our
dev
advocates
who
are
live
with
us
today-
also
have
their
own
opinions
that
you
might.
C
C
Yeah
one
of
the
things
that
this
reminds
me
of
from
from
github
there's
a
have
you
ever
used
a
service
called
green
keeper.
Have
you
heard
of
that
one?
No
anyway,
greenkeeper
will
do
analysis.
I
think
on
your
npm
javascript
libraries
and
it'll.
Tell
you
if
there's
a
vulnerability
but
it'll
also
send
you
a
pull
request
to
upgrade
your
modules.
C
C
A
So,
just
to
kind
of
segue
for
a
second
someone
asked
serena
a
question:
serena
showed
us
a
few
weeks
ago
that
you
could
pin
stuff
in
four
five
in
the
dev
console.
This
is
super
useful
to
customize
the
sidebar,
and
I
use
it
a
lot,
but
I
am
forever
switching
between
admin
and
dev
to
go
back
to
the
topology
view.
The
topology
view
is
like
the
home
page
that
I
keep
wanting
to
return
to
when
doing
stuff,
and
it's
super
frustrating
that
I
cannot
get
to
the
topology
view
from
the
admin
console.
B
B
B
A
B
E
B
Admin
but
dev
side
too,
so
I
think
that
would
be
a
great
place
to
bring
it
up.
The
other
thing
is
that
in
4.6,
one
of
the
things
that
we
have
done-
and
I
don't-
I
probably
can't
show
you
at
this
second-
because
I
don't
have
a
cluster
available,
but
on
the
project
page
in
the
admin
side,
underneath
the
workloads
tab.
What
you'll
see
is
the
list
view
of
the
topology
view
if
you're,
so
I
know
that's
not
the
same
as
customization
for
sure.
B
F
F
So
this
one
count
would
be
aggregating
both
of
those
and
you
could
break
them
down
by
severity
and
then
there
the
thought
is
that
we'd
be
able
to
filter
between
the
showing
all
of
them
or
just
the
base
level
vulnerabilities
or
the
app
dependency
vulnerabilities,
and
I
guess
I
was
curious.
We
have
functionality
like
this
in
this
bottom
area
that
lets
you
list
out
all
the
vulnerabilities
as
well.
F
You
can
filter
by
either
base
or
app,
and
I
guess
I
was
just
curious
if
anybody
had
any
thoughts
on
if
this
type
of
functionality
would
be
useful
at
this
level
to
see
one
or
the
other
or
just
always
see
both
and
then.
Similarly,
in
this
list
the
same
question:
anybody
any
thoughts
on
that
definitely
be
interested
in
hearing
them.
A
B
B
E
B
Once
you
start
once
you're
utilizing
4.5,
you
can
customize
your
own
navigation
to
do
that,
and
that
should
help
and
that's
why
again
sorry
peter
that
we're
off
topic
a
little
bit,
but
this
is
based
on
the
chat
we
are
trying
to
figure
out.
Why
are
people
switching
back
and
forth
between
admin
and
dev
perspective
and
like?
Is
it
a
wholesale
issue
or
is
it
that
are
a
few
things
that
are
missing
so
again,
all
of
this
feedback
send
an
email
to
our
google
group.
Come
here,
send
something
to
the
chat.
A
D
On
topic,
I
do
really
like
the
ability
to
separate
the
base
image
vulnerabilities
versus
the
app
vulnerabilities.
I
think
that,
having
that
ability
to
do
that
is
really
useful,
I
might
be
using
an
older
version
of
you
know
the
ubi
or
alpine
or
whatever,
and
that's
in
my
docker
file,
and
I
could
you
know
instantly
see.
D
Oh
man,
that's
like
another
check
to
make
sure
that
I'm,
you
know
making
sure
that's
updated
and
things
are
okay
and
I
think
that's
valuable,
but
maybe
I
can't
change
that
base
image
because
that's
you
know
what
we're
using
for
most
things
and
seeing
oh
there's
a
couple
different
dependencies
or
you
know
apparent
abilities.
I
I
like
having
the
ability
to
switch
that
context
really
easy
and
have
that
you
know
to
be
able
to
see
that
really
quickly.
D
Yeah,
I
think
at
least
my
perspective
on
which
one
should
be
default.
I'm
not
sure
I
think
I
would
have
to
like
use
it
for
you
know
a
month
or
whatever
and
see
which
one
I
use
the
most
or
what
is
the
most
valuable
for
me
at
least,
but
having
it
configurable.
At
least
you
know
so
that
people
could
switch.
Is
nice.
F
F
But
yeah
so
just
to
get
back
into
so
there's
some
of
this
other
metadata
there's
a
link
to
the
manifest
on
quay
one
more
time
and
then
there's
the
list
of
vulnerabilities
at
the
bottom
here
and
kind
of
like
what
I
touched
on.
So
this
would
be
the
list
of
both
the
base
and
app
dependency
vulnerabilities.
F
If
you
were
just
one
or
interested
in
one
or
the
other,
we
would
have
a
filtering
mechanism,
so
you
can
see
just
the
base
or
just
the
app
filter,
this
list
down
again
the
severity
and
then
the
source
which
would
be
based
on
where
probably
the
type
where
they're
coming
from.
So,
if
it's
a
base
base
image
vulnerability,
it's
probably
coming
from
quay
or
if
it
is
a
dependency
vulnerability.
It's
probably
going
to
be
coming
from
code
ready
dependency
analytics,
which
is
powered
by
snick
vulnerability.
Data.
F
D
F
I
think
the
way
I've
drawn
this
at
the
moment.
I
think
it
was
sorted
by
severity,
but
I
believe
we
could
even
go
check
right
now
and
I
think
that
so
if
we
check
one
of
these
out
sorry,
so
I
think
these
could
be
sortable,
that's
something
we
probably
shouldn't
do,
because
that
would
make
a
lot
of
sense.
What
I
was
going
to
say
is
it
looked
like
we
already
have
sorting
on
the
list,
so
it
seems
like
we
could
just
include
that
on
the
vulnerability
list.
That's
a
really
good
point.
D
F
And
then
the
the
last
column
that
we're
thinking
about
adding
here
also
is
just
the
application
grouping
of
which
of
these
app
dependency,
vulnerabilities
fall
in.
So,
if
you've
used
in
the
topology
view
to
set
up
applications
to
group
your
different
workloads.
This
would
then
tell
you
for
this
vulnerability,
which
application
or
applications
it's
surfaced
in.
So
that's
something
we're
feeling
out
at
the
moment.
C
I
really
like
that.
I
think
if
I
were
responsible
for
a
particular
app
at
my
company,
this
view
would
potentially
let
me
go
and
see
what
are
the
relevant
security
issues
that
that
I'm
potentially
on
the
hook
for
and
if
it's
as
simple
as
that.
The
trick
with
some
of
this,
though,
is,
I
think,
a
portion
of
the
time.
The
actual
resolution
might
be
upgrading
an
rpm
or
basically
patching
the
base
image
and
that's
potentially,
might
not
be
within
the
scope
of
a
front-end
developer.
C
So
I
might
have
to
put
on
my
lead,
developer
hat
grab
my
admin
credentials
or
something
and
rebuild
that
base
image
and
then
do
a
docker
push
into
my
internal
registry
or
something.
But
I
I
think
I
remember
if,
if
you
are
still
using
deployment
configs
instead
of
deployments,
I
think
I'm
not
sure
if
it's
different
with
deployments,
but
I
think
we
will
detect
that
a
new
base
image
has
arrived
in
your
registry.
C
The
build
config
that
you
have
stored
should
automatically
jump
into
effect,
generate
a
new
app
image
and
then
your
deployment
config,
if
you
have
automation
for
that,
enabled
might
actually
roll
out
a
new
deployment
as
well.
So
you
could
essentially
do
a
docker
push
flip
back
to
this
screen
and
then
watch
as
these
things
potentially
get
get
resolved.
B
I
wonder
if
you
would
wouldn't
mind
again
just
going
through
going
back
to
the
developer
perspective,
because
there's
a
question
around:
is
this
a
list
of
vulnerabilities
on
everything
in
openshift
or
going
into
the
application
itself?
So
I
know
you
talked
about
this
before,
but
maybe
we
could
just
kind
of
go
through
a
look
going
on
the
differences
between
the
admin
side
versus
the
dev
side
and
and
how
that
limits.
The
focus.
I
guess
of
the
vulnerabilities.
F
B
B
So
one
interesting
thing-
I
wonder
just
because
I'm
just
just
thinking
out
loud
here
since
the
title
of
that
popover
is
the
same
between
the
two.
I
wonder
if
it
is
worth
kind
of
clarifying
it
in
the
pop
over.
So
if
you
happen
to
have
access
to
both
the
cluster
overview
and
here
you're,
realizing
that
this
is
really
just
localized
to
the
apps.
Here
I
don't
know-
and
maybe
you
already
do
that
and
I'm
not
seeing
it
so.
F
F
Andrew
there's,
no
mention
of
apps
on
this
thing
at
this
point,
so
I
wasn't
sure
if
that
type
of
thing,
if
somehow
from
within
this
popover
you'd,
want
to
like
break
it
down
by
app
at
this
level
or
if
the
assumption
would
be
that
you
just
go
in
here
and
then
maybe
once
you're
in
a
particular
container
image,
then
you
can
narrow
it
down
to
a
particular
app
but
yeah.
Otherwise,
all
this
information
is
for
this
particular
project.
D
Yeah,
I
think
the
title
like
that
that
makes
sense.
You
know,
project,
vulnerabilities
or
whatnot,
but
I
think
the
pop-up
at
least
for
me.
Probably
you
know
I
like
that
the
details
you
know
there.
I
don't
think
that
it
needs
to
be
broken
down
by
apps.
If
we,
you
know,
click
view
all,
then
you
could
get
all
the
tweaks
and
filters
and
views
that
you
want.
But
this
is
just
like
a
quick
overview.
Hey
we
got
all
these
things.
This
is
like
a
21.
F
And
yeah,
so
I
guess
one
question
that
we
also
had
that
we
alluded
to
earlier,
but
by
listing
out
the
I
believe
this
is
the
manifest
id
for
this
particular
container
image.
If
it
would
be
more
useful
to
try
to
convey,
I
don't
know
I
guess
the
like
repo
name
or
the
repo
name
space
and
try
to
just
capture
like
what
this
container
image
is.
Or
I
don't
know
if
that
information
is
useful
here
or
I
guess
I
was
curious
if
anybody
had
any
thoughts
on
that
type
of
thing.
D
D
A
D
A
A
Yeah,
sorry
so
I'm
kind
of
medicated
this
morning,
so
I
apologize
but
yeah
chris
carlos
santana.
I
did
it
again,
but
he
wants
to
know
like
that.
His
sidecar
app
is
not
invulnerable
right
like
because
those
side
cars
are
going
to
become
more
prevalent
and
more
more
like
we're,
putting
a
lot
of
faith
in
istio
right
now
for
security
and
management.
So
we
need
to
make
sure
that
those
things
are
getting
looked
at
in
the
same
way,
our
apps
are
essentially.
B
Yeah,
I
think
this
is
great
feedback
and
I
think
peter.
Maybe
we
should
be
back
to
perak.
So
peraga
is
our.
I
think,
he's
like
our
security
vulnerability
pm,
among
other
things,
that
he
does,
but
it
would
be
great
to
bring
this
back
to
him
and
the
team
to
make
sure
that
this
stuff
is
being
covered
appropriately
and
see.
If
there's
anything
additional,
we
need
to
do
so.
Thanks
for
bringing
that
up.
A
F
And
I
think,
maybe
one
last
thing
that
I
didn't
really
touch
on
with
this
design.
This
is
what
it's
conveying
is,
I
think,
earlier
in
the
the
current
functionality,
you
can
look
at
the
red
hat
security
advisory
for
that
particular
vulnerability,
so
that
would
still
be
there,
but
what's
new
is
also
for
these
app
dependency
vulnerabilities
we'd
be
linking
off
to
snick,
which
is
providing
this
vulnerability
data,
so
you
would
get
more
information
about
that
vulnerability
here.
F
A
F
That's
great
feedback,
yeah,
that's
actually
something
we
started
thinking
about
exactly
like
when
we
should
expose
that
type
of
thing.
I
guess
what
severity
level
but
yeah,
that's
a
awesome
point.
Probably
stick
a
notification
in
the
notification
drawer,
just
saying
you
have
a
high
or
urgent
or
something
like
that.
Ideally
maybe
it's
a
configurable
level
of
when
you
want
to
be
notified
in
what
way
yeah.
A
A
A
D
A
Or
gitlab,
or
whatever,
somehow
find
your
find
your
vulnerability
and
patch
it
yeah
like
a
techton
deal
with
that
kind
of
deal,
yeah
that'd
be
fun
well,
leed
is
asking.
I
would
love
to
see
an
example
for
the
119
sidecar
feature,
but
we
don't
have
119
baked
into
any
open
shift
instances
right
now,
right,
it's
not
in
four
seven
or
is
is
one
nineteen
four
seven
I
forget.
F
That
was
a
good
bit
of
the
new
functionality,
we're
thinking
through
for
after
four
six,
so
yeah.
If
there's
any
other
general
comments
or
just
how
you
like
to
resolve
these
vulnerabilities
in
general,
this
is
sort
of
what
we've
designed
so
far,
but
just
curious
if
this
would
meet
your
needs
like
if
this
is
really
the
way
you
want
to
see
this
data
or
any
other
thoughts
on
this
in
general,
definitely
open
to.
But
this
is
mostly
what
I
want
to
show.
D
I
just
want
to
say
that
I
love
that
we're
showing
some
of
this
security
vulnerability
in
the
openshift
console.
It
makes
it
really
easy.
It's
really
that
you
know
nice
view
of
everything
you
have
that
thousand
foot
view
on
that
dashboard.
It's
all
you
know
baked
and
integrated
really
nicely,
which
is.
A
It's
it's
our
reminder
that,
like
it's
not
just
devon
ops
right,
like
there's
all
kinds
of
stakeholders
that
have
a
seat
at
the
table
with
openshift
right,
like
security's
involved,
you
know
any
kind
of
configuration,
management's
involved.
Any
kind
of
you
know:
compute
storage,
the
whole
nine
yards,
it's
all
installed,
so
it's
all
part
of
the
package
of
openshift,
so
it
touches
everybody
so
yeah.
We
really
appreciate
this
feedback.
Hooks
extensions
for
devops,
all
those
fun
things
are
great
yeah.
A
C
C
C
C
Might
be
labeled
appropriately,
but
assuming
your
application
groupings
have
the
appropriate
labels,
things
that
are
side.
Cars
should
be
part
of
a
pod
with
the
appropriate
labels.
They
potentially
show
up
in
this
view-
and
you
know,
as
as
a
part
of
that
security
scope
of
that
application
grouping.
So
if
you
had
side
cards
that
were
istio
or
whatever,
this
would
be
potentially
the
place
to
see
it
so
great
for
for
visibility.
C
C
On
the
other
hand,
the
the
art
of
standardizing
those
base
images,
so
an
entire
team
or
an
entire
engineering
org,
is
all
on
like
the
same
release
of
python
or
the
same.
You
know
like
you,
you
almost
want
to
do
that
as
a
administrative
level
move
to
standardize
those
base
images,
but
you
want
everyone
to
be
aware
if
their
particular
application
code
is
at
risk
right,
so
yeah
I
like
this,
but
yeah.
C
B
C
Those
solutions
will
already
have
a
bunch
of
labels
applied
to
them.
That's
also
kind
of
like
depends
on
who
your
team
lead
or
your
architect
is.
They
should
be
helping
decide
what
labels
get
applied
to
which
apps.
So
people
have
a
clear
perception
of
what's
within
their
scope
of
responsibility,
front.
C
A
C
C
I
think
you
can
look
at
there's
like
cloud
native
application,
bundles,
there's
one
specification,
there's
other
kind
of
there's
a
application
working
group
that
was
active
upstream
in
the
sig
apps
group,
but
we
basically
conform
to
the
same
labeling
scheme
that
helm,
charts
and
the
rest
of
the
cloud
native
space
is
using
for
for
app
labeling.
So
I'm
not
sure
I
don't
have
a
link
to
a
specific
reference.
A
B
There
was
a
there
was
a
I'm
looking
for
it.
Now
there
was
a
label
recommendation.
I
think
it
was
initially
gorkham
from
our
dev
tools.
Team
had
initially
created
that
and
I'm
pretty
sure
that
it
made
it
upstream
just
trying
to
see.
If
I
can
find
that
and
that's
what
we
utilize
in
the
developer
console
today
so
like,
if
you're
in
the
developer
console
today,
we
in
the
project
selector
bar,
we
also
have
an
application,
selector
bar,
so
you
can
in
in
when
you're
looking
in
topology.
B
C
C
A
B
B
F
B
A
B
B
B
B
C
So
this
would
also
be
something
that
whoever
the
team
lead
of
this
python
sample
would
be
responsible
for
maintaining
these
over
time
and
ensuring
that
the
appropriate
labels
are
applied.
Given
the
environment,
I
think
so
often
our
sample
apps
sometimes
are
used
across.
You
know
open
shift,
3
examples
and,
and
we
test
for
backwards
compatibility,
so
this
might
have
a
boatload
of
labels
to
cover
extra
use
cases,
but
yeah
good
to
see
this
thanks
again
for
doing
the
live
demo,
yeah.
B
B
Yeah
and
also
the
other
thing
is
peter
if
you
go
back
to
add
and
hit
samples
again
like
so
just
what
that
samples
area
is
doing,
is
it's
just
a
quick
way
for
developers
to
get
up
and
start
like
kick
the
tires
right?
We
are,
if
you
add
another
one
so
say
pick
java,
possibly
I'm
hoping
that
they
all
work
I
haven't
tested
today.
B
B
C
Believe
so
that's
another
way
to
get
those
kind
of
labels
applied
without
you
having
to
learn
every
last
bit
of
knowledge
about
the
kubernetes
ecosystem
and
be
involved
in
every
sig
and
be
up
to
date
on
what
did
the
working
group
decide
regarding
what
the
correct
labeling?
Instead,
you
click
on
the
option.
Button
click
on
link-
and
hopefully
we
we
give
you
the
appropriate
label
at
least
for
open
shift,
if
not
for
the
rest
of
the
kubernetes
community.
C
A
Cool
all
right,
we
are
all
into
labels.
Now
you
get
a
label,
you
get
a
label,
I
get
a
label,
you
also
get
a
label
lol,
they're
in
dev
says
everyone
gets
a
label,
but
yes,
like
carlos
santana.
I
mentioned
in
chat
like
please
reach
out
to
me
and
let's,
let's
figure
out
who
should
run
that
standard
and
actually
make
it
like
a
thing
because
clearly,
there's
some
ambiguity
there.
That
needs
to
get
cleaned
up
at
a
grander
scale
than
just
you
know,
red
hat
or
you
know
any
individual
company
right
like.
A
E
C
B
C
Developer
next
week,
yeah,
we
tentatively
have
jason
dobies
coming
back
with
how
do
developers
learn?
I
think
he
was
going
to
go
through
kind
of
our
best
of
you
know,
demo
of
learn,
dot
open
shift,
talk
about
the
probably
mention
his
book.
You
know
go
through
kind
of
a
top
opportunities
that
the
openshift
developer
program
is
already
offering.
C
A
It's
good
stuff,
it
really
is
like
I
do
reference
it
routinely
yeah.
So
thank
you
very
much
everyone
for
joining
appreciate
your
time.
Thank
you,
peter
this
great
demo.
As
always,
thank
you
for
in
in
indulging
our
chat
audience
and
we
do
love
you
all
and
all
of
your
questions
and
feedback.
It
is
very
helpful.
I
cannot
tell
you
how
helpful
it
is,
so
we
really
appreciate
it
you're,
making
the
product
better
as
you're
getting
involved
here
on
the
channel,
so
we
we
cannot.
Thank
you
enough
for
that.