►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20200106
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
All
right
we're
recording
it
is
january,
6,
2021
and
we've
got
plenty
to
talk
about
today.
Some
prs
came
in
over
the
holidays
and
I
also
have
made
some
progress
towards
conformance.
A
Maybe
it's
progress,
I
don't
know,
but
I
wanted
to
take
a
few
steps
back
and
take
a
closer
look
into
the
precedent
that
has
been
set
and
what
I'm
at
least
initially
proposing
and
kind
of
my
rationale
for
getting
there
so
for
anyone
that
may
have
seen
the
pr
come
in
earlier
this
week.
A
I
have
kind
of
a
a
work
in
progress
here.
That
is
a
really
really
simple
idea
of
what
conformance
tests
could
at
least
start
with
for
service
apis.
These
are
painfully
simple
in
the
sense
that
they
are
literally
just
vanilla.
Go
tests
that
rely
heavily
on
some
helpers,
the
you
know
just
t
dot
run.
This
is
what
we
expect
should
happen.
Wait.
It
should
look
very
similar
to
tests
you've
seen
throughout
kubernetes
repo
itself.
A
One
somewhat
weird
thing:
is
it
kind
of
structures
things
into
scenarios
this
matches
at
least
conceptually?
What
ingress
controller
conformance
is
doing
of
apply
or
create
a
bunch
of
resources
and
ingress
can
control
your
conformance.
It's
just
create
ingress,
but
in
this
case
it's
create
all
our
resources
and
then
describe
what
should
happen
right
describe
what
we
want
to
observe.
So
here's
our
opening
state
and
here's
what
we
want
to
observe
here,
given
whatever
controller
and
you
provide
a
controller.
A
So
this
is
the
really
high
level
idea
of
what
I
wanted
to
accomplish
here
in
the
simplest
way
possible
and
if
you
look
at
this
you'll
notice
that
this
is
not
exactly
ingress
controller
conformance,
which
is
where
I
started,
and
so
I
wanted
to
take
some
time
to
explain
my
reasoning
and
and
get
some
feedback
on
this.
I
know
there's
a
lot
to
take
in.
A
Look
at
what
ingress
controller
conformance
is
right
now
and
maybe
how
we
can
get
the
two
kind
of
approaches
to
converge,
because
I
did
spend
a
lot
of
time
working
on
ingress
controller
conformance
and
trying
to
get
that
to
where
I
thought
it
could
work
well
with
service
apis,
but
I
think
there's
still
enough
of
a
difference
that
it
made
sense
to
start
with
something
simpler
here.
First,
as
long
as
it
was
following
a
similar
pattern
and
could
easily
you
know
be
merged
back
together
in
the
future.
A
So
with
that,
let
me
take
a
step
back
and
look
at
ingress
controller
conformance.
This
is
also
a
relatively
recent
project.
Well,
the
current
state
of
it
is
relatively
recent.
It
started
with
some
rather
simple
structure
and
then
move
towards
a
structure
that
uses
godog
and
defines
features
and
tests
like
this.
So
here's
the
ingress.
I
want
to
apply
here's
what
I
expect
it
should
do.
A
That's
that's
the
whole
idea
behind
this
right,
so
really
straightforward,
but
and-
and
it
also
well
before
I
before
I
add
any
butts,
it
also
gives
you
some
really
cool
html
output,
and
I
would
love
to
recreate
this.
I
so
I
definitely
want
to
try
to
take
the
absolute
best
parts
of
this,
and
I
think
this
is.
This
is
a
great
one.
A
It
also
provides
a
github
action
that
you
can
use
so
install
your
your
cluster,
your
controller
in
a
cluster,
and
this
github
action
will
or
actually
I
think
you
just
provide
a
manifest
that
can
be
used
to
install
your
controller
and
then
this
github
action
will
do
the
rest
to
actually
run
conformance
tests,
which
I
think
is
quite
clever.
So
there's
a
lot
of
a
lot
of
good
work,
that's
happening
here
with
that
said,
I
think
there's
also
oh
well.
A
Okay,
one
more
thing-
and
I
think
mini
shift-
has
a
great
example
of
doing
tests
with
godog
very
well,
so
mini
shift
is
a
really
cool
tool
and
I
think
it's
seemingly
simple
enough,
where
the
tests
are
simple
enough,
that
it's
easy
to
understand
these
test
cases.
To
me
at
least.
A
What
I'm
concerned
about
with
service
apis
and
what
I
want
to
make
sure
we're
comfortable
with
is
service.
Apis
has
a
lot
of
complexity
and
that
complexity
may
be
hard
to
communicate
with
these
api
with
tests
quite
like
this,
and
even
with
ingress.
What
I
found
challenging
is
when
the
tests
fail,
it's
hard
to
understand
what
exactly
happened
and
there's
ways
and
I'm
working
on
ways
to
improve
this,
but
part
of
the
you
know
the
the
both
benefit
and
pain
of
an
abstraction
like
this
is
when
the
test
fails.
A
You
get
pointed
to
a
feature
file
and
then
you
need
to
figure
out
well,
okay,
so
I
know
that
feature
line
now.
How
do
I
figure
out
the
code?
That's
actually
pointing
to
that,
and
then
you
find
okay.
Well,
it's
this
is
the
function,
but
where
inside
that
function
and
etc
it
it
there's,
there's
not
the
same
kind
of
clear
relationship
between
a
test
failure
and
the
specific
line
it
failed
on
it
it'll
give
you
the
function,
but
that's
about
as
much
as
I've
been
able
to
get
out
of
it.
A
So
as
an
example,
here's
the
features
file.
Really.
You
know
when
I
send
x
to
y
here's
what
I
expect
back
and
here's
the
go
file
that
goes
along
with
it,
so
you
can
see.
Okay,
anything
that
matches
this
goes
to
this
function,
all
the
way
down,
so
you
can
say:
okay
and
a
new
random
name
space.
I
need
to
go
down
to
this
function.
A
That's
this!
So
something
in
here
failed
and
then
something
like
in
here
failed,
which
one
failed.
I'm
not
sure.
So
this
is
all
savable,
but
at
least
to
start.
My
hypothesis
is
that
we
can
start
with
something
a
little
bit
simple,
a
little
bit
simpler.
That
still
follows
the
same
pattern
and
leaves
room
to
kind
of
merge
the
two
approaches
together
in
the
future.
A
I
I
just
I
don't
know
so.
I've
spent
way
too
long.
I
don't
want
to.
I
don't
want
to
spend
much
more
time
talking
well
just
going
just
giving
this
intro
to
conformance
tests
and
where
my
mind
was,
but
that's
how
I
landed
here,
I
I'll
be
the
first
to
admit
this
is
very
basic,
very
simple
that
was
by
design.
A
It
may
be
too
simple,
but
I
just
wanted
to
get
some
some
broader
feedback
here
and
some
thoughts
on
conformance
tests
and
and
how
we
should
structure
this.
If
we
should
yeah
anyway
should
should
we
is
this
a
reasonable
first
step,
or
should
we
try
to
mirror
ingress
controller
conformance
a
little
bit
more
closely?
A
I
don't
know
I
am
very
open
to
feedback
on
this
one.
This
has
been
hard
to
to
really
get
to
a
good.
A
B
You
may
feel
the
pain
that
you
went
through
and
where
you
have
landed
I'll,
take
a
look
at
this
and
get
back
to
you
with
the
today
or
tomorrow,
I'm
liking.
What
I'm
seeing
right
now
in
a
very
brief
look
but
but
to
have
a
more
informed
feedback.
I
need
to
go
back
and
look,
but
this
seems
to
be
in
the
right
direction
to
me.
A
Thanks,
I
appreciate
that
feedback
and-
and
I
want
to
be
clear-
I'm
not
saying
we
should
just
dump
drop
everything
about
ingress
controller
conformance.
My
intent
here
is
to
build
something
that's
reasonably
close
enough,
that
we
can
still
use
all
the
same
tooling,
all
the
same
helpers-
I
you
know
ideally
have
the
same
kind
of
output
really
take
advantage
of
everything.
That's
done
so
well
there,
but
maybe
you
know
my.
A
My
hypothesis
is
that
service
apis
are
a
more
complex
thing
than
ingress
and
it
will
be
more
complex
to
test
and
the
pattern
that
was
used
for
ingress
may
not
work
as
well
when
it
comes
to
actually
writing
these
specific
tests,
and
so
I
just
you
know,
I'm
not
saying
a
wholehearted.
You
know
complete
shift
away
from
ingress
controller
conformance
just
this
very
top
level
of
how
we're
actually
writing
the
tests,
not
the
helpers,
not
everything
below
that.
Just
this
top
level,
maybe
can
be
done
just
in
a
more
traditional
way.
A
I
don't
know,
but
yeah
okay,
very,
very
open
to
feedback
on
this
again.
This
is
very
early
on
I'm
just
going
to
let
this
sit
for
a
little
bit.
I've
gotten
some
feedback
from
john
and
he's.
He
has
a
some
really
good
thoughts
on
how
we
could
potentially
test
this
and
integrate
this
with
the
other
projects.
So,
let's
say
so,
istio
is,
is
wanting
to
run
conformance
tests
against
our
api
and
they
already
have
their
own
test
framework.
A
That
already
has
you
know
a
cluster
spun
up
with
their
controller
in
it.
Can
we
somehow
integrate
that
and
make
that
part
of
their
go
test
suite?
A
A
So
if,
if
you
already
have
a
conformance
suite
or
a
test
suite
that
this
could
integrate
with
I'm
very
interested
in
ways
that
we
could
structure
this
too
to
fit
in
nicely.
C
Yeah,
I
know
contour
has
a
bunch
of
stuff
written
using
rego
if,
if
you're
into
rego
that
works,
I'm
still
trying
around.
D
C
I'm
still
trying
to
wrap
my
head
around
regular
to
me
it's
hard
to
follow
and
read,
but
it's
it's
kind
of
powerful
and
how
you
can
kind
of
conceptualize.
Some
of
that.
But
I
kind
of
like
what
you
have
here
better
better
than
what
we've
done
in
contour.
But
yeah.
A
Cool
yeah
now
I
I
have
a
limited
experience
enough
experience
to
have
written
one
policy
and
test
for
that
one
policy
and
it
it
has
a
learning
curve.
That's
for
sure,
but
yeah.
It
feels
like
endless
power
once
you
get
used
to
it,
but
it
takes
a
while
to
get
used
to
it.
Yeah
for
sure
yeah,
cool.
A
All
right
well
I'll,
leave
it
at
that
for
now
somehow
I'm
not
signed
in
here
cool,
anyways
and
yeah.
Just
a
reminder.
This
pr
exists-
and
I
just
you
know
I
I
felt
like
I
didn't.
I
didn't
do
well
enough-
communicating
that
I
wasn't
trying
to
drop
ingress
controller
conformance
entirely.
I
just
wanted
to
not
use
100
of
it
with
this
approach,
so
yeah
with
that,
I
will
move
on
to
pr
triage.
A
There's
been
a
few
pr's
that
have
come
in,
I
apparently
okay,
so
this,
I
think,
we'll
have
enough
time
to
go
through
all
of
these.
So
I'll
just
start
at
the
top.
A
James
discovered
this
as
the
first
person
to
write
apr
in
the
new
year.
Congratulations
and
what
he
found
is
100
of
our
co-gen
ended
up
switching
to
copyright
2021
because
that's
how
our
templating
works.
So
even
if
the
files
weren't
changing,
we
run
codegen.
And
what
do
you
know?
This
is
what
we
get.
A
A
A
I
am
very
used
to
you
know
having
a
year
here.
I
am
absolutely
not
a
lawyer.
I
don't
know
the
meaning
of
this
yeah
harry
you've
weighed
in
here
a
bit.
Do
you
have
any
any
suggestions
for
what
we
could
do
here
or
any
concerns.
A
I
I
so
I
that's
a
great
question,
so
I
came
to
that
conclusion
because
tests
were
failing,
that's
all
so
what
we
could
do
is
we
could
split
up
our
verifier
boilerplate
code.
So
if
we
go
to
this,
this
is
a
very
standard
file
right
and
it
just
goes
through
all
of
our
boilerplate
files
and
expects
them
to
have
the
appropriate
effects.
Go
files
to
match
go.you.
E
A
A
But
I
think
those
projects
all
started
that
way
and
it
feels
weird
to
go
from
having
a
year
explicitly
to
not
so
we
kind
of
started
with
a
weird
you
know
with
the
year,
and
I
I
don't
know.
B
I
see
so
the
thing
is,
the
tests
are
still
failing
on
the
pr
so.
D
B
So
I
I
have
to
we
have
to
go
back
and
read
that
dot
py
I
haven't
read
it
thoroughly,
but
I
think
if
we
remove
a
check
of
the
year
from
the
dot
from
the
python
file,
we
don't
need
to
remove
the
year
from
the
files
we
have
written
and
that.
B
B
A
Yeah
that
that
sounds
appropriate.
Let
me
let
me
dig
into
it
a
bit
further.
I
did
spend
some
time
looking
at
the
cogen
for
upstream
as
well
and
and
couldn't
figure
out
how
they
were
making
it
work,
but
you're,
probably
right.
It
is
something
like
something
like
we
can
change,
but
yeah
if
we,
if
we
can
at
least
remove
the
year
from
the
generated
files
and
get
tests
to
pass
that,
would
that
would
be
ideal.
A
One
of
those
things
I
thought:
oh
yeah.
This
will
be
really
easy
and
maybe
not
quite
but
I
I
just
filed
this
right
before
this
meeting.
So
I
haven't
had
time
to
to
dig
in
very
much
but
yeah
I'll
have
an
update
out
soon.
A
I
damian
you
have
a
simple
pr
that
ran
into
the
same
issue,
but
otherwise
I
think
it.
It
looks
good
yeah.
E
Well,
yeah
we'll
hold
it
until
this
boilerplate
year
thing
that's
addressed
yeah.
I
did
open
an
issue
that
it's
tied
to
this
pr
yeah.
You
know
this
pr
is
pretty
nearly
focused
on
a
specific
field,
but
I
do
believe
that
I've
seen
other
fields
that
have
the
same
issue.
E
I
didn't
want
to
go
ahead
and
make
sweeping
changes
without
at
least
making
sure
we're
all
on
board
with
this
change.
So
this
merges
I
go
back
and
address
the
other
fields
and
then
just
cross-reference.
This
yeah.
E
I
believe
there's
another
field
in
tls,
but
I
I
believe
it's
I
haven't
gone
through
all
of
the
apis
to
see
how
vast
this
issue
is.
Okay,
I
I
believe
that
it,
it
is
kind
of
goes
across
all
the
different
apis.
E
But
again
I
haven't
done
any
kind
of
audit.
I
just
I'm
working
on
the
implementation
side
of
things
hit
this,
and,
and
so
that's
really
what
prompted
me
to
to
look
at
this
issue
and
while
fixing
this
I
started,
I
think
there's
another
field
in
tls
that
caught
my
eye
on
how
we're
doing
the
defaulting,
and
so
that
really
prompted
me
to
say
you
know.
I
think
this
is
a
bigger
issue
than
just
this
particular
field.
A
Got
it
yeah?
It
would
even
be
great
to
it's
almost
like
this.
This
needs
tests
or
something
just
some.
You
know
in
upstream
we
have
tests
to
ensure
that
defaults
are
applied.
The
way
we'd
expect
it.
It
could
make
sense,
just
as
a
sanity
check,
to
make
sure
that
the
defaults
we've
defined
here
are
working
as
expected.
E
A
E
Because,
right
now
I
mean
we're
just
testing
to
say:
okay,
can
we
instantiate,
you
know,
install
the
crds
yeah.
B
E
Get
installed
and
and
can
we
instantiate
instances
of
those
crds
right?
We
don't
there's,
no,
like
here's.
What's
expected
of
the
the
customer
resource
to
look
like
you
know,
with
defaults.
A
E
A
Yeah,
so
on
that
note,
you
mentioned
implementation
and
it
seems,
like
a
number
of
people,
are
working
towards
implementations
here.
One
of
our
meetings
in
december,
we
kind
of
talked
a
little
bit
about
if
another
versioned
release
would
be
helpful,
not
a
v1,
alpha
2,
but
just
a
v0.2.
A
That
would
basically
be
a
point
that
implementations
could
target
that
included.
A
number
of
these
kind
of
bug
fixes
almost
instead
of
just
you
know,
pulling
from
master.
E
Now
and
I'd
like
to
work
on
a
release-
and
you
know
like
this
particular
instance-
would
be
a
bit
of
an
issue
from
the
implementation
side,
where
you
know
we're
expecting.
You
know
we're
not
checking
for
nil
on
mode
right,
we're
expecting
a
value
of
terminate
and
yeah.
This
would
cause
a
problem
on
the
implementation
side,
so
so
yeah
I
mean,
after
this
merges
again
I'd,
go
back
and
and
verify
all
the
other
fields
but
yeah
to
me.
A
Yeah-
and
I
know
we
have
at
least
one
one
fixed
in
that
that
has,
that
is
not
associated
with
the
release.
That
was
helpful,
helpful
for
k
native,
so
I
would
imagine
it
would
be.
It
would
be
good
to
get
something
out
soon-ish,
so
maybe
I'll
I'll
create
a
milestone,
for
I
don't
think
I've
done
one
yet
for
v0.2,
v0.2.o
and
maybe
in
the
next.
Maybe
we
can
say
sometime
in
january,
we'll
get
that
out.
A
I
don't
know
that
we're
at
a
point
where
we
need
to
say
a
specific
date.
Quite
yet,
but
we've
got
enough
small
little
fixes
that
it
could
be
useful
for
anyone,
and
I
think
we've
got
an
increasing
number
number
of
people
working
on
implementations
against
this
api-
that
a
more
recent
release
could
be
helpful.
E
Yeah,
I
think
so
cool
and
going
back
to
the
tests
that
you
mentioned
too.
So
would
that
be
something
that
conformance
tests?
Would,
I
guess,
not
conformance
testing
that
would
those
would
be
tests
that
are
really
outside
of
conformance
testing
to
ensure
that
the
defaults
are
being
set
properly.
A
Right
exactly,
I
think
it's
it
could
be
a
very
simple
test,
but
I
I
think
this
may
be
a
good
opportunity
to
again
use
kind
and
again
I
think
we
might
want
to
use
our
class.
I've
thought
about
the
structure
a
little
bit
yet
a
little
bit,
and
I
think
it's
relatively
simple
to
do.
Maybe
we
use
our
own
generated
client
to
accomplish
that.
I'm
not
sure
yeah,
but
I
it
should
be
doable.
E
I'm
testing
testing
this
to
ensure
that
defaults
are
being
set
to
what's
expected.
Let
me
look
at
that
and
see
how
it
could
potentially
be
ported
over
here.
A
Okay,
yeah
that'd
be
great
because
yeah
there's
definitely,
although
it
may
not
be
conformance
tests,
there's
a
lot
of
useful
code
in
that
conformance
test.
Work
like
you
know,
basically
go
code,
that's
interacting
with
these
apis
and
creating
resources
that
could
be
relevant
as
well
so
yeah.
That's.
That
would
be
a
good
area
to
make
some
progress
on
too.
I
guess
it
wouldn't
catch
this
specific
issue
because
we
didn't
have
a
default
set
at
all,
but
it
would
be
a
reasonable
way
of
listing
all
the
defaults.
A
We
expect
making
sure
they're
working
as
expected,
because
I
know
we've
had
some
cases
where,
let's
say
we
didn't
have
omit
empty
set
or
something
like
that,
and
our
defaulting
was
not
working
as
expected.
So
yeah.
E
And
I
actually
just
popped
it
in
the
chat
window
for
the
other
project
that
and
I'm
using
pretty
simple
and
verifying.
E
A
What
what
test
for
is
this
ginkgo?
No,
it's!
It's
been
a
while
since
I've
and
I'm
sorry,
it's
actually.
E
This
one,
that
kind
of
said
that
one
sets
up
the
test
environment
and
then
this
one's
actually
testing
an
instance
where
you
know.
E
A
I
know
there
had
been
some
bias
around
away
away
from
it
when
ingress
controller
can
form,
it
seems,
like
everyone
has
very
strong
opinions
on
test
spring
works
and
go.
I
don't
know.
Obviously
this
that
you
know
ginkgo
is
is
used
fairly
broadly
at
this
point,
I
I'm
one
who
I
guess
maybe
doesn't
have
the
strongest
preference,
but
I
would
like
to
to
have
some
consistency
in
whatever
frameworks
we're
using
and
wherever,
wherever
possible,
like
for
simple
tests.
A
I
I
enjoy
just
using
the
you
know,
straightforward
testing,
you
know,
go
testing
framework
but
yeah.
If
there's
enough
advantage
to
using
something
like
ginkgo,
I'm
not
necessarily
opposed
to
it.
A
We
just
we
need
to
be
consistent
throughout
our
projects,
so
we
don't
have
I'd
hate
to
get
into
a
world
where
we
have
go
dog,
go
test
and
and
ginkgo
in
the
same
project,
because.
E
Yeah,
should
we
file
a
separate
issue
on
this,
or
do
we
want
to
use
the
issue
that
I
filed
about
this
defaulting
not
happening
properly.
A
I
think
a
separate
issue
would
be
great
because
this
this
really
is
a
separate
project
of
actually
ensuring
that
the
defaults
we've
intended
are
actually
working.
E
I'll
follow
that
issue,
and
then
yeah
I
mean
it.
I
think
it's
something
that
we
need
to
make
a
decision
on
and
get
these
tests
written.
So,
like
I
said,
I'm
gonna
go
after
this
pr
gets
merged.
I'd,
go
back
and
kind
of
do
a
sweep
of
the
apis,
but
not
guaranteeing
that
I'm
not
going
to
miss
something
right.
A
Right
right
right,
but
it
is
helpful
by
writing
tests
like
this.
You
kind
of
get
this
single
place
where
you
see
all
the
defaults
you've
intended
and
if
yeah,
so
this
this
exercise
could
be
helpful
there
as
well
great
well
thanks
for
thanks
for
finding
that
and
and
already
getting
a
fix
out
for
it.
A
I
think
trying
to
close
my
many
tabs
now.
Let
me
run
back
through
some
more
prs
here.
Was
there
anything
else
to
say
on
this
tls
defaulting.
A
All
right
mark,
I
think
he
was
on
the
call
earlier
and
dropped
off,
but
he
has
this
pr.
A
That
adds
a
lot
of,
I
think
good
clarification
around
the
gateway
to
route
binding,
which
I
think
is
going
to
be
one
of
our
most
complex
and
powerful
features
of
this
api
and
as
I've
thought
about
conformance
tests,
I've
thought
and
a
lot
of
our
effort
is
going
to
have
to
go
into
this
relationship,
the
gateway
to
route
relationship
and
so
he's
taken.
A
A
Do
you
do
you
know
how
close
this
feels
to
being
ready
at.
B
C
B
This
is
sort
of
core
to
how
our
crds
interact
yeah,
so
yeah,
but
this
is
a
big
positive
change.
A
Okay,
great
that's
good
to
hear
yeah
I
mean
this
is
this
is
a
complex
area
and
it's
it's
good
to
see
it
written
out
and
and
well
defined
here
so
I'll
I'll,
try
and
follow
up
here
as
well
as
later
today,
so
I
can
yeah
so
I
so
we
can
get
another
set
of
eyes
on
it,
but
if
anyone
else
wants
to
take
a
look
at
that
this,
this
would
be
appreciated
as
well.
I
definitely
don't
need
to
be
a
project
maintainer
or
someone
who's
been.
A
You
know,
just
anyone
who's
interested
in
in
documentation.
Please
take
it.
Take
a
look
at
this.
If
part
of
this
doesn't
make
sense-
or
part
of
this
is
confusing,
it'd
be
good
to
know,
because
I
know
at
least
I
come
at
this
from
a
perspective
of
someone
who's
already
pretty
familiar
with
the
topic,
and
so
I
have
my
own
biases,
but
it
would
be
great
to
get
as
many
perspectives
as
possible
on
this
and
understand
if
we
still
have
some
confusing
points.
A
All
right,
this
is
another
tiny
pr
that
was
blocked
by
the
cogen
issues
the
year
in
cogen,
but
james
has
been
doing
some
really
good
work
on
this
tool
to
generate
crd
api
reference
docs,
which
we're
using
for
our
reference
docs.
He
forked
it.
So
we
could
get
some
cool
new
functionality
for
types
and
actually
showing
a
specific
subset
of
types
and
that
has
merged
back
into
upstream
and
so
he's
updating
the
reference
back
from
his
fork
to
amit's
original
upstream
fort,
well,
repo.
A
So
this
I
think
this
is
non-controversial
entirely.
We
just
need
to
wait
for
that
other
pr
to
get
in.
A
This
one
is
probably
a
bit
more
interesting
and
it's
caused
more
conversation
and
yes,
I
also
got
the
welcome
to
2021..
I,
as
I
recall,
with
this
goling
ci
lint.
The
rationale
was
that
we
wanted
to
be
able
to
exclude
specific
things
from
linting
and,
yes,
a
lot
more
control
over
false
positive.
A
I
yeah.
I
I
don't
know
I
need
to
think
about
this
a
little
bit
more
or
go
ahead.
B
Yeah,
so
this
is
that
this
was
specifically,
for
you
know
the
html
doc
that
we
generate
based
on
our
types.
So
we
have
like
something
like
tls
mode
terminate
is
equal
to
terminate
that's
a
constant
define
inside
our
package.
Now
tls
mode
terminate
needs
a
godoc
of
type
tls
mode
terminate
represents
the
terminate
mode
of
tlr.
B
A
Got
it
yeah
and
so
yeah?
I
remember
this.
Thank
you
for
the
reminder.
Yeah
I
mean
that
that
does
seem
like
a
relatively
reasonable
change.
A
As
long
as
we
I
one
of
the
things
I'd
push
back
on
in
the
past,
what
were
changes
to
go
comments
purely
for
to
ensure
that
the
reference
stocks
were
more
readable
but
in
turn
resulted
in
weird
syntax
inside
the
go
comments,
and
I
yeah
I
basically,
I
don't
want
to
harm
our
go
comments,
our
go
types
files
just
so
that
we
can
have
nicer
generated
html
for
our
reference
doc.
This
seems
that
this
specific
example
seems
like
a
very
reasonable
exception.
A
A
Admittedly
we
already
have
all
our
fun
annotations,
like
coup
builder
and
whatever
so
we've
already
kind
of
broken,
that
somewhat
yeah.
A
Okay,
well,
I
need
to
apparently
I
need
to
take
a
look
harry.
It
looks
like
you've
already
generally
approved
this,
and
this
is
also
a
221
blocking
pr
we're
blocked.
C
C
A
Cool
happy
new
year,
all
right
then
yeah.
I
remember
this.
James
has
taken
a
good
look
at
api
documentation,
and
this
is,
I
thought
there
was
a
broader.
A
Like
this,
that
feel
a
little
off
to
me
because,
like
this
is
a
link
that
works
in
the
generated
reference
dock,
but
is
potentially
nonsensical
inside
here
inside
go
types,
and
so
it
feels
like
ideally
we'd
have
a
better
way
to
detect
these
in
whatever
tool
we're
using
to
generate
the
docs
yeah
that
I
I'd
left
an
overarching
comment
on
the
pr,
but
I
have
not
added
it
to
each
specific
line
item
I
don't
know,
I'm
I'm
open,
I'm
open
to
ideas
here.
A
I
I
recognize
that
this
would
be
useful
for
reference
docs.
Does
anyone
feel
particularly
strongly
on
this.
B
The
ideal
scenario
would
be
that
godox
as
well
as
our
html
docs,
are
like
they
look
nice
and
you
know
they
have
all
the
good
user
experience,
but
we
need
to
to
settle
on
one
and
keep
that
perfect
in
case
you
know,
and
and
the
granularity
changes
like
kubernetes
apis
there's,
I
usually
resort
to
godox
of
cube
apis.
B
D
A
Yeah
you're
that
that's
a
good
point.
We
are
going
everything
we
put
into
these
comments
is
going
to
end
up
in
our
generated
crds,
including
this
markdown,
which
would
look
strange
that
that's
a
very
compelling
point,
and
it's
likely
already
in
this
pr
somewhere,
yeah.
D
I
really
didn't
think
I'm
not
sure
I've
talked
about
this
before,
but
godoc
is
it's
really
annoying?
How
the
godoc
goes
into
the
crd
and
your
go.
Doc
will
refer
to
kubernete,
we'll
refer
to
go
type
types
or
go
field
names
which
will
differ
from.
A
I
completely
agree
with
that
consistent
problem
that
we
run
into.
Maybe
maybe
this
is
actually
escaped
out
of
the
crd,
def
crd
yaml,
because
I'm
not
seeing
anything
like
that
I'll
have
to
take
a
closer
look,
but
certainly
if
that
had
happened,
that
would
be
a
significant
problem.
A
But
you're
right,
even
even
without
that,
the
unfortunate
casing
and
types.
A
All
right,
it
seems
like-
or
maybe
maybe
I'm
just
reading
too
much
into
this,
but
it
seems
like
it
would
be
ideal
if
we
can
find
a
way
to
find
an
alternative
to
markdown
links,
something
that
automatically
finds
keywords
and
links
to
them
would
be
awesome.
But
again
that
may
be
asking
too
much.
A
Basic
validation-
I
know
chris,
has
been
active
in
slack
and
this
pr
continues
to
evolve.
I've
added
a
few
comments
on
here
and
so
a
lot
of
other
people.
Thank
you
for
the
continued
review.
I
think
this
is
getting
reasonably
close.
It
sounded
like
today
he's
just
working
on
setting
up
certs
and
the
logic
is
mostly
there
so
excited
to
see
this
come
along
too.
We
have
a
couple
relatively
large
draft
prs
right
now
and
it's
exciting
to
see
this
one
get
pretty
close.
A
That
crack
this
okay,
this
one
is
breaking
because
is
indefinitely
on
hold
until
we
do
v1
alpha
2.
yeah
and
then
the
request
and
retry
attributes
is
really
as
we
start
to
transition
back.
I
think
once
we
start
to
have
a
bit
more
progress,
or
you
know
an
initial
web
hook,
that's
ready
and
maybe
some
initial
conformance
tests.
We
can
start
focusing
again
more
on
api
editions,
and
this
is
one
that
is
obviously
has
a
lot
of
history
here.
A
It
would
be
good
to
start
thinking
about
now
or
continue
thinking
about
where
this
belongs
in
the
api.
I
know
I
had
initially
said.
Well,
hey,
maybe
list
belongs
in
back
in
policy,
but
there
are
plenty
of
examples
of
where
these
kinds
of
config
could
also
make
sense
on
on
a
route
and
that's
what
this
pr
does
so
need
some
more
thought
here
on
where
it
could
be
both
resources,
but
that
that
is
something
like
that.
A
I
think
in
the
next
couple
weeks
we're
going
to
start
to
revisit
the
kind
of
api
editions
and
changes
we
want
to
see
in
the
new
year
as
we've
started
to
you
know,
we're
we're
getting
to
the
point
where
we
have
taken
on
kind
of
more
of
the
boring
grunt
work.
If
you
I
mean,
I
guess
it
all
depends
on
your
perspective,
but
you
know
starting
to
work
on
conformance
tests
and
web
hook
and
whatever,
and
once
we
start
to
have
that
foundation.
A
A
A
Any
anything
thank
you
damian
for
creating
that
the
latest
couple.
A
I
think
the
only
the
only
new
one
would
be
this
route.
Selector
improvement
issue
it
looks
like
mark
is
not
on
this
call.
A
A
Yeah,
okay,
yeah-
I
I
I
do
remember
this.
I
discussed
this
briefly
with
him.
The
idea
is
that
it,
it
feels
unnecessarily
risky
for
a
gateway
selector
to
select
everything
by
default,
everything
in
the
same
name,
space
by
default,
and
so,
if
we
require
the
field
to
be
set,
we
can
somewhat
get
around
that
this.
Is
you
know
a
service
with
an
empty
selector
by
default,
selects
nothing
and
relies
on
you
creating
your
custom
endpoints,
but
by
default
the
behavior,
it's
not
selecting
anything
and
so
a
gateway
with
an
empty
selector.
A
I,
the
empty
selector
thing
definitely
is
a
shortcut.
It
simplifies
the
simple
use
case,
but
maybe
that
value
is
too
limited
and
it
would
be
clearer
if
we
actually
required
the
field.
A
A
Does
anyone
does
anyone
want
to
leave
the
route
selector
optional
and
let
leave
that
behavior
in
of
a
empty
selector
matches
everything.
A
I
think
what
we
have
right
now.
I
can't
remember:
we've
gone
through
a
few
states,
but
I
think
we
may
actually
have
a
default
of
empty
and
or
okay.
I
think
it's
just
it's
not
it's
not
a
pointer,
so
there
is
no
nil,
so
the
default
is
empty
object
and
by
default
the
interpretation
of
a
selector
in
kubernetes
is
that
md
means
all.
C
D
No,
I'm
sorry,
I'm
I
miss
reading
this.
Okay
yeah,
you
have
a
selector,
you
can
have
a
selector
for
routes
or
you
can
have
a
selector
yeah
namespaces.
A
Well,
they
work
together,
so
you
select
routes
with
label
label
foo
and
those
are
in
in
any
matching
namespace,
and
so
by
default,
it's
the
same
namespace,
but
you
could
change
namespaces
to
be
for
all
namespaces
or
whatever,
but
in
most
cases
I'm
imagining
it'll
be
a
single
namespace.
E
The
core
issue
here
is
that
if
selector
is
unspecified,
then
by
default,
this
will
select
all
routes
from
the
same
name
space
as
a
gateway
right,
yeah,
that's
exactly
it!
So
it's
like
by
default.
We're
we're
open
right,
we're
saying:
okay,
let's
change
this
and
almost
like
by
default,
make
it
secure.
C
A
A
That
that
was
the
argument
initially,
but
as
I've
as
I've
thought
about
it
more,
I
I
am
more
in
favor
of,
although
it's
not
that
risky,
the
you
know
requiring
people
to
be
explicit,
because
some
people
do
have
fairly
large
name
spaces.
A
So
if,
let's
say
you
know,
they
deploy
everything
in
their
default
namespace,
for
whatever
reason
I
don't
know,
and
then
they
just
deploy
gateway
and
accidentally
expose.
I
mean
I'm,
I
don't
know
I'd
this
yeah,
it's
just
easier
to
accidentally
expose
things.
This
way.
A
That
people
who
care
about
security
wouldn't
do
a
lot
of
things,
but
that
doesn't
mean
that
we
shouldn't
have
same
defaults
like
people
who
care
about
security,
probably
aren't
using
defaults
for
many
cases
either.
But
yeah
and
yeah.
E
If
we
think
about
ease
of
use,
so
if
we
make
this
change,
then
from
an
easy
use,
standpoint
right,
because
there's
nothing
to
be
the
flip
side.
Where
it's.
You
know,
small
environments
that
want
to
make
it
easy
to
use
service
apis,
and
so
the
user
would
have
to
specify
a
selector
and
it
would
just
be
an
empty
selector
to
match
all
routes
in
the
same
name:
space
as
a
gateway.
A
What
he's
what
mark
is
suggesting,
if
I'm
understanding
this
issue
correctly,
is
that
you
simply
cannot
use
an
empty
selector
you
would,
you
would
have
to
use
labels,
you
would
have
to
specify
something
an
empty
selector
would
me
would
be
interpreted
as
matching
nothing.
A
And
the
the
argument
for
that
is
that
matches
service
behavior,
which
a
lot
of
people
are
going
to
be
familiar
with
here,
where
service
empty
selector
by
default,
doesn't
match
anything.
A
A
But
as
I've
thought
about
it
more,
especially
as
you
get
into
larger
name
spaces,
it
makes
it
more
likely
that
accidents
can
happen
and,
as
we've
learned
from
kubernetes
itself,
it's
a
whole
lot
harder
to
go.
You
know:
go
the
secure
default
route
after
you've
already
made
open
defaults,
it's
very
difficult
to
further
restrict
things
in
the
future.
E
Well,
if
that's
the
case
is,
is
there
other
areas
in
the
apis
that
we
should
then
consider,
because
I
can't
think
of
other
examples
at
the
top
in
the
head,
but
I
know
that
was
in
the
back
of
our
minds
of
like
okay,
how?
How
do
we
try
to
make
this
simple,
because
the
apis
are
already
fairly
complex,
so
yeah
we
make
this
change.
E
A
That
may
not
be
quite
as
secure
as
we'd
like
by
default,
but
again
like
like
you're,
alluding
to
there.
There
is
this
endless
balance
of
ease
of
use
and
secure
defaults,
and
it's
it's
hard
to
find
the
right
balance,
because
our
api
is
already
adding
a
fair
amount
of
complexity
on
top
of
ingress
or
any
any
other
api.
It
might
be
really
related
to.
A
Well,
if
you
have
thoughts,
I
know
where
we're
at
time
now,
but
if
you
have
any
follow-up
thoughts,
I
I'm
sure
mark
would
appreciate
comments
here
and
also
be
good
to
thinking
be
thinking
about
other
places.
We
are
maybe
leaving
our
defaults
a
little
too
open
or
too
secure,
and
you
know
where,
wherever
we
have,
that
balance
a
little
bit
off.
A
Yeah
cool
and
you
linked
one
more
pr.
E
Yeah,
I
just
want
to
go
back
to
this.
Where
did
we
leave
the
discussion
earlier
in
the
call
I
mean
is
this
something
that
we
need
to
get
talk
to
someone
illegal
and
what's
the
right
way
to
do
this,
or
are
we
fine
moving
forward
following
some
of
the
other
projects
by
removing
the
the
year
from
the
boiler
plate
and
generated.
A
I
feel
like
it'll,
be
a
lot
a
lot
cleaner,
a
lot
easier
to
make
that
decision.
If
we
can
do
what
harry
had
suggested,
find
a
way
to
remove
the
year
from
generated
code
only
and
retain
the
year
and
all
the
code
that
we've
actually
written.
That
feels
like
a
reasonable
compromise
in
what
we've
seen
in
other
upstream
projects.
A
A
Maybe
they
can
at
least
redirect
me,
but
first
I
want
to
see
if
I
can
get
to
that
I'd
closer
to
ideal
state
that
harry
had
kind
of
mentioned,
because
that
would
sim.
That
would
simplify
a
lot
and
if
I
can
I'll,
also
try
to
get
some,
you
know
confirmation
from
someone
and
contributes
or
or
any
recommended
sig
you
might
think
of,
but
I
think
that
pattern
is
pretty
widely
followed.
I
just
need
to
figure
out
how
to
do
it
all.
A
I
need
to
log
in,
but
I
will
do
that
or
if
you
want
to
hold
it,
if
you're
already
in
that'd
be
great
too.
A
I
I
switch
between
computers
for
my
zoom
calls
and
apparently
this
computer
hasn't
been
on
github
in
a
while,
so
yay
new
year.
A
Cool
all
right,
well
sounds
good,
I
think
that's
all
we
have
for
today
again,
I
would
really
love
feedback
on
a
lot
of
pr's,
but
especially
if
you
want
to
think
about
conformance
and
what
makes
sense
there
I'm
going
to
not
push
too
far
forward
for
a
few
days
on
this,
because
I
want
to
get
a
little
bit
more
feedback
on
direction
before
I
go
any
further
but
yeah.
A
So
if
anyone
has
time
to
to
look
through
that
and
look
through
other
approaches,
I
would
appreciate
any
feedback
you
have
and
with
that
happy
happy
wednesday
happy
new
year
and
we'll
talk
to
you
everyone
next
week.