►
From YouTube: Agones Community Meeting April 2022
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).
B
Was
asking
before
we
started
recording
if
we
record
the
meetings-
and
I
assured
him
that
we
did
but
then
I
was
scrolling
back
through
the
meeting
notes
and
couldn't
find
links
in
a
bunch
of
the
recent
meetings
and
steve
found
the
youtube
channel
that
it
looks
like
we
upload
stuff
too.
So
I
think
we
have
been
recording
meetings,
but
we
just
haven't
necessarily
been
putting
all
of
the
links
into
the
doc
because
it
looks
like
looking
at
the
youtube
channel.
Like
I
see
one,
I
guess
these
are
old.
A
I'll
check,
I
don't
have
anything
sitting
in
my
email
which
but
I'll
double
check
and
find
it,
but
yeah
we
did
skip
a
few
with,
like
you
know,
we
didn't
last
month
because
of
gdc
and
other
fun
stuff.
So
that's
why
there's
there
some
of
the
gaps
are
intentional,
but
yeah
I'll
double
check.
Awesome.
B
There
to
remind
you,
okay,
so
the
next
couple
things
were
sort
of
just
reminders
announcements.
I
just
finished
the
last
set
of
prs
to
update
us
to
support
kubernetes
1.22
for
the
next
release.
It's
been
a
while,
I
think
when
I
looked
it
was
like
last
october.
The
last
time
we
updated
kubernetes
version.
So
this
is
maybe
a
bit
overdue,
but
we
are.
B
We
are
keeping
keeping
up
with
the
the
releases
as
best
we
can
and
and
now
we're
up
to
1.22
and
after
we
cut
this
release
I'll
check
and
see
if
it's
already
time
to
update
to
1.23,
so
we're
gonna
definitely
try
to
keep
up
with
with
your
image
releases
and
make
sure
we
don't
one
point.
In
the
past.
We
started
following
far
enough
behind
that
we
were.
B
People
were
getting
concerned
that
we
wouldn't
have
any
goodness
released
that,
like
supported,
I
think
it
was
either
gk
or
azure
versions
before
we
like
they
started
dropping
the
ability
to
create
those
versions.
So
I
just
want
to
give
people
a
heads
up.
The
next
release
will
have
a
new
kubernetes
version,
for
you
know,
implications
for
upgrades
and
so
forth,
and
that
also
kind
of
segues
into
the
next
thing,
which
is
the
next
release,
is
coming
really
soon.
Next
tuesday,
in
particular,
is
the
release
candidate.
B
So,
if
there's
anything
you
are
hoping
to
get
into
the
next
release,
please
get
those
pr's
out,
and
maybe
ping
me
in
slack.
If
you
need
a
quick
review,
so
we
can
make
sure
stuff
gets
merged
and
then
we'll
go
into
our
week-long
feature
freeze
before
cutting
their
release.
B
The
one
thing
I
did
want
to
highlight
so
there
is
there's
been
a
pr
out
for
quite
a
while
to
add
support
for
arm
or
at
least
initial
support
for
arm
in
terms
of
building
some
stuff,
and
we
expect
that
to
be
in
before
the
release
candidate.
So
this
is
something
that
you're
interested
in
you
know.
Testing
out
or
using
this
release
candidate
would
be
an
awesome
one
for
you
to
try
and
you
know,
take
a
build
and
see
if
it
works.
B
Because
that's
that's
gonna,
be
you
know
pretty
early,
it's
it's
probably
we're
not
going
to
probably
call
it
completely
supported
yet,
and
I
think
that
the
author
of
that
pr
said
that
there
were
a
couple,
a
couple
more
follow-ups
after
this
one
for
us
to
be
finished
supporting
arm.
But
I
want
to
give
people
a
heads
up
that
this
is
coming
and,
if
you're
interested
to
please
try
it
out
either
with
the
release
candidate
or
with
with
the
next
release.
B
B
So
I
called
out
a
couple
of
here
that
I
thought
might
be
ready
to
graduate.
So
we
have
no
external
dns,
which
is
currently
in
beta.
It's
been
invaded
for
a
little
while
now
we
have
the
custom
fleet,
auto
scaler,
resync
period
and
graceful
termination,
which
have
both
been
in
alpha
for
quite
a
while.
So
I
think
that
the
node
external
dns
has
been
in
beta
since
119
we're
about
to
cut
123.
B
the
custom
recent
period's
been
in
alpha
since
117,
and
the
graceful
termination
has
been
in
output
since
118..
So
for
all
those
there's
been
quite
a
bit
of
fake
time
and
you
know
for
the
alpha
ones
to
graduate
to
beta
what
we'd
like
is
for
someone
to
actually
kind
of
be
using
them
and
say
that
it
works
and
it's
ready
to
be
turned
on
by
default,
for
everyone
for
the
beta
ones
to
graduate
to
ga
like.
B
Similarly,
it
would
be
great
if
somebody
was
using
it
and
saying
that
it
worked
properly
in
this
case
it's
already
on
by
default,
and
so
we
have
pretty
good
confidence
that
it's
not
going
to
break
things
if
we,
if
we
move
it
to
ga,
because
all
that
that
does
is
prevent
you
from
turning
it
off.
B
But
if,
if
anybody
is
currently
turning
it
off,
we
definitely
want
to
hear
about
that,
because
this
this
moving
at
the
ga
would
prevent
people
from
being
able
to
turn
it
off.
So,
if
there's
anything
that
definitely
doesn't
work
about
node
external
dns,
that
would
be
a
great
thing
to
highlight
and
call
out.
Realistically
none
of
these
are
going
to
get
promoted
before
the
release
next
week.
B
Right
because
there's
not
very
many
days
left,
but
I
think
these
would
all
be
sort
of
on
the
radar
for
maybe
being
promoted
for
the
following
release
six
weeks
later,
and
so,
unless
there
are
any
objections,
I
think
I'm
going
to
create
tickets
to
bump
all
of
these
up
mark
them
as
help
wanted
in
case
anybody
wants
to
jump
on
those
and
also
try
to
to
see
if
we
can
find
people
that
are
actually
using
them
to
comment
on
on
whether
or
not
they're
working
for
them
right.
B
So,
in
particular,
like
graceful
termination,
was
contributed
by
someone
who
said
they
needed
it.
So
you
know,
presumably
that
person
has
flipped
this
feature
flag
and
is
actually
using
it,
and
maybe
it's
happy
in
that
state,
but
we
could,
we
could
bump
it
up
to
beta
and
they
would
they
wouldn't
have
to
flip
the
feature
flag
anymore
right
same
thing
with
the
other
two.
B
So
that
was
all
on
future
updates.
The
question
in
slack
was
about
player
tracking
and
said
you
know,
player
tracking
has
been
been
in
alpha
for
quite
a
long
time.
I
think
they've
mentioned
it's
been
almost
two
years
now,
which
is
which
is
getting
kind
of
long
on
the
tooth,
and
when
I
look
it
says
alpha
since
1.6
right
and
we're
about
to
cut
123..
B
I
think
that
part
of
the
reason
for
that
is
that
the
other
parts
of
the
player
tracking
features
are
under
different
feature
flags
and
didn't
come
out
to
1.14,
so
they
haven't
been
in
alpha
for
quite
as
long
and
the
other
part
is
that
after
the
player
tracking
apis
got
in
place,
there's
a
bit
of
feedback
saying:
oh,
why
don't
you
write
those
apis
in
a
slightly
different
style
and
you
know
mark,
and
nobody
else
has
had
a
chance
to
kind
of
go
back
and
rework
those,
and
so
I
don't
have
a
great
eta
for
when
player
tracking
might
move
to
beta.
B
That's
a
much
larger
feature
to
move
forward
like
all
of
the
ones
that
I
called
out
here
are
pretty
small
things
that
are
very
low
risk
and
we
have
high
confidence
that
they
work
correctly,
whereas
player
tracking
we
both
want
to
rewrite
the
apis,
make
sure
they
still
work
and
then
and
then
talk
about
moving
it
to
beta.
So
if
anybody
is
depending
upon
the
player
tracking
apis
is,
you
know,
is
using
those
like
you
know,
either
is
really
in
in
favor
of
changing
apis
or
really
doesn't
want
to
change
the
apis.
B
I
think
that
would
also
be
great
feedback,
because
maybe
the
you
know
the
comments
about
changing
the
apis
are
two
years
old
and
we
don't
care
as
much
anymore
and
we'd
rather
take
what
we
have
that's
working
and
push
it
forward.
B
So
I
think
I
think
mark
will
be
back
for
the
next
community
meeting
next
month
and
we
can
definitely
put
player
tracking
status
and
potential
feature
promotion
on
the
agenda
for
for
picking
his
brain
to
see
where,
because
he
might
have
some
other
information
that
I
don't
have
about
that
as
well
cool
all
right
steven,
you
had
a
idea
about
passing
parameters
to
game
servers
during
allocation.
C
Yeah,
so
I
don't,
I
don't
know
if
there's
a
good
idea
or
not,
but
I'm
just
thinking
so
one
of
the
things
we
currently
do
is
have
different
game
modes,
and
so
we
have
a
fleet
for
each
game
mode.
But
I
was
wondering
I
was
thinking.
Why
don't
we
like
just
have
fleet
of
you
know
just
a
pool
of
game
servers
and
then,
when
we
allocate
them,
we
then
switch
it
to
a
certain
game
mode.
C
But
I
was
kind
of
wondering
about
if
there's
anything
already
available
for
that
or
is
that
something
the
thing
is:
it
might
mess
with
the
life
cycle,
because
then
you've
got
kind
of
ready
and
allocated,
and
it's
like
well
what?
If
it
takes
some
time
to
allocate
while
it's
activating
that
game
mode.
B
Yes,
so
there
is
something
you
can
pass
in
the
allocation
request
that
sets
extra
metadata
fields
on
the
game,
server
resource
and
the
intent
of
that
feature
is
to
do
kind
of
what
you're
describing
so
you
could
say
I
want
to
allocate
and
the
game
server
is
allocated.
You
should
tell
it.
I
want
map,
you
know
queue
and
then,
if
the
game
server
process
is
is
watching,
you
know
the
game.
Server
resource
it'll
get
a
callback
that
says
labels
have
changed,
you
know,
it'll
call.
The
callback
once
you've
been
allocated.
B
You'll
also
get
a
callback,
because
labels
have
changed
now.
It
says
map
queue
which
will
allow
the
game
server
to
kind
of
switch
into
that
mode.
You
have
a
great
point,
though,
about
timing
and
delays,
because
I
think
it's
it
kind
of
assumes
that
you
know
that
allocation.
The
allocation
is,
is
sort
of
instantaneous
right.
B
You
switch
from
ready
to
allocated
and
we
immediately
return
that
information
back
to
where
it
can
be
given
to
the
client
to
connect
right
away
and
if
it
takes
a
while
for
a
game
server
to
switch
from
I'm
ready
to
be
put
into
one
of
three
different
modes.
But
when
you
tell
me
which
mode
to
go
into
it
takes
a
little
bit
of
time
to
get
there,
there's
not
really
a
great
way
to
represent
that
right
now.
B
So
I
think
the
one
way
you
could
do
that
is.
You
could
have
like
your
matchmaker
system
in
the
middle
ask
for
something
to
be
allocated
with
a
specific
map,
get
the
information
back
about
which
game
server
has
been
allocated.
So
you
know
the
game,
server,
id
and
the
port
and
so
forth.
B
It
would
move
to
the
allocated
state
which
will
prevent
the
system
from
deleting
the
game
server,
which
is
great
like
during
auto
scaling
or
upgrades,
but
it
could
then
go
back
and
watch
the
game
server
resource
for
the
game,
server
to
update
another
label,
saying
it's
actually
ready
for
people
right,
so
the
game
server
could
be
watching.
Saying
great.
B
I've
been
allocated,
I
get
this
map
load
up
the
map
and
then
recall,
set
labels
or
set
annotations
to
put
information
back
into
the
game
server
resource
that
it's
it's
ready
for
players,
and
then
the
matchmaker
can
basically
hold
that
connection
for
some
amount
of
time
and
then
return
it
back
to
the
clients
right.
So
it
does
sort
of
delay
allocations,
because
the
matchmaker
would
would
need
to
kind
of
wait
during
that
time
because
there's
nothing
sort
of
inherent
in
the
system
right
now
that
represents
that
intermediate
state
of
I've.
B
You
know
I've
asked
for
somebody
but
they're
they're,
there's
a
delay
between
allocation
and
actually
being
ready
to
serve
people
there.
There
also
might-
and
I
haven't
checked,
but
there
might
be
something
in
the
player
apis.
That
would
facilitate
that
as
well
like
you
might
be
able
to
like
set
player
capacity
to
zero
but
allocate
and
then
have
the
game.
Server
make
a
call
to
increase
player
capacity
which
might
sort
of
effectively
do
the
same
thing
as
if
you
were
using
custom
labels
to
do
it.
A
B
Reallocation
call
to
then
go
back
and
find
the
one
once
the
player
capacity
increased.
So
I
don't
know
you
might
might
take
a
look
at
that,
but
I
know
that,
like
the
custom,
labels
thing
would
work,
but
what
would
change
like
from
the
architecture?
Point
of
view
is
instead
of
ask
for
an
allocation.
Get
it
right
away.
B
Allow
client
to
connect
you'd,
have
to
ask
for
an
allocation,
wait
some
amount
of
time
and
then
allow
the
client
to
connect,
so
that
latency
might
not
be
a
huge
deal
to
clients
if
they
say
like
you
know
me
to
a
match,
and
it
you
know,
spends
for
25
seconds
instead
of
20
seconds,
because
you
have
to
find
other
people
anyway,
then
you
know.
Maybe
it's
not
not
a
big
change
from
the
game
player
perspective.
B
So
I
might
experiment
with
those
and
and
see
how
they
work.
You
could
also
file
a
ticket
and
say
like
hey,
like.
Is
this
worth
adding
a
new
state
right?
So
I
think
you
know
right
now
we
have
our
state
diagram
with
the
different
states
and
the
the
reason
we
have.
The
ready
state
is
exactly
for
this
problem,
but
during
startup,
and
so
we
could
say,
is
it
worth
making
a
formal
state
that
is
like
this,
like
sort
of
transition
between
ready
and
allocated,
but
not
ready
for
client
connections?
B
I
think,
if
you,
if
you
look
at
the
documentation,
we
have
right
now.
It
says
like
we'd
like
to
not
add
any
more
states,
you
can
use
labels
right,
which
is
sort
of
what
I
described.
B
But
if
it's
a
common
enough
use
case,
then
we
can
turn
that,
like
label-based
flow
into
a
proper
state,
that's
supported
so
and
either
way.
We
can
also
add
documentation
to
describe
how
that
would
work
too
right.
We
have
like
the
section
on
integration
patterns
and
we
can.
We
can
add
a
section
to
the
website
for
how
to
do
these
sorts
of
things
too.
C
Yeah,
that's
great,
I
guess
there
could
be
a
risk.
Even
what
I'm
suggesting
that
if
requests
for
two
different
game
modes
come
in
soon
together,
then
we
might
not
have
the
capacity,
because
I'm
thinking
I'll
just
make
a
big
pull.
But
I
guess
you
could.
If
you
had
a
lot
of
game
modes,
you
could
make
enough
a
large
enough
shared
pool
to
kind
of
right.
B
B
I
mean
it
would
still
be
creating
multiple
fleets,
but
you
could
you
could
use
labels
on
the
game
servers
and
on
the
allocation
requests
to
say,
like
I
know
that,
like
this
binary
supports
these
three
different
types,
and
so
I
can
put
those
labels
and
allocate
and
say,
give
me
something
of
type
a
this
game.
Server
is
labeled
with
types
a
b
and
c,
so
we
can
support
any
of
those
I'll
pick
from
that
pool
right.
So
you
can
kind
of
mix
and
match
also
to
sort
of
tune.
B
Cool
all
right,
so
the
last
thing
we
have
currently
on
agenda
is,
I
also
put
your
name
on
april,
which
is
meeting
time.
I
was
going
through
old
meeting
notes
and
there
were
a
couple
things
I
wanted
to
follow
up
on
with
mark,
but
he's
not
here.
So
I
picked
one
to
follow
up
on
with
you,
since
you
are
here
which,
as
you've
mentioned
in
the
past,
that
we
might
want
to
try
to
find
a
different
meeting
time.
B
A
Yeah
we're
going
to
do
a
quick
survey
for
the
community
in
general,
so
I
was
working
with
our
survey
team
and
you
know
we.
We
just
had
some
another
fun
google
reorg.
So
when
we
can
get
all
that
back
in
place,
we'll
run
it
again.
Okay,.
B
B
I'll
said
alarm,
because
I
really
want
to
come
to
this
next
one,
but
it's
definitely
not
a
time
that
they
could
attend
regularly
right.
So
I
know
we're
kind
of
stretching
like
early
morning,
pacific
and
late
in
the
day
for
stephen
right
now
and
kind
of
balancing
those
two
and
the
other
thing
I've
seen
done
in
the
past
also
is
having,
and
this
can
be
difficult
for
people
to
remember,
but
you
can
have
the
time
like
changed
like
this
month.
We
have
one:
that's
emea
friendly
this
one.
B
I
think
that
will
do
it
for
today,
when
is
our
next
meeting
scheduled?
Is
it
like
the
end
of
may
some
point.
B
Awesome
well
by
then
we
will
have
another
release.
We
might
have
farm
stuff
more
finish
than
it
is
today.
We
might
be
upgrading
to
another
version
of
community,
so
lots
of
exciting
stuff
coming
future
and
then
hopefully,
some
of
the
features
will
also
make
make
some
forward
progress
between
123
and
124.
C
B
Yeah,
no
so
that
kubernetes
122,
I
finished
so
that
that
is
done
for
one
to
1.23.
So
what
I'm
saying
is
we
might
have
another
one
for
124.,
so
we
might
check
and
say,
like
oh
gosh
like
we,
you
know
we
waited,
I
think,
five
or
six
months
to
do
this,
one
which
might
mean
that
another
one
is
ready
to
do
right
away.
At
one
point,
the
cadence
was
kind
of
lined
up
where
basically
every
other
release,
we
were
upgrading
kubernetes
and
it's
been
quite
a
few
now
without
us.
B
Upgrading
so
kubernetes
has
also
slowed
down
their
release.
Cadence
a
little
bit.
They
went
from
doing
four
releases
per
year
to
three
releases
per
year
when
it
was
four
releases
per
year,
was
basically
one
every
three
months
and
we
cut
every
six
weeks,
so
it
lined
up,
like
almost
perfectly
calendar
wise,
that
we
were
going
twice
as
fast
as
them.
B
So
that
makes
sense
that
we
did
every
other
one
now
they're
down
to
one
every
four
months
instead
of
every
three
months,
and
so
like
the
the
timing
is,
is
not
quite
as
consistent
and
then
also
for
our
upgrades.
What
we
always
check
for
and
if
you
look
back
in
the
last
last
meeting
notes,
is
to
making
sure
the
cloud
providers
support
them,
and
so,
even
if
kubernetes
cuts
a
new
release,
it
often
takes
a
little
while
before
it's
available
on
enough
of
the
cloud
providers
that
we
feel
confident
upgrading.