►
From YouTube: Agones Community Meeting May 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
Joining
us
robbie,
you
wanted
to
talk
about
release
cadence.
B
Yeah,
so
there's
there's
not
too
many
people
here
today,
but
we'll
we'll
pull
the
people
that
are
here
and
and
then
maybe
I'll
file
an
issue
and
see
if
we
can
get
more
people
to
give
us
some
information.
What
I'm
looking
for
is
I'm
curious
sort
of
what
drives
people
to
pick
up
a
new
release
right,
so
do
people
upgrade
every
time
there's
a
new
release
out.
Do
people
wait
for
a
specific
feature?
B
Do
people
upgrade
every
other
version?
Do
they
say
like
I'm?
You
know,
gonna
be
sort
of
out
of
support
quote
unquote
if
you
will
with
the
community,
if
I'm
not
on
the
latest,
like
I'm
just
kind
of
curious
for
people
who
are
here
and
willing
to
share
like
what
prompts
you
to
to
grab
a
new
release
right
and
in
context.
Our
next
release
candidate
is
being
cut
next,
tuesday
right
so
we're
here
we
are
on
the
cusp
of
another
release
coming
out,
then,
where
are
we
speaking.
C
Yeah
speaking
personally,
I
can
say
that
we
basically
never
upgrade
agonists
unless
we
have
to,
and
something
is
forcing
us
usually
what's
forcing
us
is
agonized
versions
being
targeted
at
a
kubernetes
version
that
goes
out
of
support,
meaning
that
we're
upgrading
like
once
or
twice
a
year,
maybe
depending
on
gcp's
cabins.
C
The
reason
for
that
is
that
agonist
is
like
one
in
several
dozen
of
open
source
things
that
we
use
and
keeping
all
of
them
up
today
would
be
very,
very
labor
intensive.
So
we
don't
there's
a
couple
that
we
do
keep
up
today,
because
they're,
like
public
internet
connectivity
level,
things
that
we
kind
of
don't
want
to
go
out
today
but
stuff
like
agonist,
which
is
only
reachable
internally
through
authenticated
apis.
B
Unsupported
and
it's
kind
of
hard
have
there
been
cases
in
the
past
where
you
have
needed
a
new
feature
and
that
has
prompted
an
upgrade
or
has
have
the
new
features
sort
of
not
thin
enough
to
pump
an
upgrade
and
like
you
get
them
when
you
upgrade.
For
other
reasons,.
B
D
Share,
I
think,
for
us
it
was
also
kind
of
feature
based.
We
saw
that
there
was
the
new
sort
of
player
tracking
feature
and
we
wanted
to
start
trying
that
out.
D
We
haven't
really
integrated
that
very
deeply
yet,
but
I
guess
just
kind
of
like
that.
It's
there,
so
we
can
easily
get
to
it
when
it
when
it
is
time.
D
B
Okay-
and
I
know
luna
mentioned
like
following
our
sort
of
guidance
recommendation
of
matching
the
ignis
and
kubernetes
versions
like
what's
actually
supported.
I
know
they're,
definitely
people
that.
Don't
do
that
because
we
get
bug
reports
of
like
hey
I'm.
This
thing
isn't
quite
working
and
we're
like.
Well,
what's
your
setup
and
they
say
I'm
running,
you
know
going
x,
1.12
on
kubernetes
1.20
and
we're
like.
Oh,
we
have
tested
that,
but
it
sounds
like
the
folks
that
are
here.
B
C
An
additional
reason
for
that.
The
reason
for
that
is
at
least
at
embark.
We
built
an
addition.
We
bought
a
kubernetes
controller
on
top
of
a
guns,
meaning
that
we're
actually
importing
agonists
I'll
go
library
right.
C
If
you
try
and
do
that
with
deferring
versions
of
the
kds
libraries,
then
what
is
in
agonises
go
mods
you're
in
for
a
very
bad
time,
so
we
tend
to
just
stick
to
it.
For
that
reason,
more
than
the
actual
operational
bugs,
like
it's
impossible
to
get
a
kubernetes
controller
or
library
imported.
C
C
B
C
But
not
really
right,
like
you
still
need
to
import
the
client
to
have
access
to
the
custom
types
that
agonis
defines
if
you
want
to
do
anything
with
them,
and
it's
just
too
much
of
a
bother
to
to
try
and
do
that
with
client
library
versions
that
don't
match
you
always
end
up
with
compilation
errors
of
oh,
the
agonist
libraries
are
calling
this
function,
which
was
renamed
or
no
longer
exists,
or
this
or
that
happened
to
it.
Every
time.
B
B
All
right,
I
guess
the
the
other
part
of
this
question
for
folks,
if
you're
willing
to
share
is,
is
when
you
do
this
upgrade
so
like
now,
you've
decided
like
okay,
we
need
a
new
version
of
gke
or
we
we
need
a
new
version
of
a
gonads
because
we
want
new
client
libraries.
Even
if
we're
on
the
same
you
know
maybe
client
live,
is
a
bad
example,
but
we
need
some
new
feature
like
player
tracking
and
they
go
nice
even
from
the
same
version
of
gke
like
how
do
you
go
about
doing
that
upgrade?
B
So
we've
got
a
couple
of
different
options,
written
down
on
our
website
for
ways
that
we
sort
of
recommend
people
do
upgrades
the
first
one
being
create
a
new
cluster
shift
traffic
over
to
the
new
cluster
and
the
second
one
being
basically
drain
a
cluster
upgrade
in
place
in
that
cluster,
and
then
you
know
restore
traffic
to
that
cluster.
B
C
In
my
case,
at
least,
we
don't
follow
those
recommendations
at
all
and
we'll
update
a
cluster
live
and
in
place,
and
the
reason
for
that
is
that
if
we
upgrade
agonies
and
it
breaks-
that's
not
going
to
affect
any
already
allocated
game
servers,
but
there
is
really
no
way
that
is
going
to
affect
them.
At
worst,
the
sidecar
will
stop
working
and
what
we
don't
really
care,
because
once
we're
allocated,
we
don't
really
care
about
what
the
sidecar
has
to
say
anyway,
it
at
worst
case.
C
It
means
that
a
cluster
might
not
be
able
to
spawn
new
game
servers,
in
which
case
we
end
up
in
the
same
situation
as
if
we
had
drained
the
cluster
in
the
first
place
right,
we
have
one
less
cluster
taking
traffic.
We've
had
very
little
downsides
doing
it.
That
way.
If
we
were
ever
to
hit
issues,
we'd
probably
refer
to
draining
a
cluster
entirely
before
upgrading.
B
Okay-
and
you
say
you
generally
tend
to
upgrade
agonize
when
you're
upgrading
kubernetes
does
that
mean
you're
doing
like
the
kubernetes
upgrade
in
place,
and
then
the
organize
upgrade
in
place
sort
of
in
that
order
or
in
the
opposite
order
like
you're,
not
creating
new
clusters,
you're
taking
your
existing
cluster
and
moving
it
to
the
new
state.
It
sounds
like.
C
Yeah,
if
we
also
need
to
upgrade
a
version
of
kubernetes,
we're
actually
going
to
join
the
cluster
first,
because
bad
times
with
crds
meant
for
different
versions
of
kubernetes
and
all
of
those
shenanigans.
We
we
try
and
not
have
to
deal
with
that
interesting.
B
Okay
cool,
so
it
sounds
like
you're,
not
generally,
you
know
creating
new
clusters
very,
very
frequently.
You're
has
sort
of
a
static
set
of
clusters
and
when
you're
moving
to
new
versions
of
the
software,
you
update
those
clusters
in
place,
but
adding
new
clusters
would
be
more
like
a
capacity
planning
thing
of
like
we
need
a
cluster
in
this
geo
or
we
need
more
capacity
overall.
B
C
C
When
we're
just
doing
a
nagona's
version
upgrade
the
way
we
have
our
setup
is
that
every
region
has
more
than
one
cluster,
meaning
that
if
we
upgrade
a
cluster
in
place
and
it
fails-
and
we
can't
accept
traffic
in
that
cluster
anymore
or
software-
will
automatically
just
use
the
other
cluster.
C
The
way
it's
implemented
is
our
matchmaker.
When
it
requests,
servers
will
actually
just
pick
a
random
game
server
cluster
to
ask
for
the
allocation
if
it
doesn't
work
I'll,
try
again
a
few
seconds
later
and
the
other
in
another.
One
again
pick
that
random.
So
if
the
cluster
is
down
and
doesn't
let
you
allocate
anything
well,
we'll
just
all
go
to
the
other
one
yeah,
maybe
with
a
few
seconds
of
delay,
but
we're
fine
with
that.
C
C
We
we
use
some
basal,
tooling,
but
they're
running,
helm
and
then
applying
some
patches
with
customized
at
the
end
of
the
day.
So.
D
Yeah,
so
we're
not
really
we're
not
like
a
live
service
right
now,
so
we
haven't
really
had
to
work
through
that,
but
it
does
sound
like
if
we
wanted
to
make
sure
there
was
like
a
zero
downtime
upgrade.
We
would
create
a
new
cluster
and
we'd
stand
up
agonies
in
there
and
game
servers
in
there
and
then
like
register
it
with
our
matchmaking
and
then
unregister
like
the
original
cluster,
and
then
people
will
start
going
to
the
new
one
and
we
just
wait
for
the
old
one
to
drain.
B
Yeah,
I
think
the
thing
about
upgrading
place
is
that
we,
it
theoretically
should
work.
Okay,
we
just
don't
really
test
it
to
convince
ourselves
that
it
always
is
working
okay,
and
we
do
occasionally
have
prs
that
we
mark
as
kind
breaking
and
sometimes
a
kind
breaking
pr
might
break
in
place.
Upgrade
like
our
our
ede
test
cluster.
B
We
would
need
to
have
some
more
sort
of
test
infrastructure
in
place
to
convince
ourselves
that
that
does
in
fact,
sort
of
always
work
right
like
right
now
I
think
it
it
generally
works,
but
we
aren't,
like
you,
know,
confident
enough
to
tell
folks
that
that
is
sort
of
a
way
we
recommend
doing
it.
Does
that
make
sense
so.
C
A
question
on
that
when
your
end-to-end
cluster
breaks,
do
you
mean
the
agonist
controller
itself
breaks
or
do
allocated
game
servers
break
because
that's
a
big
difference
right
like
if
the?
If
the
agonist
controller
breaks
well,
you
effectively
are
back
to
lexan,
said
oh
you're,
just
back
to
doing
a
new
cluster,
effectively
right
and
you're
draining
and
yeah,
but
if
allocated
game
service
break,
that's
a
much
bigger.
B
Problem
right-
and
this
is
a
place
where
we
don't
have
the
test
coverage
for
for
recommending
in
place
updates,
because
when
we
update
the
software
it's
sort
of
between
test
run,
so
we
do
a
test
run
it
finishes.
Then
we
do
an
upgrade.
Then
we
do
a
test
run
and
if
we
did
want
to
say
in
place
upgrades
work,
we
would
want
to
test
the
way
you're
describing
which
is.
We
are
upgrading
during
tests
right.
We
actually
have
things
allocated.
We
verify
that
they
keep
working
while
we're
doing
an
upgrade
while
an
upgrade
breaks
right.
B
C
B
It'll,
like
miss
a
crd
and
then
the
controller
will
crash
loop
right
and
so
you'll
get
a
cluster
where
you
can't
run
the
test
successfully.
The
test
just
keeps
failing
because,
like
the
agony
system
isn't
set
up
properly
like
the
controller's
crash
looping
or
the
crds,
aren't
there
or
something's
misconfigured
right,
and
so
that's
that's.
What
I've
seen
in
our
ee
test
cluster
all.
C
B
B
Yeah,
I
know
tell
them
three,
but
it's
still
it
still
kind
of
gets
wedged,
because
the
template,
like
it's
still
running
hell
on
the
client
side
and
like
actuating,
like
the
template
that
you
apply
and-
and
I
don't
know
how
it
happens,
but
I've
definitely
seen
how
I
can
tell
you
screw
up.
Do
you
know
how
you
know
how
help
gets
screwed
yeah.
E
Apparently,
for
reasons
I
don't
understand,
the
bug
gets
fixed
in
like
kubernetes,
1.2.0
or
1.1.20.
I
don't
quite
understand
but
like
because
we
included
now
like
a
lot
more
validation
in
the
crds.
When
the
crds
change
helm
can't
produ
do
upgrades,
it
just
goes.
No
can't
do
it,
it
doesn't
work.
So
apparently
it's
been
fixed
in
kubernetes.
So
if
that
happens
it
will
it
gets
wedged
in
that
you
can't.
I
don't
think
it.
C
C
That
can
fail
for
the
same
aforementioned
reasons
of
crds,
not
matching
or
a
bunch
of
other
things,
and
if
you
get
to
that
state
you're
in
for
a
bad
time,
if
you
want
to
do
an
in-place
upgrade,
because
you'd
have
to
delete
and
reapply
right
and
what
happens
when
you
delete
a
crd,
it
deletes
all
the
things
that
are
applied
of
that
type,
meaning
you're,
deleting
all
your
game
servers
right.
So.
C
One,
if
you're
trying
to
do
in
place,
big
red
letters,
don't
delete
the
crds
under
any
circumstance
or
you
will
crash
a
bunch
of
games.
B
Yeah,
so
in
our
ad
test
we
don't
have
that
problem,
because
when
it's
in
this
sort
of
broken
state,
any
new
test
that
starts
ends
up
failing,
and
so
we
just
delete
crds
uninstall
with
helm,
reinstall
the
helm
and
then
the
next
test
run
succeeds
right.
So
it's
not.
This
is
where
I'm
saying
like
for
us
to
sort
of
advertise
or
advocate
for
an
in-place
upgrade
and
me
to
be
comfortable
with
that.
C
Yeah
and
in
my
experience,
when
you
start
going
down
that
road,
you
stand
up
needing
to
write
your
own
ctl
tool,
I'll
I'm
just
going
to
refer
to
prior
art
here
of
istio
ctl
and
a
bunch
of
others
that
do
exactly
that,
like
just
relying
on
cube,
seated
or
held
to
do.
Its
thing
is
not
going
to
be
good
enough
to
recover
from
various
failure
scenarios
right
which
might
just
be.
We
don't
want
to
do
this
end
of
story,
which
is
a
very,
very
fair.
B
Thing
well,
that's
that's
sort
of
where
we
that's
how
our
stance
has
been
so
far.
Is
we
don't
want
to
do
that
because
it
it's
a
lot
of
complexity
for
maybe
not
a
huge
game.
I
think
at
this
point
because
we're
not
hearing
a
lot
of
people
saying
like
this
is
the
only
way
we
upgrade
it
has
to
work
100
of
the
time
et
cetera,
because
you
know
you
guys
are
doing
an
upgrade
this
way.
B
But,
as
you
said
like
it's,
okay,
if
it
breaks
because
you
do
have
a
redundant
cluster
and
you
know
for
the
most
part
it
doesn't-
and
you
don't
upgrade
that
often
so
it's
not
a
huge
pain
point
right.
So
I
think
this
is.
This
is
sort
of
the
the
discussion
I
mean
so
sort
of
from
there
to
pivot.
On
to
the
second
thing
that
I
wanted
to
ask
is
our
release.
Cadence
right
now
is
the
same
release.
Kids,
we've
had
for
a
really
long
time.
B
Ever
since
I
started
working
on
the
project,
which
is
every
six
weeks
sort
of
like
clockwork,
we
cut
a
release,
regardless
of
how
many
pr's
have
merged
how
many
issues
enclosed
like
what's
gone
into
the
repository
in
the
last
six
weeks,
so
we're
constantly
creating
new
release
numbers.
Sometimes
those
releases
you
know
pick
up
a
new
kubernetes
version.
Sometimes
they
add
other
new
features
like
they'll,
add
the
alpha
player
tracking
features
and
sometimes
like
not
a
whole
lot
honestly
changed
like
especially
the
releases
we
cut
near.
B
You
know
the
winter
holidays,
like
sometimes
I'll,
be
released
where
it's
like
yep,
it's
kind
of
like
the
old
one,
but
our
you
know
we're
sticking
to
our
release,
schedule
right,
so
sort
of
given
what
people
have
said
about
about.
Updates,
I'm
curious.
If
how
people
would
feel
about
us
changing
our
release
cadence,
and
there
are
two
ways
we
can
do-
that
one
is.
B
We
can
just
reduce
the
frequency,
so
we
can
say
instead
of
every
six
weeks,
we'll
do
every
10
weeks,
12
weeks
like
pick
a
different
number,
that's
bigger
and
the
other
is.
We
could
move
to
feature-based
releases
where
we
cut
releases
sort
of
more
on
demand
when,
like
there
is
something
that
is
worth
cutting
release
for
so
that
could
be.
We've
decided
it's
time
to
upgrade
kubernetes
like
that's
generally
a
point
where
we'd
want
to
cut
a
new
release.
B
It's
you
know
we
have
a
new
feature
like
player
tracking,
it's
an
alpha
and
we
want
people
to
use
it.
So
we'd
cut
a
new
release
and
the
release
cadence.
If
you
will
at
that
point,
would
be
unpredictable.
It
wouldn't
be
every
six
weeks,
every
12
weeks,
every
n
amount
of
time
it
would
be
based
on
we've
accumulated
enough
stuff
that
it's
time
to
cut
a
new
release,
and
I
know
that
you
know
april
open,
match
kind
of
moved
to
this
model
after
they
hit
1.0
where
they
said
we
were
cutting
releases.
B
You
know
about
every
month
we
hit
1.0,
we
don't
have
a
lot
of
new
stuff,
we're
adding
in
so
let's
just
cut
releases
when
we
need
to
right
and
then
we
won't
incur
the
overhead
of
constantly
cutting
releases
and
asking
people
to
upgrade
to
them.
So
I'm
curious
if
people
have
thoughts
about
either
of
those
two
models
like
either
status
quo,
reduce
the
cadence
or
move
to
sort
of
feature
based
releases.
C
C
My
my
counter
suggestion
is
actually
keep
it
every
six
weeks
because
it's
super
convenient
if
you
need
something
against
updated,
kubernetes,
client,
libraries.
Well
just
pick
the
latest
one.
It's
probably
gonna
be
the
right
version
and
you're
never
in
a
situation
where
oh,
there
hasn't
been
any
releases
for
three
months,
because
there
have
been
no
new
features,
but
I
do
need
my
new
client
libraries
please.
C
So
my
suggestion
is
keep
cutting
it
every
six
weeks,
but
if
there
is
no
notable
features,
make
it
a
point
release
instead
of
a
major
release,
so
say:
if
say
six
weeks
from
now,
there
is
no
new
features.
Instead
of
cutting
well
you're
about
to
cut
1.12,
I
think
and
no
like
15
no
1.15.
C
B
B
We
didn't
do
it
this
time,
because
our
next
point
on
the
agenda,
we
weren't
quite
ready
to
go
to
119
for
this
release,
but
we
had
been
sort
of
every
other
version.
B
Picking
up
a
new
kubernetes
client
library
is
a
new
kubernetes
version,
but
the
alternating
releases,
unless
you
know
somebody
like
mark
added
player
tracking,
like
there
was
often
not
a
whole
lot
in
sort
of
the
other
ones,
and
so
if
we
adopted
that
model
we
might
have
had
you
know
1.13
and
instead
of
1.14
we
might
have
had
1.13.1
and
we
might
have
had
1.14
where
we
upgraded
kubernetes
and
then
114
one
right,
which
I
think
to
your
point.
It
might
have
signified.
B
Not
a
lot
has
changed
in
this
one.
So
I
think
the
the
other
thing
that
sort
of
plays
into
this
discussion
is,
if
you
look
at
like
our
feature,
promotion
process
and
our
feature
gates.
The
way
that
those
get
promoted
is
you
know
something
like.
C
F
E
A
Okay,
well,
while
he's
rebooting,
possibly
thank
you
all
for
attending
today,
you
all
get
swag,
so
I
will
send
you
codes
alex.
I
don't
know
if
yours
ever
actually
arrived
from
open
match,
but
hopefully
it's
a
good
sign,
but
we
haven't
received
like
a.
A
We
can't
find
this
person
or
country
robbie
doesn't
get
swag,
though,
because
he
had
internet
problems.
So
sorry.
B
Sorry,
my
upstream
bandwidth
has
been
flaky
lately.
That
happens
where
I
can
hear
you
guys,
but
you
can't
hear
me
so
I
think
what
I
was
trying
to
say
is
they're
they're.
B
If,
when
we
have
new
features
like
that,
presumably
when
we're
promoting
something
to
this
beta
like
it's
on,
but
you
can
turn
it
off
like
that,
should
you
know,
for
a
significant
feature,
be
enough
to
warrant
a
release
cut.
Even
if
we're
not
doing
something
like
you
know,
picking
up
a
new
kubernetes
version,
because
that's
a
sort
of
a
bigger
behavioral
change
right.
B
We
have
to
decide
if,
if
it's
a
new
thing,
that's
off
by
default,
like
with
player
tracking
going
to
alpha,
would
that
have
been
enough
to
warrant
updating
the
minor
number
or
just
the
point
number
right.
So
because
it's
not
changing
the
default
behavior,
it's
like
a
new
thing.
You
could
do,
but
it's
not
there.
That's
it's
going
to
happen
to
you
whether
if
you
do
nothing
right.
C
So,
in
my
opinion,
a
minor
release
version
should
dignify
this
is
very
safe
to
update,
go
ahead.
So
in
that
light,
since
you're
not
changing
default
behavior,
I
would
say
minor.
On
the
other
hand,
that
makes
it
harder
to
promote.
I
realize
that
so
if
that
light
may
be
major
but
yeah,
that's
that's
an
interesting
debate.
E
B
Yeah,
so
I'm
trying
to
sort
of
get
a
sense
for
like
how
much
the
first
question
was
really
a
long
lines
up
before
cutting
releases
every
six
weeks
and
nobody's
adopting
them
like
sort
of.
What's
what's
the
point
right
of,
should
we
be
cutting
releases
at
a
cadence
that
is
more
aligned
with
like
when
people
pick
them
up,
because
if
you
know
say
we
cut
115
and
nobody
ever
uses
it
like?
Was
it
worthwhile
to
spend
the
time
cutting
115
right?
B
So
I
think
part
of
the
question
is
like
if
everybody
upgrades
twice
a
year,
should
we
be
cutting
releases
at
this
fast
of
the
cadence,
or
should
we
be
like
a
monthly
release
would
probably
still
be
fast
enough
to
pick
it
up
twice
a
year
and
still
get
something
pretty
recent,
not
a
month
like
like
bi-monthly
right.
So
I
think
that
that
was
part
of
the
first
question
and,
and
it
goes
back
to
it's
sort
of
a
question
about
toil
on
both
ends.
It's
a
question
of
toil
of
creating
the
releases
takes
some
time.
B
If
you
know
when
we're
writing,
release
notes,
we're
like
wow,
there's
really
nothing
to
write
for
this
release
like
how
do
I
say,
I'm
excited
that
I'm
cutting
the
new
release
when
nothing
has
really
changed
right
like
again
that
goes
back
to
like.
Is
there
a
point
to
having
cut
that
release,
or
should
we
be
waiting
for
something
that
we
can
say?
This
is
why
you
should
use
this
release,
because
I
think
what
I've
heard
from
a
couple
people
is
sometimes
there's
a
feature.
That's
worth.
B
Upgrading
for
right
like
I
need
a
new
version
of
kubernetes,
client,
libraries
or
I
want
player
tracking
or
I
want
x
right
and
in
those
cases
the
release
notes
can
be
like
hey
with
this
release.
Here's
this
new
thing
you
can
do
or
this
new
thing
you
get.
That
might
tempt
you
to
upgrade
and
the
other
reason
people
upgrade
is
sort
of
like
the
just
the
maintenance
of
like
it's
been
a
while
it's
time
to
upgrade,
and
then
you
probably
generally
just
pick
sort
of
the
latest
one
that
works
for
you
right.
B
So
I
think
it's
on
both
sides.
It's
is
how
often
do
people
upgrade,
how
hard
is
it
to
upgrade?
Do
we
need
to
make
upgrading
easier
or
different
in
some
way,
and
then,
if
people
aren't
upgrading
very
frequently,
is
it
still
worthwhile
to
be
cutting
releases
frequently,
so
that's
kind
of
what
what
I'm
trying
to
get
at.
E
The
other
question
I
would
ask
is
if
we're
slowing
down
release
cadence.
Does
that
mean
we
might
I
mean
that
would
have
to
mean
that
we're
more
willing
to
cut
hotfixes,
which
means
that
there
is
more
honest
to
be
on
top
on
top
of
what
could
or
what
may
or
may
not
be
a
hot
fix
or
as
a
requirement
like.
I
look
at
like
the
recent
bug
that
your
pr
that's
going
through
right.
E
It's
a
really
small
thing,
like
changing
the
http
status
code,
for
when
a
game
server
allocation
happens
to
201,
which,
for
a
lot
of
people,
is
no
problem,
but
for
c-sharp
users.
Apparently
it's
a
big
problem
is
that
hot
fixable
is
that
hotfix
worthy
for
some
of
our
people
using
it.
Yes,
that'll
be
a
big
change.
That
makes
a
difference.
If
we
do
every
six
weeks,
then
we
don't
have
to
worry
about
that,
because
we
do
it
every
six
weeks.
It
makes
life
easy
for
that
very
reason.
E
B
Yes
and
that's
the
other
sort
of
follow-up
question
is
if,
if
the
consensus
was
slow
things
down,
what
are
the
follow-on
effects
from
that,
and
I
think
the
two
you
just
mentioned
are
the
most
important,
which
is
right.
Now
we
basically
say
you
know
unless
it's
a
real
emergency,
we're
not
going
to
cut
point
releases,
we
always
just
wait
six
weeks
and
that's
soon
enough.
You
know
unless
something
is
really
really
critical.
Yeah.
B
I
think
I
think,
looking
back
at
the
release,
history
there's
been
like
one
time
so
far
that
we've
cut
a
release
in
between,
but
for
the
most
part
we
say
you
know
like
with
this
c
sharp
bug.
It's
like.
Oh,
that
sounds
like
a
kind
of
annoying
pretty
bad
bug.
It'll
be
fixed
within
a
couple
weeks.
Right
like
there
will
be
a
new
release
for
you
within
a
couple
weeks.
B
Even
if
you
know
luna
doesn't
care
about
it,
it
doesn't
pick
it
up
or
sean
doesn't
care
how
to
pick
it
up
like
it'll,
be
there
for
those
people
right.
So
I
think
that's
the
advantage
of
having
the
faster
release
cadence
right
it.
I
guess
I'm
trying
to
like
step
back
and
look
holistically
like.
I
think
that
the
quick
release
cadence
makes
a
whole
lot
of
sense.
B
I
think
post
1.0
generally
I've
seen
like
the
the
velocity
of
new
features
being
added
slow
down,
because
we've
sort
of
hit
that
point
where
what's
there
tends
to
work
right
like
luna,
is
saying
like
we
don't
upgrade
unless
we
kind
of
need
to
for
some
reason
right
and
occasionally
there'll
be
a
feature
that's
of
an
upgrade,
but
generally
it's
sort
of
more
of
a
maintenance
upgrade
and
so
in.
In
that
sort
of
steady
state
does
the
same
release
cadence
make
sense,
and
the
answer
might
be.
B
Yes,
I'm
not
trying
to
say
we
should
change
it.
I'm
just
trying
to
gather
some
information
about,
like
is
what
we're
doing
still
makes
sense,
given
that
we're
post,
1.0
and
the
future
velocity
has
slowed
down
quite
a
bit.
So
I
think
I
will.
I
will
open
a
github
issue
and
kind
of
try
to
put
some
of
the
summary
stuff
in
there
and
try
to
get
some
opinions
from
people
that
don't
happen
to
be
here
today.
I'm
not
suggesting
we
change
something
right
now,
but
I
do
want
to
kind
of
have
this
conversation.
B
You
know,
maybe,
if
different
people
show
up
to
the
next
meeting,
like
maybe
one
or
two
more
times
and
then
try
to
come
to
a
consensus
on
whether
we
keep
the
status,
go
or
change
something
up.
That
makes
sense.
E
There's
probably
another
side
of
this
coin,
which
is
is
there?
Is
there
ways
we
can
impr
reduce
toil
in
the
release
process
as
it
currently
stands,
because
if
we
can
make
that
less
onerous
as
well,
then
that
also
makes
it
almost
becomes
well.
C
If
I
had
four
versions
to
pick
there
against,
then
that
would
be
a
lot
more
comfortable
for
me
right.
I
would
just
pick
oh
whatever
version
of
kubernetes.
Am
I
running
everywhere
else,
I'll
use
that
and
on
the
agona
side,
I
don't
think
it's
very
hard.
It's
just
running
the
generator
three
times
instead
of
once
right
and
then,
but
then
we
have
to
put
that
in
a
folder.
E
And
we
need
to
have
multiple
builds
and
it
makes
my
head
hurt.
B
C
A
C
The
reason
I
also
bring
this
up
is
very
old.
Kubernetes
versions
are
a
thing,
and
very
new
ones
are
also-
and
sometimes
it's
nice
to
be
able
to
like,
for
example,
let's
say
kubernetes
1.21
comes
out
and
we
have
the
feature
we're
really
excited
about.
Well,
we
can't
use
it
until
I
go
on
this
upgrade,
which
is
like
gonna,
be
two
years
from
now,
because
that's
when
amazon
is
going
to
update
it
to
it
right.
So
that's
a
nice
added
advantage
of
that.
H
Approach
by
by
the
way
is
there
a
way
just
to
document
the
approach
to
generating
I'm
gonna
for
a
previous
version
of
plus
one
or
minus
two
sorry.
H
Maybe
we
can
judge
the
command
and
say
follow
these
steps.
Can
you
say
that
one
more
time
I
mean
probably,
we
can
document
how
you
can
use
with
previous
version,
for
example,.
B
Oh
seriously,
like
you,
you
could
take
the
source
code
and
create
your
own
release.
That
was
targeting
a
specific,
older
order
version.
At
that
point,
I
think
the
the
downside
of
that
is
that
then
puts
the
onus
on
the
person
who
does
that
to
like
go
do
that
process
and
then
test
it
to
make
sure
it
actually
works,
and
if
they
tell
us
it
doesn't
work
unlikely
to
want
to
spend
our
time
helping
them
right,
but
it
certainly
would
yeah
right
if
somebody
cared
enough
right.
C
What
I'm
hoping
is
like
I'm
happy
like,
I
don't
necessarily
want
older
versions
of
kubernetes
right.
I
want
newer
ones,
because
algona
is
quite
far
behind
as
far
as
versions
go
because
of
eks,
largely
I
it'd
be
great
if
I
had
whatever
eks
has,
and
every
version
following
that
supported,
rather
than
only
whatever
eks
had.
B
So
so
the
policy
isn't,
you
know,
wait
for
eks
right.
We
changed
the
policy
that
we
didn't
have
to
wait
for
everyone,
but
we
do
have
to
wait
for
two
of
the
three
and
this
kind
of
is
a
good
segue
to
our
next
agenda
item,
since
we
only
have
15
minutes
left,
which
is
that
a
few
weeks
ago,
I
checked
all
of
the
versions
as
we
were
starting
the
process
for
the
current
release
cycle
and
not
enough
of
the
provider
supported
1.19
for
us
to
start
start
doing
the
upgrade.
B
I
think
mark
put
a
comment
in
a
pr
recently
that
we
are
now
at
that
state
where
two
of
the
three
do
support
119
as
the
n
minus
one
version,
and
we
could
start
the
upgrade,
but
it
was
too
close
to
our
next
release
cut
for
me
to
have
confidence
that
we'd
finish
it
in
time,
and
so
the
current
plan
is
for
us
to
do
it.
Sort
of
right
after
this
release
gets
cut
as
part
of
the.
If
we
keep
our
current
numbering
scheme,
1.16
release.
F
E
B
It's
in
rapid,
I
guess
that,
do
we
count
rapid
for.
E
E
B
B
I've
never
gotten
the
web
thing
like
their
their
version
of
cloud.
Shell.
I've
never
gotten
that
to
work
properly,
yeah,
so
okay,
but
I
think
you
know,
depending
on
on
what
you
find
and
I'll
go
check
again
also,
but
I
think
we
are
on
track
at
this
point
to
to
move
to
119
for
the
the
next
release
so
again,
kind
of
back
to
the
previous
conversation
about
release
cadence,
if
you're
really
hoping
for
119.
B
C
B
Yes,
I
mean,
I
think
we
we
can,
we
can
kind
of
play
it
out.
Gke
did
eventually
recently
not
eventually
recently
post
a
release
schedule
with
anticipated
release,
dates,
and
so
gke
says
that
12.21
will
be
available
on
the
rapid
channel
in
june
of
this
year,
and
so
I
think
aks
is
probably
aks
the
last
couple
times
I've
checked
has
been
ahead
of
gke,
which
means
that,
as
of
you
know
june
this
year,
which
is
also
coming
up
really
soon,
1.20
might
be
a
possible
target.
B
So
we
may
end
up
the
way
the
calendar
works
out
end
up
doing
1.19
in
our
next
agonize
release
and
1.20
in
the
following
one.
So
it
may
not
actually
be
that
far
away.
B
B
I'll
post
the
link
to
the
the
gke
release
schedule,
which
is
a
new
thing
that
they
they
pointed
us
at,
which
is
really
cool,
because
that
was
definitely
never
something
that
we
yeah.
We
saw.
C
B
Cool
all
right,
that
was
the
end
of
the
two
things
that
I
put
on
the
agenda,
which
have
taken
up
most
of
our
our
hour
today.
Mark
do
you
want
to
move
over
to
your
my.
E
That's
all
it
is,
that's
literally
it
sorry
for
being
slow
on
the
things
I'm
working
on
my
I
there's
some
other
stuff
that
I've
needed
to
work
on
and
has
taken
my
focus
away
for
a
bit,
but
I
do
want
to
complete
those
things.
I
know
they're
important
to
people,
so
that's
that's
literally
it
I'm
just.
B
B
The
tracking
issue
at
1677
and
then
was
like.
Oh
that's,
really
long
I'll
read
that
later,
so
I
have
no
no
clue
about
where
we're
at
right
now,
yeah.
So.
E
E
I
started
some
doing
some
of
the
design
work
on
that,
but
have
since
sort
of
put
it
behind
to
focus
on
the
outlet,
the
the
advanced
allocation
stuff,
because
we
don't
actually
need
the
refactoring
stuff
for
it
to
for
the
advanced
allocation
stuff
to
work.
So
if
somebody
else
wants
to
take
that
up
and
sort
of
push
that
through
that'd
be
awesome,
they
can
do
the
work
that
I've
been
doing
there.
What
was
I
going
to
say?
E
In
fact
I
can
probably
I
think
I
have
some
of
it
committed
in
a
branch
somewhere
too
so
yeah,
that's
kind
of
where
was
that
I
was
going
to
try
and
get
some
of
the
advanced
allocation
stuff
enough
in
an
alpha
state.
So
people
could
play
with
that
and
get
that
working
and
then
come
back
around
to
the
player
tracking
and
start
to
try
and
push
that
through,
but
yeah.
Those
those
two
are
not
actually
blocked
by
each
other
in
any
way,
shape
or
form
cool.
B
B
Pretty
soon
after
that,
we'd
like
to
push
for
beta,
because
it's
been
sitting
there
for
quite
a
while
on
alpha
and
it
sounds
like
for
the
most
part,
people
are
happy
with
it
that
we
want
to
tweak
the
api
so
having
two
api.
People
are
okay
with
that,
like
functionality-wise,
it
seems
like
we're.
Gonna
want
to
promote
it
pretty
quickly.
E
Yeah,
the
sdk
shouldn't
actually
change
from
like
the
the
engine
integration
side,
it's
literally
just
like
the
grpc
and
the
rest
underlying
surface,
which
will
break
some
stuff
along
the
way.
But
we're
like
you
should
follow
the
google
guides
for
how
we
do
this
and
I'm
like.
Yes,
we
should,
but
we
didn't,
because
that
stuff.
C
I
I
have
a
question
on
that
mark.
Does
that
mean
that
this
affects
diagonal
sidecar
talking
to
the
game
itself
right?
Does
that
mean
that
you
effectively
have
to
make
sure
that
the
client
version
you're
running
matches
the
agonist
sidecar
version
you're
running?
Otherwise,
things
will
break
for
player
tracking.
Yes,.
E
C
E
C
C
We
actually
have
an
extra
controller
on
top,
as
I
mentioned,
and
we
can
spawn
a
six
a
fleet
for
a
six
month
old
game
server
or
we
can
spawn
a
fleet
for
a
game
server
that
was
built
an
hour
ago
and
the
way
we
do
that
is
or
matchmaker
when
it
gets
a
matchmaking
request
that
comes
in
it
looks
at
the
build
id
and
it
then
tells
the
game
server
clusters.
Hey!
Please
pin
this
up.
E
C
B
B
A
All
right:
well,
I
think
we
can
call
it
for
this
time,
thanks
everyone
for
joining
and
we'll
be
back
next
month,.