►
From YouTube: Node Operator Roundtable - May 24th, 2023
Description
In the Node Operator Roundtable, participants discussed the Leap software status, upgrade methodologies, and operator experiences, with many building from source due to unique configurations. They also deliberated on using public repositories for automated updates, complexities of running multiple Nodeos versions on a single machine, and the balance between efficiency and security.
00:00:00 Start
00:00:19 Leap software Development update
00:01:08 Node upgrades
00:04:47 Package Managers
00:08:35 Custom Packages
00:20:15 Resyncing from snapshots
00:55:28 End
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
A
B
Yes,
thank
you.
So
leap
version
4.0.1,
which
is
a
patch
release,
has
been
completed
by
the
development
side.
The
release
notes
are
ready
to
go.
All
I
need
to
do
is
hit
the
publish
button.
There's
binaries
ready
to
go
so
immediately
following
this
call.
I'll
do
that
and
that
release
will
be
officially
ready,
any
any
node
operators
to
do
an
upgrade
as
as
soon
as
they're
able
yeah.
So
that
is
ready
to
go
as
of
today.
B
C
D
E
C
E
B
D
Us
and
there's
the
general
I
will
say
General
consensus,
but
they
most
people
tend
to
say
like
block
producers
and
people
that
are,
you
know,
kind
of
that
that
trusted
validation
of
some
of
those
should
be
compiling
their
own
binaries.
Because
that
way,
you
know
exactly
what
you're
running
a
lot
of
people
will
run
some
of
those
pre-compiled
devs,
but
ultimately
that's
where
a
lot
of
that
comes
from,
but
yeah
80,
probably
tones
yeah,
yeah.
E
I
need
to
be
ready
to
apply
it
patch,
so
I
need
to
make
sure
the
build
process
works.
So
if
a
patch
comes
along
then
I
can
apply
it
because
the
I
don't
know
what
the
patch
policy
is
at
the
moment.
But
the
previous
block,
one
policy
was
we're
gonna
ship,
you
some
like
diff
file,
you
apply
it,
you
know
and
go
we
don't
release
binaries,
for
you
know
security
patches
right
so.
B
B
I
haven't
actually
encountered
the
higher
agency
security
patch
situation,
where
I
was
running
that
so
I
actually
should
probably
figure
out
what
the
policy
of
myself
there
I
will
say
for
4.0.1.
We
we
have
a,
we
do,
have
binaries
provided
as
well,
but
it
sounds
like
most
of
the
folks
caller
are
building
food
source
anyway,
so
yeah.
D
A
D
D
C
D
D
C
D
I
mean
a
lot
of
which
I
didn't
see,
but
I
I
would
say:
I
would
use
it
heavily.
Just
I
got
somebody
asking
me
right
now
for
some
custom
binaries
of
a
three
one,
four
version,
because
they're
fighting
some
of
the
bugs
in
the
other
versions.
So
right,
yes,
and
a
lot
of
times
you
just
get
referred
to,
Sweden
Sweden
maintains
a
pretty
good
repo
of
the
devs,
but
and
then
you
you've
also
got
to
think
about.
A
lot
of
these
chains
also
have
their
own
custom
binaries.
So
it's
not
directly
related
to
you
guys.
D
E
B
That
makes
sense,
so
tell
me
more
about
the
the
custom
packages
Matthew,
just
sort
of
shared
an
example
of
why
he's
building
in
a
custom
way.
What
are
some
other
examples
folks
have
of
their
own
sort
of
custom
configuration
with
build
configuration?
What
you're
doing
that's
different
from
the
binaries?
We
provide.
D
B
D
It
I'll
say:
I
mean
there
are
some
chains
that
do
require
because
they
just
haven't
upgraded
and
activated
like
we
still
have
some
chains
on
the
2-0
binary
instead
of
running
right
alongside
four
o
binary,
three
binaries,
none
or
four
because
of
about
220
whatever.
But
the
point
is:
is
that
yeah?
It's
not
even
it's
almost
a
custom
binary
level.
It
may
even
just
be
the
particular
vertical
feature
of
the
chain
forcing
you
to
maintain
and
we
tend
to
share
infrastructure
in
some.
You
know:
scenarios
where
it
works.
D
E
E
A
D
And
kubernetes
are
reminding
me
how
inferior
I
am,
but
I
mean
I
will
say
that
you
know
kind
of
that.
Dune
self-contained
idea
of
here.
Here's
the
ability
to
have
a
self-contained,
although
it
may
be
kind
of
vanilla
and
for
a
specific
purpose,
most
people
that
are
outside
of
that
that
have
these
types
of
automated
deployments
and
whatever
it's
not
just
the
act
of
spinning
up
a
node,
there's
a
lot
of
other
I'm
sure
all
of
his
monitoring
and
and
policies-
and
you
know,
I
mean
it's:
it's
an
official
custom
deployment,
so
yeah.
E
D
It
the
point
is:
is
it's
probably
a
pretty
good
gap
between
here's,
a
vanilla,
Docker
image
and
what
I
think
of
as
Doom
versus
almost
everybody?
That's
in
that
level
is
either
I
just
want
to
spin
it
up
and
have
it
as
easy
as
possible
or
I'm
not
going
to
use
yours
because
I
just
got
to
have
all
my
extra
stuff
added
into
it.
C
E
D
E
E
E
B
E
E
E
B
C
I
mean
I
can
say
from
a
selfish
like
when
I'm
traveling
and
stuff
I've
got
my
little
MacBook
and
it's
it's
a
to
have
to
open
up
a
VM
in
order
to
run
chaos
been
asked
to
just
do
it
on
like
come
on.
It
used
to
be
like
that
and
I
was
using
it
up
until
recently,
but
you
know
when
we
went
on
to
Antelope
and
suddenly
things
like
a
lot
of
like
the
commands
they're
working
on
yep,
so
that
would
be
nice
if
I
could
just
compile.
C
B
E
C
D
C
D
D
D
E
D
D
C
C
D
F
D
Yeah,
just
the
raw
binary
would
be
fine,
but,
to
be
honest,
I
mean
it
sounds
like,
in
my
opinion,
kind
of
that
apt
repository
for
some
of
the
I
mean
there's
four
programs
at
least
that
I
pull
out
of
there.
There
may
be
a
couple
other
ones,
but
there's
node,
OS,
clios
posd
and
then
the
blocklog
tools
leap
you
tell
now
whatever
it
is,
but
obviously
far
less
use
cases.
But
I
do
put
that
on
all
my
notes,
just
because
it's
needed
when
you
really
need
it,
but
the
three
main
ones
are.
D
C
B
Everyday
experience,
and
so
the
the
you
know,
that's
context.
The
question
that
I
wanted
to
dig
into
and
Kevin
might
be
able
to
like
better
Express
this.
So
he
might
I
might
ask
him
to
clarify
after
this,
but
the
question
I
wanted
to
dig
into
is
basically
so
so.
First
of
all,
I
know,
Matthew
does
actually
I
I.
Think
I
think
he
said
Matthew
that
you
you
do
right.
The
state
to
disk,
not
using
snapshots,
do
I.
Have
that
right.
We're.
B
E
D
E
D
E
All
right,
except
the
startup
time,
is
longer
with
Heap
mode
and
swap
farm.
So
we
can.
We
run
two
wax
nodes
in
128
gigs
around,
because
it
was
the
discussion
going
on
yesterday
or
today
on
I'll
do
the
same
right,
so
you
can
run
a
wax
note
in
a
64
gigs
of
RAM.
So
we
run
do
not
stay
tissue.
There
not
stick
history.
E
B
C
Does
that
make
sense?
Well,
it's
much
smaller,
it's
smaller,
because
you
compresses,
you
compress
the
the
snapshot
and
it's
quite
significantly
smaller.
It's
I
think
a
snapshot
is
on
wax.
For
instance,
I
think
it's
like
25
gigs
and
you
compress
it
to
like
six
gigs
or
something
like
that.
Like
don't
quote
me
on
it,
but
it's
that
much
of
a
compression.
D
Were
you
asking
about
because
that
Bank
stand
does
copying
it
from
temp
FS
back
to
a
drive
and
then
dropping
it
from
the
drive
back
into
State
instead
of
launching
a
snapshot
which
is
right,
recreating
the
state
I
think
in
all
fairness,
you
definitely
avoid
the
first
half
of
having
to
copy
a
hundred
gig
temp
FS
file
out
to
disk
to
shut
it
down.
I
mean
the
same
concept.
D
D
E
Yeah,
it
can
be
done.
I
mean
I,
wrote
that
orchestration
to
copy
the
file
to
Temp
FS
copy
it
back
whatever,
but
then
it
wasn't
100
reliable
and
then
it's
like
okay
well
now,
I
need
to
cover
recover
from
a
snapshot
and
that's
like
oh
it's
too,
it
I.
Just
that's
why
I'm
still
using
keep
mode,
because
it's
like
an
address
complicated
to
get
100
perfect
one.
D
Interesting
thing
that
might
catch
people
with
that
I
just
know.
Other
people
got
burned.
Remember
that
state
database
is
written
partially,
so
people
get
burned
or
you
have
to
copy
it
sparkly
and
it's
driving
carball.
It
extract
it
sparsely
you
know.
What
will
happen
is
that
people
that
chain,
State
DB
does
and
you're
config
set
the
file
size,
but
the
OS
knows
that
it's
sparse,
so
it
doesn't
actually
fill
it
up.
Well,
what
happens
is
right.
D
D
A
D
G
Yeah
we've
done
something
similar
on
a
similar
project
in
the
past,
and
so
you
know
the
you
know
you
can
certainly
do
that.
That's
effectively
just
start
from
snapshot
with
zero
block,
blog
size
and
heat
mode,
and
then
you
know,
kill
minus
nine
as
opposed
to
you
know,
control
C
or
you
know,
C
term.
So
you
know
that's.
You
can
effectively
get
that
today
with
just
a
bit
of
rigging
but
yeah
having
a
mode
that
actually
just
says.
G
Hey
I
want
that
capability
where
it
effectively
doesn't
like
it's
it's
kind
of
like
keep
mode.
You
start
with
snapshots
instead
of
heat,
and
then
you
just
run
in
that
mode
and
then
don't
shut
down
you
just
don't
do
anything.
You
just
lose
it
in
with
the
realization
that
you're
about
to
start
up
in
snapshot
so
yeah
I
mean
that
sort
of
thing
is
is
certainly
doable.
Yeah.
G
C
C
G
Oh,
you
know,
Mac,
doesn't
you
know
Max
integration?
There
is,
which
is
surprising,
because
you
know
from
the
way
the
Mac
is
actually
created.
You
think
it's
Linux
integration
would
be,
would
be
the
best
of
both
worlds,
like
that's
what
they
tried
and
so
yeah
Windows
came
along
behind
them
and
did
it
better,
which
is
just
it's
shocking,
but
yeah.
It
really
is
it's
a
great
environment,
yeah.
E
F
G
E
Yeah
well,
I
mean
like
one
of
the
things
like
I
mentioned.
Brian
last
week
is
why
do
we
have
to
write
every
single
update
to
disk
like
let's
go
back
to
the
original
way,
node
us
Works,
where
we
swap
the
state
interrupt
right?
Why
is
every
single
update
have
to
write
to
this?
Why
don't
we
write
an
update
every
10
blocks?
E
Well,
if
you
restart
after
well,
you
lose
the
last
10
blocks.
Oh
well,
you
know,
then
it
will
resync
from
10
blocks
ago.
Well,
that's
way
better
than
the
current
situation,
where
you
know
you
have
to
restart
from
a
snapshot
right.
So
we've
made
this
trade-off.
That
says
like
we
want
to
make
sure
everything
is
on
disk
absolutely
as
much
as
possible,
but
you
know
practically.
We
can't
do
that
because
we
want
to
run
a
high
performance
blockchain,
unlike
those
other
blockchains.
F
It
is
kind
of
a
requirement
he's
saying
you
know
more,
like
async,
IO
and
kind
of
a
database
system
where
they
don't
write.
They
don't
flush
the
cache
of
all
the
rights
to
disk
every
single
right.
They
kind
of
batch
them
up
and
they
write
in
batches
again.
I,
don't
know
how
receptive
engineering
is
going
to
be
to
quote
require.
F
This
is
viewed
as
you
telling
them
how
to
write
the
code
and
not
giving
them
a
requirement.
The
requirement
would
be.
Could
you
optimize
disk
IO
better
and
you
know
be
like?
Oh,
what
do
you
mean?
Unfortunately,
I've
been
in
these
discussions
with
the
current
engineering
team
since
I've
been
here
and
they're
not
well
received,
I.
Think
it's
a
reasonable
requirement
to
say:
can
we
look
at
and
you
know
that
flushing
blocks
in
a
in
a
you
know,
in
a
periodic
or
in
a
gunk
in
a
batch
versus
every
right
to
disk.
F
Knowing
that
there's,
you
know,
21
plus
block
producers
out
there
they're
not
going
to
all
crash
at
the
same
time,
so
you
can
pick
back
up
where
you,
you
know,
sync
back
up
where
you
crashed
and
lost
stuff.
You'll
have
to
get
another
Snapshot
from
someone
else,
because
your
snapshot
won't
be
right.
Unless
you
have
another
node
that
you
know
was
was
continually
running
correctly,
but
you
know
it's
a
reason.
F
F
I
I
will
bring
this
up
with
Eve
on
my
one-on-one
with
him.
You
know
like
this
is
something
we're
hearing
quote
from
the
community.
Do
we
listen
to
it
or
do
we
not,
and
you
know
it's
it's
not
always
are
the
requirements
that
are
being
given
by
product
received
as
requirements.
They're
re
seemed
as
like.
This
is
a
design
you
guys
aren't
supposed
to
be
designing
the
product.
F
B
F
B
F
Know
yeah
I
mean
even
this.
These
are
statements,
these
aren't
requirements,
I
guess
you
and
I
can
work
on
it
in
our
one-on-one,
I
mean
I,
feel
I
heard
what
Matthew
said
and
from
a
computer
scientist
standpoint,
I
kind
of
get.
What
he's
asking
to
do
and
it's
a
reasonable
requirement
because
it
would
lower
the
disk
IO
to
the
disk
and
it
would
make
it
where
discs
last
longer
and
yeah
there's
a
penalty.
F
You
have
to
go
back
in
a
snapshot
which
wouldn't
be
right
where
you
finished
off
when
you
restarted
your
node,
because
you
missed
10
blocks
or
so,
but
at
least,
if
you
had
another
snapshot
or
you
could
grab
it
from
somewhere
on
the
network,
you'd
be
able
to
resync
back
up.
It's
not
like
you're,
forever
lost
and
now
blocks
have
been
drops
and
blocks
are
lost
forever.
Ever
you
have
a
different
startup
problem,
but
you
have
a
lower
disk
IO.
It's
a
trade-off.
F
E
F
Which
is
kind
of
that's
a
good
I
think
that's
a
very
valid
requirement.
You're
asking
for
a
trade-off
of
block
producers,
producer
restart
ease
versus
disc
abuse.
You
know
disc
longevity
so
to
make
trade-offs.
Some
of
them
might
be
like
I,
don't
mind
replacing
these
discs
every
six
months
to
a
year.
I
don't
like
having
to
deal
with
you
know
restarting
from
10
20
blocks
back
and
others
might
say.
No
I'm
I
hate
running
around
in
my
data
centers
and
pulling
disks
every
other
week.
F
C
Not
not
a
project
management
methodology
but
there's
a
waterfall
methodology
that
we
use
where
ultimately,
you
just
have
more
than
one
node
at
the
end
of
it.
So
you
have
like
multiple
nodes
so
that
when
you
do
start
one
you
know
you
you
can
take
an
hour
at
the
start
because
you've
got
you
know
five
other
ones
yeah
to
back.
C
That's
why
it
works
is
really
low.
As
far
as
state
database
goes
because
of
the
mitigation
that
we
put
into
into
play,
we
we
have
a
hindrance
or
like
a
inconvenience
of
having
to
run
up
with
the
snapshot
every
single
time,
and
we
get
by
this
by
running
more
than
one
note
so
at
so
at
the
moment,
everything
is
green,
but
it
could
be
better.
F
C
C
There's
another
added
benefit,
because
we
we
also
realize
that
you
can
swap
a
lot
of
that
resident
memory
stuff
out
to
to
swap
disk
swap.
So,
for
instance,
we
are
running
a
90
Gig
State
database
in
64
gigs
of
RAM
with
a
swap
file
and
there's
like
little
to
no
IO
because
the
it's
not
getting
hit
all
the
time.
D
E
Sense
yeah,
which
is
great
the
only
problem
with
that,
is
that
it
the
startup
time
is.
You
have
to
load
all
that
90
gigs
of
RAM
yeah,
yeah,
yeah
yeah,
that's
45
minutes.
Once
the
system
is
running,
it's
it's
totally.
Fine!
It's
great
yeah
yeah,
it's
just
a
long
startup
time.
So
we
made
the
same
choice.
E
E
This
is,
this
is
the
thing,
so
this
is
part
of
our
automation,
where
you
know
we're
deploying
Water,
Garden
deploying
you
know
console
in
order
to
do
monitoring
anyway,
there's
a
whole
infrastructure.
You
need
in
order
to
get
this
multi-node
setup
to
work
without
any
handful
thing.
It's
not
easy
and.
D
D
For
the
love
of
I
mean
it
already
peer-to-peer
already
kind
of
knows
that
that
it's,
like
hey,
bats,
think
that
live
and
then
your
way
up.
So
that's
where
that
kind
of
comes
from,
but
it's
peer-to-peer
and
HTTP
and,
to
be
honest,
it's
even
more
critical
to
peer-to-peer,
because
it's
really
difficult
I
can
at
least
try
to
that's
the
web
request
easier
because
it's
just
a
more
intelligent
proxy
system.
But
you
know
these
TCP
connections,
it's
just
ripping
into
it
and
not
letting
go.
C
D
B
G
C
G
D
Separated
so
I'll
say
that
not
all
peers
are
created,
equal
I,
don't
know
what
the
detail
difference
is,
but
I
can
put
three
nodes
in
a
load
balancer
and
one
of
them
gets
pissed
off
when
the
other
two
warrants.
So
it's
like
whatever
it
is
and
I'll
be
honest,
I
mean
I
track.
You
know
the
stats
and
stuff
of
those
connections,
and
you
can
tell
I
know
what
my
normal
peers
are.
D
I
mean
they
stay
pretty
connected
and
then
think,
but
I'll
get
these
and
then
I'll
also
get
a
a
just,
a
mountain
where
I'm
just
accumulating
a
massive
amount
of
extra
peer-to-peers
and
then,
whenever
they
get
done,
it
comes
back
down.
I
mean
I
can
handle.
If
I
you
know
more
effectively
throttling
sessions,
but
it's
noticing
the
difference.
That's
why
I
say
I
think
that
the
peer-to-peer
probably
is
the
hole
to
where
some
of
the
nasties
come
in
and
we
don't
have
a
lot
of
ability.
It's
either
acceptance
It's
the
heaviest
weight
for
a
node.
D
Oh,
yes,
absolutely
I'd,
say
more
detrimental.
What
I'm,
finding
I
can't
even
get
info
that
peer-to-peer
node
because
they're
crushing
it
so
bad.
It's
also
relaying
to
it
as
an
API
or
anything
like
that
is
pissed
off,
because
it
it's
just
not
there,
because
something
peer-to-peer
is
the
best
I
can
tell,
is
just
ripping.
C
Well,
I
I
want
to
try
for
yeah
I,
think
we're
running
three
dot
whatever,
because
obviously,
as
you're
doing
the
upgrade,
we
found
a
little
glitch
yeah.
The
the
wax
appears
all
the
heaviest
I've
got.
We've
got
two
public
peers
and
both
of
them
are
doing
25
megabytes
each
per
second.
So
that's
like
200
megabits,
but
you
know
each
so
maybe
half
a
gig
of
pure
peer
traffic
at
the
moment
and
and.
E
C
D
D
Just
as
the
metric
and
three
weeks,
I've
sent
six
and
a
half
terabytes
of
peer-to-peer
our
public
wackners
that
had
nothing
to
do
with
the
Dozen
internal,
but
you
know
stay
insane,
but
just
publicly
serving
about
100
people.
It's
it's
a
substantial
amount
of
the
same
traffic
and
as
I
was
facing
it
this
morning.
It's
the
same
I,
don't
I,
don't
have
a
limited
to
one
IP,
because
that
tends
to
catch
a
lot
of
people.
A
D
Can
tell
you
that
that's
a
legitimate
statement
I
mean
I,
can
tell
when
somebody
fires
up
a
Genesis
node,
because
you
can
see
it
rip.
You
know
a
substantial
amount
of
data
and
then
it
kind
of
drops
off
or
keeps
going,
but
you
can
tell
when
somebody
in
my
opinion
is
legitimately
but
I,
don't
know
what
the
hell
they're
doing,
but
let's
say
they're
just
and
it's
both
ways.
It's
not
just
out.
Interestingly,.
C
G
C
D
What
I
will
say
my
stats
are
at
I
run
all
of
my
peer-to-peers
through
an
h8
proxy.
So
what
I'm?
Seeing
those
lock
steps
are
the
in
and
out
purely
of
the
public
proxy?
None
of
the
actual.
You
know
node
traffic
itself,
and
it
is
always
very,
very
lock
staff.
So
it's
got
to
be
between
the
node
and
the
peers
that
are
coming
in
externally
yeah.
D
C
D
C
Those
local
local
peers
are
on
a
different
interface.
Oh
there
you
go,
so
it
is
just
a
public
interface,
yeah
yeah,
it's
public
interface.
Each
service
got
public
and
private
interfaces.
These
ones
are
like
kind
of
like
on
the
outside
to
kind
of
handle.
All
that,
because
that's
the
that's
the
by
far
the
heavier
are
the
the
seeds.
G
G
C
D
It's
on
the
record,
while
we're
on
these
calls.
Yes,
I
mean
the
team
has
been
great
and
in
responding
to
a
lot
of
these,
and
at
least
listening
we've
been
begging
for
years,
I
mean
the
fact
that
you're,
even
listening,
the
devs
may
say
yeah
you're
right,
I've
heard
it
thanks.
I
heard
the
comment,
but
thank
you
guys,
for
you
know,
and.
G
Yeah
well
I
mean
that's
the
beauty
of
the
year.
Yeah
right
I
mean
it's.
You
know
the
fact
that
we've
been
actually
able
to
accomplish
so
much
in
the
past.
Whatever
year
and
a
half
or
as
it's
been,
you
know
what
so
you
know.
So
we
continue
to
to
move
forward.
I
think
you
know,
hopefully
we'll
continue
to
see
great
things
here.
E
I
I
just
want
to
Echo
my
yeah
Ross
and
Michael
here
great
work
by
the
enf
Polk
entire
Dev
team
really
appreciate
the
responsiveness,
interactivity
feedback.
Whatever
I
can
tell
you,
I've
been
chasing
the
polygon
team
for
a
month
that
they're
equivalent
of
like
jungle
doesn't
sink
and
they
haven't
done
anything
on
it.
So
you
know
been
very
big
difference
between
what
we
see
here
and
other
blockchains.