►
From YouTube: Gateway API Office Hours 20201111
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
We
are
recording,
it
is
november.
11.
we've
got
lots
to
get
through
actually,
but
I
think
this
will
be
a
relatively
quick
meeting.
First,
I
wanted
to
go
through
our
v1
alpha
one
blockers
and
milestone
the
blockers
themselves
seem
very
limited.
Now,
thanks
to
everyone
for
getting
these
figured
out.
I
believe
these
two
are
closely
closely
related
and
when
harry's
pr
merges
here
we'll
have
gotten
all
of
our
blockers
taken
care
of,
and
this
one
feels
awfully
close.
A
I
haven't
looked
at
it
in
the
past
hour,
but
I
know
there
was
just
a
bit
of
feedback
left
from
danian
and
myself,
but
awfully
close,
I
think
so
yeah.
Thank
you.
Thank
you
harry.
This
is
awesome.
You've
done
some
great
work
to
make
these
stocks
a
thousand
times
better,
so
yeah.
Thank
you,
of
course,
all
right,
and
I
think
that's
all
that
actually
blocks
us.
So
I
I
can't
imagine
a
world
where
we
don't
release
an
alpha
a
week
from
today,
if
not
sooner
with.
A
A
I
think
I
think
you
messaged
me
just
before
this.
You
had
a
bit
more.
You
wanted
to
talk
about
on
this
pr.
B
Yeah
thanks
rob.
I
I
just
dropped
in
the
chat,
a
link
to
the
and
really,
I
guess
harry.
I
wanted
to
make
sure
we
were
on
the
same
page.
It
seemed
like
we
had
not
reach
an
agreement
on
the
conflict
resolution
yep.
That's
it
right.
There
perfect.
B
So
I
guess
I
just
wasn't
sure
what
we
wanted
to
use
if
we
weren't
going
to
use
this
tie
breaking
semantic
that
this
specific
being
the
the
route
timestamp.
You
know,
like
order
of
add.
C
Yeah
so
b.
So
this
came
up
before
as
well,
and
if
this.
B
Yeah
sorry,
I
actually
made
a
mistake
on
my
patches
here,
so
it's
like
coming
in
two
different
ones,
so
in
the
future,
that'll
be
cleaner,
but
thanks
for.
C
Yeah,
so
we
discussed,
you
know
it's
if
you
have
to
actually
implement,
like
you
know,
time
stamp
based
collision,
I'm
not
sure
how
one
would
implement
that
like
like,
if
you
know
like
two
routes,
are
exactly
the
same
or
you
can.
You
know
have
some
collision
detection
algorithm
which
tells
you
they
are
same.
C
Then
you
can
do
you
know
based
on
timestamp
or
based
on
you
know,
namespace
plus
name
combination
names
and
you
know
whatever
ordering
we
want,
but
once
you
configure
these
things
inside
a
proxy
or
inside
any
implementation,
it's
not
possible
to
you
know,
figure
out
which
one
takes
priority
right.
I
guess.
B
Well,
I
I
guess
I
was
just
going
to
say
I
was
thinking
that
the
control
plane
would
be
making
that
decision,
not
necessarily
like
the
data
plane
aspect
not
to
get
too
implementation
specific,
but
the
way
I
read
it
at
least
was
that
the
tie
breaking
semantics
were
for
the
purpose
of
driving
the
controller's
rights
down
into
the
data
plane,
not
necessarily
that
the
data
plane
would
be
responsible
for
implementing
those
timestamps
on
inside.
A
Yeah
that
matched
my
expectation
as
well
and-
and
I
think
this
this
kind
of
sounded
like
what
you
were
saying
as
well
harry
that
that,
in
the
controller
itself,
you
could
detect
these
kind
of
collisions
and
control
what
you
actually
wrote
or
configured
on
the
data
plane.
C
Yeah,
in
that
case,
yeah
this
that
can
work
it's.
It
gets
tricky
with
the
path-based
matching
right
and
path,
prefix
based
matching.
Where
I
mean
it's
f,
it's
technically
possible
it's,
but
it's
not
something
that
everyone
always
implements
so
other.
If,
if
that's
the
case,
I
think
we
should
just
clarify
that
part,
and
then
we
can
add
this,
but
we
should.
We
probably
need
to
add
that
part
to.
C
A
So
assuming
that's
a
host
name
specified
on
http
route.
I
guess
that's
all
very
possible
within
the
controller
you
you
can
dedupe
on
host.
Well,
you
can
kind
of
do
merging.
I
don't
know
what
what
the
appropriate
term
is
there,
but
you
can
write
logic,
although
it
may
be
complex
to
to
get
it
completely
right.
B
A
Yeah
great,
it
would
be
awesome
to
have
this
in
as
part
of
v1
alpha
one.
I
think
this
if
I
run
back
to
our
actual
milestone,
if
I
can
find
it
yeah
whatever.
A
I
think
that
may
be
the
last
one
left,
and
even
in
our
nice
to
have
list
that
could
potentially
no,
I
guess
this
one
would
yeah
I
I
guess
these
all
could
potentially
result
in
small
changes
within
the
goat,
the
types
file,
so
these
are
not
just
documentation
related
yeah,
okay.
A
So
if,
if
anyone
does
want
to
volunteer
on
these,
just
feel
free
to
assign
yourself,
it
would
be
great
to
get
some
of
these
knocked
out,
especially,
you
know
as
we're
trying
to
limit
any
potential
changes
to
go
types
after
everyone
alpha
one
launch.
Getting
some
of
these
nice
to
haves
in
in
the
next
week
would
be
great
and
obviously
documentation.
We
can
continue
to
add
and
improve
as
we
go.
A
Cool
all
right
that
is
all
we
had
on
the
block
is
a
milestone,
and
I
think
that
leads
us
into
danny
and
you
had
a
question
around
conformance
test
and
what
exactly
that's
going
to
look
like.
D
Yeah,
you
know
it
hasn't
been
something
that
we've
discussed
in
in
quite
some
time
and
as
we
start
planning
through
the
implementation,
things
like
tests
and
ci,
and
all
that
stuff
kind
of
came
up
as
a
discussion
topic,
and
that
brought
me
back
to
this,
and
so
I
just
wanted
to
kind
of
bring
it
up
again
and
kind
of
see.
Where
does
this
lie
and
her
list
of
priorities?
And
you
know
what
are
some
of
the
actionable
steps
that
we
can
potentially
outline?
So
maybe
we
could
start
to
move
forward
in
this
area.
E
Yeah
they're
critically
important,
I
think
after
we
cut
v1
alpha
one.
It
is
an
interesting
repo
that
exists
today
already
for
the
conformance.
There
are
some
good
things
about
it.
There's
some
kind
of
little
bit,
fiddly
thing
things
about
it,
but
one
nice
thing
is
that
the
current
approach
in
the
ingress
controller
conformance
includes
a
cucumber
like
description
of
the
behavior,
which
I,
if
I
found
to
be
pretty
nice,
if
we
can
lay
it
out
like
this.
D
And
so
would
the
conformance
test
live
in
service
apis
or
similar
to
this
ingress
controller
conformance?
It
would
be
a
separate
repo.
E
D
D
And
so
in
this
area
I
mean,
should
we
just
if,
if
someone
starts
to
move
forward
with
this,
you
know,
would
this
person
just
kind
of
look
at
the
ingress
controller,
conformance
and
kind
of
use
that
as
a
reference
model
for
creating
a
conformance
test
for
service
apis.
E
D
That
this
thing
is
that
conformance
test.
I
feel
the
same
as
bowie
that
the
conformance
tests
are
critical
after
v1
alpha
one
rob
and
others.
If
you
feel
the
same,
should
we
go
ahead
and
tag
this,
as
I
forget
what
that
tag
is
soon
to
be,
or
you
know,
I
forget
the
name
of
the
tag
that
we're
using
for
something
that
we
should
work
on
here
in
the
near
future.
A
Yeah
we
could,
we
could
potentially
give
this
a
priority.
At
least
I
don't
know
how
which
milestone
to
attach
this
to,
but,
like
you
say,
this
is
probably
important
soon.
A
But
I
don't
know
that
it
necessarily
belongs
like
this
is
something
that
we
probably
won't
start
in
very
serious
work
until
v1
alpha
1
actually
launches
right,
but
it
is
kind
of
the
very
very
high
on
the
list
after
v1
alpha
1
launches.
I
think
in
my
mind,
our
our
highest
priorities
after
wednesday,
after
that
launch,
are
going
to
be
improving
documentation,
getting
feedback
and
writing
conformance
tests.
A
So
in
no
particular
order-
and
I
I
think
that,
given
that
I
you
know
I've
I've
personally
set
aside-
I
think-
probably
a
couple
weeks
or
maybe
a
bit
more
to
to
actually
spend
work,
trying
to
help
and
contribute
to
conformance
testing
and
the
in
the
next
couple
months.
So
that
that's
definitely
something
I
want
to
help
out
with
as
well
and-
and
I
appreciate
you
bringing
this
up
because
I
think
this
really
does
need
to
be.
You
know
top
of
mind
as
we're
going
forward.
A
A
On
the
other
hand,
I
can
see
some
kind
of
value,
especially
if
we're
going
to
try
and
use
a
similar
pattern
to
trying
to
help
out
the
the
people
working
on
ingress
controller
conformance.
It
does
seem
like
there
would
be
some
level
of
overlap,
and
I
can
imagine
some.
Maybe
this
is
too
far
of
a
stretch,
but
I
can
imagine
these
same
implementations
might
be
conformed
with
both
the
ingress
api
and
service
apis.
A
At
some
point,
we
can
always
rename
the
repo
right.
That's
not
the
major
blocker.
So
is
this.
Is
this
the
kind
of
thing
where
it
would
be
distracting
to
have
all
those
tests
in
the
same
place?
I
don't
think
so.
Okay,
so
do
we
have
a
strong
preference,
then,
as
far
as
keeping
our
own
conformance
tests
within
this
repo
or
starting
work
or
starting,
to
contribute
to
the
conformance
repo.
E
It's
mostly
will
this
get
confusing
for
people
kind
of
question,
you'll
end
up
having
to
vendor
things
back
and
forth,
which
might
be
kind
of
annoying.
B
What's
the
current,
I
guess
I'm
confused
by
this
ingross
controller
conformance
point
to
begin
with,
like
they're,
not
in
the
pattern,
that's
being
used
by
like
the
service
v1
and
like
network
policy
performance
tests.
Is
that
the
issue?
B
E
This
is
like
a
it's
like
a
trial
to
see
if
you
can,
click
through
actually
rob
if
you're
sharing
your
screen,
like
you,
can
click
through
to
see
it's
not
under
test.
It's
under
features.
E
So
like
this
is
what
the
test
actually
looks
like,
which
is
kind
of
nice.
I
wouldn't
say
that
the
existing
kubernetes
conformance
suites
are
all
together
that
friendly
and
we
did
discuss
this
with
the
sig
arch
conformance
group
and
basically
they
came.
We
were
asking
like
hey.
Is
there
a
recommendation
for
doing
this,
like
you
should
be
doing
some
using
some
blessed
framework
and
the
basic
feedback
was
that
the
existing
framework
which
is
based
on
ginkgo,
is
not
like.
E
People
aren't
super
happy
with
it,
and
the
other
thing
was
that
they
actually
came
to
the
conclusion.
They
wouldn't
be
a
very
opinionated
about
the
framework
to
be
used,
and
then
there
was
some
pointing
to
the
bdd
style
framework
for
the
ingross
conformance.
E
I
don't
know
if
that
answers
your
question,
but
that's
why
this
thing
exists
and
sort
of
uses
a
bdd
style
way
to
test
things.
B
That's
perfect,
and
I
guess
just
for
clarity.
The
repository
and
contribution
activity
that
rob
was
asking
about
is
on
this
repo
we're
looking
at
here
like
alongside
these
folks.
A
Yeah,
it
would
be,
it
would
be
basically
if
we
should
contribute
our
conformance
tests
here
or
if
we
should
keep
them
and
work
on
them
inside
our
own
service.
Apis
repo.
E
I
think
someone
just
needs
to
go
and
scope
it
out
because,
as
I
was
saying
before
like
if
we
had
the
actual
test
here,
then
we
would
have
to
vendor
from
service
apis.
Every
time
a
change
happens
into
here
versus
vendoring,
the
framework
from
here
into
service
apis,
like
which
one
is
more
stable
versus
less
stable,
yep.
A
Yeah,
I
mean
to
me,
it
seems
like
it,
it
may
end
up
being
and
and
this
this
needs
more
research,
but
it
may
end
up
being
simplest
to
use
this
pattern,
but
keep
it
in
our
own
repo
and
investigate
as
our
as
our
api
stabilizes.
We
can
investigate
merging
these
together,
but
I
I
don't
know
that
that's
just
my
my
first
guess,
but
maybe
if
anyone
does
want
to
to
dig
a
little
deeper
into
exactly
how
this
these
might
integrate.
That
could
be
valuable
as
well.
B
C
B
Feeling
so
far,
just
gotta
like
find
out
more
yeah
have
an
opinion
yeah.
But
thanks
for
the
explanation,
that's
helpful.
A
Yeah
and-
and
I
think
one
other
little
detail
like
the
reason
these
tests
aren't
in
upstream
they're,
not
in
case
slash,
k
is
because
obviously
controllers
and
like
this.
This
is
conformance
testing
for
the
controllers
and
we
actually
have
ingress
conformance
tests
in
upstream,
but
they're
really
really
basic.
A
It's
just
does
the
api
server
allow
creation
deletion
etc
of
an
ingress
resource
or
ingress
class,
or
you
know,
and
these
very
basic
things,
but
these
tests
are
focused
more
on
the
implementation
of
the
api,
which
is
similar
in
concept
to
what
we'd
be
doing
with
service
apis
as
well
we'd
be
focusing
on
implementations
of
the
api,
which
is
a
strange
detail.
A
We
have
like
multiple
levels
of
conformance
in
kubernetes
or
in
this
ecosystem,
but
that's
so
so
there
is
definitely
some
overlap
with
what
this
is
doing
and
what
we're
trying
to
thinking
about
doing
here.
I
think,
but
whether
or
not
that
means
they
all
belong
in
the
same
repository,
I'm
not
sure.
A
Okay,
I'll
keep
on
moving
here
it
looks
like
damian
yeah.
I
moved
your
other
thing
up,
because
this
looks
like
it's
a
highly
worthwhile.
I
don't
know
links
to
comments
and
docs.
Don't
always
work
very
well.
Okay,
it
did
work
great
yeah,
go
ahead.
Dania.
You
probably
have
more
videos.
D
Yeah
and
if
you
could
pull
up
the
chat
window
and
click
on
the
link
that
I
just
gave
you,
because
this
is
really
the
kind
of
background
of
the
issue
that
that
I'm
getting
feedback
on
internally
from
people,
including
clayton
coleman.
You
see
his
name
there,
and
so
you
know
when,
when
we
created
the
route
api,
we
made
the
conscious
decision
to
represent
the
tls
assets
within
the
tls
config
of
the
route,
because
the
concern
is
giving
access
to
controllers
to
be
able
to
read
secrets
across
all
name
spaces.
D
There's
a
lot
of
concerns
there
with
that,
and
so
I'm
getting
that
same
kind
of
feedback
again
with
the
latest
review
the
api
review
that
I
shared
that
document
internally
within
red
hat.
D
So
I
just
wanted
to
kind
of
bubble
that
back
up
to
the
team
and
see
if
it's
worth
discussing
it
again
or
you
know
what
kind
of
just
what
people's
thoughts
are.
A
How
do
you
do
you
have
any
way
of
limiting,
since
in
in
a
world
where
you
allow
for
cross
namespace
certificate
references?
How
do
you
define
which
gateway
or
which
resource
can
use
those
certificates.
A
Trying
to
understand
your
question
so
so
I
I
think-
and
I
may
be
misunderstanding
this,
but
it
sounds
like
what
you're
describing
is:
there's
a
desire
for
organizations
to
drop
all
certificates
into
a
single,
more
secure,
namespace
and
then
have
their
resources
reference.
Those
certificates
not
necessarily.
D
Okay,
I
mean
the
so
what
we
do
with
with
http
route,
and
I
think,
maybe
with
some
of
the
other
apis-
is
right.
We've
got
this
certificate
reference
so
that
you
know
the
certificate
materials
aren't
part
of
the
http
route,
and
so
you
know
they
will
most
likely
reside
in
a
secret
that
could
be
in
the
same
name
space,
but
because
these
routes
can
be
across
different
name
spaces.
D
Essentially,
you
know
the
controller,
that's
you
know,
reconciling
all
these
routes
needs
to
be
able
to
have
read
access
of
secrets
across
all
the
name
spaces,
and
that's
where
the
concern
is
right
is
giving
controller
the
ability
to
read
secrets
across
all
the
different
name
spaces,
and
you
know
I
provided
feedback
of
okay.
You
know
here's
some
some
potential
workarounds,
you
know
like
with
the
route
bindings,
you
know,
create
a
gateway
that
only
allows
routes
in
the
same
name,
space
to
bind.
Therefore,
secrets
will
be
in
the
same
name.
D
Space
and
the
controller
would
be
configured
to
only
you
know,
read
secrets
from
that
name
space,
but
then
you,
you
know
that
becomes
pretty
limiting
and
there
is
discussion
around
you
know
the
using
a
web
hook
and
then
there's
concerns
of
scale
about
web
hooks
all
this
kind
of
stuff,
and
so
I.
A
E
B
F
D
D
D
C
A
So
if
we
add
a
namespace
to
certificateref
as
an
example
that
opens
up
another
potential
security
concern,
which
is
that
you
need
to
be
able
to
control,
you
probably
don't
want
a
gateway
and
namespace
y
to
be
able
to
grab
a
secret
from
any
other
namespace.
A
You
might
want
to
have
some
limitations
on
what
certificates
they
can
use
in
some
cases.
Maybe
not
this
specific
case.
E
Yeah
but
then
then
that
means
that
people
can
put
into
that
namespace
and
then
they
can
override
other
people's
secrets.
It
just
feels,
like
secrets,
might
be
broken
fundamentally,
if
we
think
about
this
model
because,
like
the
other
aspects,
I
guess
of
secrets
is,
is
there's
some
kind
of
redaction.
You
can't
just
like
grab
it
out
of
the
config.
D
You
know,
I
think
it's
just
a
certain
customer
base,
that
is,
you
know,
very
security,
conscious
and,
and
so
when
it
comes
to
secrets,
it's
like
how
can
we
reduce
that
exposure
as
much
as
possible.
E
B
Api
level,
though
I
mean
to
me,
it
seems
like,
in
certain
cases
I've
seen
where
customers
have
had
like
isolation
concerns
and
they
run
a
dedicated
controller
hardware,
whatever
it
might
be,
and
I'm
curious
and
sorry
I
might
kind
of
cut
you
off
but
curious
if
any
of
those
types
of
workers
came
up,
meaning
like
theoretically.
G
B
D
Yeah
and
that's
that's
consistent
with,
like
the
first
piece
of
feedback
that
I
provided
of,
saying
hey,
you
know
lock
the
gateway
down
to
a
particular
name.
Space
only
allow
routes
of
the
same
name
space
and
then
now
you're,
just
having
multiple
controllers,
one
per
name,
space
that
you
want
this
functionality
in
and
so
that's
an
option,
but
obviously
well
it's
not
necessarily
it
didn't
go
over
well,
it's
just.
You
know
when
you
come
from
the
world
that
we
see
here
where
it's
like.
D
Okay,
you
know
we
just
have
that
in
the
route
itself.
You
know
it's.
It's
just
the
perspective
that
clayton
and
others
that
have
an
interest
in
what
we're
doing
yeah,
it's
just
their
perspective
of
things,
and
so
you
know
locking
it
down
for
a
name
space,
running
controller
pronations.
That
could
be
the
workaround.
D
I
just
you
know.
I
want
to
just
bring
it
up
for
discussion
and.
E
Like,
for
example,
I
know
like
going
through
security
evaluations,
we
treat
secrets
separately
and
if
you
have
to
deal
with
them
or
copy
them
around,
then
that's
like
a
you
know
of
itself
like
a
different
level
of
scrutiny.
E
C
D
C
The
no
so
you
you
can
you
configure
tls
on
listeners
inside
the
gateway
resource
right,
so
you
have
a
special
name
space
in
which
you
put
the
gateway
on
all
the
tls
secrets.
You
know
certificate
and
private
keys
in
a
specific
name
space,
and
then
you
configure
the
gateway
to
target
the
namespaces.
You
want
it
to
right,
and
now
all
of
your
secrets
are
present
in
that
specific
name.
Space
right
so
and
the
controller
can
have
only
read
access
to
secrets
on
the
name
space
in
which
the
gateway
resource
exists.
C
E
F
F
F
C
C
C
So
so
going
back.
Danian
is
there.
Is
that
an
a
workaround
that
you
explored
when
you're
discussing
internally
at
red
hat.
C
And
I
do
acknowledge
that
you
know
there's
a
limitation
where
now
you
can't
have
dls
config
on
on
the
route
resource,
but
I
think
it's
a
good
limitation,
especially
in
this
model.
If
you
have
you
know
your
security
conscious,
so
have
self-service,
enabled
right.
In
that
case,
you
know
having
tears
configured
gateway
in
a
single
name.
Space
is
probably
the
best
for
you
right,
like
auditing,
also
becomes
easier
for
the
customer.
D
You
know
it
seems
like
a
reasonable
work
around
and
I
think
you
know
security.
Sensitive
users
are
accustomed
to
having
to
jump
through.
You
know
an
extra
hoop
or
two.
You
know
they
just
it's
just
accepted.
As
for
the
additional
security
and
so
yeah,
I
appreciate
that
that
feedback
and.
B
B
Interesting
use
case,
it
almost
helps
you
to
like
group
infra
admins
too,
almost
as
like
a
consequence.
You
know
with
that
special
access.
A
Yeah,
that
makes
sense.
I
I
missed.
I
missed
this.
I
don't
think
there's
an
issue
quite
yet
for
this
one
damian,
do
you
mind
raising
an
issue
just
so
we
don't
lose
track
of
of
this
comment.
D
E
F
E
F
Yeah-
and
I
think
that
that
leads
into
one
of
the
ideas
that's
been
discussed
in
this
issue,
which
is
to
have
a
controller
that
just
synchronizes
secrets
from
that
has
access
to
read
secrets
anywhere
in
the
cluster
and
synchronizes
them
to
some
name
space
that
the
gateway
controller
could
then
use.
So
you
have
privilege
separation.
F
E
Object,
I
see
and
the
route
objects
are
privileged
objects.
My
concern
is
like,
if
you
start
having
secret
material
in
multiple
api
resources,
then
they
all
end
up
in
the
same
category
as
secrets
which
need
to
be
closely
guarded
and
you
shouldn't
watch
across
namespaces
or
have
permission
to
read
and
at
that
point
it's
like
you
didn't.
You
just
kicked
the
problem
up.
One.
F
Level
there
are
several
problems
that
it
does
solve,
though
I
mean
it's,
I
I
suppose
they're
shortcomings,
but
it
does
mean
you're
not
granting
your
ingress
controller
access
to
unrelated
secrets
that
aren't
related
to
ingress,
and
it
means
you
have
all
your
ingress
related
certificates,
they're
in
a
specific
resource.
F
A
F
Right
that
is
a
use
case.
We
don't
handle
very
well
with
the
route
api
in
openshift
and
that's
one
advantage
of
this
separation.
You
have
with
service
apis
where
you
have
the
gateway
which
can
fdls
config
or
you
can
allow
specifying
that
tls
config
on
the
http
http
route
and
choose
when
you
create
the
gateway,
whether
or
not
you'll
allow
that
sort
of
route-specific
tls,
config,
so
service.
B
F
Has
a
nice
solution
to
that
to
a
nice
answer
to
both
of
those
use.
A
Very
interesting,
okay!
Well,
I
I
want
to
make
sure
we
have
time
for
some
of
the
the
last
things
on
our
agenda,
but
I
I'm
definitely
interested
in
in
further
discussion
on
this.
If,
if
you
happen
to
get
any
more
internal
feedback,
it
would
be
really
helpful
to
to
see
what
that
looks
like
and
maybe
an
issue
here
on
this
repo
just
so
we
can
continue
to
discuss.
D
A
Great
thanks
all
right
keep
on
moving
here.
At
this
point,
I
wanted
to
just
make
sure
we
were
on
the
same
path
for
v1
alpha
1
launch.
We
have
set
a
date
which
is
seven
days
away
now.
I
that
would
be
launched
no
later
than
v
one
alpha
one.
A
So
I
wanted
to
make
sure
that
everyone
here
was,
you
know
agreeing
with
one
the
date,
but
also
the
process
involved
and
right
now
this
process
is
very
manual
and
there's
certainly
lots
of
room
for
improvement,
but
the
process
I've
used
for
the
two
rc's
before
this
is
to
submit
a
change
log
pr
wait
for
approval
once
that's
merged,
take
that
commit
with
v0.1.0
and
launch
a
github
release.
A
Based
on
that,
I
I
think
that's
a
reasonable
approach,
but
I
wanted
to
see
if
we
wanted
to
formalize
who
exactly
needs
to
approve
this.
Do
we
want
so?
Let's
say
I
make
a
pr
or
anyway
do
we
want
more
than
one
other
maintainer
to
approve
it?
Do
we
want
a
larger
consensus
than
that,
because
it's
kind
of
a
release
triggering
pr
or
commit,
or
are
we
comfortable
with
one
other
approved
right?
A
I
I
think
I
am
kind
of
leaning
towards
that.
It's
not
a
particularly
you
know.
Obviously,
if
I
had
the
changelog
pr
queued
up-
and
it
was
generally
agreed
upon
in
time
for
office
hours
next
week,
I
think
it
would
be
relatively
straightforward
to
just
launch
a
release
based
on
that
and
and
do
it
all
live,
have
a
v1
alpha,
1
launch
party
and
and.
A
Okay
and
we
can,
we
can
make
all
our
mistakes
live
together.
Yes,
yeah,
okay,
I'll
plan
on
that,
then
I'll
try
and
have
a
pr
ready
no
later
than
tuesday,
then
with
the
change
log
and
if
others
are
able
to
to
make
any
comments
or
feedback
by
then
that
would
be
ideal.
So
I'm
not
also
editing
that
pr
live
as
we
go,
but
otherwise
I
yeah,
I
think,
it'd
be
fun
to
actually
launch
that
live
during
office
hours,
so
cool
all
right.
A
A
You
know
good
feedback
from
one
of
the
maintainers
on
that
side,
but
they're
still
trying
to
figure
out
how,
where
this
might
fit
in
which
I
think
is
very
reasonable.
I
can.
I
can
follow
up
with
them,
but
I
I
don't
want
to
rush
them
to
figuring
this
out
they.
You
know
this
is
a
relatively
new
project,
anyways,
the
gatekeeper
library
and
so
they're
they're,
trying
to
figure
out
where
you
know.
Examples
like
this
actually
belong
in
the
meantime,
I'm
curious
what
we
want
to
do
with
that.
A
There's
nothing
that
says
that
we
have
to
have
any
kind
of
example
like
this
in
our
own
repository,
we
could
simply
add
as
a
stop
gap
link
to
this
pr
in
our
documentation,
or
we
could
actually
hoist
everything
from
this
pr
and
add
it
locally
into
our
our
own
repo
and
maintain
it
ourselves.
A
D
A
Yeah,
I
agree
with
that.
It
doesn't.
You
know
it
sounds
like
they're
very
open
to
fitting
this
into
their
repository.
So
even
if
we
did
move
it
into
our
our
repo,
it
would
be
a
short
term
thing.
I
think
so
as
long
as
we're
fine
with
you
know
linking
to
a
pr
in
our
docs,
which
I
think
seems
reasonable
enough
at
this
stage,
I
will
I'll
make
a
pr
to
update
our
docs
just
to
reference
this,
for
the
time
being,.
A
I
I
imagine
I'll
take
them
a
bit
to
figure
out
exactly
how
this
fits,
but
they
seem
open
to
it
so
cool
the
next
one
is
is
more
of
just
a
you
know,
just
keeping
up
with
things
we,
we
probably
have
more
meetings
than
we
need
at
this
point,
we're
doing
two
meetings
a
week
and
I
think
we're
at
a
point
at
least
once
we
hit
this
v1
alpha
one
phase
and
especially
as
we
start
to
move
into
holidays,
where
we
can
probably
bump
our
meeting
cadence
down.
A
I'm
thinking,
probably
once
a
week
is
probably
sufficient
going
forward
at
least
post
v1
alpha
one,
but
with
with
that
said,
I
wanted
to
check
with
the
group
here.
Is
there
a
well
first?
I
should
ask:
are
we
fine
with
going
down
to
a
single
weekly
meeting,
and
if
so,
do
we
have
a
preference
on
time?
You
know
of
the
times
we're
currently
have
having
meetings?
Is
there
one?
That's
especially
bad.
A
Yeah
I
will
but,
but
I
want
to
be
inclusive
of
of
the
people
here
too,
and
make
sure
that
we're
not
choosing
a
time.
That's
going
to
inconvenience
any
of
the
maintainers
that
are
already
contributing.
D
Yeah
I
mean
at
times
work
fine
for
me
and
I'm
flexible,
and
but
I
do
agree
that
we're
at
a
state
to
kind
of
cut
back
to
once
a
week
and
then
we
can
readdress
the
topic
if
we
feel
like
after
the
holidays,
maybe
into
the
spring
that
it's
like.
Okay,
you
know
we
feel
like.
We
need
to
ramp
up
again
but
yeah.
Otherwise
the
times
are
flexible
and.
A
Everything
else
yeah.
I
agree
that
I
I
can
see
us
wanting
to
ramp
back
up
as
we
start
to
push
towards
v1,
alpha,
2
or
v1
beta
or
whatever
our
next
api
releases,
I'm
not
sure,
but
yeah.
I
think
for
now,
a
once
weekly
bumping
down
to
once
weekly
after
we
release
is
probably
reasonable.
A
I'll
think
a
bit
more
about
exactly
how
I
I
ask
people
on
sig
network.
I
know
there's
a
variety
of
different
tools
out
there
that
allow
you
to
kind
of
mark
which
times
you're
actually
available
or
vote
on
times.
So
I
might
try
and
do
something
like
that
and
send
it
out
to
sig
network,
but
need
to
do
a
little
bit
more
research,
yeah,
any
anything
else
to
say
on
meeting
times
all
right.
Let
me
keep
on
going.
Then
it
looks
like
we
have
one
pr
that
needs.
A
A
A
I
I
think
these
are
reasonable
starting
points.
I
tried
to
look
briefly
for
any
other
common
resources
that
might
collide
with
these,
and
I
couldn't
find
any
that
doesn't
mean
they
don't
exist.
A
D
C
Yeah,
I
think
yeah.
I
think
there
are
at
least
I
don't
remember.
There
are
resources
which
have
multiple
common
short
names
in
core
itself.
A
F
A
A
Yeah
that
I
was
the
one
who
initially
pushed
back
on
that
the
the
rationale
was:
if
we're
going
to
overlap
with
istio,
we
can
at
least
give
them
one
unique
way
to
still
reference
their
gateway
resource,
because,
apparently,
when
we
deploy
into
a
cluster
our
we
give,
we
get
precedence
over
istio
like
just
the
gateway
name,
and
so
if
we
also
took
their
short
name.
That
would
feel
especially
cruel.
I
don't
know
so.
E
A
That
is,
that
is
what
john
has
observed,
but
I
I
have
not
tested
this
myself.
B
D
And
then
I
guess
the
other
thing
that
stands
out
to
me
is
harry.
Is
there
a
reason
why
the
short
name
for
back-end
policy
and
gateway
class
is
quoted,
but
the
two
short
names
for
gateway
is
not.
C
D
Yeah
just
for
consistency-
and
I
don't
know
what
other
people
think.
May
I
don't
know
if
I'm
making,
maybe
a
bigger
issue
out
of
this
is,
I
would
actually
prefer
just
a
single
short
name
and
then,
if
we
get
to
a
point
where
we
get
feedback
from
users
like
wow,
this
short
name
really
stinks
all
right,
then
let's
fix
it
as
opposed
to
having
multiple
short
names.
A
Yeah,
I'm
fine
with
that.
I
I
don't
mind
either
of
these
short
names.
I
I
I
don't
feel
too
strongly
on
this
one.
I
just
wanted
to
avoid
another
conflict
here.
With
that
said,
does
anyone
have
a
preference
if
we
had
to
choose
between
either
of
these
short
names
for
gateway.
F
B
F
I'm
wondering
if,
in
a
year
we
look
and
say
no
one's
using
istio
anymore,
everyone's
happily
using
our
gateway
resource.
If,
if
there's
a
point
where
we
can
say
the
istio
gateway
resources,
deprecated,
would
we
then
add
that
gw
short
name.
A
I
think
so
I
think,
and
obviously
you
know
john
has
been
involved.
I
think
they're
they're
working
on
using
our
api,
where
they
can
for
like
ingress
or
at
least
supporting
it.
So
maybe
maybe
that
is
a
thing
that
comes
in
the
future
where
we
can
say:
okay,
this
is
not
used
enough.
Let's
just
take
it
all,
but.
E
B
Yeah
from
that
perspective,
I
guess
bowie
I've
been
commenting
on
it,
but
I'm
sufficiently
happy
enough
with
it.
Even
as
is
you
know
here,
this.
A
Yeah,
I'm
fine
damian.
Do
you
have
a
preference
between
gtw
and
g
and
the
longer
gtwi.
D
A
F
D
D
Consistent
with
the
quoting
and
let's
just
roll
with
gtwi
as
a
single
short
name
and
then
ping
me
on
slack
and
I'll
and
I'll
tag,
it.
D
D
Fine
yeah
and
harry
just
ping
me
on
slack
and
I'll
I'll
tag
it
all
right.
A
Cool
all
right.
Well,
I
think
we're
a
bit
past
time.
I
think
there's
a
little
bit
more
in
pr
and
issue
triage
that
we
can
go
through
tomorrow,
but
otherwise
this
has
been
really
helpful
thanks.
Everyone
awesome
we'll
talk
to
you
tomorrow,
talk
to
you
later.