►
From YouTube: Agones Community Meeting June 2021
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
The
first
thing
on
the
agenda
I
put
was
kubernetes
119
support,
so
I
started
working
on
this
and
cindy's
helping
out
with
the
client
go
updates,
and
one
thing
so
I
want
to
mention
like
this.
This
will
be
in
the
next
release,
like,
I
think
we're
we're
on
track
for
it
to
be
the
next
release,
which
is
great
I'll,
also
move
everything
up.
A
A
This
the
the
eol
for
118
on
aks
really
soon,
and
so
it's
really
important
for
us
to
get
119
support.
But
this
does
kind
of
make
me
wonder
if
we
should
start
to
think
about
our
policy
and
maybe
changing
it,
because
the
the
skew
between
the
different
cloud
providers
has
gotten
a
lot
wider
than
it
used
to
be.
C
D
I
guess
the
question:
I
think
it
wow.
That's
a
tough
one
because,
like
we
have
this
six
week,
cycle,
yeah
and
and
like
that
works
for
a
lot
of
good
reasons.
But,
like
I
don't
know,
is
there
a
perfect
system?
I
guess
you
were
talking
like
you
and
I
were
talking
offline.
I
think
gilker
was
there
too
about,
like
maybe
testing
more
versions
or
being
plus
one
or
something
is
that
sort
of
where
your
head's
going.
A
I
think
the
cloud
providers
used
to
have
a
little
bit
of
a
tighter
cluster
in
terms
of
version
support
aks
seems
to
be
the
farthest
ahead
in
general,
like
they
seem
to
adopt
things
quickest
with
gke
and
eks
being
a
little
bit
slower.
A
Gke
does
pick
up
stuff
a
lot
faster
like
on,
like
the
rapid
channel,
if
you're
using
the
release
channels,
if
you
want
the
newer
version,
but
if
you're
looking
at
getting
one
on
the
no
channel
version
or
on
you
know
the
regular
or
stable
channels
it
takes
a
little
bit
of
time
for
them
to
sort
of
percolate
down
and
so
yeah
kind
of
where
I
was
going
with.
This
was
because
I
was
going
to
ask
and
john
is
the
only
person
that
doesn't
work
at
google
here.
A
So
I'll
ask
ask
you
like
if
we,
if
we
looked
at
sort
of
widening
the
range
of
kubernetes
versions,
that
we
supported?
Is
that
something
that
would
be
of
some
interest
of
no
interest
or
of
like
great
interest
to
you,
as
like
a
user
of
accounts.
B
So
for
us
I
know
recently
we
had
been
paying
attention
to
the
release
schedule
for
kubernetes
on
gke
and
we
wouldn't
stood
up
a
new
cluster
and
also
on
our
our
terraform
was
complaining
like.
Oh
you.
B
Yeah,
I
can't
find
1.18,
don't
know
what
you're
talking
about,
and
it's
because
we
are
on
the
regular
channel
and
regular
had
updated
to
1.19
in
june.
That's
what
that
was,
and
we
already
had
like
another
cluster,
that
self
updated
itself
to
1.19.
A
Yes,
so
this,
so
this
is
something
I've
noticed
with
the
the
regular
channel
generally
doesn't
give
you
pretty
much
any
choice
in
terms
of
versions.
So
I
think,
if
you're
creating
clusters
on
the
regular
channel,
the
idea
is
for
you
not
to
actually
pick
a
version.
It's
just
for
you
to
say
put
me
on
the
regular
channel
and
google
will
give
me
a
version
right.
A
A
B
A
Yeah,
so
I
think
that's
yeah,
that's
that's
an
interesting,
interesting
thing
that
you
mentioned.
I
think
the
the
supported
versions
that
you
can
specify
explicitly
on
the
I'm
not
on
a
release
channel
channel.
I
think
they
call
it
no
channel
or
static
versions-
is
a
little
bit
wider.
They'll
support
some
stuff,
that's
slightly
older.
A
I
think
you
still
can
create
117
clusters
there
and
110
clusters,
although
117
will
probably
be
gone
pretty
soon,
in
addition
to
the
119
clusters
so
and
the
other
thing
that
I've
noticed
recently
about
the
release
channels
is
that
you
cannot
turn
off
node,
auto
updates
on
the
release
channels
and
that's
something
that
we're
looking
at,
how
to
better
support
node,
auto
updates.
A
If
you
look
at
the
best
practices
install
guide
right
now,
it
tells
you
to
turn
them
off
on
your
node
pools,
because,
right
now
we
don't
have
a
way
to
prevent
a
node
update
from
taking
down
an
allocated
game,
server
right
and
so
the
whole
point
of
a
gonades
is
don't
take
out,
allocated
game
servers
right.
That's
we!
A
So
I
think
what
mark
was
what
mark
was
mentioning
was
like
what
we're
looking
at
is
saying
like
right
now
we
say
this
version
of
agony
supports
this
version
of
kubernetes,
and
could
we
say
this
version?
Everyone
supports
this
two
or
even
these
three
versions
of
kubernetes
to
give
people
a
little
bit
more
flexibility,
and
that
would
allow
us
to
both
support
the
newer
versions
that
are
coming
on
platforms
like
aks
and
more
gracefully.
A
If
your
terraform
just
says
like
give
me
stuff
in
the
regular
channel,
it'd
be
nice
that
that
sort
of
always
worked
right
with
with
a
release
of
aegonix
right
and
right
now
it
doesn't
because
the
cadence
of
when
gke
pushes
a
new
version
or
when
eks
bush's
new
version
is
desynchronized
from
the
onus
releases,
because
we
sort
of
wait
until
after
that
and
then
you've
got.
You
know
four
to
six
weeks
and
then
we
support
that
version
right
and
so
it'd
be
really
nice.
A
If,
if
we
had
already
supported
that
version
to
the
extent
that
when
it
became
the
default,
it
just
worked
right.
A
That's
kind
of
what
we're
thinking
about
and
trying
to
figure
out
what
the
mechanics
of
that
would
look
like
in
terms
of
test
infra
and
actually
be
able
to
to
verify
that
things
are
working.
So
so
it
sounds
like
that
would
have.
That
would
have
probably
helped
you
in
this
case.
If,
if
the
gke
version,
when
it
switched
in
the
regular
channel,
was
still
a
version
that
was
supported
by
ignis.
B
Yeah
we'd
run
tests
and
without
knowing
that
our
other
clusters
had
been
updated
and
everything
worked
for
us
still,
but
it
would
be.
Nice
it'd
be
much
more
comforting
to
know
that
officially
agony
supported
the
next
version
of.
A
You
know,
maybe
not
across
like
three
or
four
minor
versions
of
kubernetes,
but
across
a
couple
of
versions
like
plus
one
minus
one,
I
think
will
generally
work
pretty
well,
we
just
don't
actually
test
it.
So
if,
if
something
does
break
we're,
not
gonna
notice
until
you
know
a
user
tries,
it,
we've
definitely
seen
cases
where
like
if
we're
running
agonist,
you
know
or
kubernetes
1.16,
and
somebody
tries
it
on
humanity's
1.20
that
something
is
different
and
broken,
but
generally
within,
like
one
minor
version,
things
should,
for
the
most
part
work.
A
So
we
have
hit
cases
also
in
the
past,
where
we
haven't
actually
like
you
know,
updated
the
api
versions
we're
using
until
we
have
to
which
means
that,
like
the
plus
one
version
doesn't
necessarily
always
work,
and
so
that's
where
testing
would
would
catch
that
immediately
right,
because
the
test
would
start
to
fail
and
we
we'd
be
able
to
fix
those
things
a
little
bit
earlier
and
have
better
support.
So
that
was
kind
of
like
the
sort
of
secondary
reason
that
I
put
this
on.
A
A
D
So
advanced
allocations
so
being
able
to
do
reallocations
or
allocations
based
on
player
counts
is
is
well
underway,
which
is
good,
and
thank
you
to
robbie
for
reviewing
all
my
code
as
well
and
pointing
out
where
I
write
very
scary
things.
Apparently
sometimes
so
that's
yeah,
I've
got
a
couple
of
pr's
in
I've,
got
a
bunch
of
work,
basically,
usually
just
for
context.
D
A
D
So
I've
got
this
there's
a
refactor
of
the
game,
server
state
that'll,
probably
next
it
may
split
out
the
end-to-end
tests
into
their
npr,
just
because
it's
a
bit
easier
and
then
combine
that
with
the
feature
flags
once
that's
ready
to
go,
and
then,
after
that,
I'm
doing
the
the
proto
changes
ilker,
which
I'll
forward
you
on
for,
like
the
allocation
endpoint,
which
I
have
some
questions
about
too
for
making
sure
that
saves,
backup,
compatible
and
then
roll
the
end
tests
out
for
that
as
well.
D
So
and
then
I
have
plans
for
how
I
do
the
documentation
and
that
kind
of
stuff
which
can
can
slowly
roll
that,
if
need
be
as
well,
but
the
it
on
my
end,
the
game,
server
allocation
crd
is
like
all
done
and
like
working
so
now.
I
just
need
to
take
it
apart
and
push
it
through.
So
like
it's
doing
that
for
a
game
server
state,
so
you
can
do
both
ready
and
allocated.
You
can
do
preferred
you
can
do
player
counts.
You
can
do
combinations
of
the
above,
like
that.
D
All
kind
of
works,
which
is
super
cool,
so
I
just
need
to
get
it
chunked
and
reviewed.
Make
that
pretty
so
I
will
say
everything
the
I'll
say,
crd
so
game
server.
Let
me
just
put
everything
in
quotes:
okay,
that
works
so
yeah
yeah.
It's
looking!
It's
looking
good
yeah.
F
Good
question
yeah
when
I
said
there's
a
capacity
of
ten
and
like
maybe
all
the
five
of
them
already
taken
them.
The
five
gamers
are
playing
the
game
in
that
session
and
there's
a
request
comes
and
hey.
I
need
a
game
server
with
three.
This
had
three
more
capacity
which
this
game
server
has.
So
when
this
gets
allocated
like
who
increased
that
the
three
is
it
still,
the
matchmaker
goes
on
at
three.
D
D
F
F
D
And
the
the
interesting
thing
so
the
sdk
itself
keeps
an
in-memory
track,
so
it's
always
up
to
date.
We
sort
of
built
it
that
way
so
like
you
can
always
go
back
to
the
sdk
like
how
many
do
I
have,
and
you
know
that's
up
to
date,
whereas,
like
the
crd
gets
batched
and
like
may,
have
a
slight
delay
on
it
and
we
document
that
so
that
people
were
aware.
F
D
Keeps
pulling
it
from
the
sdk,
yes,
the
sdk
will
update.
I
think
it's
currently
set
to
once
every
second.
That
seems
like
a
a
good
number
to
start
with,
so
it
keeps
an
in-memory
state
for
like
if
you're
just
querying
the
sdk
from
within
the
game.
Server
so
like
you
can
check,
but
then
yeah
it'll
batch
up
so
they're
like
if
a
thousand
people
join
you're,
not
getting
a
thousand
api
requests.
F
B
I
had
a
question
about
the
the
feature
of
allocating
a
game
server,
getting
players
into
a
game
server
that
already
has
players.
What's
the
use
case
for
that
compared
to
like
the
backfill
use
case
for
backfill
feature
with
like
open
match,.
D
I
haven't
played
with
backfill,
I
think
I
think
so
I
think
it
would
probably
be,
and
you
probably
you
probably
understand
that
much
better.
I
think
it'll
be
an
integration
question
so,
rather
than
like
a
game
server
itself,
making
a
request
for
backfill,
you
could
have
a
regular
thing
that
just
goes
hey.
Do
I
have
enough
room
for
these
number
of
players?
Oh,
I
do
then
do
a
backfill
or
like
go
and
query
it
or
something
like
that.
It
just
depends
on
how
you
want
to
make
those
two
things
work
together:
okay,.
B
D
Yeah
there's
some
there's
some
cute
tricks
in
here
that
you
can
also
do
where
and
it's
something
that's
in
the
ticket
where
you
can
kind
of
use
a
label
to
put
it
into
the
backfill
pool
or
pull
it
out
so
like
you
might
do.
You
might
have
like
hey
I'm
ready
for
new
things,
because
it's
got
like
a
label
like
backfill.
True
right
like
something
like
that
and
then
when
you
do
your
allocation
and
that
reallocation
request,
you
can
set
it
in
the
allocation
request
to
flip
that
over
to
false.
D
So
it's
going
to
take
that
pull
it
out
of
the
pool.
So
it's
not
going
to
get
reallocated
again
until
that
game
server
takes
in
some
people,
maybe
looks
at
itself
and
says:
okay,
maybe
I'm
willing
to
put
myself
back
in
the
backfield
pool
by
flipping
that
bit
on
myself
and
then
it
puts
it
back
in
the
pool,
so
it
can
kind
of
manage
some
of
those
race
conditions
in
and
of
itself,
because
it's
aware
of
what
players
are
connected
and
what
state
it's
in
and
that
kind
of
stuff.
A
Right,
I
think
the
other
part
of
that
is
like.
If
you
say
you
expect
three
more
players
to
connect.
They
may
or
may
not
actually
show
up
yeah
right,
so
the
game
server
is
authoritative
on
like
how
many
people
actually
joined
and
whether
or
not
it's
still
looking
for
more.
It's
like
that
label
trick
gives
it
a
way
to
sort
of
communicate.
A
Bi-Directionally
with
the
matchmaker
of
matchmaker
says:
hey
you,
you
should
get
three
more
people,
I
think
that'll
fill
you
up
and
then
maybe
only
one
of
those
people
actually
joins
and
the
game
server
says
hey.
I
still
need
two
like.
Let
me
put
myself
back
in
the
pool.
I
need
two
more
people
right.
D
Yeah
I
see
and
the
game
server
itself
can
watch
its
own
configuration
be
like.
Oh,
I
can
see
I've
been
reallocated
because
there's
there's
various
ways.
I
can
do
that
and
then
be
like.
Oh
okay.
Now
I
can
see,
like
maybe
there's
some
data
that
you
pass
along
with
it
like
how
many
players
you
want
again
like
it's
it,
the
the
design,
is
really
flexible,
but
there's.
D
I
need
to
write
one
of
the
things
I
want
to
do
with
this
is
kind
of
write,
a
series
of
like
guides
or
solutions,
I'm
looking
for
the
right
word
of
like
in
this
scenario
like,
if
you're
doing
a
backfill
operation
like
what
would
that
look
like
I'm
doing
a
mmo
type
persistent
world.
What
does
that
look
like?
I
want
to
do
like
that,
like
it
takes
in
the
stuff
that
we
have
like.
B
B
Those
backfill
requests,
get
included
in
the
matchmaking
process
and
as
soon
as
the
open
match
sees
that
there's
additional
people
that
could
go
on
to
that
back.
They'll
take
it
updates
the
backfill
ticket
with,
like
the
number
of
slots
being
taken
up
and
then,
when
the
game
server
goes
and
checks
on
the
backfill
ticket
in
open
match
it
sees.
Oh
more
people
were
put
in
there
and
also
the
next
round
of,
like
matchmaking,
shows
that
there's
fewer
slots
as
well
yep.
D
Yeah
I'll
be
interested
to
see
how
that
pans
out,
because
then
now
you
can
do
stuff
like
just
give
me
a
game
server,
that's
got
room
for
five
people,
whether
it's,
whether
it's
allocated
or
not
like
you,
can
do
that
kind
of
stuff.
So
again,
depending
on
your
game
and
how
you
want
to
do
it,
then
that,
then
you
have
lots
of
options
which
is
good,
yeah
or
like
like,
especially
for
lobby
servers.
You
can
be
like
make
sure
I
always
have
capacity
for
100
people
like
once.
D
B
D
And
like
our
pack,
strategy
can
also
keeps
actually
worth
noting,
like
the
pack
strategy
also
looks
at
like
which
are
the
most
full
game
servers.
So,
let's
fill
those
up
more
first,
rather
than
like
the
empty
ones
or
like
you
want
to
distribute
it
like
you
can
do
it
that
way
too.
So,
there's
there's
lots
of
interesting
options
like
we
can
do
some,
some
more
opinionated
or
like
intelligent
routing
of
players.
A
It's
gonna
be
fun
awesome.
So
the
next
thing
I
put
on
here
as
just
sort
of
fyi,
which
is
the
rust
sdk,
is
being
updated
to
use
a
different
grpc
library
and
that
pr
now
has
been
rebased
mark.
So
we
should
merge
that
before
right.
I
look
at
your
pr
again
because
they're.
A
Time
zone
and
we're
we're
playing,
should
I
do
that
now
update
the
branch
if
you're
here,
maybe
you
might
take
a
quick
look
at
it
but
yeah.
I
think.
A
Question
really
quick
for
you,
since
you
did
review
it,
does
it
change
the
like
the
sdk
where
you'd
have
to
rebuild?
I
think
it
does
right.
Yes,
yes,
it
does.
Okay,
yes,
it
does
so
I
I
don't
know
that
that
anybody
here
is
using
the
rest
sdk,
but
that's
definitely
something
we'll
call
it
in
the
release.
Notes,
which
is
let
me
get
into
that
if
you're
using
the
old
one,
it
will
still
work
right
with
the
new
release
of
agonize.
A
A
All
right
so
next
on
the
agenda
was
an
issue
that
I
filed.
I
think
earlier
this
week,
which
is
a
proposal
to
change
the
the
way
we
name
fields
in
the
game:
server
allocation
spec.
This
we've
been
we've
been
having
some
discussions
about
sort
of
how
allocations
work
and
what
the
fields
mean,
and
I
found
a
couple
other
issues
that,
like
our
documentation,
is
inconsistent.
Also,
I
think
the
field
names
are
a
bit
confusing.
A
I
think
they,
the
the
implementation
skewed,
a
little
bit
from
the
initial
proposal,
where
the
names
in
the
proposal
made
sense.
But
then,
if
you
look
at
what
actually
happens
when
you
use
the
fields,
the
names
don't
make
as
much
sense
anymore
and
it's
kind
of
confusing
we've
basically
papered
over
it
with
some
documentation.
A
So
I
have
a
proposal
to
basically
change
the
way
that
we
name
the
fields
and
get
rid
of
the
old
ones,
eventually,
possibly
but
at
least
don't
document
the
old
ones
anymore.
So
people
stop
using
them
and
replace
it
with
a
new
field
that
I
think,
better
sort
of
captures.
What
we're
doing
the
implementation
and
kind
of,
hopefully,
is
a
little
bit
easier
to
understand,
so
I
just
wanted
to
call
that
out.
A
A
So
it's
not
going
to
break
people,
but
if,
if
we're
changing
things,
we
should
definitely
try
to
change
them
in
a
way
that
we
don't
end
up
having
to
change
them
again
in
the
future,
and
so
if
people
have
other
sort
of
thoughts
or
ideas
or
if
they
think
there's
a
different
way,
we
should
change
it.
I
think
that's
what
we'd
sort
of
love
to
hear
before
embarking
on
trying
to
fix
this,
because
I
think
this
would
certainly
clean
up
our
documentation
and
make
the
the
spec
match
the
implementation
in
a
way.
A
So
I
found
this
issue
while
I
was
going
through
and
triaging
all
the
issues
yesterday
to
just
see
if
there
was
anything
interesting
to
talk
about-
and
this
is
something
that
was
brought
up-
that
I
brought
up
quite
a
while
ago
in
one
of
these
meetings
and
then
filed
an
issue
to
kind
of
follow
back
on,
and
there
were
sort
of
three
main
questions,
which
is
how
long
do
we
want
to
support
a
release
for
so
right
now
we
basically
don't
support
old
releases
right,
we
will
cut
1.16
and
if
somebody
finds
a
bug
in
1.15,
we'll
ask
them
to
upgrade.
A
If
there's
a
critical
issue
in
1.16,
we'll
cut
out
hotfix,
we
tend
to
not
do
those,
but
you
know
if
there's
something
important
enough,
we
will,
and
otherwise
you
know
fixes-
and
you
know,
new
features
will
come
in
1.17,
so
that's
sort
of
our
de
facto
operating
model.
I
think
it
would
be
nice
to
clearly
document
that
somewhere
and
or
decide
that
it's
not
what
we
want,
and
the
next
question
was:
oh,
I
guess
so.
A
The
issue
is
releases
and
sdks,
so
we
just
talked
a
little
bit
about
like
the
rust
sdk
and
how
the
old
sdk
will
work
with
the
new
release.
You
know
we
should
also
figure
out
how
long
we
want
to
support
sdks
for
is
it
the
same
model
as
releases
where
we're
not
going
to
go
back
and
fix
stuff,
or
do
we
want
to
treat
those
differently,
especially
in
cases
like
like
with
the
rest
sdk,
where
we're
changing
in
a
way
that
somebody
can't
just
recompile
against
a
new
one?
A
A
To
our
pre
pre
1.0
versions,
and
so
I
think
at
this
point
we
can
probably
drop
the
the
four
releases
before
1.0,
but
you
know
the
list
starts
to
get
pretty
long
in
the
pull
down
there,
and
so
we
should
decide
at
what
point.
Do
we
clean
that
up?
Do
we
just
do
it
every
six
months
and
arbitrarily
make
a
decision,
or
do
we
like
drop
one?
Every
time
we
cut
a
new
release
and
keep
the
sliding
window
of
the
past?
You
know
m
things.
Nonetheless,
again
we
talked
about
this
a
little
while
ago.
A
I
don't
know
if
anybody
has
any
strong
opinions
on
where
the
other.
It
was
just
something
that
I
I
ran
across
and
was
like.
Oh
we're,
still
still
sort
of
operating
in
sort
of
the
same
de
facto
mode
as
we
were
before,
but
you
know
the
project's
off,
obviously
a
lot
more
mature,
now
or
sort
of
different
phase
of
our
project
life
cycle.
It
might
be
time
to
sort
of
come
back
and
bring
some
of
these
things
up
again.
D
I
don't
have
strong
opinions,
I
think
the
only
opinions
I
have.
Probably
we
want
to
do
a
one-off,
like
hey,
drop
everything.
That's
pre
1.0,
I'm
totally
fine
with
that.
Just
on
the
on
the
on
the
documentation
outside
of
that.
D
Tend
to
backfill
in
fact
backward
bugs
just
because
either
the
kubernetes
version
rolls
forward,
or
we
just
release
every
six
weeks
and
if
you're
gonna
roll
up
a
new
version,
you
might
as
well
upgrade
to
the
new
version,
because
the
same
amount
of
work
anyway
so
like
nobody's,
really
cared.
I
think
the
only
time
we've
ever
had
to
do.
It
was
basically
internal
compliance
reasons,
because
google
stuff,
I
think
it's
basically
the
only
time
we've
already
do
it.
A
Yes,
I
think
that
would
be
a
case
where,
as
mark
was
saying
like,
maybe
it's
the
same
amount
of
work
to
upgrade
to
116,
as
it
is
upgraded
115.1,
if
like
there
was
a
vulnerable
version
of
go
or
something
else
that
we
depended
upon,
that
we
had
to
pick
up
security
bug
independency
or
if
there
was
a
cv
and
a
gunners
itself
to
fix
those
sorts
of
things.
A
Bug
and
now
you
have
to
upgrade
to
kubernetes
1.19
like
that,
would
be
a
lot
more
painful
than
if
we
back
forward
the
fix
and
said
you
can
still
run
1.15.1
on
humans
1.18.
So
that's
another
place
where
having
a
wider
version.
Wider
range
of
kubernetes
versions
would
actually
help
us
a
lot
because
then
we
could
again
have
another
excuse
not
to
backport
things.
A
So
I
think
the
mechanic
of
rolling
it
out
is
the
same
amount
of
work,
but
the
qualification
level
might
be
different
between
the
two,
and
so
that's
where,
where
I
could,
especially
if
it's
a
new
kubernetes
version
that
we're
forcing
you
to
upgrade
to
like
I
could,
I
could
see
somebody
pushing
harder
for
a
back
port
of
a
critical
security
problem
in
that.
A
D
Yep
100
agree
having
a
wider
set
of
supported
versions.
Would
so,
I
think,
is
probably
the
the
more
applicable
solution.
D
A
D
Did
but
it's
right
you,
you,
you
put
everything
on
there
that
I
wanted
to
add
there.
So
I
feel
like
that
was
a
great
delegation
of
responsibilities
on
everyone.
D
So
thank
you
very
much
for
doing
that
work.
I
just
wanted
to
highlight
something
cool.
I
think
that's
happening
in
the
k-8,
the
kubernetes
prs
that
I
think
will
be
useful
for
us
and
has
been
something
I've
talked
about
for
a
long
time.
There's
work,
that's
happening
on
in
place
vertical
in
place,
pod
vertical
scaling
to
the
point
that
they've
moved
out
of
kept
and
actually
are
implementing
stuff.
I
don't
know
where
it's
coming.
D
I
think
they're
targeting
1.2
from
when
I
looked
at
it,
but
I
don't
know
whether
that
will
land
or
not,
but
the
cool
thing
about
that
is
the
use
case,
for
that
is
like
say,
you're
doing
the
classic
example
to
say
you're
doing
a
battle
royale,
so
you
have
100
players
come
in
and
you're
like.
I
need
two
whole
cpus
for
this
thing,
but
you
only
have
25
players
show
up
and
suddenly
you're
like
I'm
keeping
up
two
whole
cpus
for
this
one.
D
I
could
be
running
it
on
a
quarter
of
that
or
like
whatever.
What's
cool
then
about
this
becomes,
is
you
could
do
in-place
vertical
scaling
where
you
could
say?
Okay,
fine.
I
start
with
the
maximum
amount
that
I
have,
but
based
on
the
amount
of
players
I
have
now
I
can
take.
D
Actually
I
only
need
three
quarters
of
a
cpu
scale
that
down
that
now
means
that
I
now
have
room
more
room
in
my
cluster
or
more
room
on
that
node
to
actually
add
more
machines,
sorry,
more
game
servers,
and
so
I
can
take
a
better
advantage
of
like
all
the
space
I
have
on
my
on
my
kubernetes
cluster,
so
yeah
once
that
lands,
I'm
sure
we'll
do
some
work
to
try
and
probably
take
a
game
server
and
be
able
to
expand
that
out
in
some
way
shape
or
form,
but
I
just
thought
it
was
cool
and
I'm
glad
to
see
it's
coming.
A
D
A
Do
so
you
mentioned
the
case
where
you
over
provision
is
there?
I
think,
there's
also
the
use
case
for
under
provisioning
and
saying,
like
I
need
to
add
a
little
more.
D
So
my
unders,
I
need
to
go
in
through
the
kep
again
I'm
trying
to
work
out
whether
what
what
happens,
if
you
don't
have
room
to
scale
up
so
like
I
I
need
so
if
say
say
you
have
other
things
in
the
cluster
and
try
and
scale
up.
Does
that
a
reject
you
because
you
don't
have
room?
Does
that
be
kick
off
a
game
server
and
if
it
does,
that
could
be
a
bad
thing.
D
B
A
D
Yeah
there's
some
there's
some
fun
stuff
in
here.
If
pods
restart
policy
is
never
the
resource
must
be
set
to
restart,
not
required
to
pass
validation,
make
sense,
because
a
lot
of
our
stuff
is
restart.
Never
actually.
No,
it's
not
yeah.
It's
fun.
It's
fun!
This
is
gonna,
be
this
is
gonna,
be
it'll,
be
fun
to
dig
through
it.
D
B
I
I
had
some
a
question
about
you
know
this
is
this:
is
about
sort
of
like
resource
usage
and
making
the
most
use
of
your
resources
in
your
cluster.
There's.
Also
cases
where,
like
say,
you've
got
a
bunch
of
like
lobby
servers.
B
You
know
it
was
prime
time
a
bunch
of
people
were
playing
and
getting
into
your
lobby
servers
and
then,
after
prime
time
is
over.
You've
got
these
servers
sitting
around
with
sparse
populations.
B
D
I
mean
we'll
have
once
we
have
all
the
player
tracking
stuff
stable.
We
could
probably
put
some
stuff
in
there
to
like
help
route,
people
and
stuff
and
you'll
have
maybe
a
better
understanding
of
where
players
are
at,
but
yeah
we're
an
orchestration
platform.
It's
up
to
you
to
do
communication
stuff.
B
D
If
you're
using
player
tracking,
you
could
do
one
one
thing
you
could
do
is
have
like
a
little
mini
controller
sitting
around
inside
your
your
cluster.
That
like
looks
at
how
many
players
you
have
on
each
one
versus
like
all
the
other
ones
and
like
sets
a
label
or
an
annotation
or
something
that
communicates
to
that
game.
Server,
like
hey,
tell
all
these
players.
D
B
B
D
Yeah
you
could
do
that
with
an
external
controller
like
I
don't
think
it
has.
To
necessarily
be
part
of
a
gun
is
okay,
because
once
you
have
that
player
information,
I
mean,
if
you're,
storing
your
player
tracking
information
outside
of
a
gun.
S2
then
you're,
just
communicating
between
the
two
systems
and
just
every
so
often
go
go
pull
your
your
player
tracking
data
and
be
like.
Where
is
it
at
all
right?
Let's,
let's
yeah,
you
can
then
go
set
labels
and
do
all
sorts
of
fun
stuff,
okay,
cool
yeah.
D
I
think
I
think
it
would.
The
other
thing
that
makes
that
tricky
for,
like
a
gun,
is
itself
and
I'm
just
a
bit
bowling
off.
The
top
of
my
head
is
like,
like
we
could
have
some
probably
basic
rules
around
like
hey.
You
want
to
consolidate
players
based
on
like
numbers
of
players,
but
you
might
have
other
rules
that
are
relevant
for
your
game,
about
where
your
players
should
be
going,
that
we
probably
we
can't
necessarily
track.
D
But
I
also
wonder
if
you
have
any
interesting
ideas,
because
I
think,
maybe
in
a
more
general
sense,
there
is
something
we
could
do
to
be
like
drain
this
game
server,
somehow
or
something
like
some
sort
of
drain
state
for
a
game
server
or
something
like
that.
That
maybe
is
a
bit
more
widely
applicable.
I
don't
know
throw
in
just
throwing
ideas
around.
D
B
Cool
all
right,
yeah,
we'll
we'll
look
at
you
know,
maybe
doing
some
of
that
on
our
own.
Then
thanks.
D
Yeah
as
a
sort
of
meta
note,
it
feels
like
one
of
the
things
that
keeps
coming
up
with.
Like
the
thing
I
keep
saying.
A
lot
is
like
that
seems
like
a
really
good
idea.
You
could
write
that
as
a
third
party,
open
source
solution
and
publish
it
and
depending
on
how
much
traction
that
gets,
maybe
that's
something
that
we
then
pull
in
later.
It
doesn't
necessarily
have
to
be
part
of
core.
So
I
keep
saying
stuff
like
that.
D
A
lot
so
which
which
I
think
is
a
good
sign
of
the
maturity
of
the
platform
as
people
get
more
and
more
niche
use
cases
and
more
opinionated
solutions,
and
we
just
start
building
more
extra
blocks
and
stuff
and,
like
we
have
a
third-party
section
for
a
reason.
So
I
think
that's
pretty
awesome.
A
G
Hi
I
am
akil
I
am.
I
was
searching
that
how
the
open,
how
the
this
open
world
games
work,
so
the
agonist
open
source
software
had
came
out
that
they
they
back
works
on
kubernetes.
D
D
D
G
So
I
I'm
an
student
and
I
want
to
contribute
in
this
open
source,
forge
project
and-
and
I
don't
know
I
have
gone
to
get
her
prepper
victory,
but
what
I
have
to
prerequisite
for
it
or
what
will
I
I
have
to
do,
because
I
I
find
very
overwhelming
the
project.
G
A
Oh
sorry,
I
think
that
the
best
place
to
start,
if
you
go
to
the
ignis.dev
websites-
and
so
you
know,
read
through
the
overview
page,
which
is
first,
it
sort
of
describes
like
what
the
project
is
and
what
exists.
And
then,
if
you
go
to
the
prerequisites,
knowledge,
page
and
sort
of
work,
your
way
through
the
different
things
that
you
would
need
to
do
to
run
a
donation.
A
I
think
a
lot
of
that
stuff
is
stuff
that
you
should
have
at
least
some
understanding
of
of
what
what
those
terms
are,
at
least
even
if
you
don't
fully
understand
them.
You
know
deeply
to
figure
out
like
sort
of
the
scope
of
the
dependencies
of
the
project
and
sort
of
where
it
sits
in
the
ecosystem.
Right,
I
think
that's,
that's
really
important,
just
to
kind
of
set
yourself
up
for
understanding
how
different
pieces
interact
and
then
once
you
feel,
like
you
kind
of
know,
like
okay,
this.
This
is
what
the
units
product
is.
A
Then,
if
you
go
to
the
github
repository
and
look
for
issues
that
are
tagged
as
good
first
issue,
so
there's
a
label,
you
can
sort
by
label
for
good
first
issue
right
now
there
are
19
open,
good
first
issues,
and
you
know
pick
one
of
those
that
looks
like
it's
either
aligned
with
you
know
something
you
already
know
or
understand.
Like
you
know,
some
of
them
are
related
to
like
the
c
plus
plus
code.
A
So
if
you
have
done
a
lot
of
c
plus
plus,
like
maybe
that's
a
place
to
start,
some
of
them
are
related
to
you
know,
terraform
or
c
sharp
or
something
else
pick.
One
of
those-
and
you
know,
take
a
crack
at
that,
and
and
generally
we
try
to
mark
things
as
good
first
issue
if
we
think
that
they'd
be
a
good
entry
point
to
someone
for
someone
just
starting
up
on
the
project
that
don't
require
sort
of
the
same
level
of
knowledge
and
expertise
as
some
of
the
other
issues
right.
A
So
a
lot
of
stuff
we've
been
talking
about
today
are
things
that
that
do
require.
You
know
a
lot
more
expertise
on
on
game
servers
and
how
goodness
works
and
stuff
like
the
stuff
mark's
doing
with
advanced
allocations
right.
That
would
be
a
good
place
to
start
right,
because
it
requires
a
huge
sort
of
body
of
knowledge,
of
understanding
both
of
the
use
cases
and
requirements
from
the
problem
space
and
then
also
the
mechanics
of
like
how
the
code
works
internally.
A
But
there
are
issues
that
are,
you
know
much
simpler
to
do,
and
then
the
other
thing
I
would
say
is
is
updating.
Documentation
is
always
a
great
place
to
start.
If
you
go
through
the
documentation,
you
know
tinkering
at
the
website
running
make
site.
Server
are
pretty
straightforward.
Once
you've
got
a
development
environment
set
up
right.
A
How
does
it
work
to
contribute
to
the
project
and
get
a
pull
request,
sent
out
and
get
feedback
and
respond
and
get
it
merged
and
like
that
sort
of
just
basic
workflow
and
then
also
using
a
gonads
right
like
running
through
the
examples
and
using
it
so
that
when
you
do
want
to
make
a
code
change
to
it,
you
can
then
run
that
code
change
and
verify
it
does
what
you
want.
So
that's
how
I'd
recommend
getting
started.
D
I
will
I
will
concur
with
much
of
that.
I
will
say
I
kill
do
not
do
not
worry
that
it
is
overwhelming
that
is
not
surprising
in
any
way,
shape
or
form.
This
is
definitely
a
project
that
is
aimed
at
people
who,
like
know
lots
of
stuff
about
lots
of
things
about
how
like
kubernetes
works
and
game
servers
and
all
kinds
of
stuff,
so
yeah
just
start
slow.
It's
all
good
100
agree
with
what
robert
said.
D
I
will
also
say
yeah
if
you,
if
there's
not
a
issue
or
a
ticket,
that
has
a
good
first
issue
or
whatever
right,
like.
Don't
worry
about
that.
If
you
just
find
something
that
you're
like
I
wish
this
was
explained
better
or
it
would
be
really
nice
if
it
was
like
that
create
an
issue
like
find
something.
That's
important
for
you
and
like
come,
join
us
in
slack
and
ask
questions
in
the
development
slack
and
we'll
help
you
out.
D
I'm
also
digging
through
I'm
just
like
reviewing
the
development,
docs
and
they're
fine,
but
I
am
sure
they
probably
also
need
improvement,
as
things
have
changed
over
time
like
I
don't
think
you
need
a
gopath
anymore,
but
yeah
if
you
find
stuff
in
there
or
anything
else,.