►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20200813
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
this
is
service
api's
meeting
for
august
13.,
and
I
wanted
to
go
through
one
last
well,
we'll
be
doing
this
every
meeting
until
we
actually
get
to
alpha
release.
I
wanted
to
go
through
our
release
checklist
and
make
sure
that
we
were
all
on
the
same
page
here.
I'm
excited
that
I
think
we're
making
good
progress
on
all
remaining
fronts
here.
Tls
config
harry
has
at
least
a
couple
prs
related
to
this
in
in
flight
advanced
routing.
A
A
We
could
go
ahead
and
turn
that
dock
into
some
kind
of
pr,
then
next
up
would
be
conflict
handling
semantics.
I've
got
some
updates
there.
I
filed
my
first
pr
around
this.
I
think
yesterday,
so
I
think
we're
we're
making
good
progress
as
well,
and
then
the
last
one
would
be
cleaning
up
status
and
conditions
which
will
probably
naturally
fall
later
on
this
on
the
scheme,
as
we
start
to
as
the
api
starts
to
stabilize,
will
probably
be
easier
to
clean
up
status
and
conditions.
A
So
I
think
I
think,
we're
in
a
good
place,
we're
making
some
good
progress
not
going
to
go
over
these
today,
but
in
office
hours.
I
covered
some
of
the
pr's
that
had
merged
in
the
past
week
and
I
think,
even
since
then,
we've
had
at
least
a
couple
more
that
have
gone
in
so
excited
to
see
some
some
more
progress
here.
A
With
that
said,
I
should
also
mention
looking
ahead
to
the
next
office
hours.
We
have
harry
had
this
great
idea
to
actually
go
back
through
and
clean
up
all
the
steel
pr's.
A
I
started
that
this
afternoon,
and
so,
if
I
close,
one
of
your
pr's
that
you
are
still
invested
in
by
all
means,
don't
hesitate
to
reopen
revisit
the
situation,
but
if
things
were
stale
and
it
looked
like
we'd
already
come
to
some
other
kind
of
resolution
on
the
issue-
I
I
would
close
those
pr's-
and
hopefully
I
gave
you
some
background
on
on
rationale,
but
don't
hesitate
to
reopen
anything
that
shouldn't
be
stale
with.
That
said,
I
think
we
should
get
into
pr
and
issue
triage.
A
We've
got
a
lot
to
cover
today
and
not
a
ton
of
time.
I
do
want
to
make
sure
we
have
enough
time
to
get
into
service
level
config
today,
but
there's
some
some
good
pr's
that
I
think,
could
use
our
time
first.
So
harry
has
introduced
this.
I
think
relatively
straightforward
pr,
adding
a
mode
and
s,
and
I
matching
s
to
for
tls
config
harry.
Do
you
want
to
give
just
a
little
bit
more
background
on
this
one.
B
Okay,
now
can
you
hear
me
yeah?
Okay?
So
I
also
don't
remember
so.
Let's
look
at
the
diff
together
yeah,
so
there
was
the
yeah
yeah.
So
this
is.
B
This
is
not
a
big
change,
but
this
gets
most
of
the
tls
proposal
in
except
the
dls
on
route
and
I
think
one
minor
change,
but
once
we
get
this
set
we'll
send
in
the
hdrs,
but
this
one
has
the
mode
bet
which,
which
says
that
you
know
termite
pass
through
and
if
you
terminate
the
upstream
connection,
can
be
plain
text
or
tls.
So
that's
something
we
will
have
in
the
service
level
config
and
the
tls
pass
through
is
essentially
your
treat.
B
You
know,
treat
it
as
a
bite
stream
right
like
so
you.
You
can't
really
do
anything
inside
the
tls
protocol
or
inside
the
stream,
because
the
gate
we
cannot
decipher
it.
So
it
adds
this
on
the
tls
config,
which
means
it
is
added
at
the
listener
level
inside
gateway,
so
inside
gateway,
you
have
a
listener
and
each
gate
each
listener.
D
I
do
have
a
question
on
the
mode.
I
see
that
the
two
options
are
terminate
and
pass
through.
Can
you
help
me
understand
how
we
support
the
use
case
of
re-encrypt
where
the
gateway
terminates
the
session
and
then
creates
a
new
session
to
the
back-end
service.
B
Right
so
so
what
this
change
deals
with
is
the.
C
B
Deals
everything
with
downstream
trs,
which
is
between
the
client
and
the
gateway.
What
should
be
the
dls
setting
is
configured
here?
What
should
happen
on
the
connection
hub
between
the
gateway
and
the
upstream
servers
is
something
we
want
to
configure
it
later
in
the
route
level
or
even
in
the
surface
service
level.
Config,
the
reason
and-
and
so
you
know,
once
you
terminate
your
tls
connection,
then
you
can
encrypt
it.
You
know
with
tls
or
https
whatever
you
want
to
call
me
upstream.
E
B
E
I
see
so
this
is
more
I'm
trying
to
think,
because
this
is
it's
interesting,
because
this
one
question
I
had
would
be
like
how
this
would
be
used.
So,
for
example,
you
would
say
it's
tls
pass
through,
but
I
still
configure
tls,
but
I
have
an
sni.
Basically,
pass-through
can
only
be
used
with
s.
I
route
kind
of.
B
E
So
it's
an
interesting
thing
like
for
the
tls
pass
through
which
aspects
of
tls
config
are
relevant
there,
because
because
you're
passing
it
through
by
sniffing,
usually
isn't
that
how
it
works,
you
can't.
Can
you
actually
modify
anything
about
the
tls.
B
B
You
only
should
configure
the
mode
bit
right
and
you
cannot
even
configure
like
certificate
or
you
could
probably
configure
like
minimum
dls
version.
I
think-
and
you
know
like
to
disallow
traffic-
that's
not
compatible
with
your
versions,
but
other
than
that.
I
don't
think
anything
else
is
possible.
E
I
see
so
it
would
be
only
settings
in
the
initial
hello
and
then
there
would
be
no.
You
really
couldn't
do
anything
other
than
just
specify.
E
B
E
Yeah
like,
why
would
you
want
that
this
versus
that
other
one.
B
Yeah,
so
that's
a
good
question,
so
the
reason
for
that
is,
the
gateway
operator
has
to
specifically
configure
each
port
as
to
how
it
should
work
right.
If
you
do
a
tls
passthrough
and
if
you
send
it
plain
text,
ecb
traffic
or
some
other,
you
know
database
traffic,
it
probably
wouldn't
work
right
like
without
dns,
so
so
it
it
becomes
the
gateway
operators.
B
It
comes
under
gateway
operators
control
as
to
how
they
want
each
port
to
behave
right
like
if
they
expose
a
specific
port
as
pass
through.
Then
you
know,
like
routes
depend
on
the
gateway
and
they
can
like.
You
can
configure
routes
on
that
specific
listener
accordingly,
but
you
cannot
use
any
port
that
is
configured
as
only
tcp
for
sni
routing,
right.
E
But
wouldn't
that
yeah
that's
interesting
like
let's
say
you
had
a
ex
you
exposed,
like
my
sequel,
using
l4
gateway,
and
then
someone
tried
to
like
point
their
web
browser
at
it.
Wouldn't
that
be
very
similar.
B
E
Right,
that's
what
I'm
saying
is
that
wouldn't
that
just
oh
I
see,
but
wouldn't
the
protocol
be
tcp
tls.
If
you
really
wanted
tls
termination
and
then,
if
you
didn't
terminate
it
would
be
tcp,
I'm
just
trying
to
understand
the
mode
where
you
have
tls
config
pass
through
trying
to
understand
like
why.
That
would
be
different
than
just
tcp.
With
the
s
I
route.
B
B
E
But
like
I
understand
it
makes
the
validation
easier,
because
you
can
look
at
just
gateway
and
see
that
attaching
only
sni
routes
can
be
attached
to
it.
The
it
or
is
it
a
statement
for
so
like?
I
can
also
see
people
using
this
sort
of
like
they
look
at
the
gateway
resource,
and
then
they
are
going
to
build
things
that
behave
differently
based
on
the
sort
of
the
listener
blocks
that
we're
doing
because
behaviorally
it
doesn't
seem.
E
Yeah
the
the
tls
config
with
pass
through
versus
just
a
tcp
with
the
sni
route.
Maybe
it's
like
a
hint
to
the
implementation
to
generate
the
right
thing
and
it's
a
little
bit
complicated
if
you
have
to
go
somewhere
else
to
kind
of
figure
out
that
it's
a
tls
pass-through.
B
Somehow
I
mean
that
depends
on
how
we
implement
sni
routing
right,
like
that's
still,
I
think,
open
and
jeremy
has
a
pr
for
that,
but
we
want
tls
sniffing
mode
and
our
tcp
mode
to
be
incompatible
like
you
have
the
concept
of
collapsible
listeners
or
compatible
listeners.
I
keep
mixing
those
two,
but.
E
C
B
Now
some
implementations
can
probably
handle
that
because
they
will
still
try
to
predict
that
you
know
these
are
the
first
few
bytes
of
client
hello
and
see
if
they
can
decipher
it
if
they
can
check
the
sni
in
the
drought
accordingly,
if
they
cannot
decipher
it,
they
will
assume
that
it's
a
tcp
like
it's
a
custom
protocol
and
you
know
just
possible.
Oh.
F
E
E
B
B
D
C
D
D
But
back
to
my
question
about
re-encrypt,
I'm
trying
to
understand
what
I'm
trying
to
kind
of
understand
your
response
so
help
me
under
or
help
me
understand
how
we
don't
need
to
address
that
if
it's
a
re-encrypt
use
case
that
the
gateway
needs
to
have
some
type
of
reference,
maybe
to
a
secret
that
contains
the
cert
to
use
for
the
back
end
encryption
or
you
know
some
type
of
client
tls
configuration
that
the
gateway
would
need
to
make
that
tls
connection
to
the
backup
yeah.
E
I
think
damian,
that
is
a
the
proposal,
is
to
put
it
on
the
server
side,
because
it's
a
description
of
the
service,
not
a
description
of
the
termination.
D
E
Yeah,
I
think
that
makes
the
most
sense
because,
for
example
like
you
could
have
like
a
slash
search
that
only
doesn't
care
and
then
a
slash
like
checkout,
that
has
specific
tls
settings,
or
maybe
it
has
different
dls
settings
like
more
secure
ones
or
different
certificates
or
different
mutual
off.
E
D
Yeah,
I
could
see
some
usability
concerns
where
it's
like.
Okay,
you
know
if
the
tls
connection
is
terminated
at
the
gateway
or
pass
through.
You
know
it's
configured
at
the
gateway,
but
if
we
want
to
do
the
re-encrypt,
then
you
have
to
do
that
at
the
route
level.
Just
you
know
having
different
areas
that
you
know
a
user
administrator
needs
to
figure
out.
Okay,
where
do
I
configure
this
tls
information
at,
but
that's
probably
just
something
that
we
we
need
to
kind
of
test
and
see
how
what
kind
of
feedback
we
get.
E
Yeah
they
do,
even
though
they
have
both
have
the
word
tls
in
it.
They
are
describing
two
different
things,
so
it
in
some
sense.
It's
not
it's
like
more
straightforward,
even
though
more
verbose
to
have
it
be
decoupled
because
they
are
too
like
they
can
move
independently.
D
D
About
the
re-encrypted.
C
Case
being
on
the
on
the
route,
so
you'd
specify
the
gateway
is
terminating
tls,
and
then
you
make
a
separate
decision
about
the
transport
protocol.
For
for
the
next
stop
the
thing
that
I
I
do
see.
Maybe
we
could
end
up
provisioning
on
the
gateway
is
if
the
gateway
has
client
certificates.
I've
had
one
person
who
wanted
that
they
were.
They
were
happy
with
a
client,
a
single
client
certificate
per
per
proxy,
which
seems
like
something
that
you
might
configure
on
the
gateway
or
the
gateway
class.
E
A
E
Know
sorry,
so
I
think
we'll
take
it
to
the
comments.
Generally,
it
seems.
Okay,
given
pass-through
is
like
a
pretty
advanced
use
case,
so
kind
of
making
it
extremely
simple
and
kind
of
implicit
probably
doesn't
give
us
much
mileage.
A
And-
and
I
should
my
kaya
had
a
pr
that
had
unfortunately
gone
stale,
and
I
think
I
may
have
closed
it
today,
but
he
linked
it
in
chat,
it's
81
and
it
was
covering
re-encrypt.
A
I
think
we're
also
going
to
end
up
covering
this
when
we
get
to
service
level
config,
but
just
keep
that
in
mind.
That's
another
pr
that
is
relevant
to
this
here,
but
yeah.
We
we
we
should
get
get
going
and
speaking
of
prs,
that
I
feel
bad
they've
gone
stale
and
I
have
not
gotten
an
attention.
This
one
is
another
one
by
mike.
That
I
think,
is
reasonable
something
we've
talked
about
before
and
I
somehow
we
missed
providing
much
of
any
feedback
on
this.
I
don't
know.
A
I
don't
know
how
I
missed
this
one.
I
I'm
sorry,
but
it
seems
it
seems
reasonable.
It's
the
the
idea
that
a
route
basically
would
have
some
kind
of
status
that
would
allow
that
would
make
it
clear
which
gateways
had
accepted
that
route
and
were
processing
that
route.
A
G
I
think
rob
covered
it,
I'll
rebates
it
and
I
think
it's
straightforward
enough.
It
just
adds
some
useful
status
information.
Nothing
too
complicated.
A
Okay,
okay,
great
thanks
and
the
last
the
the
next
one
is
mine
and
I'll
skip
that
again.
Just
all
of
the
all
of
the
rest
are
follow-up
that
we've
already
covered
and
I
think
I'll
skip
them,
but
encourage
everyone
to
take
a
look
as
a
follow-up
to
this,
but
really
wanted
to
get
to
service
level
config
and
it's
related
to
our
earlier
discussion.
A
E
So
I
think
we
went
over
this
once
probably
we
can
just
go
through
real,
quick
and
actually
funny
that's
relevant
to
the
service
level
re-encrypt,
it's
basically.
What
is
the
design
pattern?
We
want
to
use
for
things
that
are
basically
attached
to
the
services,
there's
two
or
three
different
sort
of
axes.
I
guess
so.
The
first
one
is
given
that
there's
config
that
feels
very
much
one-to-one
with
service.
E
How
do
you
make
that
association
so
as
before
we're
saying
like
this
project's
going
to
be
heavily
using
crds
and
creating
like
many
of
them?
In
that
case
like
when
you
create
a
crd?
E
How
does
how
does
how
does
the
gateway
controller
know
that
the
crd
corresponds
to
this
service
right?
So
we
had
a
couple
of
choices.
That's
in
the
dock,
the
first
one
is
it's
the
same
name
in
the
same
namespace,
there's
another
choice
where
it
has
a
selector
that
selects
a
bunch
of
services
there's
also
it
has
a
reference
that
selects
a
service
specifically
without
using
a
selector
and
then
there's
some
combination
of
those.
E
I
think
one
of
the
intriguing
ones
is
to
have
both
the
first
behavior
by
default
and
then
potentially
be
able
to
reference
things
for
some
of
the
advanced
use
cases
which
is
like
you
might
be
running,
a
gateway
that
you
want
to
override
the
behavior
of,
but
that
we
can
kind
of
table
that,
but
that's
just
kind
of
an
example
of
things
that
you
can
get
when
you
compose
some
of
these
techniques.
E
The
second
one
I
think
axis
is
basically
how
many
crds
do
we
want
like
do.
We
want
one
for
all
the
core
features
and
one
for
the
extended
features
and
then,
of
course,
you're
free
to
extend
them.
So
that's
sort
of
up
to
you
or
all
the
implementations
at
some
level,
or
do
we
want
to
basically
go
hole
in
on
crd
explosion
and
basically
have
very
focused
sort
of
task,
specific
crds.
E
So
even
in
core,
we
would
have
like
five
crds,
like
one
for
health
checking,
one
for
timeout
one
for
tls,
and
so
that's
like
the
second
thing
that
we're
talking
about.
I
think
yeah
mainly
it's
like
those
two
things
so
kind
of
wanted
to
get
feedback
on
how
people
felt
about
design
choices
in
those
two
I
was,
I
think,
like
either
yi
or
rob
or
me
was
going
to
basically
try
to
cobble
together
some
examples
to
see
how
some
some
of
these
design
points
actually
look
and
feel.
A
Yeah,
I
think
this
is
an
interesting
idea.
There's
there's
a
lot
to
digest
here.
I
know,
there's
already
been
some
great
comments
and
discussion
on
this.
One
thing
that
I'll
say
just
from
the
conflict
resolution
perspective.
A
If
we're
talking
about
just
how
we
might
reference
crds,
assuming
we
had
service-specific
crds,
the
one-to-one
match
is,
admittedly
the
least
powerful
option,
but
it
sure
is
simplest
in
terms
of
it's
very
hard
to
have
a
conflict.
It
gets
really
messy
if
more
than
one
say,
we
have
something
called
a
service,
timeout
policy.
A
So
this
kind
of
one-to-one
mapping
does
does
seem
simple,
at
least,
but
I
I
agree.
This
is
a
lot
of
potential
crds
to
add
and
a
lot
a
lot
of
api
expansion,
yeah
I'll
open
it
up
any
whatever
anyone
else
thinks
as.
B
Well,
yeah.
I
think
we
should
have
a
relationship
from
service
to
these
resources
rather
than
these
resources,
selecting
a
service
so
that
you
know
like
like
rob
mentioned,
and
also
you
can
still
have
the
behavior,
where
one
resource
is
shared
among
services,
yeah,
something
like
a
default
policy,
but
we
also
want
like
services.
E
Yeah
it's
funny
because
we
we
have
a
version
of
this
in
our
current
ingress,
we
being
the
gke,
the
google
one
and
we
do
have
the
explicit
mapping
between
service
and
the
crd
yeah.
We
have
to
look
at
the
feedback
now,
I'm
forgetting
why
we
weren't
as
keen
on
this.
I
think
it
was
just
a
little
bit
more
complicated
to
explain
and
the
other
thing
was
that
it
became
you
had
to
have
it
as
an
annotation
on
service
unless
we
wanted
to
really
edit
service
so
yeah.
E
I
think
that
was
one
of
the
key
things.
It
was
sort
of
seemed
a
little
bit
shoehorned
in
given
the
annotation,
but
we
do
have
fields
that
are
official
clinical
annotations.
So.
G
Something
I
was
thinking
about
that
relates
to
both
this
from
the
earlier
earlier
discussion
is:
when
you
define
a
route,
it
can
specify
that
you
can
specify
that
the
route
should
forward
to
multiple
services
right.
So
some
of
these
things
with
tls
could
be
kind
of
complicated
right.
If
you
have
a
route
that
forwards
to
one
service,
that's
tls
and
another,
that's
not
that
might
present
similar.
There
might
be
issues
with
some
of
these
other
parameters.
Is
that
going
to
be
a
problem?
G
So
maybe
there's
maybe
it's
a
non-issue,
but
it
just
jumped
out
in
my
mind,
as
this
is
a
way
that
this
this
makes
things
a
little
bit.
It's
a
little
bit
surprising
how
complex
this
can
make
things
on
the
implementation
side,
when
you
have
to
take
into
account
that
this
route
might
reference
two
very
different
services.
A
Implementations,
I
think
another
thing
that
is
interesting
here,
that
we
haven't
covered
very
much.
Is
this
gateway
route
concept
and
what
belongs
on
a
route
versus
what
belongs
in
this
new
kind
of
crd
or
crds?
A
Someone
might
want
to
be
different
per
route
or
per
environment
that
that
seems
like
a
real
stretch,
but
I
I
imagine
there
are
some
things
that
the
same
service
you
may
want
slightly
different
config,
for
maybe
that's
a
stretch.
I
don't
know,
but
is
there
any
kind
of
guidelines
we
have
as
far
as
what
belongs
on
a
route
versus
what
belongs
at
this
kind
of
service
level?
Config.
E
Yeah,
that's
a
good
question
and
I
think,
like
this
is
the
same
thing
that
we
grappled
with.
Actually
when
we
did
our
services
one-to-one
kind
of
thing,
because
it's
very
hard
like
one
answer
to
that,
is
well.
If
it's
different
and
it's
one-to-one
with
service,
then
create
a
new
service
and
then
have
another
thing
one-to-one.
E
For
example,
let's
say
you
had
two
different
tls
configurations
for
the
same:
let's
call
it
like
application
in
the
back
end
right.
Are
they
the
same
service
with
two
different
tls
configurations,
or
should
you
have
two
services
with
two
different
tls
configurations?
E
We
kind
of
settled
on
at
the
time
that
it
felt
like
having
a
lot
of
different
configurations
around
the
same
service
was
sort
of
like
a
fairly
advanced
use
case,
and
therefore
it
was
okay
to
kind
of
make
it
simpler
and
tie
it
to
the
service
which
is
kind
of
where
the
service
decorator
proposal
comes
in
versus
trying
to
like
basically
push
it
up
one
level
and
then
have
like
you
know
the
same
service,
but
basically
having
composing
it
with
like
many
many
different
sets
of
configuration.
E
E
So,
like
people
attach
many
meanings
to
service,
so
if
you
ended
up
having
the
user
sort
of
create
multiple
copies
of
the
same
service
because
they
have
different
configurations,
but
they
all
alias
the
same
workload.
So
if
you
had
something
that
kind
of
talked
about
the
workload
from
the
service
standpoint,
I've
seen
feedback
saying
like
well
like
that's
totally
weird.
E
I
don't
know
specifically
of
systems
that
have
been
built
on
top
of
that.
That
assume
that.
But
you
can
imagine
that
someone
may
have
made
that
assumption.
A
I
mean
that
that's
even
relevant
with
traffic
splitting,
as
as
we
have
defined
right
now,
where
you
have
two
different
services:
yeah
there
are
or
multiple
services
being
split
and
it's
essentially
the
same
workload,
different
methods
with
the
same
workload.
E
B
E
Definitely
yeah
like
one
thing
is
like:
oh
maybe
we
should
just
tackle
that
problem,
knowing
that
people
can
do
aliasing,
because
you
can't
prevent
people
from
doing
aliasing.
So
then,
if
you
build
things
assuming
there
is
no
aliasing,
then
like
necessarily
things
just
blow
up
if
they
ever
alias,
and
we
know
that
the
users
always
just
do
something
like
even
just
temporarily
right.
You
can
just
be
editing
one
thing
and
then
it
kind
of
overlaps
and
then
you
fix.
A
It
well
thanks
yeah,
there's
a
lot
to
process
here.
It
seems
like
we
have
a
good
start.
I
I
guess
is
the
is
the
next
step
here
either
to
get
more
feedback
on
the
stock
or
just
to
try
and
turn
this
into
some
kind
of
pr,
with
a
a
best
guess
and
and
iterate
from
there.
E
I
think
it's
I
would
feel
like.
We
should
just
do
a
best
guess,
but
at
least
that
previous
discussion,
we
just
had
probably
I'll
try
to
encode
in
like
a
concepts.
Pr
just
to
see
written
down.
Does
it
still
make
sense,
just
given
the
sort
of
most
common
use
cases
and
then
also
like?
Where
does
it
live
the
route
the
service
or
the
gateway.
C
E
Think
gateway
and
route
is
pretty
obvious,
but
like
route
and
service
and
what
the
rationale
is
there.
A
A
I
I
think
we
had
reasonable
consensus
on
the
ones
I've
listed
here.
If
I
had.
If
not
let
me
know,
I
add
a
comment
here-
I'm
hoping
to
translate
more
and
more
of
these
to
pr's
over
the
next
week,
but
I'll
leave
it
at
that,
because
we're
we're
already
over
time.
I'm
also
a
lot
of
these
rely
on
a
validating
web
hook
or
some
concept
of
that.
So
I
want
to
create
an
issue
to
track
all
the
different
use
cases
for
validating
web
hooks.
A
And
finally,
just
in
terms
of
organization
and
making
v1
alpha
1
easier
to
understand
and
track-
and
you
know
denoting
whether
issues
or
pr's
are
something
that
we
want
to
accomplish
as
part
of
v1
alpha
1.,
it
seemed
like
we
should
look
into
milestone
maintainers,
so
the
process
is
in
kubernetes,
there's
a
couple
different
pr's.
I
need
to
make
to
one
add
a
list
of
maintainers
and
then
two
assign
them
the
ability
to
maintain
milestones
whatever
else.
A
So,
if
you're
interested,
if
you've
been
involved
in
this
project
and
contributing
just
maybe
ping
on
slack,
is
the
easiest
way
to
to
volunteer
or
well
we're
already
over
time,
so
don't
volunteer
here,
yeah
just
ping
on
slack
and
I'll
I'll,
try
and
get
this
this
pr
out
with
with
a
set
of
maintainers,
hopefully
tomorrow,
but
but
sometime
soon,
and
one
note
you
do
need
to
be
part
of
the
kubernetes
sigs
org.
A
If
you
want
to
be
a
maintainer,
if
you're
not
in
that,
I'm
happy
to
help
get
you
there
so
yeah.
That's
all
I've
got.
I
know
we
went
over
time,
there's
lots
and
lots
of
prs
to
review
and
things
to
talk
about.
So,
let's
carry
on
the
conversation
on
github,
but
yeah
thanks
everyone
for
your
time.
It's
been
great.