►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210224
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
This
is
the
gateway
api
meeting
for
february
24th.
We've
got
a
few
things
to
cover
today,
but
I
think
it'll
be
relatively
light.
I'm
excited
to
hear
what
mark
has
to
say
about
what
we're
doing
in
gke
for
gateway
implementation
mark.
Do
you
have
any
anything
that
you
need
to
screen
share.
A
Oh
sorry,
yeah
no
problem
are
you
able
to
talk
talk
about
what
we're
doing
in
gke
for
gateway.
B
B
C
A
B
Okay,
great
so
so
the
scope
of
this
controller,
so
we're
calling
it
the
gke
gateway
controller
and
the
scope
of
it
is
to
manage
the
load
balancers
that
are
used
in
gcp
for
for
gke.
So
we
have
a
lot
of
load
balancers,
probably
more
than
we
should
have.
We
have
an
external
global
load,
balancer
layer,
7.
We
have
an
internal
layer,
7,
that's
a
regional
one.
We
also
have
corresponding
external
and
internal
layer
for
load
balancers
and
underneath
the
hood
they
actually
have
all
different
did
my.
A
B
A
Yeah
just
just
message
me:
the
the
link
and
I'll
I'll
get
in
okay.
B
So
I'll
just
continue
talking
through
it,
but
the
we'll
have
several
gateway
classes
and,
roughly
speaking,
a
gateway
class
will
correspond
to
the
underlying
implementation,
and
we
went
through
a
a
kind
of
a
a
lot
of
discussions
about.
B
Do
we
want
to
have
a
more
abstract
gateway
classes
that
interprets
kind
of
what
the
user
wants
to
do?
Or
do
we
want
to
have
gateway
classes
that
correspond
more
to
the
underlying
implementation,
and
we
found
that
it
was
probably
better
to
have.
It
correspond
to
the
underlying
implementation,
primarily
because
it
makes
the
usage
it's
the.
It
has
the
least
surprises
for
the
user
and
one
one
really
clear
example
of
this
is
in
how
diff
different
ports
are
supported
for
the
load
balancers
like,
for
instance,
the
external
load.
B
Balancer
supports
port
80,
80,
443
and
80.
The
internal
load
balancer,
I
think,
supports
a
different
set
of
ports,
and
so
we
wanted
the
ability
to
have
our
documentation.
Be
that
if
you
use
a
certain
gateway
class,
it
tells
you
exactly
what
is
supported
and
which
fields
are
supported
for
every
resource
of
the
every
resource
in
the
tree
for
gateway.
So,
for
instance,
our
external
load
balancer
does
not
support
weights,
and
so
that's
a
field
if
we
use
separate
gateway
classes
for
all
these
load
balancers.
B
It's
very
easy
to
document
to
say
if
you're
using
the
layer,
7,
xlb
gateway,
class
weights
are
not
supported
in
your
route
and
so
that's
kind
of
our
thinking
behind
our
usage
of
gateway
classes,
it's
really
used
to
kind
of
communicate
the
behavior
of
the
underlying
implementation
in
an
explicit
way.
That's
predictable
for.
B
Implementation,
so
the
the
implementation
is
based
on
borg,
hosted
or
google
hosted
controllers.
So
we
used
to
have
our
current
ingress
controller
actually
runs
inside
the
cluster
and
in
instead
of
running
inside
the
cluster.
It
was
much
easier
for
our
development
and
just
for
developer
velocity
to
run
them
as
google
hosted
so
they're,
actually
they're
watching
the
resources
inside
the
cluster,
but
they're
hosted
outside
of
the
cluster,
and
so
the
controller
actually
will
pre-install
the
gateway
classes.
So
we
have
some
gateway.
B
Class,
we
have
some
gateway
classes
that
are
that
are
going
to
be
pre-installed,
and
so
these
will
be
crds
that
always
exist
in
the
cluster,
and
so,
if
the
the
customer
basically
goes
to
their
cluster
they'll
see
that
the
gateway
classes
exist
and
they
can
use
them
for
for
different
purposes.
We've
talked
about
the
ability
to
use
or
to
create
your
own
gateway
class
and
we're
not
sure
whether
customers
will
want
to
do
this
or
not,
but
that's
something
that
we're
looking
to
probably
make
possible
as
well.
A
Hey
sorry
for
the
delay
there
mark,
I
finally
got
screen
sharing
to
hopefully
work
here.
I
I'm
highlighting
right
now
the
this
yeah
sorry.
This
is
still
internal,
dark
and
pretty,
and
I
think
most
of
this
is
fairly
internal
information,
but
coming
up
coming
out
to
be
more
public
pretty
soon
mark.
Is
there
a
specific
part
that
we
should
highlight
here?
B
B
A
E
B
If
it
were
possible,
we
may
still
want
to
have
separate
gateway
classes
and
maybe
gateways
that
share
the
same
ip
just
because
at
least
the
way
we've
been
using
gateway
classes
so
far,
they're
kind
of
just
used
as
something
to
make
the
behavior
of
the
api
explicit
and
so
because
the
layer
four
load
balancing
functions.
You
know
implementation
is
very
different
from
layer,
seven
that
we
would
still
want
to
make
that
explicit
to
users.
B
A
Yeah,
that
makes
sense.
I
think
I
I'm
not
sure
if
you
already
covered
this,
but
one
of
the
things
that
we've
been
trying
to
figure
out
as
part
of
this
is
how
we'll
handle
the
gate
gateway.
Crds
like
how
how
we'll
actually
install
these
our
api,
the
gateway,
api
and
gk
clusters,
if
I'm
remember
remembering
correctly
right
now
that
something
that
will
be
this
feature
will
either
be
opt-in
or
something
like
that
can
be
disabled.
Do
you
remember
where
we
landed
on
that
mark.
B
We
will
probably
be
an
opt-in
at
the
cluster
level
and
so
there'll
be
one
flag,
that's
kind
of
like
enable
gke
gateway
controller
and
then
so
that
enables
it
for
the
cluster
and
then
that'll
trigger
the
installation
of
the
cr
of
the
crd
and
then,
and
also
the
installation
of
the
two
gateway
classes.
We
have.
B
And
then,
of
course,
if
the
user
deletes
the
gateway
class,
it'll
just
get
reinstalled
and
then
the
way
we
are
planning
using
the
parameters
file
is
is
basically
the
parameters.
File
holds
every
dimension
that
defines
a
gateway,
class
and
they're
kind
of
just
the
dimensions
of
the
load.
Balancer
like
internal
external
layer,
7
layer,
4,
global,
regional,
those
are
kind
of
the
dimensions
that
you
know
determine
what
the
load
balancers
are,
and
so
those
will
probably
be
in
the
parameters
field.
B
A
Specifics
all
right
cool
all
right,
well,
yeah!
Thank
you
for
sharing.
Actually,
I'm
realizing
that
I
need
to
stop
sharing
my
screen
or
my
other
screen,
yeah
yeah.
Thank
you
for
that.
Definitely
interested
for
others
that
maybe
haven't
been
that
have
been
working
on
other
implementations
of
this
api
if
you're
doing
anything
different
or
if
you
want
to
share
in
a
in
a
future
meeting
what
you're
thinking
how
you're
thinking
of
implementing
this
api.
I
found
it
really
helpful.
A
You
know
last
week,
looking
at
what
sdo
what
contour
are
doing
with
the
api.
It's
it's
been
helpful
to
see
how
others
are
interpreting
this
api
and
trying
to
turn
it
into
a
real
implementation,
and
I
imagine
everyone's
going
to
have
slightly
different
interpretations
of
some
parts,
so
be
good
to
get
that
out
early
and
make
sure
that
we
can
come
to
some
kind
of
common
ground.
A
I'm
curious
for
for
anyone
that
that
was
looking
at
that
did
anything
seem
strange
or
unexpected,
or
you
know
different
than
how
you're
doing
it.
Obviously,
this
is
going
to
be
somewhat
different,
but.
C
Not
particularly
strange
still
got
a
ways
to
go
before
I'm
ready
to
have
real
input
personally,
but
I
expect
in
the
coming
weeks
to
have
real
input
and
something
to
show
okay,
so.
A
That's
great
glad
to
have
you
and-
and
I
should
say
like,
I
think
one
of
the
things
that
we're
still
not
completely
sure
about
is
we're
trying
to
we're
trying
to
figure
out
how
and-
and
I
think
this
is
true
of
the
project
as
a
whole-
we're
trying
to
figure
out
how
these
apis
are
going
to
be
installed
and
how
we're
going
to
avoid
kind
of
how
we're
going
to
all
play
nicely
together
in
the
same
cluster.
Basically,
let's
say
we
have
one
cluster
that
has
four
different
gateway
implementations.
E
A
Yeah,
I
think
the
big
difference
is
that
ingress
api
is
core,
so
you
don't
we're
adding
one
extra
layer
of
confusion
here,
at
least
for
now,
and
that
gives
us
a
lot
of
flexibility.
It
means
we
can
move
iterate
more
quickly
outside
of
kubernetes
release,
cycle
and
also
support
versions
back
to
116,
whereas
if
we
were
releasing
these
apis
in
kubernetes,
we'd
be
tied
to
say
122
or
I
don't
know
some
core
version
that
would
limit
the
availability
of
the
apis
initially.
A
But
that
does
mean
that
we're
going
to
have
this
weird
issue,
at
least
as
we
start
where
one
control
you
know:
do:
users
install
these
crds
are
users
responsible
for
installing
the
api,
or
does
it
come
bundled
with
implementations,
and
we
just
do
that
bundling
in
a
way
that
it
makes
sure
not
to
clobber
some
other
version
of
the
api.
If
it's
already.
A
Installed,
I
don't
think,
there's
a
good
question
from
bowie
and
chad.
I
don't
think
we
have
an
issue
tracking
this
yet,
but
I
think
this
deserves
more
discussion
and
and
a
tracking
issue,
because
this
this
is
something
that's
going
to
be
relevant
to
everyone's
installation
process,
and
I
think
what
we've
seen
so
far
for
from
the
early
implementations
is
just
install
these
crds
and
install
our
controller
and
everything
will
work
and
that's.
A
We
need
to
make
sure
that
we
have
a
good
story
around
this,
and
maybe
that
story
eventually
becomes
that
these
apis
transition
into
core
kubernetes,
I'm
I'm
not
sure,
but
between
now
and
then
we
need
to
figure
out
what
that
looks
like.
It
may
also
not
end
up
being
a
big
deal.
You
know
we
may
have
limited
api
versions
that
all
interact
well
with
each
other
and
we're
fine.
F
I
think,
unfortunately,
that
would
be
hard,
because
a
lot
of
people
will
be
on
cloud
providers
which
will
provide
their
own
implementation
and
then
installing-
and
you
know
they
can
also
install
stuff.
So
it's
kind
of
overly
hostile.
I
guess
in
fact
ingress.
The
whole
class
mechanism
was
to
actually
allow
like
n
providers
into
a
given
cluster.
A
Yeah,
that's
I
mean
that's
a
good
point.
I
think.
Initially,
what
we're
going
to
see
is
a
lot
of
that
kind
of
everyone's
using
a
single
implementation
in
their
clusters,
but
inevitably
there's
going
to
be
someone
somewhere
that
tries
more
implementations
they
want
to.
You
know
they
want
to
compare.
How
does
this
implementation
work
versus
that
implementation
and
if
we
don't
have,
if
we're
not
prepared
for
that,
we'll
be
in
a
bad
place.
A
I
think
it's
definitely
worth
a
bit
more
discussion,
especially
as
others
are
starting
to
get
closer
to
releasing
implementations.
I
think
it's
a
lot
more
likely
that
we'll
have
multiple
implementations
per
cluster
relatively
soon.
A
Okay,
cool
all
I
had
left
oh
yeah,
so
I
did
add
a
little
note
here
for
the
previewing
changes
with
netlify.
A
lot
of
reviewers
are
on
this
call,
and
it's
a
little
bit
less
obvious
now.
So
I
wanted
to
just
so
basically
before.
A
A
Oh
weird,
okay,
cool
black
rectangle,
all
right!
Well,
anyone.
A
No,
I
don't
know
what
it
seems
like
every
other
day.
I
have
an
issue
with
this
any
volunteers
to
share
a
screen,
real,
quick.
A
Harry
you're,
the
best
thank
you
for
always
taking
care
of
my
technical
difficulties.
A
A
Yeah,
that's
actually
perfect
any
pr.
It
doesn't
matter.
If
you
just
go
to
one
of
the
more
recent
pr's
yeah,
I
was
just
trying
to
highlight
that
it's
not
obvious
here,
the
diff
in
docs,
but
yeah.
If
you
go
down
to
deploy
netlify
and
click
on
details,
you
get
a
very
fun
preview
of
what
the
docs
will
look
like.
Based
on
that
pr.
I
don't
think
that
pr
changes
much
in
docs.
A
A
Yeah
I
mean
hopefully,
hopefully
this
is
better,
but
it
does
mean
that
we're
missing
the
compiled
html
diff,
which
means
a
lot
less
conflicts,
but
it
is
yeah.
A
Yeah
cool
all
right
and
then
the
rest
I
had
was
just
a
bit
of
pr
and
issue
triage.
There's
a
couple
of
new
pr's
up
that
I
think
we've
looked
at
briefly,
but
yeah
harry.
Do
you
wanna
click
through
just
some
of
these
yeah
the?
A
A
H
Some
of
our
examples
had
group
s
core,
but
if
you
look
at
cubicle
api
resources,
other
parts
of
kubernetes,
I
think
the
group
is
left
as
empty
for
core
apis
like
service
or
pod,
or
some
things
like
that.
So
here
the
the
right
way
to
do.
I
think
the
proposed
way
is
that
we
specify
an
empty
string
instead
of
core.
H
So
that's
why
this
peer
makes
a
lot
of
sense.
One
thing
that
I
did
notice
was
this
is
optional,
so,
rather
than
specifying
an
empty
string,
why
can't
the
user
ignore
it?
A
I
think
that
also
highlights
a
relatively
unique
thing
of
what
we're
trying
to
do
here
and
that
is
we're
trying
to
have
a
default.
That
is
not
core
which
is
not
common.
It
looks
like
in
the
rest
of
kubernetes
resources,
so
maybe
we
should
reconsider
that.
I'm
not
I'm
not
sure
here,
but
this
does
highlight
that
using
a
default
of
networking
group
would
mean
that
empty
string
for
core
and
networking
being
the
default
would
be
difficult
to
distinguish,
because
an
empty
string
would
be
transitioned
to
this
default,
as
I'm
understanding
it
right
now.
A
Anyone
who's
more
familiar
with
defaulting
can
correct
me,
but
that's
my
understanding.
So
we
could.
We
could
transition
group
to
a
pointer
here,
but
even
even
that
feels
a
little
weird.
A
No,
I
think
this
so
the
the
other,
so
this
is
not
core.
In
that
sense,
this
is
meant
to
be
a
reference
to
core
v1
like
secret,
ref
or
config
map
ref
or
all
those
other
or
service.
I
guess
would
be
the
most
common
one
for
this
api
and
so
far
we've
required
that
to
be
that
group
to
be
referred
to
as
core
instead
of
what
you've
seen
in
upstream
and
elsewhere,
as
just
empty
string.
A
Right
and-
and
I
think
this
pr
is
suggesting
that
empty
strings
should
point
to
core
kubernetes
kubernetes,
and
that
makes
sense
in
most
cases,
except
for
this
one
case
where
we
want
to
default
to
reference
our
own,
like
this
api
type.
This
this
api
group
by
default
and
having
those
two
defaults
be
different,
is
confusing.
A
A
A
So
if
we
say
the
default
value
for
this
reference,
which
in
this
case
would
be
a
route
reference
is
our
networking
group
that
that
makes
sense,
but
it
means
that
if
empty
string
is
the
way
you
reference
core
kubernetes
group,
there's
no
way
to
do
that,
because
the
default
is
always
going
to
clobber.
That.
A
A
A
H
H
A
A
A
A
A
G
A
If
you
can
go
back
to
the
pr
the
field
we're
using
here
is
not
a
pointer,
but
we
are
trying
to
apply
a
default,
and
so
when
you're
using
go
client
library,
I'm
assuming
that
it's
it's
harder
to
differentiate
between
an
empty
value,
and
so
it
just
thinks
that
somebody
that
the
user
tried
to
specify
http
path
match
here,
and
so,
if
we
change
this
to
a
pointer,
it
would
help.
In
that
case,.
A
And
and
the
pr
just
changes
that
to
a
pointer,
daniel
you,
you
seem
to
you,
you
have
a
lot
of
knowledge
or
context
on
pointer
versus
non-pointer
decisions.
Here
does.
Does
this
seem
like
a
reasonable
change
to
you?
Should
we
be
using
pointers
more
broadly
for
these,
you
know
any
anywhere
we're
trying
to
apply
default
like
this.
D
Yeah
so
since
this
is
optional,
if
it's
optional
should
have
the
omit
and
empty
json
tag
should
be
a
pointer
when
the
the
type
is
a
custom
type
like
http
path
match.
That's,
where
there's
some
ambiguity
with
the.
A
D
It
is
they
kind
of
get
into
details
related
to
the
types.
So
you
know
if
it's
a,
I
think,
if
it's
a
map
or
a
slice
and
it
doesn't
need
a
pointer
and
I
don't
think
it
really
addresses
you
know,
custom
types
so
again,
there's
just
some
ambiguity
of
the
upstream
recommendations
and
if
you
look
at
some
of
the
upstream
code,
you'll
see
you'll
you'll
see
both
options
where
there's
pointers
for
custom
types
and
there's
not
even
though
it's
optional
and
the
emit
empty
tag
exists.
A
Confusion
yeah
as
much
as
pointers
are
a
pain
to
work
with.
It
does
seem
like
this
is
a
pretty
compelling
case
where
we
should
be
using
pointers.
I
if,
if
I'm
remembering
the
api
conventions
correctly
it
it's
exactly
what
you
said
dating
and
they
it's
very
clear
that
go
values
go
types
that
have
a
easy
to
distinguish.
Empty
value.
A
Do
not
need
to
be
pointer
types
like
maps
and
slices,
but
it's
much
less
clear
for
these
custom
types,
these
trucks,
whatever
I
would
lean
towards
as
I'm
remembering
this
a
bit
more,
I
think
the
absence
of
them,
excluding
or
or
adding
an
exception
for
structs,
makes
me
think
that
we
probably
should
be
using
pointers
here.
Well,
you.
D
Know
part
of
the
challenge,
too,
is
the
upstream
recommendations,
don't
take
into
account
defaulting,
and
so
you
look
at
this
change
and
it's
like
well,
why
is
this
change
really
even
necessary
because
there's
always
going
to
be
you
know
if
this
is
you
know
if
the
path
is
undefined,
it's
always
going
to
be
defaulted
to
prefix
and
and
value
of
slash,
and-
and
so
I
just
don't
understand
why
this
would
really
need
to
be
a
pointer.
A
A
A
Yeah,
I
think
I
think
to
me
I'm
increasingly
convinced
that
this
is
the
right
direction
and
one
we
should
apply
more
broadly,
but
I
know
I
know
we
have
struggled
to
get
the
right
balance
of
pointers
and
not
here
so
need
to
be
careful
with
any
direction
we
go.
But
I
think
that's
that
the
absence
of
an
exclusion
here
for
structs
makes
me
think
that
we
should
be
using
pointers
here
as
well.
D
On
this
example,
I'd
be
curious
to
see
if
it
carries
out
if
the
http
header
matches
is
undefined,
as
opposed
to
defining
the
the
type
and
the
value
zero.
But.
G
Yeah
yeah,
I
think
this
is
this-
is
kind
of
what
they
do
for
so
they'll
create
all
these
things
like
the
wiring
and
then
update
them
as
needed.
So
the
request
comes
in
then
they
trigger
an
update
and
fill
all
these
in,
because
they're
using
those
headers
to
dictate
their
their
routes
and
everything
by
a
like
istio
or
something.
A
A
Cool,
I
can
follow
up
on
this
one,
but
definitely
appreciate
any
any
additional
thoughts
on
this
one.
If,
if
there's
a
reason,
we
shouldn't
go
forward,
but
I
I
think
it
is
probably
the
right
direction.
D
D
D
It
bypasses
the
defaulting,
but
I
have
to
just
try
to
replicate
it.
H
I
think
it
goes
through
the
go
types
right:
the
yaml
is
the
yamato
from
cube
cattle
apply,
does
not
go
through
those
go
types,
and
this
goes
through
it
right.
So,
even
though
you
have
omit
empty
on
the
struct,
the
json
of
yaml
or
whatever
marshall
marshall,
that
is
being
used.
H
D
Right
now
I
was
going
to
say
I
mean
if
we,
if
we
change
it
here,
I
would
just
suggest
that
you
know
you
kind
of
audit
the
rest
of
the
fields
right
I
mean
if
we
truly
believe
this
is
an
issue
as
described
in
that
last
screen
that
we
saw
you
know.
D
D
A
Yeah,
I
think
you're
right,
so
I
I
know
that
we're
using
this
pattern
elsewhere
and
we
need
a
pretty
clear
reproduction,
comparing
what
happens
with
a
coupe
cuddle,
apply
path
versus
a
client
go
path
and
understanding
how
changing
to
a
pointer
type
helps
there.
I
do
think
changing
to
a
pointer
type
makes
sense,
but
we
should
do
it.
If
we
do
it,
we
should
do
it
consistently.
A
Cool
all
right
I
can.
I
can
follow
up
with
that
unless
someone
else
wants
to,
but
I
don't
know
that
I'll
have
time
to
reproduce
this
soon,
but
I
think
that
that
is
the
next
step
to
compare
the
two.
A
Yeah
I
wanted
to.
I
guess:
we
had
covered
yeah,
let's
go
through
this
one
mark,
you
added,
I
don't
know,
is
mark's
still
on
the
call.
No,
it
looks
like
he
had
to
drop.
I
wanted
to
revisit
this
pr
because
it
is
a
relatively
significant.
This
is
an
ipr.
This
is
an
issue,
but
it's
a
relatively
significant
change
and
I
wanted
to
run
this
by
everyone
and
see
how
we
felt
the
the
proposal
here
is
that
route
selector
should
not
be
optional
and
the
empty
behavior
should
not
be
to
select
everything.
A
Basically,
you
need
to
specify
some
kind
of
match,
and
if
you
don't,
nothing
will
be
matched
the
concern
that
mark
was
raising
here.
That
is
that
our
current
kind
of
you
know
select
everything
by
default.
Behavior
can
lead
to
overexposure
of
routes
among
gateways.
So
if
you
create
a
gateway
just
by
default
in
the
namespace,
it's
exposing
all
routes
in
that
namespace,
which
is
amazing
for
our
simplest
use
cases
but
becomes
a
I
hate
to
say
a
vulnerability,
but
a
concern
among
larger
clusters,
larger
name,
spaces,
etc.
A
Yeah
yeah
and
I
think
I
think,
the
empty
selector
selecting
everything
is
technically
the
appropriate
action
for
a
selector,
but
it
is
probably
not
desirable
here
and
we've
already
seen
kind
of
that,
the
prior
art,
with
a
empty
selector
on
service
that
definitely
doesn't
select
everything,
even
though
a
selector
technically
should.
So.
A
I
think
we
have
enough
precedent
with
what
service
is
already
doing,
that
we
could
do
the
same
kind
of
approach
here
where
empty
service
selector
basically
allows
you
to
define
your
own
endpoints,
I
think,
or
or
another
interpretation
is
it
doesn't
select
anything
by
default.
I
think
it
would
be
reasonable
to
parallel
that
approach
to
our
api.
H
A
No,
I
mean
technically
that
is
empty
selector,
but
I
think
our
easy
case
would
have
to
evolve
in
that
case
and
always
have
a
selector
and
always
have
labels
on
the
route
which
I
think
leads
to
much
easier
expansion
in
the
future
like
if
somebody
starts
with
those
selectors
already
in
place,
it
allows
them
to
create
another
gateway
without
worrying
and
another
set
of
routes,
without
worrying
that
they're
going
to
be
selected
by
your
other
gateway.
A
So
I
think
I
think
that
sets
people
up
better
for
success,
even
if
it
does
kind
of
it
does
make
our
simple
example,
less
simple:
it
requires
labels
on
both
the
route
and
the
gateway
selector,
but
at
the
expense
of
a
simple
example.
It
gives
it
makes
this
more
robust
and
and
better
able
to
handle
expansion
and
more
gateways
in
the
same
name,
space
in
the
future.
H
Yes,
one
thing
that
I
recall
now
is
in
the
past
we
had
discussed
this.
I
think
the
point
made
then
was
that
the
default
for
name
spaces
is
same
namespace
mistaken,
so
yeah,
that's.
What
mark
has
also
been
doing
so
it
selects
all
the
words
from
that
specific
namespace.
A
Yeah,
I
know
I
argued
against
that
that
wasn't
too
permissive
before,
but
I
think
I'm
coming
around
to
the
idea
that
it
probably
is
and
and
seeing
the
challenges
that
other
apis
have
had
by
starting
with
a
a
two
permissive
defaults.
You
know
less
secure
defaults,
it's
very
hard
to
make
your
defaults
more
secure
over
time.
F
Yeah,
that's
true,
and
this
is
coming
from
testing
feedback.
So
it'll
be
great
if
some
of
the
other
implementations
when
they
talk
to
their
customers
as
well
kind
of
put
add
to.
F
A
A
So
I
think
one
thing
that
I'm
realizing
here
is
that
we're
not
actually
making
a
significant
api
change
as
much
as
we're
making
a
change
to
how
the
api
is
interpreted.
We
can't
prevent
someone
from
specifying
an
empty
selector
very
easily.
Anyway,
we
could
potentially
with
a
web
hook,
but
there's
still
potential
for
someone
to
specify
an
empty
selector.
I
think
what
we
want
to
suggest
here
is
that
an
empty
selector
instead
of
selecting
everything,
should
select
nothing.
A
A
F
F
A
A
All
right,
well,
I
know
we're
we're
basically
at
time
here.
I
think
I
I
added
one
other
issue
to
the
list,
but
there's
plenty
of
other
ones
open.
I
just
I,
the
docs
improvements,
one
from
mark
is
one
that
if
anyone
happens
to
have
some
extra
cycles,
this
would
be
an
amazing
way
to
contribute.
A
There
are,
I
think,
six
action
items
here
that
are
all
on
their
own,
relatively
straightforward,
or
many
of
them
are
so,
if
you're
looking
for
a
kind
of
way
to
get
a
contribution
or
two
in
that,
I
think,
might
be
relatively
straightforward.
This
would
be
a
great
way
to
contribute,
so
everyone.
F
Has
time
rob
I
just
I
just
posted
like
this
is
actually
worthwhile
peeing
on
slack,
because
we
have
260
people
hanging
out
there.
It's
I
haven't
used
that
as
a
channel
for
soliciting
contributions,
but
it
seems
like
a
decent
way
to
get
yeah.
A
Yeah,
that's
a
good
idea
too,
but
yeah.
If
anyone
does
take
this
on,
if
you
can
just
kind
of
add
a
comment
on
this
issue,
saying
that
you're
going
to
try
and
work
on
item
one
or
two,
you
know
this
is
a
a
pretty
big
issue.
So
no
need
to
try
and
take
everything
on
at
once,
but
just
if
you
want
to
reserve
a
bullet
point
for
yourself
just
add
a
comment
there,
so
we
won't
get
duplicated
work.
Yeah
awesome
all
right!
Well,
thanks!
A
Everyone
we'll
see
you
next
week,
thanks
again
to
harry
for
saving
me
from
my
technical
difficulties
and
yeah
have
a
good
rest
of
your
week.