►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220207
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220207
B
All
right
we're
recording,
I'm
not
actually
sure
who
this
is.
Are
you
on
the
call
regarding
external
dns.
B
Awesome:
hey,
do
you
want
to
what
should
I
click
on
first?
What
what
should
we
discuss.
C
C
I
had
a
bunch
of
questions
initially
because
yeah
I
don't
know,
I
think
some
things
weren't
clear
to
me
exactly
how
everything
in
the
gateway
api
interacted,
but
I
sorted
through
it
all
and
I
implemented
it.
C
This
is
the
first
time
working
with
external
dns,
so
there
were
some
problems
initially
because
of
some
dependencies
external
dns
had,
I
couldn't
add
the
gateway
api
that
gets
sorted
and
then
I
basically
opened
up
a
pull
request
for
this,
and
it's
been
sitting
around
for
like
five
months
now
and
I
keep
rebasing
it
and
updating
gateway
api
whenever
there's
a
new
release
and
etc,
and
last
week
mark
came
back
and
said
he
had
been
meaning
to
provide
some
feedback
and
he
had
a
couple
questions
and
said.
B
Yeah,
oh
yeah.
Thank
you.
Thank
you
for
doing
that
and
for
the
work
on
this.
I
I've
been
meaning
to
look
at
this
pr
and
implementation
as
well.
Have
you
heard
anything
from
external,
the
external
dns
team?
I
seem
to
remember
on
the
issue
they
seemed
interested
in
the
support.
C
No,
nothing
so
yeah,
I
guess
maybe
the
next
thing
would
be
to
if
you
can
open
up
that
doc
that
I
linked.
I
wrote
that
up
this
morning,
so
just
I
don't
know
how
familiar
everyone
is
with
external
dns,
but
I
just
defined
a
couple
of
things
that
they
use.
An
endpoint
is
basically
a
dns
record
so
like
a
host
name,
the
targets,
the
time
to
live
and
some
additional
metadata
that
they
use
to
keep
track
of
things.
C
Maybe
I
don't
know
some
of
it
is,
I
don't
think
much
of
it
is,
but
some
things
are
and
so
and
then,
after
just
for
context
after
the
background,
I
have
like
the
algorithm
of
how
it
all
works,
and
I
literally
just
kind
of
read
through
the
code
and
translate
it
to
english,
but
the
I
think
the
background
you
don't
have
to
go
through
all
the
algorithm
stuff
to
sort
of
understand
some
of
the
issues
that
might
be
interesting
to
y'all.
C
So
the
way-
and
none
of
this
stuff
is
necessarily
like
set
in
stone,
but
I
try
to
follow
the
conventions
of
external
dns
and
not
like
rock
the
boat
too
much
by
default.
They
have
separate
sources
for
each
kind
of
like
a
resource
type,
so
they
don't
usually
have
like
an
istio
source.
They
have
an
istio
gateway
source
and
an
istio
virtual
service
source
same
thing
for
like
contour
ingress
route
and
http
proxy.
So
I
did
the
same
thing
where
I
created
different
sources
for
the
different
gateway
route
types
and
so
they're.
C
All
you
can
turn
them
on
turn
them
off
separately
and
everything
control
them
independently,
which
leads
us
to
sort
of
the
next
potential
issue
is
that
gateway
api
seems
very
specific
about
conflict
resolution
and
has
very
strong
ideas
about
that
which
I
have
no
problem
with,
but
that's
not
really
how
external
dns
works.
So
I
kind
of
skipped
trying
to
do
anything
about
that,
so
each
source
generates
a
set
of
endpoints
for
all
of
the
resource
types
of
controls.
C
C
I
don't
really
know
what
that's
about,
but
it
just
like
makes
it
well.
I
can't
think
the
right
word:
it
makes
it
consistent,
basically
repeatable
yeah.
D
I
feel
like
that
that
seems
that
smells
like
a
accommodation
to
me.
We
had
to
make
a
similar
accommodation.
That's
one
of
the
reasons
why
we
have
the
the
rules
about,
like
you
know,
first
by
creation,
time
and
stuff
like
that,
is
that,
at
the
end
of
the
day,
dealing
with
eventually
consistent
system,
it's
possible
for
any
rule.
You
can
come
up
with
to
almost
to
be.
D
D
Then
we're
going
to
do
something
really
dumb,
because
we
just
got
to
be
able
to
pick
one
at
that
point
yeah,
and
so
it
makes
sense
to
me
that
you
know
that
they'd
be
like
look
we're
going
to
prefer
the
one
with
if
you've
got
one
that
has
seven
different
ips
for
a
single
hostname
and
one
that
has
one,
then
we'll
pick
the
one
with
one
I
mean
it
doesn't
yeah.
It
feels
like
it
doesn't
really
matter
which
way
around
to
pick
it
as
long
as
it's
consistent.
C
Yeah
and
then
well
this
other
next
part
about
that.
I
is
interesting.
I
didn't
realize
this
until
I
read
the
other
source
code,
how
it
worked,
but
if
there
is
an
existing
host
name-
okay,
so
there's
something
that
you
can
use
called
like
a
registry-
and
I
don't
remember
what
all
the
different
registries
are.
But
it's
basic
one
is
by
using
text
records
txt
records.
C
C
And
so,
if
this
record
that's
going
to
create
already
exists
and
it
needs
to
update
it,
it
tries
to
figure
out
which
short
endpoint
to
use
and
it'll
look
at
the
registry
to
see
which,
which
resource
generated
the
endpoint
that
already
exists,
and
if
that
resource
still
exists
and
is
one
of
the
candidates,
then
it
uses
that
so
it
is
kind
of
like
first
come
first
serve
in
a
way,
but
it
depends
on
like
when
the
resource
is
created
or
when
the
dns
record
is
created.
D
Yeah,
don't
don't
break
someone's
dns
because
someone
else
made
the
change
that
that
conflicts
with
it
like
prefer,
not
things
that
are
already
working
right.
They
seem
pretty
reasonable
to
me,
but
yeah
it
does.
It
does
end
up
with
feeling
weird,
so
I
guess
the
question
that
I
had
after
what
you've
said
so
far
is:
do
you
feel
like
it
would
be
fair
to
say
that
that
the
source
is
generating
a
set
of
endpoints?
It
is
like
it's
a
candidate
endpoints
right,
it's
like
I
I
am.
D
I
am
the
eco
gateway
source
and
I
would
like
to
have
yeah
this
this
this
set
of
endpoints
and
then
and
then
the
the
other
thing.
The
result.
The
conflict
resolver
figures
out.
If,
if
that
kind
of
goes
through
smoothly,.
C
D
C
Okay,
the
other
thing
I
I
just
kind
of
to
be
clear,
though
I
just
left
it
all
up
to
the
conflict
resolver.
I
didn't
try
to
do
anything
in
the
case
that
you
know
there
are
multiple
gateway,
api
routes
that
are
all
claiming
the
same
host
name.
I
don't.
I
don't
try
to
break
any
of
those
ties.
I
just
hand
it
up
to
the
conflict
resolver
to
do
what
it
wants
with
it,
which
I
don't
know,
maybe
that's
insufficient,
but
that's
what
I
did
for
now.
B
This
this
is
really
impressive
and
it
looks
it's
a
good
reminder
that
our
api
is
complicated.
So
thank
you
for
putting
up
with
it.
I
what
the
thing
that's
that
strikes
me
here
is:
it
seems
like
route.
Adding
support
for
routes
to
external
dns
is
likely
significantly
more
complicated
than
adding
support
to
gateways.
D
Maybe
it's
simpler
to
consider
the
source
as
the
gateway
and
you
look
at
the
set
of
routes
that
are
successfully
attached
to
the
gateway
and
that
are
have
some
set
of
conditions
or
something
like
that
as
like
as
the
candidates
for
the
candidate?
Sorry,
it's
it's
a
bit
rough
in
language,
but
but
like
if
you
said,
I'm
saying
that
having
having
something
where
like.
If
you
look
at
the
gateway
and
say,
okay,
what
routes
are
attached
to
this
gateway
someone's
requested
that
we
do
external
dns
for
this
gateway?
D
What
routes
are
attached
to
this
gateway?
Let's
let
the
gateway,
api
validation
and
stuff
handle
and
the
controller,
whatever
controller
is
reconciling
the
gateway
api
handle,
making
sure
that
the
host
names
are
consistent
because
there
is
a
but
like.
I
think
I
saw
you
refer
to
it
that
it's
a
slightly
complicated
set
of
rules
about
like
wild
cards
and
host
names
and
all
that
sort
of
stuff,
and
that
you
will
need
to
pass
to
be
able
to
get
like
a
set
of
candidate
host
names
but
yeah.
I
think
it
ended.
C
D
Cool
cool,
so
I
guess
in
my
mind
the
only
reason.
The
only
reason,
the
only
thing
that
I
can
find,
like
even
the
slightest
fault
with
men,
is
that
yeah
like
that
is
that
it
feels
to
me
like
it
would
be
easier,
practically
the
person
who
controls
the
external
dns,
like
I,
I
guess
it
it
comes.
Actually
it
comes
down
to
who's
asking
for
the
external
dns.
D
If
it's
the
person
who
owns
the
routes,
you
know
what
you
have
here
is
is
the
right
way
to
do
it
because
suppose
new
one's
a
gateway,
then
maybe
maybe
we
should
look
at
using
the
gateway
as
the
source,
but
it's
going
to
be
a
practic.
The
practical
effect
will
be
the
same.
You'll
probably
have
to
have
most
of
the
same
code,
it's
more
just
like.
D
E
Yeah
that,
oh
no,
no,
I
just
I
just
came
in
sorry,
go
ahead.
C
Yeah,
so
I
mean
that
that
change
could
be
made
the
as
far
as
external
dns
is
concerned,
the
source
like
the
resource
that
creates
the
endpoint.
The
only
thing
that's
used
for
is
in
resolving
conflicts.
It's
tracking,
you
know
who
owns
the
existing
dns
record.
C
Yeah
yeah,
it's
not
a
big
deal
in
the
in
the
case
where
everything's
working
appropriately
also
with
extra
dns.
This
is
my
next
point
on
the
list.
Whenever
you're
running
strong
dns,
you
can
provide
flags
to
restrict
the
resources
that
you're
looking
at
by
their
name
space
or
by
label
selectors
or
annotation
selectors.
The
annotation
selector
thing
kind
of
bugs
me,
but
whatever
it
is,
what
it
is,
and
so
I
added
the
same
thing
for
gateways
themselves.
C
So
I
added
well
not
annotations.
I
added
flags
to
select
only
you
can
either
do
all
the
name
spaces
or
a
single
name,
space,
there's
nothing
in
the
middle
and
you
can
apply
random.
Whatever
arbitrary
label
filters
you
want,
so
you
can
do
that
to
routes,
and
you
can
do
that
to
gateways
so
whoever's
running.
C
This
can
whoever's
running
certain
dns
can
select,
which
name
spaces
and
gateways
they
want
to
have
this
run
against
and
then
the
last
thing
which
I
think
can
be
problematic,
but
I
wasn't
exactly
sure
what
to
do
with
it.
So
we
figure
it
out,
but
there
are
already
ways
in
external
dns
to
provide
hostnames
for
resources
that
don't
have
them.
C
So
there's
like
a
well-known
annotation
that
you
can
add
to
your
resource
to
say
like
this
is
the
host
name.
I
think
you
might
even
be
able
to
add
multiple
hosting,
so
it's
like
putting
commas
in
it
or
you
can
provide
a
like
a
go
template
as
a
flag,
and
then
you
render
that
template
with
the
resource
as
the
input
to
generate
hostnames.
C
So
we
need
to
do
something
like
this.
This
is
the
only
way
that
I
can
figure
out
to
support
udp
and
tcp
routes,
but
additionally,
I
added
the
support
for
the
other
ones,
the
http
and
tls
the
thing
about
the
hdp,
and
so
this
is
like
a
little.
You
enter
into
like
foot
gun
territory
here
by
by
doing
this
because
well
in
my
algorithm,
to
actually
go
through
and
make
sure
everything
the
routes
matches
with
the
right
gateways
and
everything
like
that.
C
You
know
template
or
annotation
defined
hostname
in
the
case
that,
like
an
http
route,
has
a
like
an
empty
host
name
or
no
host
names,
I
guess
is
how
it
is
defined,
where
it
just
matches
everything
that
would
be
okay,
but
if
the
route
did
define
any
host
names
that
it
only
matched
these
and
it's
like
spec,
then,
even
if
the
annotation
or
the
template
matched
the
listeners
host
names,
the
listener
wouldn't
know
to
forward
those
requests
to
that
route.
So
I
just
added
it
like,
like
a
lot
of
other
external
dns
sources.
C
D
It
feels
like
you
have
made
the
best
trade-offs
that
I
could
that
I
can
imagine
for
like
what
seems
like
a
pretty
thorny
tangle
of
the
rules
that
you
could
end
up
with.
Here
I
mean
yeah.
This
is
yeah,
there's
good
thing
about
open
source,
though
right
like.
D
If
we
do
find
that
there
is
the
people
actually
end
up
finding
the
foot
gun
potential
here,
then
you
then
I
then
we
can
do
something
about
it
later,
but
it
doesn't
seem
like
that
you
would
need
you
would
want
to
do
strong
changes
to
the
model
that
you're
using
in
order
to
in
order
to
do
that.
So
I
like
this
sounds
really
good
to
me
personally.
C
All
right
cool,
I
had
one
question
as
I
was
going
through
this
and
looking
at
some
of
my
to-do's
there's
for
listeners
right,
there's
the
I
think
it's
called
allowed
the
allowed
field
and
then
and
that
struct
has
you
know
the
different
name,
space
selectors
and
what
stuff
that's
fine,
but
then
there's
kinds
which
kinds
are
supported.
C
When
I
was
implementing
this,
I
noticed
that
the
listener
spec
has
through
the
the
gateway
spec
the
listener
and
the
gateway.
Spec
has
kinds
there,
but
then
in
the
status
the
listener
status
also
has
kinds
there
and
I
wasn't
sure
which
one
to
use
and
I
wasn't
sure
if
they
could
be
different
so
anyway,
that's
something
I
wanted
to
bring
up.
D
Feels
like
we
just
need
to
make
that
a
little
clearer,
the
intent
there
is
that
if
you
specify
kinds
in
the
allowed
in
the
allowed
kind
part
under
the
listener,
then
those
will
be
the
the
special
ones
you
specify
will
be
the
ones
that
show
up
in
the
clients
on
the
status.
If
you
don't
specify
kinds,
then
it's
intended
that
the
controller
that
owns
the
gateway
will
fill
in
those
kinds.
With
this,
the
kind
that
could
be
supported
there.
So.
D
Status
is
what
kinds
are
supported:
it's
possible
for
the
owner
of
the
gateway
to
sort
of
close
that
door
a
bit
by
and
make
it
only
http
route,
in
which
case
the
controller
owns,
the
gateway
route
should
say
only
http
route,
but
so
I
mean
because
you're
not
actually
doing
the
reconciliation
of
the
routes.
You
probably
should
just
be
leaving
that
status
alone,
like
that.
That
kind
bit
alone.
C
Yeah
yeah,
I'm
not
I'm
not
changing
anything,
but
I
am.
I
am
having
to
go
through
all
the
different
routes.
F
C
The
different
listeners
that
are
in
the
route's
status
of
its
parents
and
then
looking
to
see
you
know
which
specific
listeners
should
be
attached
to
it
and
how
their
host
names
overlap
and
picking
like
the
most
well-defined
host
name
between
the
listener
and
the
route
yeah
so
like.
If
the
route
has
a
fully
qualified
domain
name
and
the
listener
has
like
a
wild
card
in
it,
then
use
the
and
they
match
then
use
the
route
first
name
and
then
also
vice
versa.
C
B
I
I
think
it
can
be
a
little
bit
easier
than
that
or
less
complicated.
I
would
say
in
that
route
status
should
give
unite,
a
picture
of
which
gateways
have
successfully
successfully
been
attached
to
that
route
or
the
route
whatever
and
beyond
that,
I
don't
think
you
need
to
think
much
more
about
it.
Just
if
the
gateway
is
saying
I'm
attached
to
this
route,
that's
good
enough,
and
and
if
it's
not,
then
you
can
disregard
it.
So.
C
C
Yeah
that
was
that
was
more
like
what
I
was
doing
originally
like
my
first
iteration
through
this
was
like
that.
But
then
I
thought
of
more
examples
where,
like
a
route,
may
have
six
different
host
names
and
a
gateway,
and
it
could
be
each
of
those
different
hostnames
could
be
attached
to
a
different
gateway,
and
I
wouldn't
know
that
from
the
route
status
from
the
route
status,
I
would
think
that
oh,
these
six
gateways
are
attached
to
this
route
and
this
route
has
success
names.
So
all
six
of
those
things
get
all
six
stay.
C
D
D
To
make
sure
that
which
the
gateway
will
tell
you
which
routes
are
successfully
attached
and
then
you've
got
to
do
the
superset
of
like
what?
What
route,
what
host
names
on
the
gateway
match?
The
host
names
that
you
have
available
on
the
route
and
those
are
the
only
ones
that
are
valid
for
that
gateway.
D
Yeah,
so
yeah
sorry,
is
what
I
would
say
there.
You
know
yeah
like.
I
think,
there's
no
there's
not
much
way
around
that,
because
we've
got
this
sort
of
flexible
mechanism
about
defining
host
names.
You
are
catching
the
the
short
end
of
the
stick:
yeah
yeah,
but
no,
it
sounds
like
you've
got
that
well
understood
and
pretty
well
handled
to
me
off
the
top
of
my
head.
I
haven't
had
a
good
look
at
the
pr
yet
either.
I'm
sorry
but
yeah,
like
the
that
document,
will
be
really
helpful.
B
Yeah
completely
agree
with
nick
on
this
thanks,
thanks
for
getting
this
together
and
yeah
thanks
for
bringing
it
to
our
attention
in
this
meeting
too,
I
I
know
I
it
kind
of
slipped
past
me
beyond
this,
I'm
just
trying
to
understand
how
we
can
help
going
forward.
It
seems
like
the
next
step
for
us
would
be
either
to
take
some
time
to
review
this
doc
or
maybe
more
concretely,
review.
The
pr
itself
is
that
how
it
can
be
most
helpful.
C
I
mean,
I
think,
either
I
mean
from
my
perspective.
I
just
want
to
make
sure
that,
like
I
did
something
reasonable
and
I'm
not
hearing
any
like
major
complaints,
and
so
it
sounds
like
it
sounds
like
what
I
have
now
is.
You
know
a
good
good
first
shot
of
this,
and
if
we
find
more
problems
later
than
we
can,
if
I
can
fix
it,
but
I
think
so,
if
you
want
to
review
the
doc,
that
would
be
great.
The
doc
is
basically
just
explaining
what
the
pr
is.
C
D
C
And
so,
if
I
think,
if
we
can,
if
you
could
do
something,
try
to
help
move
the
pr
forward,
like
maybe
just
review
the
pr
and
from
your
side
and
see
if
it
makes
sense
from
the
gaming
api
side
that
might
help
the
external
dns
maintainers,
I
don't
know,
feel
more
confident
merging
it.
I
just
haven't
gotten
any
feedback
at
all.
D
Yeah,
I
think
it
feels
pretty
reasonable
to
me
that
we
would
do
like
a
review
here
and
say
thumbs
up
from
a
gateway
point
of
gateway
api
point
of
view.
You
know
external
dns
maintainers,
it's
over
to
you
to
sort
of
say
if
this
sort
of
matches
your
style
and
does
you
know
if
you're
happy
to
merge
this
but
from
the
gateway
api
flow
point
of
view?
This
is
great
is
what
we
should.
D
One
of
us
should
comment
on
there,
and
then
we
can
ping,
and
then
we
can
poke
external
dns
maintenance
and
be
like
hey
it'd,
be
really
nice
to
have
this
in
in
internet.
B
C
D
B
Actually,
it
looks
like
lewin,
you
had
a
good
question
in
chat
that
I
missed
earlier.
I
think
you're
talking
about
for
east
west
gateway
use
case,
how
dns
would
work
yeah.
I
I
think
that's
just
this
big
unknown
right
now.
I
I
I
would
love
to
figure
it
out
too.
I
I
think
istio
may
be
furthest
along
in
east
west
implementation
of
this
api,
but
I'm
interested
in
others
that
are
in
flight
2
and
what
they
might
be
doing.
But
I
don't
have
a
good
answer.
D
Mean
we're
talking
here
about
like
between
services
rather
than
from
the
internet,
to
your
service,
so
that's
north
south
east,
so
I
would
say
it's
probably
not
too
relevant
for
for
your
pr
as
an
external
dns.
So
like
like,
I
said,
I
really
appreciate
everything
you've
done.
I
I
definitely
will
make
sure
that
I
keep
an
eye
on
this
and
poke
it
along
for
you.
Please
feel
free
to
ping
me
on
slack.
D
If
you
haven't
heard
from
us
or
I
haven't,
had
a
review,
you
may
personally
on
slack
please,
and
I
will
check
this
out
and
I
will
try
and
find
some
external
dns
maintenance
to
poke
as
well.
Okay,.
A
D
Yeah,
so
I
had
some
questions
here.
I
literally
said
sorry
for
the
verbose
notes,
but
these
are
literally
just
the
notes.
I
wrote
to
myself
to
remind
me
what
to
talk
about
yeah.
I
spent
some
time
having
a
look
at
the
how
we
publish
the
workbook
server
at
the
moment
and
yeah.
I
just
wanted
to
ask
everybody
what
we
all
thought.
The
idea
here
is.
D
I
think
that
what
we
need
to
be
doing
for
beta
is
that
we
should
have
a
standard
way
to
install
a
bundle
that
is,
that
has
the
crds
plus
anything
else
required,
in
this
case
the
admission
webhook,
and
so
we
need
to
set
along
like
what's
the
standard
place
where
we're
going
to
install
the
mission
web
book.
D
D
The
emission
web
book
should
use
bare
version
tags
like
v040,
rather
than
what
we
have
at
the
moment,
because
it's
really
clear
and
really
easy
to
use
and
really
really
straightforward
to
see,
and
I
think
that
we
should
tag
latest
as
the
current
latest
released
version
right
now.
It's
whatever
build
got
got
run
last,
so
yeah,
it's
not
going
to
be
very
stable
latest,
should
be
this.
D
The
latest
stable,
stable
release
version,
but,
like
latest
one,
that's
tagged,
that's
not
going
to
change
in
my
mind,
yeah
and
yeah
we'll
need
to,
and
that
means
in
order
to
do
all
of
that,
we'll
need
to
like
tidy
up
a
release
process
probably
have
some
scripting
and
stuff
that
runs
to
generate
the
manifests
and
manage
the
manifest
properly
and
and
all
those
sorts
of
things
I,
and
I
feel
that,
yes,
we
should
provide
a
fully
rendered
manifests.
D
Probably
I
would
kind
of
like
to
see
us
have
have
the
usual
quick
start
single
single
yaml
file,
so
that
you
can
so
that
our
docs
can
be
like.
You
know
cube
kettle,
cube
kettle
this
url
right
now,
we've
got
you
customize
a
url
and
pipe
it
to
cube,
pedal
you,
but
I
would
also
like
to
see
us
have
a
separate
like
a
set
of
broken
apart,
but
the
set
of
source
yaml
files
that
we
use
to
render
that
single
gamma
file
available
in
the
repo
as
well.
D
B
Yeah,
big
plus
one,
for
me,
I
agree
with
all
of
those.
I
I
mean
the
only
thing
is
I
I
hope
we
can
find
some.
You
know
reliable,
tooling
around
how
we
how
we
handle
release.
I
know
release
is
kind
of
a
pretty
manual
process
right
now,
and
this
adds
one
extra
piece
to
that
I
seems
like.
Maybe
we
need
some
ci
associated
with
it.
B
I'm
I'm
not
sure,
but
this
this
adds
one
more
step
forever,
at
least
so
anything
we
can
do
to
make
that
simpler
would
be
great,
but
I
completely
agree
with
the
rest.
D
Yeah,
I
feel,
like
I
mean
this
is
going
to
be
on
me
to
do
this
work.
I
assume,
since
I'm
the
one
who
knows
about
it
already,
but
it's
going
to
be
some
time
spent
getting
to
know
the
kubernetes
testing
for
a
bit
better
which
I've
intended
for
ages.
So
it's
good
for
me,
but
yeah.
D
I
would
guess
that
I
will
need
to
go
and
look
at
some
prior
art
from
other
kubernetes
six
projects
and
stuff
like
that
and
talk
to
people
who
are
doing
that
about
what
they
like
and
what
they
don't
like
about
their
current
setup
yeah.
So
for
today
the
thing
that
I
was
looking
for,
yeah
I
100
agree.
It
should
be
that
in
my
mind,
it
should
be
that
we
just
create
a
tag
and
then
the
release
happens
so
that,
ideally
you
should.
D
We
should
be
able
to
create
a
release
from
inside
from
inside
the
github
ui.
By
hitting
the
release
button,
making
a
tag,
putting
the
release,
notes
that
we've
already
appeared
into
master
and
that's
it
that's
the
release
process.
That's
the
ideal
state
yeah
completely
agree
yeah.
Oh
one
thing
that
I
did
realize
as
well:
I'm
looking
around
at
kubernetes
a
number
of
them
and
I'm
happy
to
ask
about
this
as
well.
A
number
of
them
have
performed
the
master
domain
migration
as
well,
which
I
would
like
to
do
at
some
point.
B
Yeah,
better
sooner
than
later
so
yeah.
If
you
have.
E
D
Having
a
look
at
having
a
look
through,
I
haven't
seen
a
lot
of
places
where
we
heard
codemaster,
but
there
are
a
few
yeah
so
yeah.
If
you
maybe
I
can
talk
to
you
another
time,
bowie
about
the
steps
involved
and
then,
since
I'm
up
to
my
it's
in
this
already,
then
I
can
at
least
build
a
list
of
places.
We
need
to
touch.
D
A
hiccup
yeah
yeah,
I
mean
yeah,
there's
a
huge
migration
plan
thing
that
we've
got
to
do
there,
but
yeah,
I
don't
know,
I
don't
even
know
the
steps.
I
know
the
steps
for
that
we
did
for
contour,
but
I
don't
know
the
steps
for
you
so
I'll
talk
to
you
about
that.
Another
time
by
the
way,
yeah
I'm
very
interested
in
feedback
from
you
know,
people
who
aren't
me
or
rob
about
this.
Does
anyone
have
else
have
strong
thoughts?
D
D
Cool
okay,
so
yeah.
I
will
proceed
ahead
with
that
I'll
make
some
pr's
and
start
like
writing
things
out
in
issues
and
things
like
that:
yeah
yeah.
So
and
once
I
do
that,
please
feel
free
to
object
there
as
well.
If
you
come
up
with
anything,
that's
a
problem,
but
I
feel
like
what
I
have
talked
about
is
the
best
way
that
I
can
think
of
to
do
it.
B
That's
it
for
me
cool
great,
just
a
couple
of
small
things
for
me,
the
I
don't
think
this
is
new,
but
I
just
wanted
to
bring
it
up
in
a
little
bit
more
detail.
I'd
been
talking
about
writing
some
kind
of
docs
that
covered
additional
potential
use
cases
of
the
api
that
are
just
not
well
defined
right
now,
and
I
don't
think
we
we
have
enough
detail
to
go
into.
B
You
know
huge
amounts
of
detail
on
what
mesh
or
egress
could
look
like
with
this
api,
but
I
think
it's
worth
adding
some
documentation
somewhere
to
describe
that.
This
is
potentially
possible
with
api,
maybe
a
list
of
implementations
that
are
exploring
this
direction
and
what
it
might
look
like.
So
it's
more
of
an
exploratory
dock
than
a
concrete.
This
is
how
it
is
done,
but
I
think
it
could
be
helpful
to
to
expand
on
what
I
think
is
the
primary
use
case
of
the
api
so
far,
which
is
ingress.
B
So
I
I've
been
thinking
about
writing
some
kind
of
documentation
around
this,
but
one
does
that
make
sense
and
two
are
there
other
use
cases?
I
should
cover
as
potential
extension
points
of
this
api.
F
I
don't
know
about
potential
extension
points
I
mean
I
think
mesh
and
ingress
are
both
are
both
great
things
to
be
thinking
about,
but
something
I'm
thinking
about
that
was
brought
up
last
week
about
grpc
routes
and
perhaps
the
philosophy
or
what
constitutes
a
route
or
why
we'd
add
another
one,
for
instance
like
sctp
or
click
or
maybe
another
one
of
these
l8
l
7.5
type
routes.
I
like
it,
this
encapsulated
protocol
that
grpc
is
thinking
you
know,
maybe
iot
use
cases
or
something.
B
B
But
then
two?
How
do
you
build
your
own
route?
If,
if
that's
what
you
want
to
do-
and
I
think
that's
a
great
way
yeah.
Thank
you.
Yeah.
D
Great
point:
I
think
that
yeah,
our
guidance
on
we've
got
places
where
you
can.
You
can
add
your
own
version
of
something,
but
our
guidance
on
how
you
would
go
about
doing
that
is
severely
lacking
and
so
yeah.
I
have
a.
I
have
a
to-do
that
I
have
been
having
a
look
at
as
well
as
about
about
creating
an
actual
work
example
of
how
of
a
policy
api
object
and
how
it
would
work
and
how
what
implementations
would
need
to
do
to
support
it.
D
The
one
I
picked
for
that
is
a
tls
minimum
version,
because
I
think
that's
pretty
common
across
lots,
lots
of
different
like
layer,
seven
controllers
that
do
http
route
or
tls
route
and
so
being
able
to
say
you
know,
being
able
to
default
or
override
the
tls
minimum
version.
D
I
think,
is
a
really
good
way
to
explain
what
the
policy
engine
is
intended
for,
and
so
I
would
like
to
supply
the
tls
minimum
version
policy
plus,
like
yamls,
plus
how
you
would
actually
like
use
them
in
a
worked
example
to
make
that
thing
clearer,
because
I
think
the
policy
is
also
very
ugly.
D
D
So,
like
you
know,
ingress
is
translating
between,
like
the
internet
or
external
and
internal,
for
lack
of
a
better
word.
Whereas
a
mesh
use
case
is
like
you
know,
translating
between
services.
That
might
not
know
exactly
how
to
reach
the
service.
They
just
know
that
they
want
to
reach
this
particular
service.
D
Egress
is
translating
between
knowing
how
to
ask
for
a
service
from
inside
the
cluster
and
sending
that
outside
the
cluster,
sometimes
somewhere,
and
so
like
that.
The
thing
that
all
of
those
gateway
use
cases
have
in
common
is
a
is
that
it's
a
logical
network
device,
a
logical
network
point
that
translates
that
translates
between
the
networks
and
so
thinking
about
that
in
terms
of
already
existing
network
devices.
D
That's
literally
what
a
router
is,
and
so
like
in
my
mind,
there's
probably
some
space
for
some
low
lower
layer
like
gateway
constructs
that
could
let
you
describe
like
vpn
tunnels
or
things
like
that.
So
ip
route,
gre
route,
vpn
route,
something
like
that
yeah.
So
this
I
think
that's
a
pretty
nice
use
case.
That
might
not
be
that
useful
for
a
lot
of
people,
but
the
people
who
it
would
be
useful
for
would
be
very
useful.
D
Being
able
to
describe
your
your
like
vpn
endpoints,
using
intercourse
in
cluster,
things
seems
like
it
would
be
pretty
handy
for
the
people
who
really
needed
it
so
yeah.
That
was
my
thought
about
an
additional
use
case,
though,.
B
Yeah,
that's
a
that's
a
really
good
point:
yeah
lots
of
good
content
to
add
in
our
docs
and
actually,
while
I'm
thinking
about
docs
nick,
you
had
organized
a
what
is
it
a
docs
review.
D
Yes,
so
yeah,
I
should
talk
about
that.
So
I
have
organized.
I
will
be
mentoring,
a
linux
foundation
mentee,
who
we
got
a
mentor
mentorship
project
assuming
that
we
get
people
applying
for
it,
I'm
pretty
sure
we
will
that
they
will
be
doing
cncs
tech,
writers,
style,
docs
assessment,
which
is
basically
going
through
our
docs
as
like
a
standard
checklist
of
things
for
them
to
check,
and
then
writing
up.
You
know
using
tech
writing
skills
to
write
up
like
here's.
D
What
I
think
you
should
change
about
the
docs.
The
idea
here
is
to
have
someone
who
is
technically
literate,
but
not
gateway
literate
to
go
through
the
docs
and
sort
of
read
them
for
clarity
and
how
we
explain
these
quite
complicated
concepts
to
someone
who
is
capable
of
understanding
them,
but
doesn't
understand
them
yet
and
come
up
with
suggestions
for
what
we
need
to
change
about.
The
docs.
B
D
Think
lewin
had
some
questions
in
the
chat.
D
So
I
think
you
were
asking
about
like
the
east-west
things
here
for
within
cluster
east-west
is
handled
by
core
dns,
but
I
think
this
is
talking
about
like
between
clusters
or
east-west,
to
some
other
service.
That's
not
running
in
a
cluster.
Maybe
so
does
that
answer.
A
Yeah,
I
I
think
I
was
trying
to
answer
bullish
questions
yeah,
so
I
think
my
I
know
I
don't
know
how
to
implement
yet.
But
it's
something
like
what.
If
our
http
route
is
like
first
class
citizen
like
service
and
I
define
a
name
called
full
dash
l7,
this
is
name
and
can
a
part
in
the
in
the
same
cluster.
Can
he
just
say:
curl
full
dash,
l7,
slash
version
one
or
slash
version.
Two
assuming
the
http
route
already
have
those
version.
One
version
two
defined
that
that
was
that's
my
question.
D
I
haven't
really
yet,
but
it
does,
it
does
seem
like
it
seems
a
little.
D
It
seems
a
little
like
where
it
means
that
you're
sort
of
it
would
be
weird
for
me,
because
it
would
mean
that
your
gateway
would
kind
of
need
to
define
this,
the
the
in
cluster
or
host
name
as
the
host
name,
rather
than
like
an
externally
visible
one
and
then
you're
kind
of
having
your
traffic
like,
if
I
think
of,
if
I
keep
think
of
the
gateway
like
if
I
think,
of
a
cluster
like
an
old
school
network.
This
is
a
kind
of
equivalent
to
hair,
pinning
out
to
your
to
your
internet
interface.
D
To
then
come
back
in
through
your
load,
balancer
to
then
be
load
balanced,
which
you
can
totally
do
and
has
definitely
has
use
cases.
D
But
it
feels
like
just
the
straight
like
in
in
the
case
where
you
do
like
the
vu
l7
versus
one
is:
is
it
that
you're
looking
to
be
able
to
do
the
path-based
routing
to
different
versions
of
the
service
to
do
like?
You
know,
in
this
case
you're
thinking
of
like
a
like
a
blue-green
roll-out
kind
of
thing?
Right
where
each
thing
has
a
service,
but
you
want
to
be
able
to
talk
to
a
name
that
represents
the
sort
of
super
service.
A
Yeah,
I
think
I
last
I
think
I
think
I
put
the
slack
about
the
use
case.
I'm
thinking
about
you
know
I
have
right
so
so
I
understand
this
is
for
one
of
use
case
multi-cluster,
but
another
case
I
could
have
inventory
hdb
router
or
I
can
have
a
parking
route,
so
my
application
can
just
say:
curl
inventory,
dot,
com,
slash
version,
one
of
version
two,
and
I
can
also
say
application
too,
can
say
parking.
A
You
know
just
like
I
mean
I
would
like
to
see.
Is
it
possible
that
to
the
http
route,
like
really
the
first
class
season
down
the
road
like
almost
like
kubernetes
service
right
in
kubernetes
service?
Today,
if
I
define
a
service
full
everything
is
taken
care
of
automatically
right,
all
the
coordinates,
everyone,
you
just
say,
curl
full
and
then
they
will
tell
you
whether
it's
crosstalk,
ip
or
nlp
ip.
A
So
I'd
like
to
see
something
similar,
I
understand
we
have
gateway.
You
know,
canada
hook
them
together
can
application.
You
know
I
want
to
talk
to
inventory
service.
I
can
go
through
a
gateway.
I
can
or
just
directly
curl
inventory,
with
the
specific
name
and
that,
of
course
our
name
is
unique
and
just
specify
you
know,
curl
inventory,
slash
version
one
or
something
can
application
do
that.
B
B
I
I'm
pretty
sure
I've
heard
tim
ask
if,
if
there's
ever
a
point
where
gateway
of
type
cluster
ip
makes
sense
like
a
cluster
ip
gateway
class,
that's
very
theoretical
at
this
point,
but
I
think
that
kind
of
overlaps
significantly
with
what
you're
describing
of
this
kind
of
built-in
concept
or
support
for
gateway.
A
Actually,
I
kind
of
in
sync
what
I
was
thinking
you
know
it
would
be
great
if
we
have,
let's
imagine
if
somebody
say
curl
inventory
and
that's
basically
get
automatic
extended
to
inventory
the
cluster
sets
and
we
notice
one
of
the
azure.
You
know
come
back
with
ip.
It's
all
taken
care
of.
You
know,
let's
say
assuming
you
know,
inventory
does
actually
without
it's
for
multiple
cluster.
You
know
you
can
define
in
the
management
cluster
and
which
going
to
use
by
multiple
cluster.
A
Just
like
the
last
diagram,
I
put
it
in
you
know
the
same
route
can
be
accessed
from
two
applications,
one
and
two,
but
it's
really
owned
by
the
same
team.
So
this
http
router
is
defined
in
this.
It's
like
a
cluster
sets
scoped.
So
today
htrl
you
can
have
classiscope
namespace
spokes
scoped.
What
if,
if
we
have
cluster,
sets
scopes?
A
A
So
I
think
how
did
I
say
this
if
we
you
know
if
cluster,
if
there's
part
of
cluster
sets
in
the
future,
if
the
class
success
can
automatically
update
the
code
dns
and
my
application,
whether
it
cost
you
know
my
application,
I
can
just
say
curl
inventory.com
and
it
will
get
automatic,
expanded,
expanded
to
inventory.cluster
sets
and
I'll
get
this
ip
address,
and
I
can
just
send
it.
D
All
I
care
about
that
is
that
I
get
to
inventory
service
within
some
specified.
You
know
service,
laptop
service
level,
agreement
you
know,
and
so
and
doing
what
you're
talking
about
is
sort
of
the
the
dream.
Like
I
said,
the
dream
end
state
of
of
that
sort
of
thing
where
you
have
a
cross-cluster
service.
Merch
is
exactly
what
it
is.
D
It's
like
any
service
can
ask
for
any
other
service
by
a
single
name
across
the
whole
thing
and
and
be
comfortable
that
that
it's
going
to
access
it
by
the
best
way,
where
the
best
way
is
defined
by
the
person
who
owns
the
service.
You're
talking
to
yeah.
G
D
Yeah,
I
feel
like
the
gateway.
Api
itself
is
a
part
of
of
a
thing
that
you
would
use
to
implement
that
because,
as
I
said
before,
the
gateway,
the
gateway
is
the
point
at
which
you
translate
between
between
different
views
of
the
network
right.
So
in
the
case
that
you're
doing
like
a
multi-cluster
kind
of
thing,
you
know
if
you're
doing
the
service
export
service
import
parts
that
are
multi-cluster.
There
are
multi
clusters,
the
current
sort
of
upstream
approach
to
multi-cluster.
D
Does
then,
when
you
import
a
service,
maybe
you
want
to
refer
to
the
service
that
you're
importing
by
by
like
inventory.com
and
that
inventory.com
points
to
a
gateway
in
the
other
cluster
that
then
lets
that
other
cluster
abstract
away
exactly
what
version
they're
running
and
all
that
sort
of
stuff
so
that
it's
a
so
there's
a
layer
of
abstraction
for
them
to
do
so.
I
feel
like
a
gateway,
the
gateway
api,
as
we
have
it
today
feels
like
unnecessary,
but
not
sufficient
part
of
our
upstream
solution
for
multi-cluster
stuff.
D
If
you,
if
you
understand
what
I'm
saying
so,
the
thing
that
we're
doing
here
in
this
meeting
is
like
defining
how
you
translate
between
like
stuff
that
doesn't,
for
example,
for
ingress
use
cases
stuff
that
doesn't
know
about
how
the
cluster
networking
works
to
stuff.
That
does
you
know
internet
to
cluster.
D
Essentially,
you
know,
but
the
thing
that
rob
mentioned
before
about
a
cluster
ip
thing
would
be
where
you
translating
between
like
something
that's
in
the
cluster,
but
it
wants
to
just
talk
to
an
industry
service
and
I
don't
care
about
how
it's
running
and
then
the
people
who
are
running
the
inventory
service
can
abstract
away
like
green
migration
between
deployments
and
all
this
sort
of
stuff,
without
with
still
having
a
single
name
to
talk
to
you
know,
all
of
those
things
have
in
common
that
you're,
translating
that's
the
key
part
of
the
gateway
api
is
the
translating
part.
D
The
translation
is
important
to
be
able
to
do
the
multi-cluster
stuff,
but
it's
not
sufficient.
You
need
to
have
like
a
way
to
look
up
all
of
the
names
or
how
do
you
know
that
you
can
talk
to
the
inventory
service
by
the
name,
inventory
and
think,
and
things
like
that,
and
so
I
think
that
that's
what
jeff
talking
about
a
lot
of
what
console
does
is
to
solve
some
of
the
service
discovery
problem
for
you.
D
So
we're
all
we're
all
going
to
end
up
approaching
these
same
problems
in
different
ways
like
or
needing
to
solve
this
same
problem.
I
think,
and
so
the.
I
definitely
think
that
there's
a
lot
of
crossover
between
the
mesh
use
case,
the
egress
use
case,
what
we're
talking
about
with
gateway
api
and
what
you're
talking
about
that.
All
of
those
things
are
useful
things
that
we
need
to
do
and
that
what
you're
talking
about
is
100
useful,
and
I
agree
that
it
would
be.
That
is
a
great
thing
to
work
towards.
D
I
feel
like
is
going
to
need
a
bit
more
cross
communication
than
we
have
available
in
this
meeting
to
talk
about
it
because
we're
going
to
need
a
you
know,
there's
already
an
existing
multi-cluster
stream.
In
the
rest
of
the
kubernetes
project
that
we
need,
that
needs
to
be
coordinated
with.
I
feel
like
this
project.
D
It
wants
to
say
access
me
via
this
this
name,
because
the
other
way
that
you
can
solve
this
is
just
make
all
the
clusters
have
all
their
endpoints
visible
and
you
just
use
the
cluster
and
do
some
dns
inputting,
there's
a
very
simple
way
that
you
can
do
that.
I
think
that's
not
very
practical,
because
it
doesn't
do
that
abstraction
thing
you
don't
get
to
encapsulate
how
a
service
runs
and
so
that
the
people
who
own
the
service
can
do
what
they
want.
D
B
I
feel
like
there's
more
people
interested
in
this
topic
than
are
at
this
meeting,
and
so
just
having
that
some
place
to
clearly
describe
the
use
case,
and
you
know
that,
like
nick
mentioned
this,
this
kind
of
this
topic
spans
a
lot
of
different
areas.
It
spans
potentially
mesh
it
spans,
potentially
cluster
ip,
it
spans
multi-cluster
and
there's
it's
broad
and
so
there's
a
lot
of
people
that
are
working
on
different
subsets
of
that,
but
trying
to
pull
it
all
together
would
be
very
interesting
yeah.
B
D
E
B
Thank
you
yeah.
That's
great,
thank
you
for
raising
that.
I
I
think
we
just
have
a
couple
minutes
left
to
go
through
any
outstanding
issues
or
questions.
B
Egress
use
cases
this
is
hopefully
going
to
be
covered
for
docs,
but
this
is
just
tracking
a
question
that
we
got
in
slack
recently.
B
So
if
anyone
does
have
use
cases,
this
would
be
a
great
way
to
track
them,
but
I
don't
know
that
we
need
much
conversation
on
that
in
this
meeting.
Doc's
assessment
nick
you
already
covered
that
I
yeah
I
don't
know.
I
don't
know
who
is
available,
but
I
you
know
we
have
sig
security.
Now
I
if
anyone
wants
to
volunteer
to
reach
out
to
them
to
make
sure
we
have
some
some
scanning
in
place.
That
would
be
awesome.
B
I
know
you
know
what
right
now
I
know
we
have
some
vulnerabilities
affecting
our
python
dependencies
which
are
just
used
for
build
and
they're.
I
don't
think
I
don't.
I
don't
think
they're
actually
used,
but
our
requirements.txt
is
out
of
date,
and
so
we
need
to
work
on
this
and
we
need
to
have
some
automation
around
this
yeah.
D
Basically,
all
of
all
of
the
ones
that
say
admission
web
hook
are
the
admission
workbook
pre-beta
cleanup
tasks
is
like
the
epic
and
those
are
like
sub
issues.
Essentially,
github
has
a
thing
where
you
can
take
the
task
list
and
actually
just
click
a
button,
and
it
makes
you
an
issue
that
covers
that
task.
So
that
was
what
I
did.
B
That
makes
a
lot
of
sense
cool.
Well,
thank
you
for
creating
these.
These
are
going
to
be
helpful
to
track
track
of
the
all
of
these
are
nick.
Are
you
volunteering
to
lead
most
of
these,
or
do
you
want
help
with
any
role?
I
mean.
D
I
think
that
it's
useful
for
not
just
one
person
to
be
like
yeah
until
until
I'm
until
I
have
a
better
idea
of
which
ones
interact
with
which
I'm
it's
probably
best
to
just
have
one
person
leading
them
all
and
trying
to
figure
out
what
we
need
to
do
once
I
have
some
better
to-do
lists,
I
will
try
and
I'll
start
adding
help
on
it
and
stuff
like
that
and
picking
them
a
bit
more
awesome.
B
Great,
I
think
that
that
takes
us
until
yeah
last
year,
so
perfect,
all
right.
Well,
thank
you.
Everyone
for
meeting
today,
great
discussion
all
around.
I
think,
if
we
don't
have
anything
else
we're
at
time,
so
we
can
call
it
all
right
thanks.
Everyone,
google
cheers.