►
From YouTube: Kubernetes SIG Apps 20180122
Description
Kubernetes SIG Apps meeting on 01/22/2018.
C
A
A
So,
if
you're
familiar
with
the
professor
amaryllis,
it's
like
after
university,
you
do
tenure
track.
You
get
full
professor,
you
teach
for
awhile,
get
lots
of
research,
grants
have
a
successful
career
and
then,
at
the
end
of
it
you
become
an
Android
Asst
professor.
So
you
get
to
come
back
and
lecture
from
time
to
time.
You
keep
your
status
in
the
university,
but
you
don't
have
to
teach
classes
anymore.
A
You
don't
have
to
publish
or
perish
you,
don't
have
to
go
chase
research
grants,
so
a
kind
of
equivalent
or
an
anomalous
position
in
helm
is
an
emirate
ascore
maintainer,
which
means
you're,
probably
not
gonna,
see
these
guys
being
as
active
in
doing
code
reviews
and
in
merging
new
features,
but
going
forward
they're
still
going
to
maintain
the
status
of
maintaining
can
get
involved
kind
of
out
there
choosing
to
continue
to
contribute,
and
we
have
our
first
three.
So
congratulations
to
relay
it:
gifts,
Miguel
Martinez
and
Stephen
Harris
and
another
issue
along
the
same
vein.
A
We
are
going
to
get
to
new
he'll,
maintain
errs,
one
of
whom
is
Matt
Farina.
So
congratulations,
Matt
and
another
is
Nikhil
Moncada,
aka
slick
Nick
on
github
and
congratulations,
Nikhil
I
think
that's
also
Helm's
summit.
If
you
haven't
registered
yet
and
you're
intending
to
go,
it
would
be
a
good
idea
to
register
now.
A
I'm,
definitely
going
I
know,
that's
gonna,
be
there
I
know
a
lot
of
people
from
cig.
Apps
have
already
planned
to
attend
and
the
more
people
who
attend
the
more
opinions
we
get
the
more
input
we
get
the
better.
So
if
you're
thinking
of
attending
please
go
ahead
and
register
now,
okay,
so
now
we
have
a
couple
of
demos:
do
we
have
mica
house
LaRon
want.
C
A
D
E
D
D
So
we
basically
assigned
a
unique
ID
just
to
generate
you
at
UID
for
a
specific
installation
of
a
chart
or
specific
specific
release
with
the
values
associated
with
it.
So
if
you
had
slightly
different
values
in
different,
say
regions
or
whatever,
for
different
clusters
for
those
Google
datastore
table-
and
it
was
all
high
based
and
for
us,
this
worked
pretty
well,
but
acts
acquired
access
to
the
chiller
server.
D
F
Yep
alright,
like
you
said
my
name,
is
Ethan
Rogers
I
work
with
Micah
on
our
Technical
Operations
team,
so
yeah,
so
managing
values
for
us
was
kind
of
monotonous.
We
had
to
jump
different
VPNs
squid
is
a
is
a
ui/ux
toolkit,
and
so
we
pretty
much
just
used
our
own
product
to
build
out
a
UI
to
manage
this
stuff.
F
So
for
us,
where
we're
storing
chart
releases
in
dynamo
and
a
release,
is
the
chart
inversion
and
a
specific
set
of
values
for
a
given
identifier,
so
here
in
our
UI
we're
talking
to
dynamo
to
get
this
information.
This
is
just
stable,
Jenkins
from
the
main
repo
we
can.
You
know
we
can
edit
and
make
changes
to
whatever
chart
version
we
want
whatever
namespace
this
stuff
is
going
in
and
then
over
here
on
the
right.
You
can
see
this
value,
senator
so
you're.
F
Obviously,
everyone
here
is
familiar
with
installing
helm,
charts
what
we
did
with
home
value
store
once
we
started
figuring
out
where
our
pain
points
were,
we
were
able
to
to
improve
it.
So,
instead
of
having
to
jump
across
a
bunch
of
VPNs,
we
built
a
server
with
an
API
for
installing
a
hell
chart
into
home
value
store.
So
the
API
just
takes
this
unique
identifier,
and
we
put
some
authentication
and
authorization
around
that
and
what
we
can
do
from
our
UI
is.
F
F
F
You
know,
keep
track
of
unique
IDs
as
we're
doing
that
in
our
terminal.
We
can
just
do
it
all
from
right
here
in
the
UI.
We
can
make
edits
to
these
things
and
roll
those
changes
out.
So
here
we've
got
this
Jenkins
demo.
That
I
was
showing
earlier
using
stable,
Jenkins
0.13
of
zero,
and
you
know
we've
already
kind
of
pre
set
this
up.
These
are
all
the
user.
The
default
values
right.
These
are
the
default
values
out
of
the
chart.
F
F
A
H
A
I
A
Ok,
that's
better
thanks,
so
the
underlying
motivation
is
that
if
you
look
at
something
like
this
WordPress
manifest
right,
you
could
be
cuddle,
apply
this
and
you'll
turn
up
a
bunch
of
headless
services.
A
client
service,
while
load-balanced
service
to
staple
sets
and
you'll
get
an
instance
of
a
running
WordPress
application.
The
kind
of
problem
with
that
is
that
there's
some
semantics
that
are
lost
in
creation
there
right,
like
the
fact
that
this
set
of
things
actually
aggregates
into
an
application,
is
really
lost
on
the
kubernetes
side.
A
We
can
ask
people
by
convention
to
use
a
standard
set
of
labels
which,
in
my
opinion,
I
think
we
should
anyway,
but
it
really
doesn't
help
things
like
server-side
garbage
collection.
It
doesn't
allow
you
eyes
to
have
a
standard
way
to
select
all
the
things
that
are
in
an
application
and
display
them
cogently,
be
they
graphical
or
command-line.
A
A
That's
out
there
right
now,
but
if
everyone
is
kind
of
doing
this,
why
don't
we
just
have
the
application
as
a
first-class
object
inside
of
the
apps
API,
so
that
we
have
a
consistent
way
for
everyone
to
interact
with
the
same
object
and
when
users
create
an
application
using
Hjelm
or
compose
or
Kuby
kuddle
apply.
However,
they
do
it.
We
could
have
all
the
UI
as
interact
in
a
similar
way
and
have
a
uniform
user
experience
across
everybody's
UI.
Also,
everyone
doesn't
have
to
reinvent
the
wheel.
A
We
can
do
things
like
add
garbage
collection
and
we
can
do
things
like
server-side
validation,
that
the
application
creation
is
valid.
So
to
that-
and
this
is
the
basic
API
and
I'm
not
going
to
go
too
far
into
depth
with
it,
just
because
it's
rather
large
and
really
to
give
useful
feedback
and
the
people
will
have
to
read
the
cap.
But
the
underlying
idea
is
that
we'd
have
a
high
level
application
object
that
has
status,
has
potentially
a
pot
health
check
and
it's
a
standard.
A
Kubernetes
api
object
with
a
spec
and
a
status,
and
you
can
compose
all
of
your
application
metadata
in
a
single
location
in
the
API
server,
as
opposed
to
having
to
append
all
of
the
information
to
every
object
in
order
to
determine
what
application
it
comes
from,
what
component
it
represents
and
what
license
it
has
who
the
maintainer
czar.
What
a
description
for
it
is
the
basic
functioning
of
it
is
to
list
the
components
by
group
version
kind
inside
of
the
application
metadata
and
then
add
a
selector.
A
That's
able
to
select
those
components
from
an
API
standpoint,
at
least
so
it
might
look
something
like
this.
So
the
same
WordPress
application
that
we
looked
at
above,
but
we
now
give
this
application
object.
The
application
object
has
a
selector
that
selects
all
the
components
of
the
WordPress
application,
the
specific
group
version
kinds
of
those
components
and
what
they,
how
they're
realized
is
made
explicit
in
the
component
section.
A
This
lets
any
client
know:
okay,
I
can
get
this
component
from
this.
Gbk
use
this
label
selector
to
do
my
list
or
my
watch
and
pull
it
back
down,
so
it
kind
of
because
there
is
a
bulk
API
that
allows
you
to
do
a
generic
watch
and
there
are
individual
client
sets
for
the
go
clients
that
allow
you
to
pull
down
individual
clients,
exposing
the
gpk
information
of
the
created
components
along
with
the
label.
Selector
is
sufficient
information
for
you
to
at
least
retrieve
the
component
from
a
UI
perspective.
A
There's
still
a
lot
of
challenges
around
like.
If
you
say
my
application
contains
a
deployment
that
deployment
also
has
replica
sets
and
those
replica
sets
have
pods.
So,
there's
an
object
hierarchy
of
ownership,
that's
implied
by
kubernetes
api
s
that
we
really
don't
address
in
this
cap
at
all,
so
UI
designers
are
still
gonna
have
to
display
a
deployment
the
way
they
know
how
to
display
it.
A
A
The
other
thing
that
the
application
api
has
is
a
notion
of
aggregation.
So
in
the
example
above
there
was
one
giant
application
that
contains
an
AR
DBMS
along
with
the
web
server,
but
a
model
of
tenancy
doesn't
go
for
every
application
or
every
organization
right.
Some
people
are
going
to
have
one
team
that
maintains
MySQL
as
a
database.
Maybe
it's
a
highly
available
replicated
version
of
MySQL
whatever,
but
it's
a
separate
app
from
the
application
of
that.
A
The
web
server
is
right
and
maybe
there's
a
tendency
model
where
multiple
people
are
going
to
be
dependent
on
this
same
app.
So
the
application
object
also
supports
the
notion
of
dependencies.
So
you
can
explicitly
say
that
an
app
depends
on
another
app.
So
in
this
example,
you
have
an
application
called
Bias
ql,
which
is
one
app
that
provides
the
database.
A
Then
you
have
a
second
half
which
depends
on
my
SQL
and
that's
WordPress,
and
that's
just
a
way
for
designers
to
be
able
to
again
split
apps
and
this
Express
dependencies
between
apps.
The
basic
functionality
that
we
want
to
end
up,
providing
via
the
controller,
will
be
the
API,
is
being
able
to
select
applications
and
all
their
components.
Retrieve
applications
get
dependencies,
provide
for
health
checks
and
from
the
server
side,
we'd
like
to
implement
garbage
collection
for
application
cascading
to
none.
A
So
if
you
could
be
cuddled
delete
app,
it
would
delete
the
app
along
with
its
components,
but
not
its
dependencies.
If
you
QB
cuddle
delete
app
non
cascading,
it
would
just
delete
the
application
object,
but
it
wouldn't
delete
any
of
its
dependencies
because
of
the
way
it's
designed,
you
could
actually
also
add,
apps
or
application
objects
to
existing
components.
A
So
there's
nothing
that
would
stop
you
from
creating
an
application
object
appropriately,
labeling
the
components
of
the
application
objects
having
a
label
selector
on
the
application,
object
that
selected
a
bunch
of
existing
components
and
composing,
a
bunch
of
services.
Ingresses
and/or,
pod
containers
like
staple
sets
and
deployments
into
an
application,
and
then
the
rest
of
the
the
cap
is
mainly
about
risks
and
mitigations.
Graduation
criteria,
that's
kind
of
important
to
talk
about.
I
mean
basically,
if
people
in
this
thing
don't
find
this
useful.
C
A
J
J
First,
is
it
seems
that
most
of
it
can
be
achieved
with
labels,
and
you
mentioned
it
yourselves
and
I
think
it's
pretty
common
standard
to
label
use
the
label
of
app
and-
and
we
found
that
it,
this
simple,
very
simple
label
can
meet
most
of
the
complexities
around
finding
the
components
for
enough
and
the
other
consideration
is.
There
seemed
to
be
some
overlap
with
the
helm
in
terms
of
the
metadata
dependencies
and
stuff,
and
just
wondering
how
you
see
these
these
to
work
together.
A
If
the
app
object
becomes
standard,
I'd
like
to
so
first
of
all,
I
think
it's
compatible
with
helm
and
I.
Don't
think
it's
something
you
would
do
instead
of
helm,
it's
something
to
enable
developers
of
tools
like
helm
and
compose
and
other
application
designers
to
kind
of
have
a
higher
level
object
that
provides
them
some
utility.
So
the
idea
wouldn't
be
to
replace
helmets
to
provide
a
tool
for
hell
yeah.
The
interaction
that
I
would
see
with
helm
is
that
you
would
have
inside
of
your
templates.
A
You
would
add
an
application
if
you
chose
to
do
so
near
manifest.
The
other
thing
is
it's.
This
is
kind
of
an
opt-in,
not,
and
you
must
feature
it's
a
you
may
so
if
we
can
get
broad
agreement
as
a
community
that
something
like
this
is
useful
and
it
helps
you
eyes
have
a
consistent
experience
like
the
idea
would
be
if
I
can
so,
the
broad
vision
is
I
can
help
install
an
application
and
then
I
can
Kuby
cuddle
get
the
application
and
it
works
or
I
can
I
can
use.
A
What's
the
I
forget
the
name
of
the
the
tool
the
case
on
it
yeah
so
I
can
case
on
it,
install
an
application
and
then
I
can
use
helm
to
update
it
or
get
it
right
like.
The
idea
would
be
to
provide
a
single
object
that
lets
all
the
tools
in
the
community
speak
the
same
language
about
applications,
but
not
sort
of
place,
any
of
them
yeah.
G
K
Just
had
a
quick
question:
I
think
this
looks
really
good
thanks
for
the
thanks
for
showing
it
and
it's
definitely
the
kind
of
thing
that
I
know
our
group
would
use,
but
I'm
curious.
Have
you
gotten
any
pushback
from
the
wider
community
about?
It
seems
like
this
abstraction
kind
of
moves
up
the
stack
a
little
bit
like
away
from
what
a
lot
of
the
other
things
that
kubernetes
has
done.
Do
you
think
you'll
get
pushback
about?
A
That
remains
to
be
seen,
but
I
hope
not
I
mean
ultimately
we're
sig
apps
right
and
we
have
an
act
group
in
the
API
and
if
we
think
this
is
useful,
when
it
provides
features
for
the
tooling
that
are
so
I
mean
like
the
thing
about
what
what
made
an
iPhone,
not
the
great
hardware.
That
was
one
thing,
but
ultimately
it's
the
apps
right.
A
So
kubernetes
is
probably
going
to
be
as
useful
as
its
apps
and
if
we
want
people
to
continue
to
developing
apps
and
contributing
to
a
rich
ecosystem
around
it,
we
have,
to
you
know,
meet
the
needs
of
those
people
of
those
developers.
If
we
want
our
users
to
have
a
consistent
user
experience
across
all
of
the
kubernetes
deployments,
including
tecktonik,
including
canonical
distribution,
including
AWS
and
azure
and
gke,
and
we
want
their
apps
to
work
in
all
those
environments
approved
for
them
to
be
able
to
use
their
tools
in
all
those
environments.
A
We
have
to,
in
my
mind,
provide
them
some
level
of
a
consistent
experience
and
labels
and
conventions
are
sort
of
one
way
to
do
that,
but,
ultimately,
a
well-intentioned
designer
of
a
tool
by
accidentally
not
meeting
a
particular
convention
that
we
put
out
there
and
said
you
should
do
this
can
break
somebody
else's
tool
or
somebody
else's
user
experience.
So
having
consistency
to
me
is
important
just
because
it
allows
a
user
to
go
from
environment
environment
from
tool
to
tool.
A
Let
these
that's
the
argument
I
intend
to
make,
but
I
mean
you
know,
make
sense
yeah
we
have
to
see
if
the
community
I
would
say
that
if
everybody
who
works
on
the
ecosystem
is
in
favor
who
reward
in
this,
and
if
we
can
address
all
of
your
feedback,
that's
a
strong
indication
that
that's
just
something
we
should
do
if
there's
no
interest
in
it
or
if
everyone
says
this
is
not
useful.
Well,
then
we
have
to
take
that
as
feedback
to
you
right.
E
I'll
just
jump
in
here,
so
one
of
the
things
at
the
app
dev
working
group,
where
folks
from
a
number
of
SIG's
have
come
together
to
discuss
application,
compatibility
and
tooling
compatibility
to
allow
things
to
work
together.
One
of
the
very
first
things
that
came
up
was
a
similar
concept
to
this
in
the
form
of
a
CR,
D
and
Antoine,
actually
demoed.
E
That
I
think
in
the
very
first
app
deaf
working
group
meeting
to
show
that
off,
and
so
this
idea
has
been
a
long-term
discussion
point
over
there,
and
one
of
the
actions
was
to
bring
that
kind
of
idea
here,
and
it
so
happens
that
Ken
was
coming
over
with
this
and
we
were
looking
at.
When
do
we
talk
about
a
CR
D
and
the
agenda
he's
like
well,
do
we
make
it
part
of
apps
v1,
and
so
the
conversation
was
kind
of
moved
over
here?
E
A
K
And
yeah
it
definitely
makes
sense.
Like
I
said,
our
group
is
doing
something
very
similar
with
the
apps
that
we're
creating
in
terms
of
putting
together.
You
know
our
own
custom
labels
and
annotations
to
collect
these
things.
I
was
just
kind
of
curious
about
you
know
fitting
into
the
ecosystem,
but
I
think
your
ration,
how
it
makes
good
sense
to
me
and
like
a
point
that
I'll
point
our
group
at
this,
hopefully
get
some
comments
there.
We.
A
Particular
we're
looking
for
maybe
Anton
to
give
some
credit,
because
he's
done
a
lot
of
work
with
these
CR
IDs
and
getting
the
coral
or
the
tectonic
feature
out
to
market.
So
any
lessons
learned
or
any
like
I
mean
I've.
We
put
some
fields
in
for
a
notion
of
what
these
are,
the
things
that
are
valuable
or
in
application,
for
instance,
but
we're
not
convinced
those
are
necessarily
the
right
set
of
fields.
So
is
there
anything
that
should
be
in
there?
Is
there
anything
that
shouldn't
be
in
there?
A
The
other
thing
is
with
the
Anton
I
think
is
going
to
talk
about
this
next
with
there's,
there's
still
value
in
having
a
standardization
of
labels
across
tools.
Even
if
we
do
this
application
so
maybe
and
I
think
I
tried
to
leverage
some
of
the
the
the
the
that
gets
the
design
document
for
common
labels
across
applications
anyway,
but
making
sure
that
we
capture
that
is
probably
important
as
well.
L
I'll
jump
in
here
with
a
comment:
this
is
really
exciting.
I'm,
looking
forward
to
reading
the
cap
in
detail,
I
think
the
notion
of
an
application
level.
Health
check
is
something
that's
really
exciting,
and
this
in
particular,
is
a
really
good
way
to
do
it
and
I'm
sure
you're
gonna
be
talking
about
this
at
home.
Someone
in
the
working
group
right,
okay,
I.
L
A
You
but
definitely
I
intend
to
attend
the
app
depth
working
group
meeting.
That's
I
believe
this
Wednesday
and
discuss
further
there
and
see
if
there's
interest
there
as
well,
but
primarily
I
mean
you
guys
are
the
ultimate.
You
guys
would
be
the
consumers.
You
guys
would
be
the
users
you
guys
are
driving
the
ecosystem
that
this
is
meant
to
support.
So
your
feedback
is
like
some
of
the
most
important.
E
A
D
Mentioned
that
this
this
is
super
interesting
to
me.
I've
been
working
on
some
film
charts
that
have
like
and
like
a
number
of
deployments,
a
number
of
states
or
sets,
and
all
the
services
and
PVCs
and
everything
tie
them
together
and
to
have
an
extra
layer
where
I
can
kind
of
describe
them
all
together
and
kind
of
more
how
they
function
together
and
do
that
application
level
health
check
as
I.
Guess
it's
almost
like
a
better
application
at
that
stage.
H
H
M
A
M
A
Should
definitely
engage
the
definition
working
group
I
brought
it
to
see
gaps
first
because
see,
gaps
is
kind
of
where
everybody
who
works
on
the
ecosystem.
Pooling
tends
to
show
up
so
I
thought
it
would
be
a
great
place
to
engage
people
who
are
working
actively
on
helm
or
working
working
actively
on
compose
or
case
on
it
or
any
other
type
of
pool.
That
is
using
applications
in
that
ecosystem.
I
mean
we're
talking
about
an
app
object
that
would
live
in
the
apps
group.
A
M
So
I
look
at
the
proposal.
I
think
we
at
Salesforce
are
also
doing
something
similar
internally,
but
obviously
using
crts,
and
so
would
love
like
we
have
a
lot
of
feedback
in
those
areas.
So
I
look
at
the
proposal.
One
last
question:
is
this
not
just
API
object
right?
Obviously,
it's
going
to
be
supported
by
an
entry
controller
as
well
correct.
N
Can
do
you
have
any
fine
lines
where
you
wanna,
when
you
are
planning
to
implement
this
I
mean
that
today
is
a
feature
freeze
for
one
point:
ten
I'm
assuming
that
you're
starting
the
discussion,
and
this
will
be
landing
for
what
eleven
or
are
you
actually
interested
in
having
something
in
place?
For
one
point,
ten
we're.
A
Interested
in
doing
it
in
1.10
and
starting
at
the
mutation
in
one
point,
10
and
getting
it
to
alpha
in
1.10,
there's
planned
implementation,
history
on
a
Kappa,
so
we'd
like
to
get
potentially
to
beta
by
111,
provided
we
get
adoption
and
that's
really
the
graduation
criteria
for
going
to
beta.
As
far
as
the
cap
is
concerned,
right
now
right,
so
if
everyone
finds
it
useful
and
if
people
can
start
playing
with
it
at
an
alpha
level
in
1/10
through
111,
maybe
by
111,
we
could
take
it
to
beta.
E
It's
also
worth
knowing
for
anybody.
Who's
who
isn't
familiar.
The
caps
are
the
direction
that
kubernetes
just
kind
of
going
for
major
changes
like
this.
It
stands
for
kubernetes
enhancement
proposal
and
where
there
were
features
and
some
other
things
in
the
past.
This
is
the
direction
that's
being
piloted
for
the
new
system.
It
was
built
around
things
like
rust
and
their
system
and
Python
maps
to
try
to
bring
all
of
this
stuff
together
that
we
have
done
in
the
past
and
be
able
to
link
off
to
stuff.
E
So
if
you're
ordering
we're
in
the
proposal
process
and
things
it's,
this
is
kind
of
being
beta
tested
as
a
new
system
to
kind
of
supersedes
the
past
once
beta-tested.
So
the
the
process
may
change,
but
that's
where
this
sits
and
so
eventually
it'll
get
in
front
of
others
like
sega
architecture
and
things
like
that
as
it
continues
to
move
along.
But
this
is
kind
of
the
proposal
process
these
days
that
we're
trying.
A
C
A
Anything
you
would
do
a
design
for
I
think
at
this
point
you
would
probably
want
to
do
a
chance
for
most
thing
if
it
doesn't
require
a
design,
if
it's
a
small
change
or
great
fix
or
bug
fix,
and
that
wouldn't
require
attempt.
That's
my
understanding
at
least
Caleb
or
Jo,
beta
or
maybe
Sarah
would
all
be
people
that
you
might
want
to
reach
out
to
in
terms
of
better
understanding
exactly
what
requires
a
Kevin.
What
doesn't
is.
E
A
E
P
P
P
E
If
anybody
wants
to
look
at
it,
what
we're
really
looking
at,
though,
is
in
the
process.
This
came
out
of
the
application
definition
working
group,
and
one
of
the
things
that
we've
got
here
is
we're
looking
at
the
proposal
for
the
names
we're
discussing
the
different
ins
and
outs
of
the
characteristics-
and
we
want
to
go
now-
create
best
practice
document
to
put
up
on
kubernetes
I/o
to
go.
E
Tell
folks
here
is
what
they
are
and
then
some
folks
you
can
build
things
like
validators
across
it
like
there
is
a
demo
I
think
that's
gonna,
be
at
the
app
dev
working
group
that
actually
shows
somebody
can
go
inspect
the
different
resources
running
in
a
cluster
and
see
how
they
match
up
to
what
labels
and
annotations
they've
done
here
right.
So
you
can
see
who's
doing
it
who's
not
have
they
done
this?
P
So
if
you
have
opinions
or
is
like
some
open
question,
left,
for
example,
the
name
should,
if
I
take
the
example
of
what
price,
should
it
be,
what
price
will
be
my
square
like
a
component
of
for
price,
what
the
name
should
be
in
this
case.
It
also
just
is
some
open
question
and
invite
you
to
comment.
E
There's
something
some
folks
may
want
to
call
attention
to
you'll
notice
that
everything
is
named.
Spaced,
which
I'll
be
honest,
is
harder
on.
You
acts
in
fact,
there's
a
discussion
on
that
and
the
reason
the
first
pass
didn't
use
namespaces
on
the
labels,
but
we
didn't
feel
it
was
appropriate
to
take
over
the
global
namespace
either,
and
so
that's
where
we
went
with
the
namespace
I.
Don't
think
this
would
be
accepted
up
if
it
just
decided
to
come
up
with
the
names
for
the
global
namespace.
E
But
there's
still
debate
going
on
in
this
document
as
weary
finally
refine.
What
should
be
in
which
would
be
out?
How
should
it
be,
you
know,
should
it
be
tier
or
component
or
layer
or
something
else
right
how
the
new
wants
naming
right?
That's
where
you
want
our
case,
that's
where
we
tend
to
debate
things,
and
so
please,
if
you've
got
opinions
come
in
chime
in
because
after
it
goes
through
the
app
dev
working
group
on
maybe
Wednesday
I
hope
to
craft
the
PR
which
I'll
send
out
on
the
mailing
list.
Here.
M
E
So
that's
two
things
they're
complementary
to
each
other,
as
it's
seen
in
how
we're
gonna
do
it.
One
of
the
things
in
the
app
to
have
working
group
was
will
to
have
multiple
ways
to
handle
things,
labels
and,
in
this
case
its
labels
and
annotations,
because
we're
actually
using
both
and
they've,
got
slightly
different
purposes
with
labels.
You
can
query,
but
they're
shorter
annotations
can
be
longer,
but
you
can't
query
on
them,
so
you
can't
put
like
the
URL
into
a
label
because
a
label
doesn't
have
enough
space,
but
that
works
for
an
annotation.
E
So
there's
things
like
that,
but
in
many
projects,
if
you
go
look
at
places
like
AWS
labels
or
tags
or
equivalent,
is
a
way
to
structure
and
put
this
information
out
there.
It's
patterns
people
are
used
to,
and
we
could
start
putting
this
out
and
building
on
it
today
and
using
it
today.
In
fact,
things
like
home
already
use
labels
in
how
they
do
things
right.
E
It's
it's
part
of
the
best
practices,
it's
useful
information,
and
so
this
is
kind
of
a
way
to
kind
of
expand
that
to
a
broader
set
of
folks
and
opportunities.
While
doing
some
more
generic
ones
that
are
not
necessarily
helm,
specific
or
something
else
specific
to
their
cases
but
kind
of
bringing
that
together-
and
so
that's
that
was
kind
of
the
idea
here-
is
things
that
would
complement
each
other.
E
Some
things
you'll
have
in
the
higher-level
app
API
that
you
wouldn't
have
here,
like
maybe
a
link
to
and
a
hike
on
right
that
that's
the
kind
of
thing
that
you
wouldn't.
You
wouldn't
necessarily
put
on
every
object
that
you'd
have,
but
some
things
you'd
have
on
more
objects,
and
so
they
can
complement
each
other
and
I
would
expect
this
to
evolve
over
time
depending
on
how
people
use
it
and.
B
Is
there
not
go
good
I
see
how
the
two
proposals
are
complementary,
but
from
the
standpoint
of
a
user
that
hasn't
been
through
all
the
conversations
about
the
cap
and
the
working
group
and
doesn't
understand
how
he
came
to
decision.
We
should
ask
if
it
will
seem
confusing
that
there's
two
different
ways
to
create
two
group
resources.
So
I
know
both
groups
are
rushing
to
get
a
solution,
but
it
would
be
good
to
make
sure
we
head
up
with
someone.
That's
not
confusing
for
future
users.
E
E
A
That's
okay,
but
I
kind
of
look
at
it
as
the
application
object
being
am
a
thing
that
people
can
opt
into
and
the
labels
being
a
should
thing
that
should
be
done
that
make
sense
like
everyone's
already
do
it.
Using
labels
like
this.
Like
most,
these
things
that
are
listed
in
the
common
labels
and
annotations
proposal
are
annotations,
that
I
see
in
helm,
charts
or
in
case
on
acree
applications
or
in
kubernetes
manifest
they're,
just
raw
manifest
right,
so
I
would
think
marking
marching
forward
and
getting
consistency
there
on.
B
Good
outcome
for
my
users
2/4
from
now,
is
that
there's
a
single
document
that
tells
them
you
know
whether
they're
a
UI
designer
or
an
application
author,
all
the
things
they
may
or
should
do
in
sort
of
a
coherent
language.
So,
even
if
we
have
two
separate
proposals
at
the
end,
we
need
to
come
up
on
the
docs
page
with
one
document
that
says
how
to
group
group
your
resources.
E
It
would
be
nice
just
to
have
here
is
the
different
layers
of
things
you
can
and
should
you
know,
do
and
here's
what
you
can
get
out
of
it
by
doing
those
things
and
I
don't
know,
maybe
I'll
delay
the
PR
on
the
labels
and
annotations
until
we
have
a
better
idea
where
things
are
going
to
go
with
the
app
object
and
just
see
how
we
can
make
a
consistent
holistic
approach
to
this.
That.
D
Interesting
thing
I
think
we
might
get
out
of
this
is
in
theory,
something
like
home
could
actually
generate
the
app
resource
based
on
the
labels,
if
they're
done
correctly
here
and
or
it
could
actually
test
the
application
resource
against
the
labels
and
say,
okay,
you
have
to
describe
what
your
application
actually
is,
because
the
labels
exists,
as
we
would
expect
them
to
so
I
think
there
were
some
interesting
testing
use
cases
and
also
like
automating.
The
application
resources
as
well
would
come
out
of
making
sure
that
were
complementary
and
understand
each
other.
E
E
All
right
so
so
back
to
opinions
on
this,
though
feedback
or
input
on
this.
Please
get
it
in
here,
because
it
will
help
and
back
to
the
other
proposal
if
you've
got
feedback
on
the
app
object
as
well.
Please
give
it
think
it
through
look
at
how
you
could
or
would
use
it
so
that
they
can
get
an
alpha
implementation
working.
E
E
N
C
N
N
E
N
A
N
Pretty
much
pretty
much
or
at
least
start
some
discussion
in
what
direction
we
want
to
go
with
it
and
I'm
personally,
leaning
towards
not
including
it
and
I
would
like
to
hear
from
other
folks
what
they
think
comment
on
the
PR
or
on
the
original
issue.
Both
are
linked
in
the
agenda,
what
they
think,
whether
we
should
allow
it
or
should
not,
and
what's
the
interest
actually
for
the
future,
I
haven't
seen
any
major
interest
in
that
feature.
That's
why
I'm
leaning
towards
not
including
it
at
all.
A
That
might
be
something
that
we
should
take
up
with.
Sig
you'd
want
to
take
up
with
sig
architecture,
because
it's
kind
of
beyond
just
the
ecosystem,
around
kubernetes
or
the
workload
controllers
or
apps
itself.
It's
kind
of
a
very
major
decision
that
you
would
want
I
think
top
level
maintainer
feedback.
A
If
you
are
going
to
try
to
do
it
and
then
I
think
you
gave,
we
gave
a
brief
summary
of
some
of
the
issues
that
would
surround
doing
that
in
terms
of
time,
zones
can
be
somewhat
brittle
other
than
that
I
mean
I
I,
don't
really
have
anything
else
to
add,
so
it
would
be
great
if
other
people
who
do
have
a
strong
opinion
from
sig
apps
could
chime
in
on
it.
And
but
you
really
think
it's
a
great
feature,
maybe
shout
for
it
now,
so
we
can
try
to
resolve
it.
That's.
E
You
might
want
to
bring
it
up
to
actual
discussion.
I
just
dropped
in
the
sig
architecture,
meeting
minutes
and
agenda
into
chat,
sig
architecture
every
other
week
has
basically
office
hours
to
bring
topics
like
this
up
and
then,
if
they
don't
have
enough
to
go
and
deal
with
other
working
things
over
there
and
this
week
is
an
office
hours.
So
if
you
want
to
bring
it
up,
you
can
get
it
on
the
agenda
for
this
Thursday
and
it's
at
I,
don't
know
how
it
works,
but
it's
8:30.