►
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
Yeah,
I
know
we
don't
have
very
many
people
today,
but
I'll
go
ahead
and
just
run
through
the
release
checklist
one
more
time
we're
getting
awfully
close.
This
should
look
familiar
to
most
people
at
this
point.
A
A
I
don't
think
james
is
here,
but
I
can
follow
up
with
him.
We
also
want
to
have
some
kind
of
automation
around
verifying
that
our
examples
are
still
up
to
date
and
the
vast
majority
of
work
left
is
around
documentation.
A
Api
cleanup.
There
is
a
pr
that
I
think
is
just
about
ready
to
go
in
and
with
that
maybe
we
should
get
into
oh
actually
bowie.
You
mentioned
release
candidate
last
yesterday
and
we
talked
about
it's.
I
don't
know.
If
there's
anything
else,
we
need
to
cover
today.
A
I
think
our
goal
had
been
to
release
this
to
come
up
with
a
release
candidate,
ideally
on
friday
of
this
week,
like
tomorrow,
does
that
match
what
you
remember.
A
Bowie,
I'm
not
sure
if
you
are
trying
to
say
something.
I
can't
hear
you
with
that
said
I'll
move
on
then
so
for
pr
initiate
triage,
there's
a
few
prs
that
are
still
open,
they're,
all
fairly
straightforward
and
tiny,
except
for
this
api
validation
and
cleanup
one
which,
as
the
comments
suggest,
was
absolutely
massive.
A
Thank
you
to
everyone
for
the
feedback
on
this
one
yeah.
So
this
is.
This
is
really
really
simple.
It
just
needs
a.
I
think.
A
final
lgtm
here
should
be.
It
should
be
pretty
straightforward
to
to
move
forward
on
this
one
and
every
every
additional
pr
after
this
is
going
to
be
based
on
this
work,
so
that
that
is
api,
validation
and
cleanup.
A
I
think
we're
mostly
good
to
go
on
this
front,
actually
danny
and
since
since
you're
here
I'm
curious,
I
I
was
a
little
confused
on
this
final
feedback
from
you
there.
It
was
something
like
about
our
status,
and
I
my
interpretation
is
that
maybe
it
should
not
have
been
optional.
B
Yeah
yeah
rob.
I
think
the
feedback
was
generally
that
when
I,
when
I
looked
through
the
pr,
I
see
that
I
think
it's,
the
gateway
status
conditions
have
like
certain
default
set
and
so
forth,
and
then,
when
you
go
to
like
listener
status
conditions,
those
look
different
and
you
go
through
some
of
the
other
status
conditions
throughout
the
types
and
they
they
differ
from
the
gateway
status
conditions.
So
it's
just.
B
A
C
A
B
Yeah
yeah,
all
the
all
the
kind
of
builder
tags.
A
Okay,
do
you
mind
if
we
cover
that
in
a
follow-up
pr
just
yeah,
I
hate
I
hate
keeping
on
re-basing
off
of
this
this
individual
pr,
because
it
makes
so
many
changes.
A
D
D
B
Just
say:
let's
merge
it
unless
rob
is
or
something
major.
Otherwise,
you
know
some
of
the
final
feedbacks
and
I
figure
after
it
merges
two.
I
want
to
just
kind
of
take
one
look
through
everything,
because
I'm
sure
it
seems
like
every
time
I
look
at
this
there's
always
something
else.
I
catch
that
I
didn't
see
from
the
time
before
and
because.
A
B
B
A
D
A
I'm
glad
to
see
this
go
in.
Thank
you
all
right.
So
I've
got
a
couple,
a
couple
more
prs
that
I
based
off
of
this-
and
we
talked
about
this
a
little
bit
yesterday,
but
this
was
updating
route
name
spaces
to
use
the
route
gateways
pattern.
This
is
going
to
be
familiar.
I
want
to
cover
two
things
that
we
didn't
cover
yesterday
very
well.
I
I
got
some
feedback.
Oh
I
forget
this
is
based
off
of
that
other
one
one.
Second,
okay,
I
got
some
feedback
from
danian
yesterday.
A
That
was
excellent,
that
it
would
make
sense
to
go
ahead
and
just
add
that
all
namespaces
option
like
we'd
talked
about
this,
of
course,
could
be
communicated
with
selector
empty
selector,
but
explicitly
saying
all
namespaces
feels
a
little
easier
to
understand.
A
This
is
a
little
duplicative
in
a
sense,
but
I
I
think
I
think
it
makes
for
an
easier
to
understand
and
work
with
api.
So
I
have
gone
ahead
and
added
that.
A
A
second
question
that
I
had
had
and
gotten
some
feedback
on
was
whether
or
not
we
should
have
a
default
here.
A
I
right
now
there's
a
default
of
from
same
namespace
and
I'm
curious
if
we
should
just
not
so
what
what
this
looks
like
is,
anytime,
you
create
a
gateway,
even
if
you
don't
set
this
field,
it's
going
to
get
set
for
you
and
it's
going
to
have
from
same
namespace.
A
The
argument
against
that
is
is
just
it
pollutes
the
animal
with
something
that
could
potentially
be
inferred
as
a
default.
I
I
don't
know
I
don't
know:
does
anyone
have
a
strong
preference
one
way
or
the
other
here.
D
And
this
is
kind
of
important
like
they
should
know
whether
they
want
same
namespace
or
not,
and
I
like,
if
we're
saying
that,
there's
an
abstraction
that
the
infrastructure
provider
is
giving
for
the
controller
like
they
shouldn't
care
about
the
controller.
So
much
as
as
much
as
say,
like
this
class
is
meant
for
this
purpose,
then
having
it,
this
sort
of
thing
based
on
the
controllers
seems
to
be
less
useful.
D
B
Think
I'm
small,
as
I
mentioned
my
comments,
I
I'd
see
that
there's
strong
use
cases
for
both
allowing
only
name
space
or
same
name
space
along
with
all
name
spaces.
I
think,
especially
for
you
know,
small
environments
where
to
be
more
common,
to
have
a
single
gateway
that
supports
routes
across
different
name
spaces.
B
I
mean
it
might
not
be
bad
just
to
say,
hey,
let's
not
set
the
default,
make
it
required,
provide
these
different
enum
options
and
then
maybe,
as
we
iterate
on
this,
if
we
start
to
see
more
more
users,
you
know
prefer
a
certain
default.
We
could
always
add
that,
as
a
default
later
on
make
it
required.
D
And
have
the
users
we'd
have
to
do
it
before
beta,
otherwise,
it's
going
to
be
a
version
transition.
But
yes,
I
agree
that
this
is
something
that,
like
I
can
see
things
like
how
red
jacks
is
interpreted
or
something
to
be
sort
of
controller
specific.
But
this
is
almost
like
a
very
generic
non-controller
specific
field,
but
we're
saying
you
should
default
it
from
the
controller
which
feels
like
there's
a
bit
of
a
mismatch.
A
A
A
D
And
I
see
how
does
that
work
because,
like
for
example,
when
you
submit
a
pod
spec,
it's
usually
pretty
sparse
and
then,
when
it
gets
pulled
through
the
whole
system,
it
comes
back
with
a
whole
bunch
of
stuff
set
to
it.
Yeah
in
what
you're
suggesting
is
that
you
don't
set
anything
it
gets
pulled
through
the
system
when
it
comes
back,
it's
actually
still
empty
yeah,
which
might
be
confusing.
I
guess.
A
Yeah
yeah,
so
I
I'm
fine
with
requiring
this.
I
think
that's
a
reasonable
solution
here
and
it
also
removing
the
default
also
uses
an
argument
that
I
used
elsewhere
in
another.
Pr
that
we'll
cover
today,
which
is
not
like
removing
a
default,
is
something
that
is
hard
to
do
in
a
backwards
compatible
way.
Adding
a
default
can
be
done
in
a
backwards
compatible
way
because
you're
not
breaking
any
current
users,
so
anyways,
starting
without
defaults
and
in
a
sense,
is
actually
probably
preferred.
A
Might
get
a
better
understanding
of
what
a
default
should
be
based
on,
so
I
I
will
plan
on
removing
this.
A
Yeah,
okay,
and
on
that
note,
does
anyone
mind
this
edition
of
the
all
name
spaces
option
with
the
understanding
that
you
could
already
accomplish
this
without
that
option,
just
potentially
more
confusing.
D
Shouldn't
we
say
that
I
think
the
api
reviewers
will
flag
this
as
a
duplication.
D
A
B
Yeah
and
it's
nice
just
to
be
explicit
in
in
the
docs
so
yeah
I
like
that
idea
really.
A
All
right
well
I'll
get
those
updates
in
shortly
there's
a
related
issue
here
and
we
have
several
issues
to
cover,
but
since
this
is
so
related
to
what
we
just
discussed,
I
wanted
to
bring
it
up
here
if
I
can
get
the
right
issue.
Okay.
A
So
what
we
have
right
now
is
a
bit
of
a
strange
api.
Here
we
have
speaking
of
duplication.
This
feels
like
duplication,
we
have
routes
and
then
inside
routes
we
have
route
namespaces
and
route
selector.
A
It
seems
like
the
route
prefix
on
route,
namespaces
and
route.
Selector
may
not
actually
be
necessary.
A
I
explored
that
a
little
bit,
and
this
is
the
case
where
that
feels
a
little
a
little
weird
where
you
have
selector
right
above
selector
and
the
indentation
here
matters,
but
as
a
whole
routes,
dot
name
spaces
feels
reasonably
clear
to
me.
Then
routes,
dot,
route,
namespaces
or
routes,
dot
route
selector-
I
don't
know-
and
certainly
if
you
don't
specify
namespaces
at
all
or
if
you
don't
specify
a
selector
here.
D
We
could
put
namespace
selector
if
you
wanted
to.
If
you
think
that
the
namespaces
is
going
to
be
the
lesser
use
case
to
for
disambiguation.
A
A
I
think
by
default
we're
calling
it
nil
and
not
empty
for
selector,
and
so
it
would
be
some
kind
of
validation,
error
or.
D
A
A
Reasonable
I'll
take
silence
as
support
of
this.
If
anyone
has
an
issue
with
this,
definitely
let
me
know
well,
I
I
can
follow
up
file
a
pr
to
actually
implement
this.
I
don't
think
I
don't
think
it's
critical,
I
just
as
I
was
working
with
this.
It
felt
like
we
had
some
repetitive
names
here:
okay,
the
other
pr
that
I
I
think,
there's
several
prs
that
oh
I
haven't
gotten
to
this
one,
yet
I'll
make
sure
I
get
there
next.
A
This
one,
I
know,
is
going
to
be
controversial
or
I
feel
like
it
could
be
controversial
one.
This
is
they
the
first
part
of
this?
I
don't
think
is
controversial,
and
this
is
based
on
the
discussion
in
293,
where
it
seems
like
we
got
some
reasonable
consensus
that
we
should
move
from
resource
back
to
kind.
A
Even
though
resource
would
be
easier
for
implementations,
it
would
be
more
confusing,
for
users
seem
to
be
the
general
consensus,
so
that
is
the
first
part
of
this
pr.
The
second
part
of
this
pr
is
potentially
much
much
more
controversial,
and
that
is
removing
all
object
references
we
have
that
had
defaults
in
them.
So
if
you
remember,
we
still
had
a
few
object.
References
left
like
a
look
at
here.
A
A
Admittedly,
these
defaults
would
get
filled
in
and,
if
you
did,
you
know
a
get
from
api
you'd
see
that,
but
just
looking
at
the
manifest,
it
may
not
be
obvious
and
similar
argument
for
the
service
default
reference
and
in
instead
of
that
the
preference
was
what
we've
done
with.
Where
was
it
back
end
policy?
I
think
we've
already
done
this,
where
you
can
specify
either
a
service
name
or
an
object
reference.
A
A
This
is
just
my
my
take
on
this
with
that
said,
going
back
to
what
we've
been
talking
about
earlier,
I
use
the
same
argument
here
of
it's
a
lot
easier
to
add
defaults
in
the
future
than
to
remove
defaults,
so
I
would
rather
lean
on
the
side
of
less
defaults
initially
and
if
we
see
that
there
really
is
demand
for
defaults,
maybe
we
add
that
with
say
a
secret
name,
kind
of
field
or
a
service
name
kind
of
field
instead
of
these
default
groups
and
resources
or
kinds
that
that
is
my
motivation
here
and
my
rationale
I
with
that
said:
I
am
very
interested
in
feedback
and
thoughts
on
this,
because
I
know
it
may
not
be
something
like
everyone
agrees.
C
C
I
don't
think
it's
a
major
issue
to
change
this.
I
think
making
it
explicit
is
fine,
we'll
get
some
feedback.
Just
one
comment
on
on
the
pr
itself
is
that
I
think
in
the
examples
you
should
just
make
sure
to
use
real
kinds.
So,
in
a
couple
of
examples,
you've
used
parameters
and
there's,
I
think,
there's
another
one
which
is
a
yet
custom
back
end.
So
we
should
use
kinds
which
are
in
the
cluster
so
that
you
can
apply
this
yaml
to
verify
it.
A
So
yeah
that's
good
good
feedback.
The
problem
with
at
least
parameters
is
for
parameters.
References
we
have
no.
There
is
no
in
cluster
resource
that
you
know,
by
definition,
that's
meant
to
reference
a
custom
resource,
so
we
can't
yeah.
You
know
we
can't
do
anything
with
that.
I
don't
think
there's
no
cluster
scoped
configuration
resource
that
we
could
reference.
C
C
A
Everything,
no
that's
fine.
I
mean
it
is
unfortunate
because
there
is
basically
no
validation
around
this
I
mean
there's
the
basic
things
of
mid
length
max
link,
but
that's
about
all
we've
got
here
and
I
I
have
been
verifying
manually
that
this
and
the
previous
prs
all.
Actually,
the
examples
are
actually
applying
with
the
crds
and
it
is
all
actually
working,
at
least
on
my
cluster
same
as
the
old
works
on
my
machine
kind
of
thing.
But
theoretically
these
should
all
work.
A
Okay,
any
anyone
else
have
any
hesitation
around
this.
This
change.
A
A
Then,
with
that,
I
think
there's
a
couple
other
pr's
here
danian
thank
you
for
working
on
docs.
C
B
Great
to
me,
jeff,
yeah
generally,
what
I
try
to
do
is
is
get
away
from
some
of
the
specifics
that
were
originally
in
the
workflow
dock,
just
to
avoid
it
becoming
stale
again
and
just
being
more
of
a
higher
level
request.
Workflow
may
be
easier
for
someone
new
to
understand.
A
A
A
A
A
C
A
Cool.
Okay,
awesome!
That's
great!
Okay!
Thanks
for
taking
this
on
yeah,
I
I
have
not
looked
at
this
as
closely
as
I
should
have
cool.
A
And
then
the
other
ones-
oh
yeah,
we
haven't,
I
don't
think
we
brought
this
up
anywhere,
yet
extensions
on
gateway.
There
was
a
bit
of
discussion
in
the
pr
itself
about
this
about
whether
we
should
had
an
extension,
ref,
2
gateway.
A
Yeah
trying
to
summarize
and
and
remember
this
discussion
james,
do
you
happen
to
remember
where
this
left
off.
C
C
I
think
when,
when
we,
when
we
re
revamped,
the
listeners
concept
that
got
dropped-
and
that
was
how
we
ended
up
with
this
dangling
listeners-
object,
ref
type-
I
I
think
that's
the
name
and
then
someone
within
vmware
who
was
looking
at
an.
C
Kind
of
pinged
me
with
the
network,
access
control,
use
case
for
gateways
and
they're
like
oh,
I
really
want
to
their
proxy,
has
some
sort
of
access
control
policy
and
they
they
really
wanted
to
put
it
on
on
the
gateway
and
that
kind
of
seemed
seemed
reasonable.
C
So
that
prompted
me
to
think
you
know
it
probably
is
reasonable
and
gateway.
Is
such
a
fundamental
object
in
the
model
that
is
probably
reasonable
to
want
to.
I
thought
it
probably
was
reasonable
to
want
to
add
your
own.
C
D
Yeah,
it's
not
as
elegant.
I
think
there
is
a
definitely
a
case
where
it's
not
consistent
and
that's
fairly
confusing.
The
only
thing
is
that
currently,
where
extension
ref
is
being
used,
it's
because
you
had
to
do
it
because
it
wasn't
a
one-to-one
correspondence
with
an
object.
For
example,
you
couldn't
shove
it
into
annotations
easily.
D
It's
worth
thinking
about
this
because
technically,
like
every
single
object
in,
if
we
add
extension,
ref
at
the
object
level,
almost
every
single
kubernetes
object
could
be
like.
You
could
argue
that
they
should
all
have
it,
which
then
makes
it
that
that
one.
I
have
the
that's.
What
brought
up
that.
D
C
Yeah,
I
don't
have
a
strong
sense
of
what
to
do
here.
I
think
that
people
do
want
to
add
their
own
tweaks
to
gateway.
I
think
that's
probably
a
likely
case,
but
maybe
maybe
we
could
resolve
this
and
say
document
the
name
maps,
decorator
pattern.
D
Yeah
like,
for
example,
you
can,
you
can
see
like
let's
say
you
had
two
groups
and
they
both
were
working
on
independently
and
they
decided
to
extend
gateway.
At
that
point,
you
wouldn't,
you
would
probably
end
up
having
a
list
of
extension
refs
and
then
it
just
becomes
like
a
a
object
reference
annotation
almost,
which
may
be
yeah.
D
C
A
C
Hearing
a
lot
of
enthusiasm,
so
maybe
if,
if
I
document
this
is
how
you
can
extend
things,
that'll
satisfy
the
satisfy
the
implement
those.
A
And
so
I
think
I
think
that
makes
sense,
and
I
agree
with
everything
that
has
been
said.
I
I've
been
thinking
about
our
other
resources
and
how
you
might
extend
them
because
always
comment
about
well,
you
know
we
could
have
an
extension
rep.
Her
her
resource
got
me
thinking
about
just
what,
where
our
current
extension
points
lie
and
so
for
gateway
class,
it's
almost
entirely
about
linking
to
parameters,
so
that
is
kind
of
the
extension
point,
the
far
other
side
of
our
spectrum.
We
have
back-end
policy,
which
again
is
I'm
pretty
sure.
A
So
that's,
I
guess
the
idea
is
you
can
build
a
superset
of
that
if
you
want
your
own
custom
resource
routes
are
unique
in
that
you
can
build
your
own
kind
of
route
if
you
would
like,
if
you
don't
like
a
current
route,
it's
very
easy
to
build
your
own
route
and
bring
that
gateway
is
kind
of
unique
and
that
is
kind
of
our
core
resource
that
we
don't
really
have
a
model
for
extending,
etc
or
or
replacing
with
an
alternative.
A
I
I
think,
that's
fine.
I
think
the
the
solution,
at
least
short
term,
is
just
to
document
how
you
would
extend
it
and
it
may
not
need
an
extension
ref
per
se,
but
it
is.
It
is
good.
I
I
appreciate
you
at
least
exploring
how
we
would
extend
gateway,
because
this
does
seem
like
a
hole
in
the
current
api.
A
Even
if
the
solution
is
use,
annotations
or
name
mapping
or
whatever
it
happens,
to
be
documenting.
That,
I
think,
would
be
great.
A
Cool
any
any
last
things
on
that
pr.
A
All
right
I'll
keep
on
moving
that.
That
has
me
at
thinking
about
one
of
harry's
recent
issues,
which
I
think
is
a
decent
transition
point
here.
There
was
a
a
slack
thread
that
harry
has
at
least
partially
documented
in
this
issue,
and
that
is
if
we
want
to
have
any
kind
of
idea
of
how
extension
points
you
know
like
why
we
need
an
extension
point
in
a
route
match
with
the
idea
that
we
already
allow
for
custom
routes.
A
A
A
A
Yes,
you
could
I,
I
think
there
are
other
extension
points
that
potentially
provide
more
value
but
you're
right
yeah.
I
guess
I
guess
my
my
argument
of
when
would
a
crd
versus
a
custom
route
like
one
with
an
extension
crdb
preferred
over
a
custom
route
that
yeah
that's
fair
it
just
for
matching
logic.
Specifically,
it
seems
like
I
can
extend
what
I
can
understand
why
you
might
want
to
have
a
custom
extension
for
either
say
filters.
Filters.
A
Yeah
definitely
want
custom
extension
point
there
for
protocols
where
you
may
not
have
a
clear
concept
of
how
you
would
match.
Okay
sure
I
can
understand
why
we
might
have
an
extension
point
there,
but
for
http
route
it
seems
like
we
already
have
a
fairly
solid
understanding.
C
A
You
might
match
request
and
adding
an
extension
point
may
not
be
necessary,
and
this
this
goes
back
to
my
original
bias,
to.
A
Be
hesitant
about
the
fields
we're
adding
as
part
of
like
we
already
have
a
pretty
large
api
service
surface,
and
I
know
this
is
alpha.
I
know
we
can
break
things.
I
know
we
can
remove
things,
but
it
will
still
be
harder
to
remove
something
like
if
someone
is
already
using
x
feature
and
if
we
don't
have
a
very
clear
answer
to
how
a
specific
extension
point
might
be
used.
A
I
I
don't
know
I
I'm
not
as
sure
there's
value
there.
At
least
this.
This
is
my
recollection
of
that
slack
thread
and
and
my
own
personal
bias.
C
A
A
A
So
we've
got
spec
and
we've
got
an
extension
ref
here.
This
certainly
could
follow
the
same,
the
same
guidance
and
the
same
the
same
idea
that
bowie's
already
communicated
for
the
potential
extension
ref
on
gateway.
A
So
I
think,
there's
limited
rationale
for
having
this
here.
Then
we
go
into
hp
route
match
eventually,
and
we
get
this
extension
graph,
and
this
is
in
the
same
context,
we're
matching
path,
headers
and
then,
who
knows
what
else
we
might
want
to
match?
A
C
A
A
Well,
no,
but
I
thought
I
think
that
would
fall
under
implementation.
Specific
right,
half
match
type
yeah,
which
oh
that's
header.
A
Oh
we
actually
do
have
regular
expression
here.
But
yes,
there
is
a
theoretical
reason
to
have
extension
ref
on
the
route
match.
I
can't
think
of
any
compelling
reason
to
have
extension
ref
in
spec
here,
if
we're
not
going
to
also
have
extension
ref
in
gateway,
and
I
think
I
would
lean
toward
not
having
them
in
either
place
and
instead
deferring
to
a.
A
Okay,
well,
I
know
I
know
we're
over
time
here
that
was
a
that
is
an
existing
issue
that
could
use
some
more
conversation
I'll
try
to
summarize
our
conversation
today
here,
but
if
anyone
has
additional
feedback,
I
am
I'm
sure
it'd
be
great.
To
add
to
this
thread:
yeah!
Okay!
Well,
I
think
that's
all
for
today
was
there
anything
else
that
we
should
have
covered,
that
we
didn't
have
time
for
rc1.
A
Thank
you.
Thank
you
for
keeping
me
on
the
agenda.
Yes
rc1.
I
think
I
think
it's
very
reasonable
to
throw
out
a
rc.
I
especially
now
that
api
cleanup
is
in
I'd
love
to
get
that
out
tomorrow.
Maybe
we
can
rely
on
some
is.
Are
there
any
other
prs
or
any
other
things
that
we
would
like
to
get
in
before
we
throw
out
an
rc.
A
Of
the
pull
requests
that
exist,
I
of
course
I'm
biased.
I
would
love
to
get
a
couple
more
of
these
in
the
request
workflow
this
one
feels
like
it
can.
I
mean
this
is
a
doc's
pr,
so
maybe
that's
not
quite
as
important
for
rc,
but
still,
I
think
that's
super
close.
C
I
really
need
to
make
the
conditions
changes
for
http
route
that
we
discussed.
A
Okay,
would
you
do
you
think
we
should
wait
for
an
rc
before
we
should
wait
for
those
updates
before
releasing
an
rc
I'll,
get
it
done
by
monday,
okay,
okay,
that.
A
And
okay
yeah:
let's
plan
on
that,
then
I
don't
think
there's
a
huge
difference
between
a
friday
and
monday
rc
and
it
would
be
good
to
have
those
conditions
in
does
that
work
for
you,
bowie.
D
Yes,
although
those
are
famous
last
words
getting
it
done
by
monday,.