►
From YouTube: SIG Network Gateway API meeting for 20230724
Description
SIG Network Gateway API meeting for 20230724
A
Because
you've
started
the
video
with
excitement,
we're
already
excited
all
right,
hello,
everybody
Welcome
to
the
July
24th
edition
of
The
Gateway
API,
sync
yeah.
As
usual.
Please
put
your
name
in
the
attendance.
If
you
will
we'd
like
to
keep
track
kind
of
like
how
many
people,
if
not,
who
and
so
forth,
are
coming
to
meetings
and
we're
talking
about
potentially
changing
some
times,
which
is
in
the
agenda
for
today.
So
this
stuff's
helpful
for
us.
We
appreciate
it
as
usual.
A
This
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
effectively
to
be
nice
to
one
another.
So
please
do
be
nice
to
one
another
and
it's
very
helpful.
If
you
use
the
hands
up
feature
when
you
want
to
talk
in
Zoom,
so
that
we
can
kind
of
coordinate,
giving
people
opportunities
to
talk
and
not
be
talking
over
one
another,
we
have
a
reasonably
light
agenda
for
today.
It's
all,
as
always,
it's
an
open
Agenda.
A
So
please
do
as
we
go
feel
free
to
add
stuff
above
the
triage
section
if
you'd
like,
if
there's
anything
we
can't
get
to,
we
can
always
fold
it
over
into
the
next
meeting
and
with
that
I,
don't
think
we
we
haven't
taken
the
opportunity
to
like
check
on
anybody
who
is
kind
of
new
I.
Think
last
time
we
missed
that
we
try
to
occasionally
check
in
and
be
like
anybody
new
to
the
community
who's
joining
this
meeting
for
the
first
time,
we'd
love
to
hear
from
you.
A
If
you
don't
want
to
you,
don't
have
to
stand
up
or
anything,
but
if
you'd
like
to
just
kind
of
say,
hey
I'm
here-
and
this
is
what
I'm
doing
with
Gateway
API
we'd
love
to
hear
about
it.
So
I'll
give
a
couple
seconds
for
anybody
who
wants
to
pop
in.
C
A
Then,
let's
move
on
to
our
agenda
Rob
go
ahead
and
talk
about
v080.
D
Cool
yeah
I
really
don't
have
much
here
other
than
to
say.
Yes,
we
are
finally
starting
the
API
review
process
this
week.
Thank
you
to
everyone
who
helped
contribute
here.
There
are
two
things
left:
they
are
both
docs.
They
both
are
on
Flynn.
So
thank
you,
Flynn
and
one
of
them
at
least
one
of
them
has
a
PR
open
for
it.
Maybe
both
I
think
both
no
just
one
I
can't
hear
you
Flynn.
It.
B
May
just
yeah
I.
That
was
my
turn
to
talk
to
myself.
Only
one
of
them
has
a
PR,
but
the
pr
for
the
other
one
should
be
up
everybody
cross.
Your
fingers
should
be
up
tomorrow.
E
D
Awesome
cool,
so
those
are
high
priority
if
we
can
get
reviews
on
talking
to
myself
as
well
on
those
ones.
Those
are
the
last
bits
left
on
080,
pending
API
review,
but
hopefully
that'll
be
a
relatively
smooth
process.
This
time
around.
A
Thank
you
again,
Flynn
for
finishing
up
the
last
couple
in
there.
We
appreciate
that
don't
see
any
hands
up,
so
we
can
move
on
to
the
next
thing.
I
I,
don't
remember
me
writing
this
next
thing,
but
I
can
go
with
it.
A
I
mean
it's
just
talking
about
V1,
so
V1
is
what's
coming
up
right
after
v080
I
think
it's
probably
important
to
note
that,
even
though
there
are
quite
a
few
things
in
here,
only
the
things
that
are
marked
as
a
release,
blocker
are
the
things
that
we
feel
will
actually
block
the
release
right
now
and
the
rest
of
them
are
in
the
shape
of
like
this
probably
can
wait
until
after
the
release.
A
If
we
have
no
other
time
that
said,
we
still
are
continually
grooming
through
that,
in
fact,
Rob
and
I
just
did
an
hour
before
this
of
grooming
kind
of
looking
at
that.
If
you
see
anything
that,
like
you're
like
hey
wait,
this
doesn't
look
like
it's
marked
right.
This
needs
to
be
a
release.
A
Blocker,
please
do
comment
on
it
and
mention
it,
but
we
are
kind
of
continually
over
the
months
until
we
release
trying
to
double
check
on
all
these
things
and
triage
incoming
things
to
make
sure
if
anything
else
needs
to
be
in
this
I
really
don't
remember
writing
that
I
was
going
to
talk
about
V1.
A
This
is
what
we
just
talked
about,
so
while
we
were
grooming
it
all.
It's
all
clear
to
me
now,
while
Rob
and
I
were
grooming,
there
were
a
couple
issues
that
came
up
that
we
wanted
to
kind
of
just
raise
for
everyone
they're
older
issues
they
are.
A
We
were
going
through
the
in
progress
and
looking
at
things
that
might
not
actually
be
in
progress
for
whatever
reason-
and
in
this
case
supporting
and
test
to
support
and
test
multiple
TLS
certificates
per
Gateway
listeners
is
an
old
one
that
we
kind
of
had
in
progress
and.
C
A
A
I
guess
this
one,
the
pr
that
we
have
open
right
now,
basically
is
taking
what
happens
when
you
have
multiple
certificates
from
implementation,
specific
meaning
we're
not
saying
what
it
does
to
try
to
actually
say
what
it
does,
but
we
never
really
came
down
to
what
that
should
be,
and
we
don't
necessarily
think
it
should
be
a
blocker
for
GA,
although
it
would
be
really
nice
to
get
that
in
for
GA
anything
else.
You
want
to
say
about
that.
One
Rob.
D
Yeah,
so
if
you
go
back
to
the
issue
down
at
the
bottom,
we
left
a
comment.
I
left
a
comment
that
is
basically
just
saying
before
we
can
move
any
further
on
this.
We
really
need
somebody
to
own
this
and
just
say
hey.
This
is
what
nginx
at
proxy
Envoy
other
implementations
do
when
they
have
multiple
certs
to
choose
from
and
there's
some
kind
of
conflict
or
overlap.
D
How
do
they
handle
that
right?
Because
we
need
to
call
this
extended?
We
need
to
know
that
there's
some
kind
of
path
to
portability
here
I
know
there's
a
few
people
that
are
interested
in
calling
this
extended
and
having
conformance
tests
for
it.
So
if
you're,
one
of
those
people
that
would
like
to
see
this
go
forward,
I
would
love
some
help
on
this
one,
but
just
I
just
would
like
to
you
know
more
clearly
state
that
this
is
no
longer.
B
A
That
and
then
the
other
one
partially
invalid
routes,
I,
don't
think
I
opened
it
or
if
I
did
I
can't
see
it
partially
invalid
routes.
We
just
got
done
talking
about,
and
I
commented
on
this
one
is
basically
we
have
two
things
that
we
say
right
now
that
conflict
with
each
other.
If
you
have
partially
invalid
routes,
we
have.
B
Well,
Shane
is
demonstrating
starlink
yeah.
Is
this
talking
about
syntactically
invalid
routes,
or
is
this
talking
about.
F
This
is
talking
about
a
route
where
you
have
like
moderable
rules,
for
example,
and
one
of
the
rules
is
valid
and
fine
and
good
config
and
one
of
them
is
not
what
should
we
do
in
this
case
generally,
we
have
preferred
to
sort
of
say:
okay,
in
that
case,
we'll
program,
the
bits
that
are
good
and
not
program,
the
bits
that
are
bad
and
we
need
some
way
to
tell
you
that
that's
happening
and
the
reason
that
we
have
generally
preferred
to
do.
F
That
is
because,
if
you
have
a
working
system-
and
you
add
a
non-working
bit
of
config-
and
that
then
means
that
that
whole
that
entire
config
it
stops
working,
then
that's
bad
Shane,
you're.
F
Let's
see
what
what
I
was
just,
what
I
was
just
saying
is
right
now,
right
now
the
problem
is,
we've
got.
You
know
the
there
are
things
in
here
that
you
know
sometimes
in
some
parts
of
the
documentation.
We
say:
if
there's
an
error
here,
then
that's,
then
that
should
fail
the
entire
route
that
should
be
not
accepted,
and
there
are
some
parts
that
say.
Oh
it's,
okay
for
this
bit
to
be.
You
know
this
bit
to
be
invalid.
F
If
the
rest
of
the
route
is
invalid
now
and
then
you
put
a
comment
on
it:
I'm
sorry
I
missed
that
I
missed
the
meeting
you
and
Rob
had
earlier,
but
you
have
you
put
a
comment
on
this
saying
you
prefer
to
fail
faster
and
not
have
partially
invalid
States.
F
The
reason
why
we
haven't
wanted
to
do
that
in
the
past
is
that
if
you
do
that,
that
means
that
if
someone
edits
a
route
and
that
has
multiple
rules
and
and
makes
an
error
on
one
of
the
rules,
all
of
the
rules
will
be
chucked
out.
Yes,
which
means
that
which
means
that
it's
really
easy
to
make
very
far-reaching
changes.
If
you
have
a
rule
with
multi
a
route
with
multiple
rules
like
you
could
blow
up
lots
of
lots
of
stuff
by
making
a
one
typo
in
one
part
of
a
file.
F
A
F
A
I
get
I,
get
that
I
do
get
that,
and
that
said
the
downside
of
that
is
we'll
have
no
understanding
when
there
is
no
way
to
understand
when
the
different
pieces
may
have
a
relationship
and
whether
it's
actually
appropriate
to
have
part
of
that
relationship.
Work
and
part
of
it,
not
so
I
mean
Liu
in
lieu
of
that
understanding.
We
can
just
say
it
has
to
all
work
or
it
doesn't
work,
and
it
has
one
additional
benefit.
A
Despite
having
the
major
downside
of
like
yes,
we
could
one
mistake
can
potentially
have
a
catastrophic
effect,
and
that
is
if
we
start
with
a
fail
fast,
do
not
have
partially
invalid.
If
it's
invalid,
it's
invalid
State,
we
can
progress
after
people
bring
in
issues
and
be
like
that.
Doesn't
work
for
me.
I've
had
these
situations,
which
I
want
to
tell
you,
you
know,
I
want
to
talk
to
you
about
where
I'm
trying
to
make
a
case,
for
you
should
change
this.
E
G
F
I
my
experience
here
has
been
that
it
won't
take
it's
it's
going
to
be
such
a
short
time
before
people
find
ways
to
that.
This
is
a
problem
that
we
should
just
deal
with
it
straight
up,
because
the
the
we
actually
have
some
reasonable
rules.
There
I
think
that
the
problem
is
that
they're,
just
not
consistent
enough
and
they're
not
easy
to
understand
enough.
You
know
right
now.
F
The
rule
is,
if
you
have
multiple
routes,
rules
in
a
route-
and
there
is
at
least
one
valid
rule,
then
that
route,
then
that
route
should
still
be
accepted.
You
know
the
the
sort
of
the
underlying
rule
here
is:
if
a
route
can
produce
config
in
the
underlying
data
plane,
then
it
should
still
be
accepted.
Even
if
not
all
of
the
route
could
produce
can
is
correctly
producing
config
in
the
underlying
data
plane
and
the
again.
E
B
Been
remembering
a
conversation
with
Nick
that
we've
got
into
Great
Lengths
about
that
pretty
much
that
exact
situation,
although
I
think
we
might
have
been
talking
about
back
ends
rather
than
route
rules.
But
it's
the
same
thing.
So
I
agree
with
Nick
that
I
think
the
time
between
submitting
that
and
getting
feedback
will
be
zero.
A
A
I
do
think
the
bare
minimum
if
we
decide
to
go
that
way.
The
bare
minimum
is
something
along
the
lines
of
documenting
that
implementations.
Will
it
doesn't
really
mean
anything?
It's
almost
ceremonial,
but
just
to
say,
hey
if
you
know
of
relationships
between
these
things
like
where.
Actually
let
me
think
through
this
with
a
question
where
what
do
we
do
about
situations
where
there
would
be
relationships
that
the
implementation
would
know
about
that,
it
could
then
have
be
like
actually
I
can't
have
one
of
these
things
on
and
one
of
these
things
broken.
A
F
The
the
idea
here
is
that
this
that
this
is
intended
to
handle
things
like
you,
it
handles
a
few
things
like
you've
made
a
mistake
in
a
rule,
and
now
the
rule
is
not
valid
for
some
reason:
yeah
an
example
that
Sanjay
used
in
that
in
the
issue
that
you've
referenced
there
is
that
the
you
know,
you've
got
two
filters
where
you
in
in
a
rule,
and
you
can
only
have
one
of
that
specific
type
you
or,
and
that
makes
that
rule
that
rule
invalid
or
you've
got
a
back
end.
F
This
is
a
valid
back-end
reference,
but
that
has
zero,
endpoints
or
other
stuff,
like
that.
You
know
like
and
there's
a
bunch
of
other
cases
like
that
that
are
similar,
that
if
you
just
blow
up
the
whole
route,
it's
going
to
be
a
problem,
but
I
should
stop
talking
now,
because
we've
got
a
few
people
with
their
hands
up.
Costan.
C
Yeah,
maybe
that's
the
case
for
saying
that
well,
configuration
changes
must
be
tested
before
they
put
in
production
to
minimize
and
and
actually
in
history,
I
mean
I'm,
not
joking.
Actually,
in
istio
we
have
some
ability
to
put
some
labels
on
on
on
routes
or
virtual
service,
or
any
configuration
to
specify
a
specific
revision
and
to
kind
of
make
it
they
apply
only
on
a
canary
version
of
the
Gateway-
and
we
have
all
kind
of
you
know,
eastways
revision.
You
can
have
multiplicators
and
different
revisions.
F
We've
talked
about
that
before
we've
talked
about
that
before
and
the
the
problem
there
is
that
you
start
violating
the
sort
of
the
the
declarative
Loop
like
the
pro
the
clarity
properties
of
kubernetes
API.
If
you
declare
something
and
then
you
like,
you
sort
of
test
apply
it,
you
know
like
the
you
it.
It
becomes
hard
to
know
like
what's
applied
and
what's
not
I'm
not
saying
like
I,
think
that
that
is
absolutely
a
thing
that
we
should
allow
implementations
to
do.
F
But
I
don't
think
that
we
can
mandate
that
or
like
require
the
implementations
to
it
like
it
should
be
possible
to
have
an
implementation
that
does
the
stupid,
brutal
thing
and
just
takes
what
you
have
and
and
applies
the
the
config.
But
you
I'm
not
like
the
point
that
I
don't
think
we
can
make
that
like
a
even
and
extended
Behavior
I
think
that
that
can
be
an
implementary,
specific
behavior,
but
not
an
extended
one.
C
No,
no
I
agree,
it
can
be,
but
I
I
think
the
recommendations,
the
best
practice
and
what
we
should
recommend
this
again.
You
should
have
a
canary
Gateway,
you
should
apply
the
canary,
and
maybe
you
should
standardize
the
rules
for
using
this
kind
of
candidates
because
they
are,
you
know,
far
more
things
that
can
break
without
testing
yeah.
F
F
What
is
the
flow
of
the
API
objects
when
that
happens,
and
that's
I
think
that's
that's
the
tricky
part
like
I
100
agree
that
in
actual
practice,
it's
a
really
good
idea
to
sort
of
try
these
things
out
in
some
way
before
you
do
it
and
not
just
be
live
editing
your
production
website.
You
know
that's
bad,
but
but
you
know,
but
the
spec
needs
to
be
able
to
like
have
defined
behaviors.
For
what
happens,
if
someone
does
do
something
that
silly.
C
We
should
be
very
clear
what
happens
well,
my
my
what
I'm
trying
to
say
is
that,
in
the
case,
you
are
doing
Canadian
it's
better
to
fail
completely
and
not
have
a
partial
application,
because
you
want
the
canary
to
fail
fast.
If
you
are
in
the
other
situation
where
you
you
apply,
edit
live
production,
I
agree
with
you.
It's
the
best
solution
is
to
just
pay.
What
I
mean.
C
Try
to
you
know,
be
conservative
and
and
keep
as
much
as
possible
running
it's
a
choice,
but
we
need
to
support
both
choices
because
in
the
other
case,
it's
actually
much
better
to
train
fast
yeah.
F
And
so
in
in
the
API
we
have
specifically
made
some
choices
about
failing
in
that
way,
because
of
that
exact
thing
you
know
like
we
have
specifically
said
if
you
have
weighted
you,
if
you
have
weighted
back
ends,
and
you
make
a
mistake
in
one
of
those
weighted
back
ends,
then
you
should
still
send
you
should
fail
a
the
weight
percentage
of
request
to
the
invalid
back
end
and
the
reason
to
do
that
is
you
know.
F
That
is
an
argument
where
you
could
say:
hey,
you
don't
want
to
blow
things
up
and
people,
someone
made
a
mistake.
The
reason
to
do
that
is
that
that
specific
case
is
when
is
how
you
do
Canary,
and
if
you
don't
have
a
the
correct
percentage
of
requests
fail,
you
could
conceivably
go
through
the
whole
process
until
you
get
to
100
and
then
have
everything
fail
so
like
we
have
absolutely
sort
of
taken
that
into
account
in
other
places
in
the
API.
F
But
this
is
like
this
is
the
case
where
there's
like
a
bit
of
a
sliding
scale
and
like
for
partial
validity,
like
you,
I
think
it
needs
to
be
a
little
bit
more
on
the
kind
to
the
user
side
than
on
the
you
know,
respect
respect
the
declared
intent.
You
know
you
need
to
be
able
to
impute
some
intent
here.
D
Yeah
I
I
think
what
we
have
said
and
and
I
actually
kind
of
regret
some
parts
of
our
API,
one
of
them
being
that
we
have
a
list
of
rules
in
HTTP
route,
because
what
we've?
D
What
we're
essentially
saying
here,
is
that
the
rule
is
the
minimum
viable
valid
unit
roughly
and
it'll,
be
a
lot
easier
to
represent
if
there
wasn't
a
list
of
them
within
a
resource
right
and
so
right
now
our
status
is
for
the
entire
route
and
we
don't
have
a
way
of
referencing
hey
one
of
one
or
more
of
your
rules
in
this
route
is
invalid.
D
I
think
the
kind
of
Ideal
case
is
hey,
someone's,
creating
a
brand
new
route
and
any
part
of
it
is
invalid.
The
whole
thing's
invalid,
but
the
again
you
know
how
implementable
that
is
to
differentiate
between
brand
new
and
already
existing
is
yet
another
thing.
But
what
I
think
Nick
is
saying
and
I
think
I
I
I
get.
D
That
idea
is
just
you
want
to
be
somewhat
kind
to
users,
and
if
you
have
a
a
very
large
route
and
some
portion
of
a
route
rule
fails,
although
I
can
be
a
really
painful
thing,
if
it,
if
it
ruins
your
entire
route
and
other
unrelated
route
rules,
one
potential
thing
we
could
do
is
we
could
just
issue
guidance
and
say:
hey,
just
don't
do
a
lot
of
Route
rules
in
the
same
in
the
same
route
and
because
they're
all
going
to
fail
together.
D
If
one
fails,
we
could
just
issue
that
guidance
and
make
that
decision
too.
But
that's
pretty
harsh
I,
don't
know,
but
I
think
I.
Think
the
high
level
thing
that
we
need
to
come
out
of
this
with
well
out
of
this
issue
with
is
some
kind
of
guidance
on
how
you
represent
this
state,
because
right
now,
we've
left
it
wide
open
and
if
we
go
to
GA
without
some
kind
of
guidance
here,
we're
going
to
have
everyone
doing
their
own
different
thing,
which
is
just
not
going
to
be
a
good
experience
for
anyone.
D
G
Yeah
one
question
I
have
when
we
talk
about
partial,
are
we
talking
about
with
respect
to
the
rest
of
the
object
or
time
like?
Are
we
ever
considering
I
changed
a
value
from
valid
to
invalid,
and
now
we
still
want
to
buy
the
old,
valid
state
or
I
mean
the
other
approach
is
obviously
like
one
route's,
okay
and
one's
not
or
both
of
the
business
go
for
the
separate.
D
I'll
give
a
biased
answer
and
say
that
gk's
own
implementation
today
defers
back
to
the
previous
known,
good
state.
It's
not
viable
for
everyone,
but
that
is
something
like
that.
The
implementation
has
chosen
to
do
now
for
now
that
actually
makes.
E
F
I
think
the
problem,
the
problem
that
we
have
encountered
before
is
that
not
everybody
can
do
that
and
the
again
it
also
so
the
the
problem
that
I
have
with
that
is.
That
is
that
it
means
that
the
you
know
your
your
declarity
system
is
now
stuck
in
a
non-declarative
state.
F
Right,
like
you
know,
the
you
know,
you're
you're,
stuck
sort
of
like
the
the
declared
state
will
never
be
reconcilable
to
the
thing,
but
you
have
some
State
configured
that
you
don't
know
what
it
is,
because
it
is
not
represented
in
the
declarative
system
at
all,
because
the
last
known
gone,
good
config
is
gone
because
it's
been
overwritten
by
the
bad
config,
so
you
have
no
way
declaratively
in
the
API
of
retrieving.
What
the
current
actual
config
is
and
I
feel
like.
F
That's
a
very
big
sort
of
violation
of
one
of
the
core
kubernetes
principles,
and
so
that's
one
of
the
reasons
why
I
have
sort
of
you
know
preferred
to
say
Hey,
you
know
implementations,
you
could
do
that,
but
like
in
general,
you
should
try
and
you
know
make
it
so
that
what's
in
there
is
what's
configured
and
if
there's
bits
of
it
that
are
not
valid,
then
those
bits
are
just
not
configured.
F
Shane,
I,
assume
you're,
probably
going
to
be
like
we
need
to
time
box.
This.
A
We're
at
the
half
hour,
yeah
I
have
a
million
things.
I
could
say
about
this.
I
appreciate
everyone's
feedback
and
thoughts.
It
sounds
like
we
have
a
lot
of
them
and
that's
good.
We
did
Mark
this
as
a
release
block
for
V1,
because
we
right
now
we
definitely
feel
like
we
want
to
get
this
sorted
out
before
V1.
It
would
be
kind
of
weird
to
not
sort
this
out
before
V1.
A
If
everybody
who
has
thoughts
on
this
could
start
commenting
in
issue
1696,
we
would
really
appreciate
it
we'll
try
to
see
if
we
can
drive
forward
a
little
bit.
Sorry
in
advance,
Sanjay
we're
about
to
like
blow
up
your
issue,
but
I
think
it's
for
the
it's
for
the
greater
good
of
everybody
that
we
get
this
one
sussed
out,
because
otherwise
we
will
be
in
a
weird
state,
so
yeah
yeah.
F
Yeah
again,
I
am
sorry
to
be
sort
of
no
no
you're
right
to
be
just
close
it
to
close
this
out.
I'm,
sorry
to
be
the
you
yeah.
We
already
talked
about
that
and
here's
what
happened.
But
in
this
case
we
have
already
talked
about
this
many
times
and
so,
like
you
know,
and
I
have
been
involved
pretty
much.
All
of
them
so
like
I
can
recover
the
context
of
what
we
talked
about
previously.
So
I'll
try
and
keep
that
I'll
train.
F
To
some
extent
it
is
yeah
yeah,
it's
like
so
sorry
to
be
the
guy
who's
like.
Oh
actually,
we
already
talked
about
that,
and
this
is
why
we
didn't
do
it,
but,
like
some
of
these,
things
are
things
that
we
took
months
talking
about
early
on
in
the
API
and
went
backwards
and
forwards
many
times
and
I'd
rather
not
spend
months
again.
If
we
can
avoid
that,
please.
D
D
D
Thank
you
all
right,
so
yeah,
the
next
thing
kind
of
a
footnote
actually
trying
to
move
to
more
EMA
friendly
meeting
times
so
starting
next
week
on
August
one
we're
looking
at
an
8
A.M
meeting
and
then
potentially
continuing
that
every
four
weeks,
I
think
there's
been
some
discussion
in
slack
around
that
I
was
trying
to
remember
the
old
threads
just
trying
to
find
times
that
work
better
for
different
people
and
we've
seen
with
other
meetings
that
we
are
getting
decent
attendance
at
earlier
times.
D
F
D
D
Okay,
that
sounds
awful
for
you,
I'm
sorry,
yeah
yeah,.
D
B
D
So
there
so
trying
to
avoid
getting
people
to
start
early
on
a
Monday.
We
have
this
all
this.
The
slot
that's
being
recommended
here
was
an
old
gamma
slot,
so
gamma
used
to
meet
at
this
time
slot.
But
since
they've
gone
to
bi-weekly
this
time,
slot
is
free
and
hopefully
still
reserved
on
some
calendars.
So
I
figured
just
reuse
it.
While
it
was
still
around.
B
A
B
D
Cool
I
I
added
this
one
to
the
agenda.
It's
cell
I
think
I
was
on
the
call
too
so
feel
free
to
jump
in
if,
if
you've
got
anything
out
of
but
I
just
this
is
a.
This
is
a
big
transition
for
Gateway
API.
It's
been
a
long
time
coming,
but
working
towards
moving
to
cell,
which
is
kind
of
in
line
and
cell,
is
like
a
expression.
Language,
common
expression,
language
I
think
that's
what
it
stands
for.
It's
all
correct
me:
it's.
B
That
enables
animation.
D
G
B
G
Gonna
ask
I
had
a
couple
questions.
Do
we
know
how
much
of
the
web
hook
can
be
implemented
in
cell?
Is
it
all
of
it.
E
D
No
I
I
think
you've
got
it.
You've
got
a
better
handle
than
I
do
at
this
point.
What
you've
done
so
far
looks
very
promising,
though,
and
I
think
it's
near
100
coverage
of
Gateway
and
Gateway
class
and
you
it
sounded
like
100-
was
possible.
Correct,
yeah.
D
G
D
Piano
sorry
yeah,
my
my
recommendation
was
going
to
be
starting
in
080.
to
make
it
assuming
we
can
get
this
in
to
make
it
optional
and
recommended
for
kubernetes
version,
124
and
older
and
not
recommended,
and
even
recommend
that
hey.
If
you
had
this
running,
you
may
want
to
uninstall
it
when
you
upgrade
to
one
to
vo80crds
yeah.
F
D
D
So
one
of
the
things
is,
we
also
control
our
crd
generation,
so
we
could
potentially
I
don't
know
if
this
is
helpful
or
painful,
but
we
could
potentially
have
some
like
shortcuts.
That
mean
basically
call
out
to
this
function
that
we
know
of
in
our
crd
generation
are.
A
A
Familiar
with
I,
don't
think
it'd
be
super
bad.
If,
like
we
were
able
to
put
these
in
functions
or
something
in
files
and
then
call
them,
but
it's
a
little
bad
like
it's
nice
to
be
able
to
go
in
here
and
look
at
them
and
be
like.
Oh
it's
right.
There
I
know
exactly
what
it
does
until
it's
not
nice
until
it's
until
it's
huge
and
then
it's
like.
Oh
that
could
be
in
a
file.
E
So
I
think
one
aspect
is
that
if
something
is
genetic
enough,
we
could
add
it
to
the
API
server
Library,
which
we
could
call
out
from
within
these
things.
But
that
would
be
only
for
like
very
generic
things
which
could
be
used
in
other
aspects
as
well.
But
besides
that
I
don't
think
I
have
come
across
so
far
of
ways
of
how
we
can
call
out
some
functions
or
some
templates.
A
F
That's
right:
yeah
I
had
a
couple
questions.
There's
been
there's
a
couple
of
questions
in
chat
as
well,
so
the
first
question
I
heard
of
is
I
haven't
played
with
so
much
yet.
What
happens
if
you
have
the
cell
definitions
in
a
CID
and
you
apply
it
to
a
version
of
kubernetes,
let
you
know
less
than
123.
E
I
have
only
explored
this
for
versions
123
and
for
that
at
least
I
know
that
it
is
ignored
for
versions
120
for
versions
below
123
I
have
not
touched
that
part.
So
I
think
that
will
I'll
have
to
probably
take
a
look
and
get
back.
D
Yeah
my
my
understanding
I
talked
briefly
with
Joe
Betts
and
it
sounded
like
below
123.
Those
crds
would
get
rejected,
so
we
can.
We
can
kind
of
decide
as
per
project
if
for
some
short
period
of
time,
we
want
to
maintain
a
legacy
set
of
crds
for
122
and
older
I
would
not
like
to
carry
that
on
for
a
long
period
of
time,
though,.
F
Yeah
yeah
and
I
agree:
it's
the
it's
more
just
the
yeah
I
just
wanted
to
check.
That's
gonna,
that's
coming
up
from
for
me
and
other
things
as
well.
So
thank
you.
That's
a
useful
to
know
so
Mikhail
said.
Is
there
an
option
to
rerun
the
rules
and
implementations
and
and
Travis
said
to
comments
about
that
too
and
I?
Think
the
the
key
thing
for
me
is
that
the
important
thing
about
cell
is
that
it
takes
effect
at
apply
time.
It
is.
F
It
is
literally
like
you
like
a
validating
weapon
but
but
kind
of
better,
because
you
don't
have
to
run
anything
it's
done
in
the
API
server,
then
yeah
and
I
think
that
the
idea
here
is
that
we
want
to
get
as
many
things
as
possible
in
there
and
I
think
that
it
is
possible
that
there
will
be
rules
that
we
have
to
do
that
are
not
possible
to
to
write
and
sell.
And
if
that
is
the
case,
then
we'll
have
to
provide
the
Web
book.
F
That
said,
there
is
I,
think
Robin,
Shannon
and
I
were
talking
about
the
I
I
opened
an
issue
like
a
long
time
ago.
That
basically
said
we
should
ensure
that
everything
all
of
the
invalid
cases
that
we
have
that
we
could
possibly
have
are
being
tested,
that
they
are
invalid,
and
that
should
be
part
of
conformance.
F
You
know
like
so
you
know
we
should
ensure
that
you
know
part
of
conformance
is
that
your
implementation
will
reject
everything
it's
supposed
to
so
that
you
know
we
have
some
sort
of
invalid
examples
already,
but
you
know
I
think
that
that's
really
yeah,
that's
it
yeah
one,
five,
one,
four
thanks
yeah!
We
should
check
that
the
web
without
that
that
I
think
we
maybe
even
should
just
change
that
to
say
the
test
that
tested
validations
are
performed
as
part
of
conformance.
F
You
know
and
then
then,
for
us
for
Michaela,
because
with
kind
of
Black
Box
testing
that
the
validations
are
performed,
then
it
kind
of
doesn't
matter
for
conformance
whether
exactly
how
they
get
performed,
if
they're
done
by
cell
or
a
Web
book
or
your
implementation
or
whatever,
like
the
important
part,
is
that
those
validations
are
performed
and
that
things
that
that
don't
pass
the
validations
get
rejected.
A
A
Had
a
pretty
decent
conversation,
we
have
some
open
questions
about
what
this
means
in
terms
of
older
versions
of
kubernetes,
which
we
should
sort
out
in
this
PR
before
we
merge
it
and
at
least
have
that
understood
and
documented,
and
what
we're
going
to
do
I
mean
we're
going
to
know
what
we're
going
to
do.
A
B
A
And
if
you
do
want
to
jump
in
that,
PR
is
2226.
Please
do
jump
in
there.
If
you
have
important
comments
and
stuff
like
that,
Robin
leor.
What
time
are
we
at?
We
got
15
minutes,
so
we
should
probably.
D
Yeah
this
is
this
is
a
quick
one.
It's
just
an
FYI.
We
already
have
at
least
one
a
couple
of
gtms
on
this
one,
but
this
is
really
it's
not
quite
a
gap,
but
it
is
almost
an
API
change
because
we're
saying
the
mirror
filter,
which
previously
could
not
be
repeated
now
can
be.
So
if
you
want
to
mirror
to
multiple
back
ends,
you
just
use
the
filter
more
than
once.
It's
not
a
perfect
scenario.
You
know.
D
Ideally,
we
could
have
had
like
a
list
of
backend
refs
in
the
filter,
but
that's
a
real
pain
to
transition
to
at
this
point.
So
for
now
the
FP
proposal
is,
you
can
just
have
more
than
one
reference
to
that
filter
or
in
in
the
chain.
D
This
is
an
FYI.
We
would
love
to
get
a
couple
more
comments
on
this,
but
specifically,
if
you're,
you
know
working
on
an
implementation,
you
know
this
would
I
I,
guess
we.
We
know
this
is
not
going
to
be
supportable
well
supportable
by
everyone,
but
really
the
the
bigger
thing
is.
If
you
would
rather
see
this
API
work
some
other
way,
it
is
some
form
of
an
API
change,
so
just
wanted
to
highlight
it
because
it's
small
enough
that
it's
not
going
through
the
Gap
process.
D
D
Hold
off
on
you
know
if
we
don't
hear
anything
in,
say,
24
hours,
I.
Imagine
it's
just
going
to
merge.
This
is
just
waiting
for
consensus
and
if
it
doesn't
happen
we'll
just
March
anyway,.
A
And
that's
21.99
pull
request
all
right,
a
quick
update
on
conformance
profiles,
because
John
kind
of
reminded
me
that
we
may
not
have
shouted
this
out
loud
enough
to
everybody,
but
conformance
profiles
has
made
it
to
the
experimental
state
in
terms
of
its
Gap.
It
has
an
experimental
CLI
that
is
actually
under
the
go
tag
experimental
and
an
experimental
test
Suite
that
you
can
run
from
go
if
you
like
at
this
point,
I
think
it
is
either
merged,
or
it's
about
to
merge.
A
The
basic
idea
at
this
point
is
that
we're
in
a
kind
of
trial
period
for
at
least
six
months,
where
we're
going
to
kind
of
move
this
one
forward
together,
everybody
use
it
report,
make
sure
things
are
working
and
once
we're
all
happy
with
it,
we
can
consider
it
stable.
A
G
A
Thank
you,
yeah
I
did
get
that
feedback
on
the
channel,
I'm
glad
that
it
worked
good
for
you
and
just
yeah.
Let
us
know
we
want.
We
want
the
issues
and
stuff
if
you
guys
run
into
anything
weird,
even
if
it's
smaller
you
know,
we've
got
plenty
of
time.
We
don't
need
this
to
be
done
just
to
make
it
clear.
We
don't
expect
this
to
be
in
a
stable
State
before
GA.
A
C
We
we
normally
have
you
know,
gateways
for
internet
traffic,
all
is
understood,
but
with
all
the
ingredients
there
was
some
annotations
that
made
it
an
internal
Gateway
in
JK.
There
is
a
special
class
that
makes
a
Gateway
B
internal
in
issues,
there's
some
annotations
and
trying
to
figure
out.
If
what
other
implementations
are
doing
about
it,
and
if
there
is
any
desire
to
be
more
explicit
about
the
Gateway
is
that
you
know
get
an
internal
IP
and,
and
it's
not
exposed
to
the
internet.
D
D
Yeah
for
gke
right
now
that
the
idea
is
just
to
publish
you
know
this
is
this:
is
the
routability
of
this
Gateway
I?
Don't
know
that
we're
going
to
support
because
we
already
have
Gateway
classes
for
the
thing
I,
don't
know
that
we're
going
to
introduce
no
new
Gateway
classes
that
you
can
figure
this
way.
F
D
G
Yeah
one
thing
to
note,
though,
is
that
the
Gap
specifies
that
in
cluster
implementations
should
not
implement
the
private
mode,
so
yeah.
F
Yeah
that
I
think
correct
me
if
I'm
wrong,
but
that.
F
C
A
Oh
I,
guess
it
popped
over
the
weekend,
but
I
saw
it
today.
The
JWT
Gap
and
it
looked
like-
was
that
you
rob
don't
want
to
talk
about
that.
D
No,
it
was
just
informational
that
that's
it
I,
don't
think.
There's
anything
that
really
needs
to
be
talked
about.
I
think
it's!
It's
a
good
start!
It's
good
to
have
some
conversation
about
this,
because
there
are
already
multiple
implementations
of
the
Gateway
API
that
have
kind
of
gone
their
own
way
with
enjoy
based
extensions
policies.
Etc
so
trying
to
bring
that
back
into
tree
is
great.
Just
yeah
would
be
good
to
have
some
feedback
and
discussion
on
this
yeah.
F
I
think
I
feel
like
I
should
be
pretty
clear
here,
though,
that
this
one's
not
going
to
go
super
fast
because,
like
it's,
not
a
j,
blocker
yeah
like
we'll
keep
it.
Everyone
should
continue
discussing
on
it
and
stuff
like
that.
But
I
want
to
manage
expectations
a
bit
here,
like
you
know,
there's
a
lot
of
stuff
to
do
before
1.0
and
for
I
I.
F
Think
I
can
speak
for
Rob
and
Shane
here,
but
for
the
three
of
us,
like
the
ga
stuff,
is
going
to
beat
this
stuff
in
terms
of
bandwidth
and
so
like
non-ga
stuff
is
going
to
be,
is
going
to
be
best
effort
for
the
sort
of
the
three
of
us
for
for
a
bit
so
like
I,
will
I
go
and
have
a
look
at
this,
but
I
don't
know
if
I'm
going
to
be
able
to
give
it
a
proper
review
or
like
have
a
lot
of
discussion
on
it,
and
if
it
does
end
up
being
a
lot
of
discussion
on
it,
then
I
might
not
be
able
to
keep
up
with
it,
because
I'm
going
to
focus
my
the
time
that
I
have
to
spend
on
Gateway
API
is
going
to
be
focused
on
sort
of
Burning
Down
The
the
1.0
blocker
list,
rather
than
sort
of
working
on
gaps
that
can
happen
after
1.0.
F
G
F
Just
want
to
sort
of
be
super
upfront
about
things.
I
100
agree
that
this
is
a
great,
a
great
gap
for
us
to
start
and
and
kick
us
out
the
process
and
for
us
all
we'll
be
talking
about,
and
this
is
absolutely
a
thing
we
need
in
the
API,
but
because
it's
not
a
block
of
Fergie
like
I'm,
probably
not
gonna,
be
able
to
spend
as
much
time
as
it
deserves
before
G8.
Personally.
B
A
It
let
me
see
where
we're
at
actually
professional
yeah,
the
I
think
this
one
and
the
egress
one,
although
it's
not
in
yet
it's
still
on
a
PR,
are
kind
of
in
a
similar
boat.
Thank
you
for
being
patient
with
us.
Please
be
patient
with
us.
We
got
a
couple
more
months
here
to
kick
the
last
most
important
things
up
for
GA,
and
then
these
things
should
get
more
gas.
A
F
And
the
same
will
go
for
probably
other
new
gaps
that
are
raised,
that
aren't
if
they
are
not
specifically
GA
blocking,
then
you
know
it's
going
to
be
similar
for
them.
Like
you
know,
I
will
do
my
best
to
have
a
look
at
it,
but
like
I'm,
going
to
prioritize
hitting
the
GI
stuff,
because
I
think
we
all
really
want
this
API
to
go
ga
in
time,
and
for
that
to
happen,
you
know
we
need
to
make
sure
that
the
three
of
us
are
not
sort
of
blocking
approval
and
approval
and
merging
of
stuff.
A
Roger
that
with
six
or
so
minutes
to
spare,
we
have
reached
the
end
of
our
agenda.
For
today,
we
can
give
a
couple
seconds
for
anybody
who
has
a
last
minute
thing.
They
want
to
bring
up.
A
Please
do
otherwise.
We
can
give
everybody
their
time
back.