►
From YouTube: Velero Upload Progress review discussion - Feb 25, 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
And
then
just
get
started
okay,
so
this
is
the
meeting
for
reviewing
upload
progress,
monitoring
and
just
dive
into
it.
So
this
is
a
design
that
I'd
like
to
get
into
the
one
seven
release,
and
the
goal
here
is
to
start
enabling
us
so
start
having
valero
track
the
progress
of
snapshot
uploads
that
are
happening
in
the
background
and
that
will
get
us
on
the
steps.
So
currently
we
have
a
couple
of
we
have
several
different
plugins
that
do
this,
where
they
upload
data.
A
So
I
think
we're
all
relatively
familiar
with
the
existing
plug-in
volume
or
architecture
so
most
of
the
snapshots.
So
the
snapshot
plug-in
volume,
snapshotter
api
goes
ahead
and
we
say,
take
a
snapshot
and
then
it
returns
back
to
valero
and
then
valero
continues
on
to
the
next
thing
and
when
all
the
snapshots
have
finished
and
when
all
the
valer,
when
all
the
kubernetes
metadata
has
been
written
into
the
object,
store
the
backup's
completed.
A
But
we
have
existing
examples.
For
example,
like
with
aws
eds
you'll
go
ahead
and
you'll
ask
ebs
to
take
a
snapshot.
It
will
return
immediately,
but
the
snapshot
may
not
be
usable
until
sometime
in
the
future
when
it's
actually
presented
into
s3.
So
there's
a
window
there
where
your
valero
backup
can
be
completed.
A
A
We
probably
won't
be
able
to
push
that
into
the
background
until
we
marry
rustic
or
rustic
like
things
with
snapshotting,
but
it'd
be
nice
to
be
able
to
do
that,
and
really
our
goal
on
the
snapshotting
side
is
to
take
them
as
close
together
as
possible.
So
we
don't
want
to
slow
anything
down
on
the
snapshot
side
and
we
might
just
move
things
along.
A
A
We
want
to
be
able
to
say
that
if
your
backup
isn't
really
persistent
or
it's
not
usable,
it
shouldn't
appear
as
completed,
and
we
want
to
not
like
change
everything
in
the
volume
snapshots
and
so
forth.
At
this
point,
we're
not
going
through
and
unifying
backup
item
actions
and
volume
snapshotters.
A
So
there's
two
snapshot
paths
right
now
that
do
not
go
through
volume
snapchatter,
that
is
the
the
csi
snapshotting
and
the
vsphere
snapshotting,
and
these
both
go.
These
with
appears
backup
item
actions,
so
we
need
to
be
able
to
handle
backup,
item
actions
and
volume
snapshotters
that
can
have
ongoing
things.
In
the
background.
A
A
A
B
A
So
right
now
we
have
two
end
states.
We
have
partially
failed
and
completed
so
when
we
move
so
if
we
didn't
have
so,
I
initially
designed
it
without
this,
and
if
we
just
had
uploading,
we
would
have
to
keep
the
fact
that
the
end
result
was
going
to
be
partially
failed
somewhere,
and
I
didn't
have
a
good
somewhere
okay,
because
if
I
kept
it
in
memory,
then
we
couldn't,
you
know
like
if
we
restart
for
some
reason
the
uploads
may
be
completely.
A
You
know
fine
at
the
end,
but
we
wouldn't
we
wouldn't
be
able
to
mark
it
as
partially
failed
or
we
could
always
mark
it
as
partially
failed
because
we
crashed.
But
then
that
might
not
be
true,
because
we
may
have
done
everything
correctly,
but
the
the
server
simply
was
restarted
during
the
middle
yeah.
A
B
A
A
A
A
D
D
C
A
C
A
Yes,
well,
we
can
also
monitor
the
ebs
uploading,
so
what
we
we
should
be
able
to
do
is
when
we
come
is
when
we
do
a
restart,
we
should
be
able
to
say:
okay,
you
know,
I
think
we're
gonna
have
like
our
logs
gonna
be
stored
off
somewhere.
I
hope
so
we'll
have
to
we'll
have
to
look
a
little
bit
at
restart,
but
restart
should
enable
us
to.
A
I
think,
if
we're
in
the
middle
of
a
backup-
and
we
restart-
we
simply
say-
and
we
failed-
but
if
we're
in
these
phases,
where
something
could
be
going
in
the
background,
we're
going
to
expect
the
background
tasks
to
pick
up
and
mark
their
own
success
of
failure.
But
then
we
should
be
able
to
you
know,
watch
them
so
we'll
want
to
clean
up
our
restart
logic
as
part
of
this
project.
E
If
I'm
at
that
phase,
it's
like
at
that
point
of
the
process,
so
that
for
me,
is,
I
think,
it's
extremely
useful
when
I
look
at
this
diagram
and
by
the
way,
thank
you
because
this
makes
everything
so
much
easier
to
understand.
Do
you
have
a
request
that
if
this
diagram
needs
correction,
that
you
know.
E
I
just
like
prioritize
that,
because
it
is
so
extremely
helpful
for
people
at
least
I
think
for
everybody
who
is
very
visual.
I
am
like
that
anyway.
I,
when
I
look
at
this,
I
wonder
if
we
are,
is
it
possible
that
we
are
conflating
two
things?
Okay,
that
is
so.
This
is
a
question,
the
state
of
the
backup
at
any
given
moment,
with
the
reason
for
a
change
of
state.
E
So,
for
example,
maybe
the
states
would
be
new
in
progress,
partially
failed
and
failed
or
specially
felt
felt
complete.
And
then,
if
we
say
partially
in
progress,
we
can
say
it's
uploading,
it's
in
progress
in.
What's
what
operations
going
on
it's
uploading
so
and
then
maybe
we
can
simplify
the
transitions
and
if
it's
partially
failed,
then
we
can
say.
E
A
E
E
Maybe
this
is
the
phase
two
you
were
talking
about,
for
example,
if
snapchat
is
being
uploaded
and
the
black
backup's
complete,
but
it
hasn't
but
but
the
snapshot
is
still
going
on,
we
should
is
there
a
way
for
us
to
like
make
a
call
to
that
api
find
out?
Oh,
that
is
like
continuously
find
out,
it's
done
and
then
come
back
and
say
no
now
it's
done
done.
E
C
Field
we
talked
before
about
a
field
where,
in
the
case
that
we
couldn't
upload
the
logs,
we
basically
have
no
information
so
having
a
field
that
would
say:
hey
it's
partially
failed
or
failed,
because
we
couldn't
upload
logs,
which
is
separate
from
this
upload.
This
is
a
snapshot
upload
this,
but
still
having
that
that
description
field
would
be
helpful,
but
I'm
specifically
thinking
about
the
case
where
we
couldn't
upload
logs
for
a
backup,
because
something
happened
and
there's
really
no
way
to
tell
that
right
now.
A
E
I
think
would
be
useful
if-
and
I
am
volunteering
to
to
hash
this
out
with
you-
I
be
glad
to
this-
is
very
interesting,
very
interesting
problem
to
solve,
and
it's
going,
I
think
it's
also
very
beneficial
anyway.
I
think
it
would
be
interesting
to
maybe
open
a
spreadsheet
and
just
list
like
with
this
design.
E
E
I
know
I
know,
but
before
we
get
to
draw
the
diagram,
walk
like
okay,
we
have
the
idea
we
did.
We
have
this
diagram,
so
let's
work
with
it.
Let's
walk
through
like
difference
like
happy
path
in
use
cases
that
touch
every
deaf
ends
in
every
end
point
I
think
it's
gonna
be
helpful.
If
we
do
that,
you
know
what
I
mean
like
have
what
at
least
one
use
case
that
ends
with
every
endpoint
here
that
we
are
looking
at
so
you're,
proposing.
F
E
E
E
A
E
Oh
so
so
these
are
like
this
is
not
like
what
I'm
thinking
is
like
a
brainstorming
exercise.
It's
not
to
formalize
this
in
the
spreadsheet.
It's
just
to
walk
through
like
because
I
can't
hold
all
the
cases
in
my
head
at
the
same
time
for
one
model
and
then
like
another
one.
What
the
other
I
got
lost,
I
I
particularly
would
get
lost
so
I'm
thinking
it
will
be
easier
to
communicate.
It
will
be
easy
to
see
the
trade-offs.
A
E
E
E
G
Yeah,
that's
one
of
my
questions.
I
have
in
mind
too
that
when
we
transition
from
in
progress
to
upload,
for
example,
then
in
the
backup
workflow,
what
operation
can
be
done
at
that
point,
for
example,
if
there
is
no
useful
to
have
another,
even
though
you
know,
I
know
that
in
when
you
start
to
switching
into
uploading.
G
That
means
the
snapshot
had
been
created
and
I
started
able
to
using
the
snapshot
like
a
read
only
or
something
like
that.
Then
after
I
finish
uploading,
then
I
can
do
something
else.
For
example,
I
can.
I
just
started
throwing
out
the
that,
for
example,
if
I
already
up
even
I'm
and
even
have
stead
of
uploading,
I
can
read
it,
but
I
cannot,
you
know,
do
anything
else
with
it.
When
I
actually
completely,
then
I
can
do
a
lot
of
stuff
like
cloning
and
so
on
so
forth.
G
E
E
E
You
still
need
to
look
look
things
up
to
to
make
sure
if
you
fit
you
in
under
what
condition
the
backup
is,
but
you
know
it's
it's
going
to
be
useful
under
certain
conditions,
so
you
know
you
can
do
something
with
that
backup
and
then
there
are
other
cases
that
okay,
it's
just
not
useful
at
all.
I
don't
even
have.
I
just
have
to
find
out
why
bro
fix
it
and
but
I
need
another
backup.
B
I
I
I
think,
yes,
that's
a
worthwhile
exercise
to
do
what
I
do.
What
I
would
caution
us
from
would
be
like
increasing
the
number
of
states
things
can
be
in
which
means
there
will
be
like
it'll,
be
harder
to
implement
and
there'll
be
more
chances
of
bugs
like
implementing
a
state
machine
diagram
with
like
10.
E
A
A
E
A
C
Some
so
another
wrench
I'll
throw
in
here
is
a
lot
of
other
kubernetes
objects
are
using
lists
of
conditions.
So
when
you're
creating
a
pod
or
a
deployment,
they
say,
okay,
I'll,
add
a
condition
that
one
pod
came
up
and
I'll
add
another
condition.
Another
pod
came
up,
so
they
have,
they
don't
just
have
one
phase,
they
have
a
list
that
can
be
used.
C
Crds
have
this
pods
and
deployments
have
this,
so
it
does
make
the
logic
a
little
weird,
because,
like
in
in
valero,
we
have
to
check
on
valero
install
we're
like
is
this
deployment.
Has
this
deployment
gone
through
these
like
two
three
phases
same
with
crds?
We
have
to
say:
does
it
have
these
two
or
three
conditions,
but
that's
another
format
to
consider.
E
A
It's
useful,
but
it
also
it's
tricky
because
we
get
things
like
I'm
gonna
turn
off
this
system
I
mean
literally
physically
go
turn
the
power
off
and
the
guys
are
to
come
in
and
haul
it
away
for
e-waste
and
if
we're,
if
we
mark
completed
because
it's
usable,
but
it's
not
durable,
now
you're
in
a
bad
situation
and
in
fact
it's
even
more
in
the
in
the
cloud,
because
if
you
simply
delete
all
your
resources,
things
can
go
bad.
I
think
ebs
snapshots
are
good.
A
E
Yeah
a
different,
the
second
and
last
comment
that
I
have
is
show
comments,
so
you
can,
you
can
move
on.
Is
there
is
an
issue
that
talks
about
this
back
when
I
think
even
andy
was
on
the
project?
I'm
sure
no
one
remembers.
I
unfortunately
didn't
look
it
up
before
this
meeting,
but
he
talks
about
a
bunch
of
gotchas
that
you
know
with
the
because
this
has
been
a
desirable
behavior
for
a
long
time,
but
the
the
challenge
with
you
know:
do
we
upload
how?
E
E
A
C
E
F
A
A
So
the
idea
here
is
that
we'll
continue
on
with
our
existing
behavior,
so
we'll
go
ahead
and
call
of
our
call
all
of
our
backup
item
actions
and
volume
snapshots
just
the
way
we
currently
do
and
they're
going
to
return
snapshot
ids,
just
as
they
currently
do,
but
then
we'll
be
able
to
monitor
these
snapshot.
Ids
with
the
plugins
optionally.
A
So
so
plugin
needs
to
be
able
to
provide
status,
we'll
also
need
to
be
able
to
handle
cancellation
and
deletion
so
like
if
the
backup
gets
deleted.
While
it's
in
the
uploading
phase,
we
need
to
go
through
and
whack
all
the
snapshots
as
part
of
the
deletion
and
the
plugins
need
to
be
able
to
either.
You
know,
cancel
the
upload
or
delete
the
the
snapshot
at
the
end
or
whatever,
but
they
they
need
to
be
responsible
for
actually
cleaning
things
up
and
then
yeah
when
everything
all
the
snapshots.
A
So
we
talked
about
the
partially
failed
state.
So
that's
this
and
then
if
it
goes
to
failed,
the
expectation
is
that
we
will
stop
or
delete
all
the
snapshots
that
are
associated
with
it.
I'm
not
sure
if
that's
the
right
thing,
maybe
that
that
should
really
be
something
that
happens
as
part
of
the
actual
deletion.
F
F
F
Yeah,
no,
it's
just
so.
Is
there
there's
a
difference,
though,
between
deleting
the
resources
and
stopping
any
from
any
further
ones
from
being
created,
because
if
we've
initiated
the
the
upload
part,
then
maybe
we
don't
necessarily
need
to
continue
with
the
upload,
but
you
still
want
to
keep
the
existing
resources
that
have
already
been
created.
A
B
C
A
C
A
E
A
A
Well
and
like
so
so,
like
the
the
thing
that
drove
me,
nuts
was
when
I
was
working
on
the
azure
testing.
The
azure
plug-in
would
fail
because
we
didn't
allocate
enough
memory
to
the
pod,
but
it
only
failed
when
we
were
actually
uploading
to
the
object
store.
So
at
that
point
we
had
marked
the
backup
as
well.
We
hadn't,
like
the
backup,
is
complete.
C
Right
so,
okay,
so
I'm
talking
about
two
different
things.
So
that's
that's
the
case
where
a
description
field
would
be
useful
because
we
cannot
make
a
log
like
we
cannot
upload
it
to
object
storage.
So
we
should
write
that
in
description
field
there
are,
there
are
errors
when
you
do
a
backup
or
restore
describe
so
things
like
when
you
just
describe
a
restore
and
say
it'll
say
we
couldn't
restore
an
object
because
one
was
already
there.
Those
those
kinds
of
errors
are
there,
but
we're
not.
A
C
F
Very
side
point,
but
is
there
any
way
that
we
could
potentially
change
how
the
logs
are
kind
of
currently
managed
so
that
you
essentially
have
like
two
writers
for
the
logs,
the
one
that
can
be
streamed
during
the
backup,
that's
in
progress
and
then
one
that
eventually
gets
written
to
to
object?
Storage,
I'm
just
thinking
about
like
a
separate
another
project
that
I'd
worked
on
in
the
past.
F
A
D
A
C
Well,
so
I
think
what
shawn's
referring
to
is
the
kubernetes
event
structure,
which
is
also
ipods
and
everything
those.
So
I
actually
looked
in
the
looked
into
this
last
year,
maybe
late
2019,
but
we
didn't.
We
didn't
go
forward
with
it,
but
I
think
it's
a
valid
idea.
The
events
in
kubernetes
are
meant
to
be
transient,
so
it
would.
C
E
E
E
C
You
make
the
log
too,
so
I
think
we
would
combine
that
with
like
bridget's
t
kind
of
idea
that
we
do
both.
I,
I
don't
think
we
could
rely
solely
on
the
kubernetes
events
and
I
don't
want
to
capture
them
because
that's
an
anti-pattern
with
what
everybody
else
does.
But
if
we
log
as
well,
I
think
we
get
both
things.
A
C
Yeah
and
like
this
is
this
goes
back
to
the
constraints
under
which
valero
has
been
designed
so
far
like
we
could
do
all
this.
We
could
put
a
little
web
server
that
fronts
it
or.
However,
it's
I
think
to
accomplish
that.
We
would
need
to
have
a
valero
service
that
people
would
have
to
plumb
through
because
right
now,
a
good
thing
about
valero.
Is
you
just
submit
stuff
to
the
kubernetes
api
server?
There's,
nothing
special!
You
don't
have
to
set
up
any
routes
or
anything,
there's
no
ingress
right,
yeah,
which
is
nice.
From
our
perspective.
C
C
A
Yeah,
it
opened
up
a
whole
can
of
worms.
It's
also
like
you
know.
The
the
opposite
argument
is
what
we're
getting
some
smaller
is
like
hey.
I
may
not
have
access
to
that
object,
store
that
we're
actually
writing
into
from
my
desktop.
I
do
have
access
to
the
cluster,
but
the
object
store
itself
is
firewalled
off
for
me,
for
whatever
reason.
C
Guarantees?
Yes,
yes,
we
like
we
had
the
the
recent
requests
about
proxies,
there's
no
guarantee
that
we
could
get
it
that
we're
not
going
to
be
banned
in
the
middles,
so
yeah
there's,
I
could
see
a.
I
could
see
an
argument
for
for
saying:
valero
needs
an
ingress
and
a
service
that
we
can
hit.
I
think
that's
a
big
design
change,
but
it
enables
some
other
use
cases.
A
Is
really
good,
but
it's
a
little
off
so
the
idea
here,
let's
see
so
so,
there's
one
kind
of
really
major
change.
That
happens
in
the
way
that
we
interact
with
the
object
store,
and
that
is
that
we
might
upload
a
bunch
of
stuff
to
the
object
store.
So
we
would
put
in
like
the
the
tarball,
the
log
files.
A
A
So
the
idea
here
is
that
we'll
change
the
or
add
some
things
to
the
plug-in
apis.
So
we
have
a
upload
progress
structure
that
we
can
ask
them
for,
and
this
will
just
return.
It
has
a
flag
to
say
whether
or
not
things
are
completed.
There's
an
error
to
say
you
know
if
there
was
an
error
that
happened,
and
then
we
have
this
items
completed
items
to
complete
this
could
be
bytes.
This
could
be
objects,
it's
whatever
it
is.
A
So
we
have
like
delete
item
action
is
a
separate
plugin
from
backup
item
action,
so
this
is
kind
of
following
the
same
model
where
we
have
a
backup
item
progress,
but
I
think
I
could
go
either
way,
but
I
was
just
I
think,
nolan
and
I
bounce
this
around
a
little
bit
and
it's
like
hey.
Let's
just
keep
it
parallel
to
the
existing
plug-in
structure.
A
You
know
munging
records
and
twiddling
bits
and
have
snapshotting
be
explicitly
snapshotting
and
not
just
oh.
By
the
way,
our
backup
item
action
happened
to
do
a
snapshot,
and
then
we
can
go
back
to
tracking
all
of
our
snapshots
like
right.
Now
we
have
the
volume
snapshots
file,
that's
part
of
the
backup,
but
that
doesn't
get
updated
properly
for
backup
item
actions
that
start
doing
snapshots.
C
D
A
C
Actually,
scott
has
revised
that
design
and
it
will
be
a
breaking
api
change,
so
I've
asked
him
to
I.
I
know
following
you're
interested
in
this,
and
I
think
scott
is
too
like
we
will
need
help
to
get
the
plug-in
versioning
api
out
early
in
the
1.7
release.
Okay,
yeah
scott
scott
was
actually
implementing
his
old
design
and
he's
like.
Oh,
this
won't
work.
So,
okay,
I
did.
B
C
See
that
yeah
it's
it's
posted
on
the
core
repo,
but
he
before
he
proposed
that
he
pinged
me
and
was
like
what
should
I
do
to
reconcile
this?
I
told
him
update
the
design
but
yeah
as
one
seven.
I
think
one
of
the
very
first
things
we'll
have
to
do
is
make
sure
we
get
the
the
plug-in
versioning
rationalized.
G
A
Yes,
so
that's
good,
so
so,
which
way
we
actually
implement
the
apis.
I'm
willing
to
go
either
way.
Does
anybody
see
any
issue
with
the
basic
algorithm
where
we
snapshot
everything
and
then
we're
pulling
in
the
background
into
the
plugins?
And
you
know
timeouts
or
you
know,
polling
intervals
and
so
forth.
B
C
B
A
C
A
C
A
B
A
We
made
a
bunch
of
progress
anyway,
so
we're
almost
to
time
so
there's
no
changes.
I
don't
believe,
there's
any
actual
changes
in
the
velo
backup
format
itself,
except
for
you
know,
adding
the
new
phase
and
putting
off
when
we
upload
the
backup
record.
A
little
discussion
here
on
what
things
would
do
pretty
much.
We
talked
about
the
backup,
workflow
and
then
on
restart.
We
discussed
that
a
little
bit
that
we
would
go
ahead
and
look
for
backup
resources
that
are
in
uploading
oops.