►
Description
Praefect in the charts demo
A
Okay,
so
this
is
the
distribution
team
demo.
It
is
now
the
time
that
it
is
scheduled
to
start.
So,
if
you
are
late,
we
will
not
wait
for
those
of
you
who
are
not
looking
at
the
demo
notes.
I'm
going
to
today,
demo
deploying
private
into
kubernetes.
The
details
are
all
in
there
there's
a
link
to
the
issue.
I
have
a
few
scenarios
I
want
to
poke
around
with.
I
want
to
test
the
blank
make
sure
it
works
when
other
people
are
watching,
which
isn't
always
a
guarantee.
A
I
don't
want
to
kind
of
poke
around
a
little
see
what
we
can
do.
I
want
to
test
scaling
up,
get
away
replicas.
I
have
never
done
this
and
I
wanted
to
scaling
down
very
silly.
Reckless
again,
I
have
not
done
that
and
then
I
want
to
try
just
kind
of
killing
pods
and
see
how
trifect
handles
that
in
this
scenario,
because
I
have
not
tested
that
at
all
as
well,
so
we'll
give
this
a
shot.
A
A
A
So
while
we
wait
for
those
who
aren't
aware,
prefect
is
sort
of
like
the,
I
guess,
a
high
availability
coordinator
for
giddily,
so
each
giddily
node
will
be
a
replica
of
the
other
one.
They
all
have
their
own
pve,
but
they
will
then
pray
effect
will
ensure
that
all
the
data
gets
replicated
between
all
of
them.
A
A
A
A
B
C
C
It
there's
a
matter
of
gaining
confidence,
understanding
the
actual
application
performance
metrics,
how
it
actually
behaves
with
our
load,
the
database
impact,
the
monitoring
impact,
etc.
So
we
can't
just
like
roll
the
fleet
into
it
because
in
reality,
you're
going
from
a
italy
instance
to
two
or
more
giddily
instances
with
two
or
more
prefect
in
front
with
two
or
more
databases
in
between.
B
A
C
A
A
A
A
A
A
The
project
config
is
very
similar
to
the
gita
config,
which
can
be
frustrating
when
you're
debugging.
Why
it's
not
working
and
it
turns
out
it
picked
up
the
gitly
config,
but
other
than
that.
It's
fine
and
it's
pretty
standard.
We
are
using
the
urb,
but
the
database
settings
and
we've
got
the
virtual
storage
settings.
A
Because
so
there
are
database
migrations,
so
we
can
check
the
state
of
those
and
those
are
all
applied.
So
that
is
good.
We
do
have
the
startup
script
for
for
pre-effect
just
runs
the
migrate
on
every
start,
there's
not
operation.
So
there's.
No,
it's
not
a
heavy
cost
to
make
sure
all
the
migrations
have
started
every
time.
We've
done.
Sql
thing
make
sure
to
talk
to
the
database,
that's
good.
A
If
they
weren't
working,
we
just
run
sql
migrate
there
and
it
would
migrate
everything,
and
then
we
can
dial
those
to
check
each
of
the
node.
It
can
talk
to
they
check
text.
I
can
talk
to
them.
It
can
check
their
consistency
and
that
everything
is
good.
So
everything
is
happy
there
and
then,
if
it
wasn't,
we
could
run
reconcile
or
we
could
accept
data
loss.
I
haven't
played
around
with
those,
so
I'm
not
sure
the
full
implications
of
doing
that.