►
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
A
A
We
did
not
formally
support
this
in
the
api,
but
they
had
a
creative
way
to
make
it
work
and
yeah.
This
is
a
lot
of
this.
Conversation
is
still
happening
in
may,
where
we're
starting
to
think
about.
Tcp
route
etc,
and
then
it's
basically
just
been
kept
on
life
support
without
a
whole
lot
of
action
beyond
that.
A
A
A
I
know
that
this
specific
issue
is
about
making
listeners
option
optional,
so
you
can
have
that
direct
link
or
make
that
direct
link
easier,
and
my
proposal
is
to
make
that
direct
link
official
and,
although
they're
not
exactly
the
same
thing
they
they
seem
very
closely
related,
so
yeah
that
that's
where
this
one
is
at.
I
think
I'm
going
to
skip
ahead,
because
this
is
related
and
go
through
how
I
think
this
could
be
solved,
and
then
maybe
we
can
talk
about
the
broader
picture
here
and
what
might
make
sense.
A
Hopefully
everyone
can
see
this
it's
linked
in
the
agenda.
It
looks
like
at
least
someone's
here,
so
the
idea
I
had
was-
and
this
is
not
a
new
idea
or
necessarily
my
idea-
to
begin
with
that-
it's
something
that
I
think
andrew
and
folks
at
vmware
had
been
pushing
for
earlier
on,
like
back
in
may,
and
this
is
finally
me
trying
to
figure
out
like
what
this
could
look
like,
and
so
my
idea
is,
can
we
add
some
kind
of
forwarding
shortcut
that
allows
you
to
bypass
routes
for
the
simplest
of
use
cases?
A
A
A
So
I
outlined
two
potential
options
here.
One
would
be
to
in
addition
to
the
l4
shortcut
use
case.
We
could
kind
of
repurpose
this
a
bit
and
call
it
default
backend
and
for
anyone
who's
familiar
with
ingress.
This
is
a
very
similar
concept
from
ingress
right
with
ingress.
You
have
a
default
back
end
and
if
no
nothing
matches
the
default
back,
end
is
selected,
and
so
this
would
in
the
simplest
of
use
case,
if
there
are
no
route
selected
default.
A
Backend
hits
all
serves
all
requests,
but
this
could
also
work
in
the
sense
that
if
you
have
route
selection,
but
your
routes
don't
handle
a
specific
request,
you
can
use
this
default
backend.
So
it's
it's
kind
of
two
things.
One.
It's
a
default
way
to
link
without
routes
or
two.
It
can
be
a
fallback
if
you
do
have
route
selected,
but
they
they
don't
match
a
given
request.
A
The
second
option
I
kind
of
explored
here
would
be:
let's
just
call
this
back-end
reference,
and
let's
make
this
a
mutually
exclusive
behavior.
You
can
either
use
a
route
selector
or
you
can
specify
a
backend,
and
let's
just
have
this
direct
linking
so
you
can
use
routes
or
you
can
not
and
we
won't
muddy
the
water
with
the
kind
of
in-between
state
that
default
backend
provides.
A
This
is
certainly
simple
and
potentially
easier
to
understand,
but
it
does
offer
slightly
less
flexibility
than
the
default
backend
approach
above
and
then
below
this.
I
had
attempted
to
just
describe
how
protocols
would
be
actually
understood
with
this
kind
of
config,
because
you
could
argue
well,
maybe
you
should
have
a
protocol
on
default
back
end,
but
my
idea
has
been
that
you
can
either
rely
on
the
listener
protocol
if
the
backend
doesn't
specify
one
or
if
the
back
end
does
specify
one
use
that
so
yeah
that's.
A
A
A
B
A
C
D
C
Yeah,
I
was
just
gonna
say
so
do
we?
I
mean
option
b
kind
of
indicates
that
the
default
route
will
continue
to
be
this
kind
of
implicit
thing
that
yeah
there.
If
there
isn't
one,
you
know
route
that
matches
everything
that'll
be
it,
but
if
there's
multiple
everything
routes,
then
they'll
conflict,
and
I
just
want
to
say:
oh
that's
kind
of
a
decision.
We're
making.
Are
we
okay
with
that.
B
B
A
C
Yeah,
that's
a
good
point
like.
If
they
didn't
have
the
route
here,
then
it
would
still
go
to
that
default
route
right
if
they,
if
they
didn't
use
it
in
this
default
backend,
and
I
also
kind
of
like
it.
It
feels
like
we,
this
option
a
feels
like
a
special
case
just
to
do
default
routes,
which
seems
kind
of
strange,
and
so
I
kind
of
like
the
black
and
whiteness
of
you.
Either
do
routes
or
you
have
the
back
end
ref
and
it
keeps
it
much
simpler.
A
D
A
That
that's
a
a
good
question
so
as
I've
defined
it,
it
is
at
the
listener
level.
Obviously
the
way
that
this
issue
defines
it
it
they're
asking
for
optional
listeners
because,
as
as
I
understand
how
they
implemented
this,
they
had
either
annotations
or
labels
on
the
gateway
itself
that
referred
to
a
service
backend.
A
D
I'm
thinking
is:
if
it's
not
at
the
listener
level,
then
you
know
we
kind
of
bring
it
up
a
level
and-
and
it
removes
some
of
the
ambiguity
of
having
that
behavior
within
a
listener
right,
because
the
listener
defines
a
host
name
that,
I
would
think,
is
most
likely
irrelevant
for
layer
four
load
balancing.
We
of
course
have
the
routes
field
there.
D
So
we
would
have
you
know,
separate
gateway
classes
and
gateways
for
our
layer,
7
load,
balancing
and
our
layer,
4
load,
balancing
and
a
gateway
for
layer,
7,
load,
balancer
would
instantiate
a
contour
environment,
for
example,
and
then
a
gateway
instantiation
for
the
layer,
4
gateway
class
would
instantiate
some.
You
know
layer,
3,
4,
load,
balancer,.
D
A
Right,
I
think
that's
interesting,
I
think
one
yeah
we
do
still
have
and-
and
I
should
say
that
I
think
that's
that's-
going
to
be
a
common
thing-
a
differentiation
between
l4
and
l7
load,
balancing
implementations,
one
thing
that
routes
give
us.
I
think
it's
really.
The
primary
thing
at
this
point
is
some
level
of
l4
traffic
splitting.
A
How
common
that
will
be
is
unclear,
but
it
is
something
that
routes
and
listeners
provide.
The
other
thing
that
I
I
would
assume
we
would
want
with
a
l4
load.
Balancer
is
still
this
concept
of
the
protocol.
You
should
listen
on
and
the
port
I
I'm
assuming
yes,
and
so
so
some
form
of
the
listener
concept
still
feels
relevant
here.
B
D
D
A
Yeah
I
mean
I,
I
think
that
that
is
still
fine,
assuming
that
you
would
again
still
have
a
single
l4
listener
on
port
80,
let's
say
or
whatever
port
it
happens
to
be
that
protocol
and
port
are
going
to
be
unique
for
that
gateway
like.
I
think.
I
think
that
still
is
generic
enough.
A
uniqueness
requirement
that
it
would
be
true.
D
Well,
I
haven't
thought
through
this,
but
I
know
like
just
some
of
the
basic
testing
right
is
like:
okay
stance,
data
gateway,
class
gateway
and
http
route
and
the
gateways
you
know
I
either
don't
specify
hostname
or
specify
the
wild
card
character
right.
So
it's
kind
of
like
you
know
the
default
ingress
example
and
everything
works.
And
now
I
say,
okay.
Well,
I
want.
D
I
wouldn't
necessarily
define
a
host
name
right
for
my
layer.
4
listener
right
right,
rob
right
so
I'd
say:
okay,
import!
Whatever
protocol,
I
don't
know
if
we
haven't
specified
that
is
tcp.
Maybe
we
have
no
tls
config.
We
have
no
routes,
so
I
guess
how
would
the
gateway
know
like
to
forward
to
use
layer,
seven,
behavior
and
forward
it
to
you
know
a
route
that's
specified
for
the
one
listener
that
is
using
the
wild
card,
character
and
route.
D
B
A
B
A
A
D
Way
it
may
be
something
to
consider
is,
is
instead
of
back
end.
Ref
is
like
something
override
or
you
know,
route
override,
and
you
know
just
so
to
me.
It's
like
very
clear
to
the
user
that
when
they
set
this
option,
they're
essentially
overriding
the
routing,
behavior
and
just
forwarding
to
whatever
reference
is
specified
there,
which
sounds
like
it's
just
going
to
just
going
to
be
a
service.
Or
would
we
want
to
support
other
types.
D
I
yeah
now
that
I
think
about
it.
I
do
agree
with
you
because
again,
unless
I
misunderstood
is
the
a
the
routes
of
a
listener,
would
now
be
optional
and
so
a
listener
could
be
just
a
back-end,
ref,
correct,
yep,
exactly
okay,
all
right
yep!
No,
I
agree.
Let's
just
go
ahead
and
strike
what
I
said
about
renaming.
A
A
Maybe
I
should
create
another
issue
around
this
and
then
I'll,
let
I'll
let
it
soak
for
maybe
a
week
or
so
just
to
see
if
we
get
any
more
feedback
around
this
and
if,
if
it
still
seems
reasonable
a
week
from
now,
I
can
or
I
or
anyone
can
work
on
an
implementation
of
this.
This
is
the
kind
of
change
that
I
think
is
almost
back.
You
know
it's
it's
fully
additive,
but
I
guess
because
we're
making
a
field
optional,
maybe
not
quite
back
backwards,
compatible.
A
A
D
A
So
I
this
fixed
one
default,
and
there
was
concern
at
that
point
that
maybe
we
were
missing.
Other
defaults
yeah
for
some
of
the
other
resources
right
yeah.
When
we
moved
to
meta
v1
condition,
these
additional
fields
became
required,
and
so
we
have
better
testing
now.
So
we
know
at
the
very
least
that
our
defaulting
shouldn't
be
causing
any
errors,
but
we
don't
know
that
we're
not
missing
a
default
somewhere,
that's
harder
to
identify.
D
A
Cool
all
right,
the
next
one
is
114.
This
was
a
much
larger
discussion
that
you
know
also
has
a
lot
of
history
here.
This
was
the
idea
of
pluggable
access
control.
I
tried
to
read
through
this
again
before
the
meeting
and
there
there
was
a
good
discussion
of
how
we
could
do
this
in
some
kind
of
standardized
way,
and
you
know
this
idea
of
hey:
can
we
can
we
have
a
authorization
field
in
our
spec?
A
A
And
so
this
is
this
was
all
in
that
discussion.
You
can
see
this
continuing
on
of
hey.
Can
we
do
an
extension
ref
with
this
one
of
the
points
as
we
went
further
down?
Is
there
really
is
no
standard
way
to
do
this?
To
you
know,
every
implementation
is
going
to
have
a
different
way
of
plugging
in
authorization.
A
B
Yeah,
I
think
the
onus
would
be
on
someone
to
create
a
proposal
that
is
reasonably
or
conceivably
could
be
portable,
as
opposed
to
asking
for
to
support
a
specific
thing,
because
because
you
can
always
support
a
specific
thing,
with
the
current
set
of
extensions
to
loft
it
to
the
level
where
we
put
as
part
of
the
api.
Probably
it
requires
someone
to
do
that
like
work
yeah
into.
D
Bowie's
point
I
know
joakim,
which
is
what's
his
name,
j.m
prusi
in
this
issue.
You
know
I've
had
several
discussions
and
to
bully's
point.
That
is
exactly
what
I
told
joe
came
to
do
is
start
off,
creating
a
proposal
and
actually
gave
them
some
references
to
proposals
that
the
community
has
created
in
the
past.
D
A
A
D
D
You
know
any
user
that
tries
to
create
a
contour,
that's
outside
of
its
namespace.
So
you
know
the
intent
is
hey.
An
administrator
creates
the
name
space
to
run
the
operator
in,
and
the
administrator
creates
instances
of
this
contour
custom
resource,
and
it
should
be
name
space
and
scope
in
the
same
name,
space
that
the
contour
operator
runs
in,
and
so
you
know
we're
just
trying
to
get
away
from
saying:
okay,
let's
create
a
new
custom
resource.
D
That's
essentially
the
same
as
the
existing
custom
resource,
and
the
only
difference
is
that
it's,
you
know
globally
scoped
and
we,
you
know,
as
part
of
that
too,
is
we
thought?
Oh
wow,
you
know,
maybe
maybe
there's
a
use
case
for
going
ahead
and
saying
taking
existing
contour
environments,
and
you
know
with
with
the
new
version,
that's
released,
that
supports
service
apis,
that
users
can
go
ahead
and
say:
hey,
let's
just
enable
these
contour
environments
to
use
service
apis.
D
A
Yeah
thanks
for
thanks
for
that
background,
and
I
think
that's
a
really
interesting
and
I
think
fairly
compelling
use
case
for
how
you're
doing
that.
I
my
con.
My
concern
here
was
that
obviously
the
gateway
and
gateway
class
relationship
is,
you
know,
really
closely
tied
to
the
ingress
and
ingress
class
relationship
before
it.
And
ideally,
if
we,
if
we
changed
one,
we
would
change
the
other,
and
I
guess
this
is
specifically
related
to
the
parameters
reference
from
class
to
parameters.
A
A
I
think
there
was
an
ingress
working
group
meeting
where
we
discussed
this
and
then
shortly
after
a
sig
network
meeting
on
may
28th
and
of
course
it's
not
record
recorded,
because
why
would
it
be
that
every
every
other
meeting
is
uploaded?
But
the
may
28
one
is
not.
But
I
remember
that
that
it
was
a
pretty
quiet
discussion
in
the
sense
that
there
wasn't
a
whole
lot
of
feedback
one
way
or
the
other.
I
think
it
was
primarily
a
discussion
between
myself
and
tim
and
maybe
a
couple
others.
A
What
you're
describing
is
actually
a
little
bit
unique
in
that
it's
a
namespace
scope,
crd
and
and
so
that
automatically
removed
some
of
the
pushback
that
we
had
back
then
I'll
also
say
I
was
not
the
strongest
champion
of
this.
I
just
you
know.
This
was
something
that
came
up
and
I
raised
it
and
there
wasn't
a
whole
lot
more
support,
and
so
you
know
we
say
that
status
quo.
I
think
this
is
worth
bringing
up
at
the
next
sig
network
meeting
just
to
see
if
we
can
champion
change
there,
yeah.
B
A
Yeah,
I
was
trying
to
think
that
through
too,
the
the
cluster
scoped
resource,
referring
to
a
namespace
scope
resource,
seems
like
a
relatively
rare
thing,
but
it
r
back
itself
does
this?
If
you
think
about
a
cluster
role,
binding
being
bound
to
a
service
account
that
is,
or
can
be,
a
a
reference
to
a
namespace
scope
resource
from
a
cluster
scoped.
One.
A
But,
but
that
the
specific
use
case
danian
has
presented
has
is,
is
interesting
to
me,
I'm
interested
if
we
can
maybe
con
compile
a
few
more.
I
know
harry
had
specifically
mentioned
further
up
this,
that
maybe
a
a
config
map
would
be
compelling
in
some
cases
too.
I'm
less
sold
on
config
map
here,
but
the
specific
idea
of
namespace
scope
crd
seems
relatively
reasonable
to
me
at
these
tasks
being
used
here.
B
A
A
Yeah
yeah
it
I
my
the
way,
I'm
remembering
this
initial
discussion
is
that
keeping
resource
references
at
the
same
scope
is
always
simpler
and
unless
there's
a
very
compelling
reason,
you
know-
and
we
just
couldn't
come
up
with
that
very
compelling
reason.
At
least
config
maps
were
not
it,
but
maybe
this
is
so.
D
Yeah
yeah-
and
I
do
think
you
know
config
maps
because
it's
an
option
that
we
consider
on
the
implementation
side
as
well,
and
it's
like
okay.
Well,
we
already
have
this
crd
created
and,
aside
from
it
being
namespace
code,
you
know
we
prefer
using
it
since
it's
you
know
structured,
but
I
could
see
an
implementer.
That's
like
hey!
You
know.
Configuration
is
just
a
bunch
of
key
value
pairs.
Why
not
just
use
a
config
map.
A
Well,
just
so,
if
you
have
a
schema
associated
with
the
crd,
it's
easy
to
see
what
you
can
actually
set.
Where
a
config
map
you
can.
You
can
set
anything
and
it's
it's
similar
problem
to
annotations.
You
know
if
you've
worked
with
english
controllers
that
require
a
great
deal
of
annotations.
You've
likely
made
a
typo
at
some
point
and
not
understood
why
the
thing
you're
doing
isn't
working
and
it's
you
know,
there's
no
validation,
at
least
with
crds.
You
can
drop
fields
if
they're
not
supported.
D
Yeah,
I'm
just
trying
to
think
in
the
from
the
mind
of
like
a
simple
implementation
again
yeah,
I
don't
know
how
the
rest
of
the
community
feels.
But
it's
like
you
know
it's
nice
not
having
to
support
crd-
and
you
know
my
specific
use
case
having
to
create
almost
an
identical
crd
is
really
something
we
want
to
try
and
avoid-
and
I
think
you
know
with
with
some
of
the
benefits
it's
like.
Okay,
I'm
in
the
config
map
on
its
own.
D
You
know,
there's
some
limitations
there,
but
it's
being
referenced
by
like
a
gateway
class,
maybe
there's
logic
in
the
gateway
class
controller.
That
can
go
ahead
and
say:
oh,
you
know
something
is
wrong
here
with
the
configuration
and
then
surface
that
status,
condition
and
the
gateway
class
saying
you
know
like
invalid
parameters,
ref
and
then
yeah
pop
in
some.
A
Yeah
you're
right
and
we
do
already
have
that
condition-
reason
whatever
it
is
so
yeah
that
that
is
definitely
possible.
So
yeah,
it
probably
isn't
the
end
of
the
world
there.
There
is
the
the
ideal
implementation,
but
then
also
the
the
realistic
one
and
need
to
keep
them
both
in
mind.
Don't
want
this
api
to
be
too
much
of
a
pain
to
actually
implement.
B
A
D
D
Yeah
and
I
think
hebrew
brought
up
a
great
example
of
you
know:
cluster
cluster
role,
referencing
a
a
named
space
service,
account
right
yeah.
So
I
guess
to
because-
and
I
do
agree
right-
ingress
class
gateway
class.
I
agree
that,
let's
you
know,
keep
those
as
similar
as
possible,
so
agree
with
you.
There
so
is.
Are
you
able
to
help
me
on
the
ingress
class
side
and
having
that
discussion
yeah
if
it's
with
sig
network
or
whatever.
A
B
A
A
D
A
D
A
Yeah
yeah
and
admittedly
we
could
do
something
different
for
gateway
class,
but
then
I
think
we
just
reach
all
kinds
of
confusion.
Yeah,
you
know
one
one
of
the
idea.
Ideas
was
maybe
there's
a
way
that
implementations
can
use
the
same
parameters
for
ingress
class
and
gateway
class
that
that
may
not
actually
end
up
making
sense
for
a
lot
of
implementations,
but
maybe
it
could
and
if
one
ends
up
being
named
space
scope
and
the
other
doesn't
that
yeah
all
kinds
of
complications.
A
D
Attendance
of
sig
network
to
continue
that's
good,
urging
for
my
use
case
and
I'll
I'll.
Do
that
I'm
just
like
so
up
to
my
ears
and
the
implementation
side,
short
timeline.
So
I'm
really
trying
to
focus
in
on
that
and
then,
when
we
hopefully,
I
think
around
april
good
to
go
there.
Then
I'll
free
up.
My
time.
A
E
E
But
that
will
allow
me
to
actually
push
this
to
the
official
repository
it
has
all
the
scaffolding
needed,
as
well
as
the
first
kind
of
set
of
changes
where
I
think
there's
like
three
parts.
This
is
one
that
I
thought
was
most
straightforward
to
get
in
first,
so
I'd
like
to
merge
this
one
and
then
in
two
subsequent
prs
I
could
do
the
other
two,
the
one
thing.
E
A
Oh,
I
see,
I
see
what
you
mean
no
there.
There
is
not.
I
don't
know,
maybe
maybe
I'm
misremembering
this,
but
I
don't
know
that
it.
It's
significant
whether
something
is
core
or
extended
support
for
this
or
was
were
we
saying
that
we
would
allow
duplicate
filters
if
they
were
of
type
extended
was
that
was
that
the
idea.
E
Can
certainly
mark
it
to
do
so
because
I
believe
for
this
to
go
probably
even
to
beta
that's
something
that
we're
gonna
have
to
solve
soonish,
because
it's
it's
one
of
the
big
selling
points
of
v2
as
far
as,
but
I
think
at
this
moment,
there's
gonna
be
whether
I
create
the
helper
method
now
to
to
do
those
things.
There's
gonna
need
to
be
something
keeping
track
of
a
list
somewhere.
A
A
A
I
guess
a
safe
initial
way
would
be
to
just
say:
regardless
of
the
filter
type,
you
can
only
have
one
and
then,
as
we
get
requests
for
more
duplicate
filter
types,
let's
say
we
can
revisit
this
and
add
support
for
multiple
extended
filters
here,
but
yeah.
Let
me
that
that's
my
initial
thought,
but
I
know
we're
already
over
time,
but
let
me
let
me
follow
up
if,
if
anyone
else
has
thoughts
on
how
we
should
handle
this,
definitely
this
is
pr506.