►
From YouTube: Office Hours: 2021-08-19
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
all
right
so
welcome
everybody.
We
have
a
few
items
in
the
agenda.
I
I
added
two
here
towards
the
the
bottom.
I
didn't
want
to
put
my
items
up
there,
but
if
you
have
any
anything
that
you
want
to
discuss,
you
can
feel
free
to
add
anybody
can
add.
It
should
be
edited
by
anybody.
A
So,
let's
start
reference
implementation
work
is
getting
started.
I
know
that
ben
was
working
on
creating
implementers
team.
I
invited
beijiu
and
project
to
the
org.
I
think
you
guys
got
the
invite
so
we're
just
working
through
some
logistics
in
terms
of
actually
having
the
github
org
team
and
who
has
right
access.
I
believe
scott
you
already
got
got
in
to
that
team
as
well.
A
A
C
D
Yeah,
I
definitely
agree
that
implementation
is
weird
renaming
things
at
this
point
is
relatively
easy,
so
I'm
not
worried
about
whether
we
do
that
now
or
later.
A
A
Ben
created
this,
I
don't
know
if
ben
wanted
to
do
some
implementation,
but
we're
probably
easygoing
for
rene.
E
I
was
hoping
that
it
would
change
while
you
were
still
talking
about
it,
but
I
had
to
log
in
working
on
it
right
now.
Yeah
cool.
A
All
right,
so,
besides
the
name
anything
we
want
to
say
about
this,
it
looks
like
it's
already
been
populated
with
some
some
good
stuff
here.
C
D
Yeah,
the
only
thing
in
here
so
far
is
really
just
the
the
default
scaffolding,
as
well
as
the
the
types
were
copied
from
the
the
the
spec
beyond
that
there's
actually
no
controller
implementation
so
far,
so
all
that
still
needs
to
be
done.
We've
primarily
just
been
setting
up
infrastructure
like
getting
ci
running,
making
sure
tests
run
getting
the
pen
the
bot
bumping
our
dependencies,
so
nothing
too
exciting.
Yet
but
more
so.
This
is
an
fyi
that
the
repo
exists.
There
are
things
going
on
here.
A
And
I
assume
we
want
to
use
this
repos
self-contained
for
issues
related
to
the
impul,
not
push
this
back
up.
I
think
that's
a
good
idea,
so
we
have
the
vision
between
this
pack.
I
just
noticed
service,
binding
operators,
probably
an
xpr.
We
want
to
change
some
of
the
the
words
here
and
maybe
just
copy
and
paste
from
somewhere
else.
A
That
awesome,
thanks
for
starting
this
anything
else
on
this
first
topic,
probably
more
just
awareness.
C
Yeah
in
case,
if
somebody
send
a
peer
which
is
not
really,
you
know,
part
of
kubernetes,
what
should
we
do
like?
We
can
hold
it
or.
E
So
my
feeling
is
right
now
only
the
people
who
commit
should
be
committed
right,
like
I
don't
even
know,
like
I
don't
believe,
there's
a
permission
that
will
allow
us
to
turn
off
prs
from
outside
of
the
group,
but
we
should
be
summarily
rejecting
them.
We
shouldn't
encourage
people
to
do
it.
They
can
open
issues,
but
nobody
should
be
contributing
code.
Other
than
members
of
this
working
group
that
we
have
guaranteed
signed
things.
E
A
You
yeah,
I
I
know
there
in
when
I
when
I
was
working
at
the
micro
profile
open
api
spec.
There
was
a
bot
that
was
automatically
checking
for
that.
Is
anybody
familiar
with
enabling
that?
Because,
if
we
had
a
way
to
automatically
check.
C
Then
I
don't
think
we
can
enable
the
cncf
bot,
because
I
think
that
that
they
need
some
kind
of
token
which
we
get
if
we
are
part
of
the
kubernetes
project.
So
I
don't
think.
D
It'd
be
fairly
easy
just
to
write
a
github
action
that
closes
the
pr
with
a
nice
message
if
it's
created
by
someone
who's
not
on
a
white
list,
yeah
plow
list,
yeah.
Sorry,
it's
basically
three
or
four
names
at
the
moment
so
like
it
wouldn't
be
it's
particularly
hard,
yeah
or
if
it
becomes.
We
can
also
just
wait
until
it
becomes
an
issue
and
then
deal
with
it.
A
C
A
A
All
right,
okay,
second,
item;
okay,
just
switch,
so
we
can
go
to
that.
One.
E
Okay,
so
one
of
the
things
I
worked
on
over
the
weekend,
it
was
actually
a
couple
weekends
ago
was
writing
clients
for
service
bindings,
and
I
took
a
crack.
I
got
a
jpm
based
on
a
go-based
one
and
a
javascript
based
one,
and
I
was
wondering
if
there's
any
interest
in
this,
I'm
also
working
on
a
python
one
of
the
at
the
moment
for
having
a
set
of
libraries
for
actually
consuming
these
things.
E
C
Oh
okay,
actually
I
remember
there
was
another
issue
and
I
had
already
created
a
couple
of
electrical
for
one
for
python.
Another
for
go.
Okay,.
E
C
I
think
that
you
know
discussion
in
that
ticket
to
us
like
we
don't
need
to
make
it
part
of
our
this
project.
We
can
keep
it
like
a
external
yeah,
but
we
can
aggregate
it
somewhere,
maybe
a
link
in
a
prominent
place
so
that
people
can
discover
it
but
need
not
to
mix
with
this
spec
or
effort.
Yeah.
B
Okay,
yeah,
I
think
in
general
I
like
the
idea
of
starting
it.
The
only
I
think
concern
which
both
probably
scott
and
I
shared
on
the
same
thread
is
that
there
would
be
general
maintenance
and
maturity
expectations,
which
is
something
this
small
group
may
not
be
able
to
serve,
and
that
is
why
we
may
not
want
to
put
it
as
part
of
the
implementation
or
the
group
or
the
org
right
away,
but
then
we
should
definitely
aggregate
it
in
one
organization
and
then
eventually,
when
we
feel
that
this
group
has
the
you
know.
B
This
group
feels
comfortable
that
this
can
be
maintained
over
time
or
let's
say
we
figure
out
that
it
is
not
really
a
huge
maintenance
override.
We
just
over
thought
it
a
little
too
much
we
were
just
taking,
but
I
think
once
that
gets
figured
out,
I
think
then
we
should
take
it
in,
but
prior
to
that
it
should
be
in
some
other
organization.
B
D
D
Unless
we're
really
saying
this
is
the
client's
api
for
this
language,
what
I
think
we
should
do,
regardless
is
to
have
a
section
of
the
spec
that
talks
about
known
implementations,
where
we
can
basically
just
call
out
crds
that
expose
or
conform
to
the
provision
service
resources,
cases
where
we
know
that
there
are
mappings
defined
for
other
types
of
crds
that
aren't
necessarily
possible
and
then
also
have
known
clients
or
sort
of
app
frameworks.
D
A
Yep,
it
sounds
good.
My
question
was
around
just
a
use
case,
which
I
think
you
you
touched
upon
squad.
So
these
are
clients
in
the
sense
of
applications
that
are
consuming
the
mounted
bindings
is
that
is
that,
where
they
are
yeah
think
I
think
that's
that's
awesome.
A
And
I
think
one
of
the
one
of
the
future
goals
could
be
to
help
kind
of
adoption.
Is
you
know?
I
mentioned
micro
profile,
that's
kind
of
one
of
my
backgrounds.
I
would
love
to
go
to
them
in
one
of
the
specs
and
work
with
them
and
to
say
maybe
the
micro
micro
profile
config
and
have
some
native
way
that
they
consume
service
bindings
right.
So
I
think
that
would
be
an
awesome
thing
for
us
to
pursue.
A
You
know
spring
boot,
like
any
anything
that
we
can
go
as
a
framework
and
and
try
to
to
insert
the
the
service
binding
adoption
from
that.
I
think
that
would.
E
If
you
looked
at
these
implementations
and
none
of
the
languages,
are
they
particularly
difficult
to
do
for
someone
to
do
them
internally,
but
there
is
still
a
barrier
to
entry
that,
like
jaccard,
is
never
going
to
take
a
dependency
on
by
you
or
me
right,
and
I
think
they're
going
to
be
a
lot
of
companies
who
would
be
hesitant
to
taking
a
personal
dependency
in
a
way
that
they
wouldn't
have
a
problem
with
it
if
it
was
from
the
reference
implementation
itself.
So
I
think
that's
like
next
step.
E
We
should
keep
an
eye
on
that
what
it
takes
to
basically
and
because
I
also
like
take
a
look
at
a
bunch
of
other
cncf
projects
that
I'm
involved
in,
like
the
one
that
really
stands
out
for
me.
Is
the
cncf
r
socket
project?
Sorry,
not
cncf,
the
linux
nope.
E
Let
me
get
it
right,
reactive
foundation,
our
socket
project,
which
is
a
amazing
project
that
has
two
or
three
language
findings:
clients
effectively
for
it,
but
without
a
go
one
like
it's
really
hindered
adoption
and
it's
not
like
somebody's
going
to
write
all
those
things
on
their
own
yeah.
C
I
think
we
can
create
a
guitar,
separate
youtube
organization,
and
you
know
I
encourage
people
to
contribute
it.
We
don't
need
to
have
any.
You
know,
I
would
say,
no
no
need
to
keep
any
big
free.
I
mean
what
you
call
like
a
cnc
for
anything
of
that
sort.
We
can
just
keep
it
as
an
organization.
Anyone
want
to
contribute
it.
C
Let's
keep
it
very
liberal,
so
that
yeah
that's
what
I'm
thinking
so
that
it
not
only
in
my,
for
example,
in
my
python
is
it's
goes
to
by
gm
yeah.
That
doesn't
looks
good.
I
mean
in
somebody's
cloning,
even
in
the
go
library.
Staying
in
my
personal
repository
may
not
be
a
good
thing
for
who
looking
to
adopt
that
one
right,
yeah.
A
Yeah
and
scott
we'll
go
to
and
go
to
next,
milo
commerce
is
going
to
be.
We
do
have
a
samples
repo
in
this
org,
which
may
be
a
home
to
put
this
stuff
in.
For
now.
I
just
would
hate
to
create
yet
another
org
that
we
need
to
keep
track
of
as
we're
trying
to
move
to
sig
or
something
else,
so
maybe
samples
or
something
we
can
just
put
it
there.
E
Yeah
yeah
I'd
like
I,
I
wouldn't
even
get
too
nuts
about
this,
like
I
don't
think
it's
a
pressing
thing
for
adoption
today
right
so
like,
let's
just
keep
what
we're
doing,
keeping
them
in
the
personal
places
and
once
we
get
to
1-0,
then
we,
I
think,
that's
when
we
start
thinking
about.
Should
we
have
our
own
reference
implementations.
Do
they
get
another
org
et
cetera,
et
cetera,.
C
There
are
other
you
know,
community
members
already,
for
example,
in
red
hat.
Our
middleweight
team
has
already
worked
created
on
node.js
and
there
is
something
called
what
is
called
java.
Corkus
right,
yeah
caucus
one.
So
this
all,
I
think
it
is
not
just
library
some
of
them
are
depending
on
the
framework
itself.
So
that
means
those
are
going
to
be
external
libraries
or
frameworks.
D
Yeah
my
pipe
dream
for
where
this
ends-
and
I
realized
like
this-
is
not
anything
that
we
have
direct
control
over
and
it'll
take
years
to
actually
materialize
is
that
over
time,
application
frameworks
will
basically
natively
implement
this
sort
of
the
in
container
element
of
the
spec
as
well
as
that
service
drivers
will
basically
implement
this.
Like
can
just
they'll
just
know
to
like
check
if
this
invar
is
set
and
then,
if
it
is
set,
then
go
look
at
that
directory
so
like.
D
If
you
are
a
redis
client,
when
someone
instantiates
the
redis
client
like
if
they
don't
have
to
specify
the
location
of
your
reta
server,
then
the
client
can
basically
go
see.
Oh
this
mvar
set.
Let
me
go
check
to
see
whether
there
are
any
bindings
that
are
type
redis.
If
there
are,
it
can
just
go
grab
it
configure
itself
and
then,
like
everything,
just
works
without
actually
users
having
to
do
anything
special
but
like
that's
like
the
huge
ecosystem
play
hopefully
happens.
D
E
A
All
right,
so
I
think,
there's
some
good
things
for
us
to
follow
up
in
the
future
with
this.
Okay.
Moving
on
to
the
next
one
issue,
one
one:
three
api
group
domain,
name,
scott.
I
believe
you
have
a
pr.
No
it's
an
issue.
Okay,
it
should
be
domain
name.
D
I
didn't
add
this
to
the
agenda.
Okay,
this
is
I.
C
Guess
I
added
this
this
last
week
we
discussed
regarding
our
apa
group
name,
so
I
remember
ben
is
going
to
check
with
their
organization
any
update
on
that
bin
regarding
whether
we
they
can
vmware
can
take
care
of
this
domain.
A
E
Yeah,
I
don't,
I
don't
have
any
updates.
I
don't
see
constant
on
the
call
either
around
the
same
stuff.
Unfortunately,
so
I'm
not
sure
there's
any
change
there.
So
on
the
api
group
I
checked
over
on
our
side.
There's
no
appetite
for
us
to
take
the
lead
on
this.
So
red
hat
wants
to
take
the
lead
on
building
a
straight
oss
project
around
it.
We're
supportive.
B
Yeah,
I
think
that
sounds
okay
to
me.
There's
a
so
I
think
then
we
can
decide
on
a
domain.
It
doesn't
have
to
be
what
we
have
now.
So
we
can
decide
on
a
domain
together
and
I
can
have
the
open
source
program
office
own
it
and
manage
it
and
provide
and
give
us
whatever
we
need
to
to
be
able
to
point
our
stuff
to
it,
so
that
that
should
be
fine.
A
I
think
it'll
be
awesome
because
it
it
puts,
I
don't
know
if
he
puts
a
bit
pressure
on
on
sick,
to
move
forward
a
bit
more,
but
I
think
in
any
case
it
just
at
least
gives
us
a
home
that
we
could,
if
we
wanted
to
ship
1-0
right.
It
seems
like
this
is
the
missing
piece
of
the
puzzle
that
we
that
we
kind
of
needed
and
we
could
always
ship
1-0,
even
while
we're
still
trying
to
figure
out
sig
cf
whatever
home.
You
know
state
where
we
are
in
this
new
new
domain.
E
Yeah
yeah,
I
think
the
the
one
the
one
request
we're
going
to
have
from
our
side,
and
this
is
sort
of
like
an
informal
request
from
joe
beta
rather
than
a
mandate,
and
I
I
assume
your
ospa
is
going
to
say.
The
same
thing
is
like
it:
shouldn't
have
kate's
in
whatever
our
domain
ends
up
being
absolutely.
B
Like
a
hard
thing,
okay
yeah,
I
think
so
so
our
open
source
program
office
would
do
the
general
legal
checks
with
what
the
name
should
be
availability,
whether
like
in
some
cases
they
even
go
to
different
stakeholders,
who's
squatting
on
it
and
request
them.
Give
them
some
time,
probably
even
offer
money
if
needed
to
you
know
let
go
of
a
domain
if
we
choose
to
so
so
yeah.
B
I
think
in
general,
if
we
could,
as
a
group,
agree
on
a
rough
name,
and
then
I
can
provide
it
to
the
open
source
program
office
to
give
us
the
available
permutations
of
it
and
then
from
there
I'll
I'll.
Even
add
you
folks
to
the
same
thread
with
them
and
eventually
the
idea
would
be
we
would
have.
This
group
will
have
a
control
over
what
gets
pointed
to
it
from
different
places,
so
yeah.
B
I
think,
then,
as
a
next
step
for
the
backup
plan,
we
should
decide
on
what
we
want
as
the
domain
name
roughly,
and
then
we
can
get
is
that
is
that
a
good.
C
C
Having
going
for
this
domain
need
not
be
a
backup
plan,
in
my
opinion,
because
you
know-
let's
say
if
you
start
with
the
kubernetes
it
for
no
54.
That
means
part
of
cncf
right,
so
it
becomes
more
vendor.
I
mean,
or
even
foundation
neutral
for
that
matter.
So
having
our
domain-
and
you
know,
even
if
this
getting
into
cncf
or
kubernetes
project
is
delayed,
it's
not
going
to
affect
us
right.
So
I
think
we
can
start
this
right
away
without
waiting
for
that
cncf
or
kubernetes
yeah
sick
thing.
A
Think
I
think
at
this
point,
at
least
for
me
and
and
the
teams
that
I've
talked
to.
C
A
You
know
in
products
we
ship,
then,
if
that's
sig
or
ctf
or
anything
as
long
as
we
have
something
that
we
can
use,
I
think
has
got
to
the
point
where
it's
it's,
that
has
become
more
than
what
is
the
name
in
our
in
our
api
group.
So
definitely
plus
one
for
let's
see,
let's.
E
C
Okay,
and
as
soon
as
you
know,
the
cnc
for
whatever
comes
up,
we
can
the
redhead,
you
can
hand
over
yeah
just
make
sure
we
need
to
make
sure
that
they
can.
You
know
hand
over
that
domain
to
that
foundation.
That's
it.
B
Yeah,
I
think
that
should
be
fine,
because
the
the
folks
who
are
in
the
open
source
program
office,
some
of
them,
are
chairs
in
a
bunch
of
six
anyway.
So
I
think
that
that
should
be
pretty
pretty
easy,
pretty
easy
to
do.
In
that
case,
why
did
you
want
to
go
and
start
go
ahead
and
start
the
thread
to
brainstorm
wrong
names,
and
then
we
can
get
it
started.
Then,
okay,
yeah.
A
We'll
do
and
the
the
last
comment
I
guess
I
had
about
this-
would
be
we
did
some
work
in
terms
of
figuring
out,
like
you
know
who
the
admins
would
be,
who
the
committers
would
be
and
all
that
stuff
for
sick
should
we,
it
seems
reasonably.
We
can
reuse
that
since
we
already
gone
and
gone
through
that
you
know
so
we
don't
have
to
go
through
it
again.
A
D
A
D
A
See
where,
where
we
are
over
slack
okay
next,
one
final
call
yeah
application
to
workload
name
so
for
anybody
that
wasn't
here
two
weeks
ago
we
did
take
a
vote
and
workload
won
over
applications.
So
I
I
admit
I
I
had
voted
for
applications
so
but
I'll
I'll
concede
to
the
the
majority
and-
and
I
I
gave
my
approval
to
the
pr
you
just
felt-
I
think
ben.
A
You
also
approved
the
pr
thanks
scott
for
making
all
those
changes,
but
if
they
felt
like
a
big
enough
one
that
we
wanted
to
the
final
call
here
before
merging.
So
if
you
have
any
concerns.
A
Yeah
and
also
very
important,
shubik
and
and
other
folks
from
service
binding
operator.
What
that
would
mean
in
terms
of
reacting
right-
and
I
know
there
is
a
service
binding
cr
in
that
community-
that
closely
resembles
the
the
spec,
so
getting
in
line
with
the
with
the
term
would
be
very
good
after
we
merged
this
as
well.
B
C
Yeah,
I
also
agree
so
let's
go
to
that
workload.
D
Something
somewhat
related
excuse
me
is
that
whenever
we
cut
our
our
next
release
preview
or
not
of
the
spec,
we
should
definitely
bump
the
api
version,
so
that
implementations
can
provide
a
conversion
web
hook,
so
that
basically
we're
not
breaking
existing
users.
Necessarily
at
least
an
implementation
could
support
both.
C
Yeah
in
kubernetes
community
normally
observe
that
as
soon
as
it
enters
beta,
they
support
this
apa
migration,
but
in
during
alpha
they
don't
do
that.
E
It's
also
useful
just
to
be
fails
early.
If
your
implementation
doesn't
support
that
kind
of
thing,
do
we
want
to
change
just
to
v1
alpha
2
as
part
of
this
pr
or.
E
B
D
D
We
can
also
do
that
later,
like
there's,
definitely
other
subtle
changes
that
have
gone
in.
So
I
think,
just
before
we
cut
our
release,
we
should
do
that.
Are
we
going.
C
It's
really
necessary
because
I
don't
think
any
elimination
has
at
least
the
one
which
our
data
were
working
on.
We
haven't
implemented
that
api,
so
yeah.
D
D
E
A
Yeah,
which
I
think
scott
opened
a
different
one,
to
address
it:
okay,
globally,
so.
E
People
keep
open
and
step
up.
Do
you
we
want
that
to
go
into
rc
whatever
the
next
milestone
is
ideally.
D
A
A
Thank
thanks
scott
again
for
working
through
this.
I
know
this
was
a
brave
thing
to
bring
up,
and
you
know
he
ended
up
being
the
right
thing.
So
thank
you
and
there.
A
There
you
go
now.
I
need
to
work
with
workloads.
It
would
take
some
time
but
I'll
get
there.
Okay,
application
cluster
application,
resource
mapping
or
is
a
cluster
workload
resource
map.
You
know
183.
A
D
Will
rebase
it?
This
is
something
that
we
talked
about
last
call
where
I
volunteered
to
write
up
a
draft.
It
definitely
needs
an
edit
and
a
good
review,
but
I
think
the
bones
of
it
are
in
place
for
people
to
kind
of
look
at
and
make
sure
that
this
is
what
they're
comfortable
with
one
thing
that
we
did
talk
about.
That
I
didn't
do
in
here
is
to
find
a
new
grammar
for
a
json
pointer.
D
C
But
I
can't
say
when
I
looked
at
that,
I
can
see
you
still
following
the
json
path.
Syntax,
I
thought
we
are
going
for
json.
I
mean.
D
That's
what
I
was
just
saying
is:
I
I
think
I
kept
it
as
just
the
raw
jason
pointer
syntax
for
now,
just
to
make
sure
that
we
all
agree
about
like
the
core
behavior,
and
then
we
can
introduce
the
new,
like
the
new
grammar,
for
doing
this
path.
Expressions
later
like
it
should
be
not
too
complicated,
but
I
didn't
want
to
distract
from
the
core
of
what's
being
proposed
here.
D
A
A
All
right
next
one
application
and
service
labels.
This
is
pr
179,
so
just
a
bit
of
background,
so
this
pr
was
my
proposal
for
adding
a
the
label
capability
for
selecting
a
service
and
also
making
consistent
the
the
semantics
that
both
application
or
workload
and
service
labels
would
only
pick
the
the
first
match.
Scott.
You
had
some
valid
concerns
with
that.
A
D
Yeah
I
mean
this:
is
this
one
gets
sticky,
because
I
see
the
the
value
and
the
benefit,
but
there's
also
some
actually
a
fair
number
of
corner
cases
that
have
also
exposed
us
when
we
start
doing
label
selectors,
particularly
against
services,
because
we
can
only
have
effectively
one
concretely
named
service
that
gets
injected
at
a
time
and
the
idea
of
having
a
label
selector
that
is
limited
to
selecting
a
single
resource
feels
very
unintuitive
in
the
kubernetes
space,
because
label
selectors
are
inherently
queries
that
can
select
zero
to
many
resources
so
like.
D
If
we
really
want
to
have
like
no,
it
only
selects
one.
We
need
to
really
define
all
of
the
cases
for
which
one
gets
selected.
What
happens
when
there
are
two?
What
happens
when
one
becomes
two?
What
happens
when
two
becomes
one?
What
happens
when
there's
three
like
there's
a
lot
of
just
there's
a
lot
of
corner
cases
that
creep
up
where
it
seems
like
it
could
end
up
being
something
that
surprises
users
and
ends
up
causing
more
unexpected
behavior
than
it
provides
ultimate
benefits.
D
So
I
do
think
there
are
a
couple
things
that
we
discussed
previously
that
I
still
think
are
valid
like
one
is
like.
I
think
there
are
good
ideas
here
that
are
worth
exploring.
D
I
think
a
couple
ways
to
do
this
is
either
to
create
a
higher
resource
that
has
that
selector
defined
and
then
decomposes
into
individual
service
bindings
to
actually
do
the
actual
wiring,
depending
on
the
services
it
finds,
or
we
could
basically
create
a
mapping
that
is
using
the
label
selector
and
then,
basically,
it
decides
what
single
service
to
expose
and
then
that
single
service
can
then
be
bound
directly
in.
A
Okay,
would
you
say
that
would
be
like?
I
know
we're
not
using
extensions
anymore,
but
we
have
those
side,
side,
tanks.
D
A
D
As
an
extension
or
whether
it's
like
external
just
happens
to
exist
like
we
can
figure
that
out
later
but
like.
I
think
that
there's
enough
there's
enough
semantic
ambiguity
that
I
look
at
it
from
an
implantation
from
an
implementer's
perspective
and
a
user's
perspective
that
I'm
not
comfortable
pulling
it
into
the
core.
Yet
until
we
kind
of
like
prove
it
out.
C
Scott,
what
is
your
suggestion
to
regarding
that
immutable
resources
like
cron
job?
I
mean
sorry
job.
D
Prepare
us
trying
to
add
in
label
selectors
for
services
and
part
of
the
discussion
that
we
had
is
that
there
was
a
desire
to
have
symmetry
between
the
services
reference
and
the
workloads
reference,
so
something
one
of
the
original
drivers
for
creating
or
adding
the
workload
or
at
the
time
application.
Selector
was
a
resource
like
a
cron
job,
where
it
was
not
itself
pod
speckable,
so
we
couldn't
natively
inject
into
it,
but
it
also
created
resources,
jobs
that
are
immutable
using
a
generated
name.
D
But
now,
since
we
have
the
ability
to
provide
custom
mappings,
like
our
canonical
use
case
for
disgusting,
mappings,
has
actually
been
cron
job
so
like
we
can
bind
into
cron
job
successfully.
The
spec
says
we
should
be
able
to
so
that
you
initial
driver
for
needing
workload
label
selectors
is
like
lessened.
D
I
still
think
there's
absolutely
like
real
uses
to
do
application
selectors
so
like
I,
I
do
find
it
useful,
but,
like
I
opened
a
separate
pr
that
actually
removed
it
just
as
a
as
a
counter
to
like,
if
we
actually
want
to,
if
we
value
symmetry
of
these
two
things
of
these
two
of
these
two
object
references
then,
I
think
like
I
would
rather
actually
remove
the
label
selector
from
workloads.
C
Yeah,
I
don't
know
whether
the
symmetry
is
that
important,
but
for
application
level
selector
I
can
see
it
will
be
still
useful.
So
I
can
see
if
the
pr
is
still
in
draft.
So
are
you
going
to
open
it
for
submission
or
what
is
the
state
of
the
appear.
B
D
A
Fine
yeah,
I
I
think
I
think,
definitely
made
some
good
points
caught
in
terms
of
the
the
behavior
on
you
know.
If
you
see
one
and
then
that
goes
down
other
one
comes
up,
you
then
switch,
I
think,
trying
to
restrict
labels
to
just
one.
I
can
see
how
that
can
be
a
problem
and
at
the
same
time
I
can
see
how
people
may
they
want
to
use
it
as
well.
So
so
I
think
I'll
be
okay.
A
If
we
like
my,
my
preference
would
be
to
go
with
your
pr
to
drop
everything
and
redesign
this
in
a
way
that
we
don't
have
these
restrictions
that
make
it
so
hard
to
know,
what's
going
to
happen
so
that
if
label
match
two
you're
going
to
get
two
right,
it
like
it's
it's
more
kind
of
clear
and
if
we
need
to
work
through
a
higher
level
resource,
maybe
that's
the
way
to
go,
and
that's
not
such
a
bad
thing.
Yeah.
D
So
I
mean
just
to
make
sure
that,
like
level
setting
to
understanding
just
to
make
sure
everything
is
clear,
the
there
are
alternate
ways
that
we
can
get
the
the
multiple
service
perspective,
working,
whether
it
be
a
mapping
that,
like
has
a
restriction.
That
is
only
one
in
which
case
then
it
can
just
expose
that
for
service
and
the
service
binding
can
reference
it
or
whether
it's
a
separate
resource
that
can
support
multiple
services.
D
That
then
it
creates
multiple
service
bindings
to
target
the
workload,
and
then
it
can
basically
make
sure
it
can
deconflict
the
name.
However,
it
chooses
to
actually
do
that
so
like
there
are
alternative
ways
to
implement
multiple
services,
there's
not
really
a
good
alternative
to
support
selectors
for
our
applications,
because
it's
actually
the
target
of
the
injection
so
like
if
we
do
end
up
pulling
it
out
like
it
is
functionality
that
we're
just
dropping.
D
D
Yeah,
it's
the
same
issue
and
again
this
is
like,
like
this
is
corner
cases
kind
of
stacking
on
top
of
each
other
to
a
certain
bit.
But
if
you
have
an
immutable
resource,
where
you
don't
know,
the
name
in
advance,
like
the
only
way
to
inject
into
that
is
to
define
a
label
to
have
that
service
binding
in
existence
before
the
actual
resource
gets
created.
D
Otherwise
it
gets
created
and
it's
immutable
when
it's
too
late.
So
like
that's
the
issue,
we
ran
into
with
cron
job
and
job
so
like
if
that
pattern
exists
somewhere
else
in
a
way,
that's
not
that
doesn't
work
with
a
custom
mapping.
Then
we
would
basically
like
it
would
be
uninjectable
from
our
perspective.
A
A
A
Yeah,
I
don't
know,
maybe
I
need
more
coffee,
but
I
still
don't
get
how
that,
because
to
me
you
know
selecting
something
with
kind
name
or
or
just
the
label
and
that's
just
selecting
the
resource,
the
the
read
and
write
and
what
you
do
it
to
me.
That's
orthogonal,
that's
that's
different
right.
Then
then
I
found
the
cr
that
I
want
to
work
with.
D
D
So
it's
from
from
the
perspective
of
multiple
services,
it's
the
minute.
It's
the
resulting
manipulation
of
the
workload
that
becomes
strange.
That
causes
issues,
so
I
think,
definitely
the
ability
to
support
label
sectors
across
multiple
workloads
like
it
works.
It
works
fine
like
there's
no
issue
there,
like
the
only
reason
to
remove
it
is
if
we
value
the
symmetry
between
the
application
or
between
the
workload
and
the
service
references.
E
D
D
A
Right
and
we
pushed
it
in
right,
I
was
trying
to
find
it
through
the
workload
resource
mapping.
D
D
So
we
removed
mappings
the
the
array
from
the
service
binding,
but
we
haven't
actually
created
any
new
mapping
resources
to
replace
them.
Yet
I
know
by
you
you're
playing
around
with
a
couple
but
like
we
haven't
like
pulled
any
of
them
in
as
extensions.
D
A
A
Which,
I
think
is
the
key
that
we
just
have
to
be
honest
with
ourselves
that
you
know
it
is
missing
as
well
right.
So,
okay.
D
Yeah
and
I
I
think
it's
one
of
those
things
where
like
if
we,
if
we
develop
the
semantics
and
we
feel
really
good
about
how
they
work
like
we
can
promote
it
into
the
core
yeah
but
like
right
now
as
it
stands,
there's
enough
unknowns
and
ambiguities
like
I
actually
don't
know
how
to
implement
the
behavior.
That's
specked
out
in
that
pr
so,
like
it
just
says
to
me,
like
it's
not
ready
to
go
into
the
core
spec.
If,
as
an
implementer,
I
absolutely
I
don't
know
how
to
do
it.
D
A
Yeah,
no
for
sure-
and
I
think
this
is
always
a
good
test.
Sometimes
we
suggest
something
to
spec
that
the
implementation
is
very
complex
and
stuff,
so
it's
always
a
good
check.
So
what
I
would
propose,
as
next
steps
is,
I
can
close
my
pr,
which
is
what's
the
number
179
and
we
can
work
on
reviewing
scots
pr182
to
drop.
A
It
drop
applications
labels
so
that
we
and
and
then
we
create
a
new
issue
if
we
don't
have
one
already
to
properly
design
this
as
a
higher
level
cr
or
set
of
crs
or
crds
that
deal
with
that
for
both
application
and
workloads
and
and
service.
You
know,
having
parody
in
mind
from
the
start,
I
think
would
be
good.
They
could
be
separate,
but
having
a
solution
for
both.
A
A
A
Okay,
those
are
all
the
items
we
do
have
a
standing
item
for
surface
binding,
ref
implementation
design.
Anybody
have
anything
to.
A
Cool
ben
anything
from
from
you
closing
remarks.