►
From YouTube: Agones Community Meeting - April 2023
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
A
Welcome
to
another
episode
of
the
Agonist
Community
meeting
stuff,
oh
God
I'm
not
doing
well.
Let
me
take
things
away.
C
So
we've
skipped
last
month
because
of
GDC,
so
we
haven't
met
in
a
couple
of
months.
We've
got
a
few
things
on
the
agenda
today.
C
So
I
just
did
a
quick
audit
and
went
through
and
filed
tickets
for
all
the
ones
it
seemed
like
they
made
sense
to
promote
with
the
idea
of
sort
of
mentioning
it
today
and
sort
of
getting
some
consensus,
or
if
this
is
a
feature,
that's
something
that
you've
been.
C
You
know
interested
in
or
been
testing
out,
especially
if
it's
an
alpha,
you
know,
I
think
the
the
main
things
we're
looking
for
to
go
from
to
data
are
that
the
the
person
who
asked
for
the
feature
has
actually
used
it
and
find
that
it
actually
solves
the
problem.
C
Once
features
are
in
beta
they're
on
for
everybody,
but
they
can
still
be
turned
off,
and
so
what
we're
looking
for
to
go
from
beta
to
stable
is
that
it
hasn't.
You
know,
broken
anybody's
deployments
right
so
once
a
feature
goes
from
alpha
to
Beta
and
it's
on.
If
it
breaks
you
in
some
way,
you
can
flip
the
future
flag
and
turn
it
off
to
make
things
continue,
working
as
they
were
before,
once
we
go
from
beta
to
GA,
that's
no
longer
possible.
C
So
what
we're
looking
for
to
go
from
beta
to
stable?
Is
that
they're
not
breaking
anybody?
So
there
are
a
number
of
things
here.
I
think
I
sorted
them
in
the
meeting
notes
based
on
the
first
one,
the
first
set
of
ones
or
ones
going
from
beta
to
stable,
and
there
are
one
two
three
four
of
those
which
is
graceful
termination,
sck,
graceful
termination,
Custom,
Fleet,
auto
scalar,
sync
interval
the
state
allocation
filter
and
save
to
evict
those
have
all
been
beta
for
a
couple
of
releases.
C
Now
it
seems
like
from
my
gandering
at
the
issues
that
they're
all
ready
to
move
up
to
stable
and
the
three
that
are
currently
in
Alpha
that
it
would
be
nice
to
turn
on
by
default,
so
that
everybody's
is
using
them
are
the
split
controller,
extensions,
pod
host
name
and
resetting
metrics
on
delete,
I
think
out
of
those
three
the
first
one
is
probably
the
one
that
might
impact
people,
because
when
we
split
control
and
extensions,
it's
actually
changing
our
deployments,
I'm
going
to
be
running
an
extra
pod
or
two
in
your
cluster.
C
This
actually
has
a
number
of
benefits,
though,
and
I
think
we're
going
to
end
up
there
anyway.
So
I
don't
see
any
reason
to
wait.
This
gives
us
much
higher
reliability
on
The
Agonist
control
plane
and
does
allow
us
to
scale
out
the
governance
controller
from
one
to
many.
If
we
want
to
from
one
to
more
than
one,
which
is
great
in
terms
of
things
like
upgrades
and
resiliency
and
node
failure,
you
know
time
to
recovery
and
so
forth.
C
So
with
that
sort
of
diatribe
over
I
filed
issues
for
all
of
these,
if
people
want
to
follow
up
with
any
specific
one,
please
go
chime
in
on
the
issue:
we'll
use
lazy
consensus
for
moving
forward
and
the
ones
that
we're
particularly
excited
about
pushing
from
you
know
you
put
a
note
that
one's
already
moved
to
Beta,
so
I
missed
one
apparently
since
I.
A
B
C
A
B
D
I
think
the
only
thing
that
gives
you
pause
about
any
of
this
is
the
it
does
seem
like
a
lot
of
users
tend
to
stay
on
one
version
and
then
jump
much
later
and
so
I
don't
know
how
to
properly
get
signal
off
of
the
future
Gates.
D
So,
like
you
know,
I
think
SDK
graceful
termination
as
an
example
is
probably
fine,
because
118
is
like
a
year
and
a
half
old
or
something
but
like
the
ones
that
have
been
since
1,
30
I,
don't
know
what
the
right
answer
is,
and
similarly,
like
I,
don't
know
if
we
can
figure
out
a
right
answer
without
you
know,
I
think
that's
the
reason
that
laser
consensus
has
to
be
the
way
we
go
and
kind
of
telegraphing.
In
these
meetings
like
by
the
way
we're
doing
this
yeah
I.
D
C
Of
these
people
that
are
are
jumping
releases
like
even
like
all
the
ones
that
are
going
up
to
stable,
except
for
safe
to
evicted,
been
there
for
quite
a
while.
So
even
people
are
jumping
releases,
hopefully
have
jumped
into
a
release
where
this
is
already
on
by
default,
yeah
and
if
not,
then
they
might
have
to
run
an
old
release.
While
we
figure
out
what
what
bug
got
introduced,
which
has
definitely
happened
before
so.
A
A
This
is
basically
an
end
to
end
tested.
It
isn't
really
actually
backwards
like
it's,
not
a
breaking
change
in
terms
of
APR
or
anything.
It's
just
providing
more
more
stuff.
Just
I
think
a
lot
of
people
are
already
using
and
this
one
since
there's
an
option
to
always
turn
it
off.
I
think
that's
also.
Okay,
so
that
would
be
all
right.
I'll
write
notes
on
the
tickets,
but
that
would
be.
D
I
think
we
could
move
on
to
Max's.
That
sounds
like
we
dispatched
that
topic.
F
Yeah
sure
so
the
thing
I
want
to
talk
about
is
like
design
proposal
to
basically
expose
some
a
status
for
the
Philips
to
indicate
together.
F
The
background
is
that,
right
now
we
don't
have
like
such
a
indicator
in
the
fleet
to
to
to
tell
user
or
some
third
party
CI
orchestrator
advisor
of
lead
role
is
complete
or
not
especially
the
case
when
you
use
a
governance-based
cloud
deploy
when
you
trigger
a
route
through
Cloud
deploy,
you
will
say,
slow,
UI
or
CLI.
You
will
say
that
the
cloud
deployed
world
is
immediately
finished
after
you
submit
command.
F
You
know
either
no
matter
the
fleet
road
is
actually
finished
or
not.
So
the
general
design
idea
is
pretty
straightforward,
which
we
will
I
propose
to
integrate
with
another
open
source
Library,
which
is
called
quest
status,
which
provide
some
standard
status
which
can
be
understand
by
Cloud
deploy.
F
F
The
open
question
I
have
is
that
how
we
Define
the
completion
of
a
fleet,
rollout
I,
think
by
definition
when
certifying
the
completion
as
there
there
is
no
like
old
version
of
game
server
running
English
blades,
which
is
similar
as
the
definition
of
deployment
throughout
completion.
But
the
issue
is
that
for
Fleet
for
game
server
we
have
the
allocated
status
allocated.
State
will
not
be
terminated
or
scaled
down
by
during
a
layout
process,
so
this
will
make
the
reward
process
on.
F
If
customers
do
not
terminate
their
allocated
games
over
in
the
old
game,
server
set
like
for
a
long
period
Then
if
we
Define
the
road
process
of
it,
completion
is
like
there's
no
old
word
engagement
servers
then,
basically
their
route
will,
you
know,
never
finish,
or
only
finish
after
a
very
long
time
after
customer
manually
terminates
or
somehow
terminates
their
old
Gaming
server,
so
I'm
not
quite
sure
like
how
we
should
Define
this
completion
or
what's
the
use
case
or
customers
use
journey
like
how
they
will
use
this,
how
how
what's
the
real
state
or
real
you
know,
indicator
customers
care
about
yeah.
A
Thoughts
I
have
thoughts
but
you're
the
you're,
the
the
I
don't
say
token
end
user
here
for
your
ID.
A
E
Yeah
I
guess
usually
immediately
I'm
interested
when
I
change
the
fleet.
Just
for
the
the
ready
servers
once
they've
obviously
been
updated,
I'm
less
concerned
about
the
allocated
ones.
E
I
might
want
to
do
some
I,
don't
know
if
I
could
do
a
thing,
I'd
be
once
the
ready
ones
have
been
updated
and
then
maybe
later
on
allocated
but
I
think
yeah.
We
have
that
exact
use
case
where,
like
after
updating
a
fleet,
it
might
not.
You
know
the
allocator
service
might
take
a
day
to
recycle.
E
Yeah,
it
would
be
nice
to
actually
override
that
for
some
of
the
fleets
as
well
to
kill
the
allocated
servers
during
that
rollout.
But
that's
probably
a
different
problem.
D
The
the
thing
that
gives
me
pause
about
just
the
ready
servers
and
allowing
the
allocated
to
continue
is
that,
at
the
very
least
like
and
I,
obviously
come
from
a
more
traditional
like
web
services
thing,
but
like
wanting
to
know
that
the
binary
deployment
is
like
fully
rolled
out
is
sometimes
necessary
for
things
like
dependency
management.
So
if
you
have
like
binary
a
that
uses,
some
back-end
service,
like
version
one
that
uses
a
back-end
service
and
version
two
doesn't
and
you
want
to
know-
hey
I
can
actually
drain
that
back-end
service.
D
Now
that's
the
case
where
you
really
want
the
allocated
servers
to
to
be
relayed
as
well.
A
Well,
actually,
that's
a
really
interesting
point
deck
should
the
should
the
litmus
test
almost
be?
Has
a
new
game
server
gone
from
ready
to
allocated
and
had
someone
play
on
it
and
therefore
we
know
it's?
Okay,
oh
because
you're,
that's
literally
your
point
right,
like
an
international
web
service
manner,
you
would
roll
out
part
of
it
and
see
if
it's
still
working,
but
the
only
way
to
test
the
game.
Server
is
actually
have
some
play
on
it.
D
E
D
Thing
that
I
want
to
know
is
that
the
binary
that
uses
it
is
no
longer
there
but
you're.
What
you're
talking
about
is
actually
interesting
in
a
different
way,
which
is
yeah:
okay,
yeah,
which
is
Canary,
which
I
honestly
is
like
a
more
interesting
feature,
or
isn't
that
not
more
interesting?
But
it's
a
different
feature
right
well,.
A
Not
it's
not
necessarily
Canary
I'm,
just
thinking
about
it
when
like,
if
Okay,
when
is
when
is
a
fleet
rollout
done
enough
right
like
enough
right
like
because
I
think
that's
the
word,
because
in
theory
you
could
have
a
fully
allocated
Fleet
if
you
had
a
completely
full
cluster,
like
probably
has
not
like
you,
may
have
some
buffer,
which
would
be
ideal
right,
so
we
may
assume
some
buffer
you
could
you
could
argue
that
if
you
had
one
ready
game
server,
that's
enough
of
the
new
type,
Maybe
I
think
you
could
argue
if
all
of
them
were
replaced
from
everything
like
the
old
game.
A
Server
sets
gone
and
like
everything
between
is
gone.
I
think
you
could
also
argue
yeah,
actually
no
I'm
going
to
rescind
it
I
think
I
think
my
idea
of
like
if
what's
the
word
I
was
going
to
say
if
a
if
it's
played
on
it's
a
valid
rollout,
because
it
worked
because
I
think
you're
right,
I
think
that's
Canary,
and
if
you
want
to
do
that,
that
has
to
be
a
different
approach.
Yeah!
No,
okay,
no
yeah.
D
F
D
So
one
option
and
I
think
Mark
Hardy
said
something
like
this:
in
the
ticket
or
in
the
dock
somewhere
might
be
just
to
provide
configuration
as
to
which
which
thing
you
want
to
roll
out,
reconciling
to
be
tied
to
yeah
any
way
to
accomplish.
That
might
actually
be
to
relay
both
conditions
and
have
actually
like
three
like
what
I
would
say
is
like
have
a
three-way
so
that
you
can
have
call
it.
D
Maybe
you
know
reconciling
done
and
reconciling
or
reconciling
all
and
reconciling
ready
or
something
like
that,
and
then
there's
a
configuration
value
as
to
which
one
which
one
of
those
two
conditions,
the
actual
like
case
status.
D
Reconciling
condition
is
so
that
that,
like
reconciling
condition,
would
just
be
equal
to
one
of
the
two
values,
but
then
so
case
status
would
be
able
to
pick
up
the
reconciling,
depending
on
on
whatever
configuration
you
wanted.
But
if
you
wanted
to
have
like
custom
Logic
on
the
other
condition,
you
could
just
write
a
controller
that
was
looking
for
that
condition
too.
D
A
You
almost
I'm
I'm,
oh
I'm,
almost
wondering
if
it's
like
either
a
number
or
percentage
of
ready
of
the
new
version.
If
that
makes
sense
would
if
you
were
like,
we
say
we're
done
when
you
either
like
this
is
how
many
so
100
10
would
mean
that
or
you're
just
like
five
give
me
make
sure,
there's
five
ready
or
two
or
one
whatever
it
happens,
to
be
default,
could
either
be
one
or
100
I,
actually
don't
really
care.
F
Do
you
think
it's
enough
to
only
think
about
the
new
version
of
game
server,
the
customer
really
care
about
like
the
clean
out
process
of
the
old
Gaming
server,
because
I'm
thinking
about
because
maybe
they
care
about
the
resource
of
the
okay
over
game
is
over
consuming
so
like
how
many
over
game
server
is
already
cleared.
A
Which
I
just
need
to
drop
the
docs
on
pretty
much
to
have
as
a
thing?
Because.
F
A
E
Yeah
I
think
I
think
either
way
is
fine,
I
guess
as
long
as
the
the
command
line
isn't
hanging.
While
we
wait
for
the
elite
to
be
updated
right
for
a
day
and
we
have
to
control
C
and
then.
A
D
B
C
If
we
pick
one
way
to
do
it
to
start,
which
we
think
is
reasonable,
we
know
how
we
could
add
stuff
later
if
people
actually
need
it,
but
it
all
almost
feels
like
we're
over
designing
if
we're
adding
a
whole
bunch
of
stuff
that
we
think
people
may
need
in
the
future
or
might
want
to
do
it
slightly
differently,
whereas
right
now
that
doesn't
exist
at
all
and
once
people
know
like
oh
I
can
now
plug
into
case
status
or
hook
this
up
to
my
Jenkins
or
whatever.
C
Then
they
might
start
asking
for
things
that
we
haven't
thought
of
right.
So
if
we
say,
let's
put
the
condition
in,
let
people
start
using
it,
make
it
based
on
something
we
think
is
reasonable,
and
then
we
know
there
are
ways
we
can
change
that
condition
in
the
future
or
give
people
ways
to
set
it
differently,
et
cetera,
et
cetera.
We
can
always
add
that
later
I'm
not
sure
it's
necessary
to
add
from
the
start,
especially
when
Steven's
kind
of
like,
like
anything,
would
be.
C
Okay
right,
so
I
think
I
would
think
putting
something
in
there
we
can,
then
you
know
have
a
demo
of
using
it
with
case
status
of
using
like
rollouts,
explain
people
how
to
use
it
and
if
they
say
like
oh
you're,
telling
me
the
wrong
signal,
then
we
can
make
sure
we
put
the
right
signal
in,
but
we'll
give
them
a
signal
that
doesn't
exist
at
all
and
I
think
we
can
do
that
in
a
much
simpler
way.
To
start
there.
D
Was
actually
why
I
would
ask
the
overly
complicated
thing
is
like
similar
to
when
Mark
describing
described
like
percentage
blah
blah
blah?
It's
like
yeah.
We
could
do
all
these
things,
but
I
am
very
concerned
about
introducing
API
that
doesn't
seem
necessary
because
when
we
have
to
continue
to
support
it,
so
it
makes
sense
that.
C
Yeah
so
I
would
I
would
argue
to
start
with
something
simple
yeah
and
then
I
think
we
have
a
great
way
to
extend
it.
If
we
want
to
add
here's
how
you
can
tweak
how
this
variable
gets
set
through
extra
conditions
and
pick
which
one
gets
you
know
propagated
up
or
by
specifying
you
know
some
sort
of
rules
on
how
this
condition
gets
set
or
whatever
it
is
like
that
stuff
can
all
be
added
to
the
API
later.
C
E
Maybe
another
complication,
but
what
would
happen?
Let's
say
yeah
we
do
a
fleet
update
and
then,
but
before
it's
done,
we
do
another
Fleet
update.
Do
we
need
to
think
about
this?
What
happens
on
the
first
one?
Is
there
another
event
to
say
it
was
it's
overridden
or.
F
Yeah,
what's
the
current
anxiety
to
be
only
show
that
the
older
Fleet
is
doing
the
reconciling
the
programs?
So
no
no
difference
like
well
weather
is
like
override
to
a
new
flavor
out
or
something
else.
Yeah.
D
I
think
both
you
and
Steven
expressed
a
that
that
just
doing
the
ready
game
servers
seems
to
be
the
the
intuition
you
both
have
so
I
say:
let's
roll
with
that
as
y'all
are
actually
probably
more
experts
than
we
are
at
this
point.
C
A
E
F
Okay,
so
the
takeaway
for
me
is
that
we
will
start
from
simple
the
basic
condition
started.
Is
that
way
the
new
free,
the
new
game
service
that
have
won
better
game
server,
then
we
call
Face
Down
doesn't
make
sense?
A
Depending
or
was
it
did
you
say
either
as
soon
as
the
new
game
server
set?
Has
one
ready
game
server
were
done,
or
did
we
say
that
whenever
the
old
ready
game
servers
that
are
ready
get
replaced,
it's
done?
If
that
makes
sense,
or
is
it
something
in
between.
B
E
A
A
D
A
A
Actually,
the
the
if
it
doesn't
come
up
the
rolling
update,
should
actually
abort
there's
there's
some
stuff
in
there
about
that.
Oh
I
see
so
we
already
kind
of
do
that.
We
already
kind
of
do
that
anyway.
Okay,
I'm,
writing,
I'm,
just
gonna
I'm.
Writing
an
audit
Trail.
B
B
I'm
saying
that
only.
F
F
B
A
A
D
Well,
actually,
I
recently
backed
off
a
little
and
Max's
did
the
last
couple
days
of
Investigation,
but
both
of
you
then
yeah.
So
the
ede
has
to
been
very
flaky.
Recently
I
did
find
there's
a
gke,
seemingly
a
GK
product
issue.
That's
been
affecting
some
of
it
and
I.
Don't
we
we've
still
been
working
through
that
internally.
I
actually
need
to
get
some
time
to
look
at
our.
D
Of
it
and
work
with
teams
here,
but
we
think
that
I
I
I
think
it
has
a
workaround
in
the
EES.
That's
already
present
in
Maine.
D
Max
took
the
most
recent
run
at
this,
and
it
is
a
very
broad
set
of
failures
that
all
kind
of
seem
to
be
failing
in
different
ways
and
we
don't
have
a
handle
yet
on.
What's
what's
going
on
and
then
Max
I
think
you
said
it
actually
cleared
up
for
a
little
while.
So
it's
kind
of
you
know,
weather
related
or.
A
So
I
I
was
happening
and
we
don't
know
why.
The
worst
kinds
of
bugs.
D
Yeah
so
Stephen
I
hope
this
is
inspiring
a
lot
of
confidence.
A
D
F
D
Just
a
big
query
table
that
I
set
up
might
make
it
fairly
trivial
to
see
where
the
need
to
eat
test
failures
are
like
whether
there
is
really
a
cluster
on
the
autopilot
side,
so
it
might
be
we'll
see
if
I
can
poke
some
Cycles
into
that
soon
and
then
separate
from
the
edes
Max.
Didn't
you
call
it
yesterday
that
there
was
like
the
SDA
SDK
conformance
test,
just
started
flaking
no.
A
F
A
D
You've
mentioned
the
fix,
well,
you've
mentioned
afix
for
it
several
times
and.
A
Wait,
oh,
we
have
a
bug
for
C
sharp
conformance
test,
but
we
absolutely
do.
We
have
that
as
a
thing
here
we
go.
Yeah
I
found
it
I
found
the
one.
D
Because
that
that
particular
test
has
written
us
several
times
and
the
the
most
infuriating
part
of
it
is
when
is
when
I
see
the
flake,
we
I
intuitively
just
go
and
hit
the
retry
build
button,
and
it.
A
D
So
us
kind
of
a
more
general
question
of
how
to
get
confidence
back.
Max
and
I
have
been
talking
about
using
some
bandwidth
during
this
Fix-It
to
try
to
like
I've,
been
trying
to
work
on
those
kind
of
reports
on
like.
B
D
And
ede
flakes
I
think
between
that
and
then
also
improving,
like
how
we
either
fan
the
logs
out
or
or
like.
A
D
Yeah
I
totally
agree
with
that,
and
so
maybe
there's
some
some
ideas.
We
could
take
forward
to
try
to
help
with
that.
You
know
one
idea
that
I
had
on
on.
D
D
Back
script
that
Max
already
has
for
like
Fanning
out
the
build.
You
could
then
like
kind
of
bring
together
all
the
stuff
and
and
and
then
dump
the
logs
out,
but
like
that's
how
we
handle
it
internally
is
like
when
our
internal
builds
fail
like
we,
we
often
have
a
whole
set
of
like
different
log
files
to
look.
D
Yeah
exactly
and
if
we
had
such
a
like
a
pert
test,
ground
I
could
also
then
like
I
once
had
Aaron
turned
on
the
helm,
debug
logs,
because
his
his
build
kept
failing
during
Helm
install
but
that's
the
helm
debug
is
is
like
20
times
bigger
than
our
media.
E-Logs
and
I
was
like.
Oh
that's
not
going
to
work
in
general
and
it'd.
Be
nice
if,
like
I,
could
just
do
that
and
then
redirect
standard
error
to
somewhere
else.
D
So
we
always
have
the
Helen
debug
log
logs
available,
because
you
know
it.
There
is
like
a
one
in
20
or
150
flake
or
something
where
we
just
run.
We
try
to
run
the
helm,
install
on
E
to
e
and
it
fails,
and
it's
like
well
there's
no
way
I'm
going
to
be
able
to
debug
that,
because
I
don't
have
anything
to
go
on.
D
So
there's
an
idea
running
around
there
somewhere
of
like
okay.
Maybe
we
just
have
more
a
way
to
get
more
artifacts
out
of
the
build.
Maybe
that's
an
interesting
request
for
cloud
build
of
like
how.
How
is
this
pattern
supposed
to
work?
Is
there
a
way
that,
like
a
build
container,
can
you
know
specify
like
an
artifact
directory
of
this.
A
A
D
So
I've
been
doing
a
little
bit
of
picking
on
that
too
yeah
just
for
context
of
anyone.
Listening
like
four
months,
I,
don't
remember
how
long
ago
I
changed
it
so
that
we
retry
our
end-to-end
tests
using
this
package
called
go
test,
some,
which
is
super
nice
yeah.
It's
it's
an
interesting
package
and
that
it
basically
just
runs,
go
test
just
Json,
and
that,
like
is
basically
just
a
harness
around
go
test,
Jason
that
that
then
looks
at
whether
the
test
failed
or
not,
and
and
reruns
the
tests
it.
D
It
is
conservative
when
a
test
panics,
which
is
why
sometimes
you
see
ede
runs
where
you'll
see
like
a
panic
at
the
at
as
one
of
the
first
failures.
Oh
and
then
you'll
see
a
bunch
of
like
unknown
tests
because
on
the
panic,
the
test
harness
takes
out
like
all
of
the
other
tests
and
so
you'll
see,
go
report
them
as
unknown.
D
I've
been
doing
some
light,
scrubbing
anytime,
I,
see
something
like
that.
Like
I
sent
the
pr
to
Max
on
Monday,
where
like,
for
example,
we
have
a
slew
of
tests,
I
actually
just
fixed,
like
a
dozen
of
them
in
the
fleet
tests
where
they
were
using
like
a
cert,
not
nil
or
a
certain
nil
on
on
errors.
But
then
then
they
would
just
continue
on
so
I
changed
them
all
to
run.
D
Yeah
yeah
yeah
in
a
funny
case,
where
required
is
actually
the
right
thing
versus
like
that
weird
other
case
we
found.
C
A
D
That
makes
sense
if
we
wanted
to
maybe
as
part
of
the
fix
it
again
like
if
we
wanted
to
have
like
a
concerted
effort
to
kind
of
audit
the
tests
and
figure
out,
like
you
know,
just
bang
through
and
say,
make
sure
that
like,
if
you
hit
an
error
and
you
and
you're
also
taking
a
a
pointer
to
an
object
like
you,
stop
there
because
you're
about
to
look
at
it
and
and
panic
like
that.
That
could
be
something
we
do.
D
On
the
other
hand,
handling
it
kind
of
piecemeal
as
they
come
up,
is
not
the
end
of
the
world
either.
No.
A
That
makes
a
lot
of
sense.
The
other
thought
I
had
in
my
head
that
you've,
probably
already
thought
of
I,
had
a
look
especially
thinking
of
like
autopilot.
D
Like
early
on
in
the
autopilot
side,
I
actually
did
change.
There's
a
framework
most
of
the
calls
that
wait
for
resources
like
wait
for
a
ready
game
server,
Etc.
D
Go
through
like
a
framework
retry
of
some
sort
like
wait
for
ready,
blah,
blah
blah
and
there's
kind
of
just
now
a
there
was
like
a
hard-coded
like
five
minutes
and
I
think
I
buffed,
that
to
like
10
minutes
for
autopilot
early
on
just
because
it
makes
sense.
I'm
not
like
I
would
like
to
know.
If
that's
what
is
causing
it,
because
I
inserted
that
just
for
the
any
flakiness
around
the
nodes
coming
up,
or
rather
any
like
you
know,
the
P90
on
a
node
starting
on
autopilot
might
be
above
five
minutes.
D
D
So
but
autopilot
could
be
causing
us
something
some
other
problem
and
that
that's
what
it
might
really
work
out.
Yeah
and
the
other
part
is
that-
and
this
is
you
know,
kind
of
what
we're
trying
to
work
through
internally
as
well,
is
that
our
standard
clusters
are
very
standard
clusters
like
they're,
pretty
much
like
the
bog
standard
configuration
if
you
were
just
to
run
the
defaults.
D
So
autopilot
has
much
more
of
the
the
kind
of
fancy
features
for
gke.
It
has.
You
know,
workload,
identity,
it's
running
data
path,
V2,
it's
running
like
all
of
the
features,
because
those
are
the
features
we
think
that
you
know
people.
D
Running
anyways,
and
so,
like
you
know
whether
it's
autopilot
or
whether
it's
like
ABCD
feature
is
unknown
at
this
point,
and
we
may
be
seeing
like
issues
with
some
other
feature
that
we
could
probably
reproduce
on
standard
as
well.
So
it
makes
sense.
A
D
We
are
not
right
now,
but
actually
that
was
the
reason
I
set
up
the
question
yeah
like
we're
now
logging
to
a
bigquery
sync,
so
that
I
can
do
someone
else
like
post-hoc
analysis
on
it,
and
that
was
actually
one
of
the
reasons
was
I
was
gonna.
Try
to
have
it
output
in
some
funny
way
that
I
could
pick
up
in
that,
but
yeah.
D
One
report
does
a
an
inference
on
like
whether
it
was
an
internal
retry.
It
also
tries
to
make
an
inference
on
have
I
ever
seen
as
an
example
have
I
ever
seen.
This
commit
past
on
this
configuration
at
all.
D
So
if
someone
actually
went
and
retried
the
entire
build,
it
says
you
know,
oh
I
have
seen
you
know
hash
abc123
pass
on
autopilot126
before
Ergo.
If
anything
fails,
it
must
be
a
flight.
So,
like
we
have
several
layers
of
possible
retries
that
can
all
kind
of
come
into
play.
There.
D
D
We
should
probably
move
on
to
the
to
your
thing
if
the
other
stuff
yeah
I,
was
realizing,
we're
only
10
minutes
left.
Oh.
A
Boy
mine's,
pretty
easy,
I
just
need
to
push
up
the
docs,
and
then
that's
done.
I
actually
have
the
docs
I
just
need
to
push
them
up.
A
A
And
it's
improved
and
it's
gone
through:
let's
go
ahead
and
I'll
feature
gate.
So,
yes,
we'll
have
that
functionality
around
just
yeah
once
yeah
once
the
what's
wrong
call
it
the
case
status.
Stuff
comes
through
for
the
mechanisms
for
rollouts
people
will
be
able
to
do
a
bit
of
both,
which
is
nice.
B
D
So
we
now
have
moving
on
to
the
last
topic.
We
now
have
a
robot
that
will,
do
you
remember
the
the
timing
criteria.
It
marks
things
stale
after.
Oh,
you
see
you're
here.
Do
you
wanna?
Do
you
want
to
talk
to
that
part.
G
Yeah,
so
basically,
if
the
issue
is
not
is
inactive
for
more
than
30
days,
it
will
start
marking
the
issues
clue
a
steal
they've
made
for
another
30
days.
If
there
is
an
activity,
then
it
will
mark
this
is
obsolete
and
if
still
inactive,
then
it
will
close
it.
G
So
we
activated
this
GitHub
action
this
month,
so
there
are
around
seven
eight
issues
that
got
marked
as
still
because
we
don't
want
to
mark
all
of
them
at
once,
because
it
will
be
too
much
to
handle
so
some
of
them
I
think
Mark
marked
them
as
we
still
need
it
and
he
added
that
awaiting
maintenance
label
so
that
it
will
not
be.
It
will
be
excluded
from
monitoring
so
right
now
there
are
other
five
issues
that
are
marked
as
stale.
G
So
do
we
want
to
take
a
look
at
those
or
what
should
we
do.
D
So
I
think
Max
proposed
that
in
this
meeting
we
could
actually
just
triage
the
stale
issues
and
we
could
probably
just
insert
this
as
an
ongoing
thing
Mark.
If
that
sounds
reasonable
to
you,
yeah.
D
Because
then,
we'll
always
just
have
a
process
of
every
month
we
go
through
and
try
to
make
sure
the
stale
issues
have
some
sort
of
like.
If
we're
going
to
close
them.
We
at
least
do
it
publicly.
C
I
just
figured
it
was
only
five
I
think
we
could
do
it
pretty
quickly,
yeah,
so
on
this
first
one
can
we
start
from
the
top
or
the
bottom
all
right.
Let's.
A
C
Got
them
all
open
in
tabs,
so
so
this
is
actually
interesting
because
I
think
there
are
multiple
solutions
to
this
problem.
Now,
I
think
when
this
was
filed,
those
didn't
exist
or
we
didn't
know
about
them,
so
I
think
for
UDP
Game
servers.
We
can
use
quokken
and
then
you
can
use
Note,
7,
external
IP
and
for
TCP
Game
servers.
We
know
that
you
can
use
traypic
and
you
can
use
nodes
without
an
external
IP,
so
we
actually
have
solutions
for
this.
C
I.
Think
really.
The
ask
at
this
point
is
just
to
sort
of
document
and
or
put
together
a
demo
of
how
to
use
them.
So
we
can
either
leave
this
open
and
say
that
these
are
the
two
solutions.
We'll
close
this
with
documentation
or
we
can
close
this
with
I
already
dropped
a
comment
on
here
a
while
back
about
Quicken.
C
We
can
add
a
note
about
traffic
if
you
want
to
do
TCP
and
kind
of
leave
it
up
to
you
know,
folks,
to
find
and
or
discover
those
Solutions
through
the
issue
so
I
think
either
way
would
be,
would
be
fine
if
we
want
to
leave
this
as
a
documentation
tracking
issue,
I'm,
okay,
leaving
it
open
or
we
can
just
kind
of
let
it
close
on
its
own.
G
This
issue
I
think
Robert
had
already
added
steel
level.
That's
why
it
has
got
obsolete
levels,
so
it
will
get
closed
in
next
30
days
if
it
is
not
addressed.
So
do
we
want
is
that
okay.
D
I'm
not
against
changing
this.
To
you
know,
document
quilkin
or
other
options.
I
would
just
change
the
issue
title
and
then
put
in
a
waiting,
maintainer
or
whatever
on
it,
or
we.
A
A
A
B
Oh
and
I
do
that:
let's.
A
B
A
This
could
be
a
great
actually.
This
is
a
good
first.
You
should
probably
because
there's
a
doc's
issue.
G
Is
it
something
that
can
like
and
since
you
added
it
as
first
good
issue,
is
this
something
color
can
help
yeah
yeah
I
think.
B
B
A
So
this
is
about
passing
average
three
metrics
on
game
server
to
open
census.
I
I
was
thinking
let
this
just
pass
through
yeah
and
let
the
system,
unless
someone
immediately.
B
A
C
B
A
I
have
no
strong
opinions
either
way.
I
could
flip
a
coin
I,
don't
care
go
ahead
and
close
it
all.
B
A
B
A
B
A
We
got
asked
about
this
a
lot
in
the
past.
I,
don't
think
like
there
probably
had
more
Legacy
Game
servers.
I,
don't
think
it
happens.
Nearly
as
much
but
I
figured
seems
like
a
good
one
to
see.
If
somebody
complains
about.
A
Weird
Legacy
Game
servers,
they
have
a
thing
security,
best
practices.
A
A
The
right
spot
in
the
docs
and
just
some
clean
up
it
wasn't
terrible,
but
I
also
wonder
whether
it's
we
could
actually
just
be
like
go
look
at
these
kubernetes
docs.