►
From YouTube: Velero Community Meeting / Open Discussion - Feb 9
Description
Feb 9, 2021
Status Updates - items working towards roadmap
nrb
Helping implement credential support on volume snapshot locations
Opened a PR to close issues if they’re stale. (PRs will not be closed as stale)
Opened a PR for labeling issues and adding a PR template
Working with Dave to solidify a roadmap for the next few versions
Reviews of items defined as release blockers.
This list is incomplete, but these are the PRs we’re prioritizing
Aim to get a pre-release of v1.6.0 out by end of February
Playing with “crashd” to get info about a Velero install within a cluster.
Getting some sort of bundling would be helpful so we can put the Velero crashd scripts in our repo.
Would be part of a solution to velero debug or something similar
bridget
Working on multiple credential support
Blocked on #3190 and #3409 (working off these branches locally)
Will push branches for support in BSLs and VSLs once the above are merged
Work on restic support is still ongoing
carlisia
Updated DownloadRequest PR, ready for review
Wrapping up addressing reviews for the BSL credentials field PR
Next: review PRs related to the multiple credentials change
After: PR review of the e2e tests
dave
Community support last week
Upload progress design doc - https://github.com/vmware-tanzu/velero/pull/3416
Will schedule community design review on upload progress
E2E tests running automatically
Discussion Topics
shawn-hurley (Shawn Hurley)/dave (Dave Smith-Uchida) - Have the Velero CLI use the active namespace in the current context (https://github.com/vmware-tanzu/velero/issues/3194)
This has links to multitenancy design - if Velero watches for backups & restores in different namespaces, this becomes important
Nolan owes architecture diagrams
Rahul Rathi - Ways to capture the volume size corresponding to every snapshot contained in a backup
Currently there is no place where Velero captures the snapshot sizes
Can the velero VolumeSnapshotter API add a way to report the size of the snapshot and the size of the volume?
Dave - snapshots could have dependencies
This is why there’s a request for the original volume size
Nolan
Does the CSI API expose this?
There’s a restoreSize field there
We’d need to add another field on the CSI objects, which is viable
How would this work with restic
Could use PV’s size to start with
Also helps on restore
Dave - Can we get use cases?
May need a dry run
Give users an idea of how much data is going to be restored?
This would be hard to use across clouds
Requirements in priority
Volume size (in Velero and CSI API)
The VolumeSnapshotters are eventually going to be deprecated, so we’ll need to make sure it gets into CSI
CSI and vSphere snapshots are a different path - they’re BackupItemActions
We have the PV YAML in the backup, and can scrape it
Can we get a design doc?
Frankie (codegold79)/Rafael (brito-rafa) - Update on PR #3133 (Enable API Groups Feature)
Contributor Shoutouts
@a-mccarthy: remove FAQ pages
@mike1808: Add colors to describe command
@shellwedance: Modify InitContainer checking function that potentially incurs error
@aslafy-z: [velero] feat: allow servicemonitor to be deployed in another namespace
A
A
First,
one
will
be
closing
issues
if
we've
asked
for
information
and
they
we
haven't
gotten
response
for
35
straight
days
and
the
other
one
is
adding
issues
and
labels
to
prs
and
adding
a
pr
template.
So
now,
when
you
open
pr,
you'll
get
the
template
and
it'll:
ask
you
for
things
like
signing
the
dco,
creating
a
change
log
and
up
uploading
documentation
so
looks
like
these
are
both
merged.
A
A
We
may
get
some
other
ones
in
in
between
now
and
then,
but
these
are
going
to
be
the
focus
and
anything
around
multiple
credentials
may
pop
into
this
list.
So
I
just
wanted
to
communicate
that
so
yeah
we're
aiming
for
late
february
for
a
pre-release
and
then
for
one.
Seven,
we've
been
talking
about
this
valero
debug
command
and
I
started
playing
with
crash
d
or
crash
diagnostics,
which
is
a
vmware
tonsil
tool
that
can
gather
a
bunch
of
information
out
of
your
cluster.
B
C
D
I've
just
noted
there
they're
the
two
pr's
related
to
the
cli
and
then
also
getting
the
credential
field
into
the
vsl
and
bsls,
which
I've
been
working
off
locally,
so
I
think
like
if
we
can
try
and
focus
and
just
get
bump
those
pr's
just
like
a
little
bit
of
the
priority
queue.
That
would
be
super
helpful
for
me.
Stan
that
unblocks
me
to
push
a
new
pr
which
adds
support
into
these
for
the
for
the
bsls
and
bsls.
D
That
means
that
they
will
be
able
to
read
that
credential
and
then
apply
it
whenever
performing
the
operations
with
the
plug-ins,
I'm
still
working
on
the
restic
support
that
one's
the
way.
The
the
way
you
pass
credentials
and
jurassic
is
just
a
little
bit
different.
So
that's
just
taking
a
little
bit
more
effort
just
to
make
sure
that
I've
got
all
the
the
cases
covered
there.
I
haven't
mentioned
it
here,
but
after
this
yeah
I'll
try
and
get
some
of
the
other
high
priority.
D
E
E
And
the
I'm
wrapping
up
the
addressing
code
reviews
for
the
addition
of
a
credentials
field
to
the
create
backup,
storage
location.
So
we
can
support
the
multi
credentials
that
bridget
is
working
on
and
after
that,
I'm
going
to
prioritize
reviewing
apr.
That's
related
to
multiple
credentials
and
after
that,
I'm
going
to
do
the
e2e
test.
Pr
review.
F
F
I
think
we
got
everything
moving.
At
least
I've
been
working
on
the
upload
progress
design
dock,
so
this
would
allow
us
to
monitor
data.
That's
moving
after
we've
taken
snapshots
and
after
the
backup
is
finished,
so
this
is
currently
something
that
like,
for
example,
in
aws.
You
know
ebs
snapshots
after
you
snapshot
them.
There's.
Actually
a
phase
where
they're
not
ready
to
use
yet
same
is
true
for,
like
the
vsphere
plug-in,
so
we're
going
to
formalize
this
bring
it
into
valero,
where
the
backup
won't
actually
say
it's.
F
It's
done
until
it's
actually
done
so
the
design
docs
there
and
moving
forward
we're
going
to
start
doing
architecture
reviews
on
design
things
as
a
as
a
meeting.
So
I'm
just
going
to
go
ahead
and
schedule
a
meeting
for
that,
and
you
know
I'll
publish
it
here
and
everybody's
welcome
to
drop
in
and
discuss,
and
for
this
week
I'm
working
on
getting
end-to-end
tests
running
automatically.
F
This
is
inside
some
of
the
vmware
framework,
because
we've
got
a
bunch
of
a
bunch
of
automation
going
on
there
once
we
get
that
going,
I
think
we
can
look
at
maybe
as
a
community
thing,
taking
what
we've
got
and
hooking
it
together
with
like
cappy
so
like
we
have
tools
to
spin
up
clusters
across
multiple
clouds,
and
you
know
setting
that
up,
so
people
can
use
it
and
making
it
more
public
yeah.
So
that's
it
for
me.
A
F
C
C
The
issue
is:
can
we
use
the
kubernetes
context,
cubeconfig
context
and
like
the
default
one
for
valero
commands,
so
that
you
don't
have
to
specify
the
namespace
if
you're
in
a
different
name
space
than
valero
every
time
or
set
a
environment
variable
right?
Instead,
you
you
work
on
your
cube
context.
C
That's
the
that's
the
issue.
Obviously
this
is
a
breaking
change
in
the
sense
that
right
now
the
valero
name
spaces
the
default.
We
would
be
changing
that
to
the
context
default
and
that
would
be
that
could
potentially
be
a
pretty
large
breaking
change
for
users
if
they're
not
ready
for
it.
So
I
think
we
were
kind
of
talking
about
okay.
What
is
the
right,
precedence
order
and
so
carlesi,
I
think,
actually
added
a
set
of
them
right
there
yeah.
C
So
that's
what
we
were
going
with
and
then
I
think
dave
you
brought
up
some
concerns
around
two
specific
calls
around
the
or
two
specific
situations
where
it
was
the
valero
install.
Might
then,
with
that
gonna
go
to
the
default
newsletters
of
the
letter
name
space,
maybe
the
like,
is
the
valero
installed.
Maybe
that
should
be
handled
differently.
With
my,
I
think,
response.
F
Go
ahead,
I'd
like
to
take
a
step
back
and
like,
what's
the
feature,
who's
the
feature
for
because
the
way
I
read
this.
This
is
something
that's
more
of
a
feature
for
a
valero
developer,
because
I
think
most
people
are
going
to
install
valero
and
then
they'll
interact
with
it
through
the
valero
cli,
but
their
context
for
their
name.
Space
is
going
to
be
whatever
they're
actually
working
with
in
kubernetes,
and
it
won't
be
the
valero
name,
space.
A
A
G
Well,
the
other
thing
with
that
is
that
if
you
have,
if
you
have
two
different
valero
installs
and
two
different
name
spaces,
each
valero
only
watches
the
one
in
that
namespace,
which
allows
you
to
actually
have
different
versions
of
valero
installed.
But,
but
I
guess
part
of
the
issue
here,
I
think,
is
at
least
in
our
use
case.
F
G
F
F
You
know
or
set
that
as
my
default,
so
that
when
I
do
a
backup
it
just
does
the
current
name
says
as
a
user.
That
seems
valuable
to
me
because
I
don't
have
to
mess
with
minus
minus,
include
and
type
in
all
this
junk,
every
time
or
aliasing,
and
then
it's
wrong
because
I
switch
namespaces.
So
I
think
there's
a
feature
there
and
then
there's
a
feature
where
we
say:
okay,
if
you
have
an
alternate
namespace
or
alternate
namespaces,
multiple
installs
of
valero,
how
do
we
make
that
easier
to
use?
E
F
A
I
I
want
to
break
this
apart.
Just
a
little
bit:
valero's
client
on
client
side.
You
can
tell
valero
which
namespace
to
send
it's
resources
too.
So
if
you
run
this
valero
client
config
set
namespace
command,
it
will
say
when
I
say,
valero
backup
it'll
send
resources
to
that
namespace.
So
in
scott's
case,
where
they're
using
openshift
migrate,
you
would
set
this
to
set
namespace
to
openshift
migrate
and
that's
where
your
valero
client
would
be
operating.
A
F
So
then
it
switches
with
you
as
you
change
your
context
with
cubectl
you'll
go
to
the
right
one
and
that's
really
a
developer
feature.
I
think
it's
useful
for
us
all.
It's
pretty
easy
to
set
an
environment
variable.
You
don't
have
to
change
it
every
time
you
just
set
it
once
and
say
this
is
the
behavior
I
want,
and
then
we
go
with
this
current
proposal,
but
gated
by
that
behavior.
F
Well,
what
I'm
hearing
is
that
people
have
multiple
installs
of
valero
and
they
want
to
be
able
to
go
to
the
right,
install,
which
is
the
one
that
they're
actually
working
on
using
cubectl
as
well,
and
so
they
would
have
set
the
in
their
context
to
the
valero
namespace
they're
working
on
you
know
our
install
they're
working
on
and
they
would
like
to
just
have
the
valero
cli.
Follow
that
without
your
step
right
and
so
I'm
thinking,
maybe
we
just
have
an
environment
variable.
F
That's
basically
for
this
scenario
that
says
I
will
follow
your
default
context
and
then
all
the
rest
of
the
stuff.
It's
just
gated
by
that.
If
that's
on,
then
this
behavior
happens,
but
for
the
average
user,
I
don't
think
they
want
to
have
multiple
valeros
installed.
In
fact,
we
don't
want
them
to
install
multiple
values
if
we
can
avoid
it
and
they're,
almost
certainly
not
going
to
be
using
cube
ctl
with
valero.
G
H
F
Yeah,
that
makes
sense
too
I
mean
we
can
have
a
flag.
That's
just
like
minus
minus
valero
name
space.
You
know
equals
current
or
something
cube,
ctl,
and
then
you
can.
You
can
script
that
and
not
have
to
worry
about
setting
environment
variables
and
have
everything
be
set
somewhere
else.
Is
that
reasonable.
A
F
I
G
A
A
D
E
So
what
I
think
that
I
wanted,
and
that
I
thought
people
also
would
benefit
from,
is
have
a
conf
have
a
way
to
configure
so
that
when
I
specify
where
valero
is
what
the
namespace
profiler
is.
So
if
I
issue
a
command
for
valero,
I
don't
have
to
specify
the
namespace
if,
wherever
I
am
so,
if
I
say
if
I
in
the,
if
I
have
one
or
if
I
have
two
they'll
start,
the
one
namespace
or
two
or
multiple
or
whatever
that
doesn't
matter.
E
E
A
I
do
want
to
pop
up
and
clarify
that
valero
valero
only
stores
its
its
stuff.
It's
back
to
crds.
It's
restore
crds,
all
that
in
its
own,
in
whatever
name
space
you
give
for
valero,
but
it
doesn't
scatter
it
across
the
cluster.
It
doesn't
say,
like
I
put
backups
in
the
default
namespace
unless
you
install
it
there,
but
it
can
query
everything
on
the
cluster.
So
that's
how
the
valero,
valero,
backup
and
restore
process
works
is
that
valero
itself
lives
in
its
own
namespace.
A
C
A
A
C
So
then
you
would
have
a
what
you
would
have
is
a
plug-in
that
doesn't
back
up
the
valero
stuff
right,
obviously
rips
it
out
of
the
backup,
but
that
then
I
would
be
watching
you
know
each
individual
name,
space
and
so
valero,
backup
and
namespace
a
would
backup
namespace
a
right.
I
guess
I'm
going
to
say,
speed
would
mac
up
namespace
b
and
the
valeria
instances
would
be
sega,
segmented
out
and
users
would
be
creating
the
backup
crs,
not
in
the
valero
name
space,
but
in
their
own
name
spaces.
C
C
A
C
Yeah
yeah,
I
was
kind
of
thinking
it
would
probably
be
the
same
name
space
you
would
just
have
a
would
be
the
same
space
and
then
add
a
plug-in
that
would
remove
the
backup
right,
like
remove
the
cr,
remove
the
crs
that,
like
that,
we
want
to
get
rid
of
for
the
valero
thing.
So
when
you
do
the
backup
you
just
remove
them
well,.
F
F
A
I
did
that
okay.
Well,
if
you
did
that,
then
I
would
like
to
see
your
configuration
just
so
we
can
because
that's,
I
think,
that's
the
part
I
was
getting
hung
up
on
here,
but
in
that
scenario
it
does
make.
This
makes
more
sense
to
me.
So
if
you,
if
you
have
like
the
commands,
you
issued
to
make
sure
it
watched
a
different
name
space,
then
maybe
my
understanding
is
incorrect
and
we
we
do
provide
that.
So
we've
been
looking
at
multi-tenancy.
F
And
nola
and
I
were
battened
around
different
ways
to
multi-tenancy,
and
I
was
suggesting
that
we
do
that
approach
where
we
let
people
write
backup
crs
into
their
own
namespace
and
nolan
brought
the
issue
that
that
you
know,
as
he
stated
earlier.
That
then
puts
the
backup
inventory
into
the
namespace
you're
protecting
and
we've
got
enough
of
a
problem
already
with
the
backup
inventory
living
in
the
cluster
that
we're
protecting,
but
even
putting
into
this.
F
But
if
you
make
it
even
more
so
where
it's
tied
to
the
namespace,
you
know
when
you
delete
the
namespace,
the
backup
crs
disappear
and
there's
no
good
way
to
get
back
to
them.
So
there's
a
multi-tenancy
issue
that
we've
got
to
address:
we're
not
going
to
address
it
today.
It's
on
the
road
map
and
I
definitely
invite
input
for
how
we're
going
to
get
there.
But
let's,
let's
not
drive
too
much
into
the
rat
hole
at
the
moment.
C
F
A
So,
where
we're
at
with
this
issue,
I
I
sean
if
you
got,
if
you
got
valero
the
valero
server
to
recognize
for
the
little
pod
to
be
in
one
name
space
but
watch
backups
in
another.
Could
you
post
that
configuration
in
this
issue
because
that,
for
at
least
for
me
that
helps
me
understand
the
environment
this
con?
This
request
is
running
in.
I
think.
C
Yeah,
I'm
not
relying
on
it.
I
I
I
do
think
that,
like
that's,
probably
a
standard
way
to
deploy
some
stuff
right
yeah,
so
I
I
do
think
yeah.
I
think
lots
of
controllers
watch
name
spaces
that
they're
not
in
like
the
yes
right
and
only
watch
one
name
space.
So
I
think,
like
that's
a
that's
a
pretty
well-defined
pattern.
I
think
that
would
be
something
that
would
make
sense.
F
It
the
the
problem,
is
the
declarative
api
part
of
it,
where
the
backup
cr
is
the
backup
and
for
most
of
the
other
controllers,
that's
ephemeral
with
your
cluster.
If
you
delete
your
namespace,
your
resource
is
supposed
to
go
away.
If
you
delete
the
namespace
that
has
your
backups
in
it,
the
backups
are
not
supposed
to
go
away.
So
that's
that's
kind
of
the
mishmash
between
the
declarative.
A
H
F
A
Valero
server
has
at
startup,
and
while
it's
running
has
a
sync
process
that
it
goes
to
the
bucket
you've
defined
and
says:
okay,
are
there
backups
in
the
bucket
that
I
don't
have
listed
in
the
cluster
and
it'll
pull
them
down?
So
that's
how
we
get
around
the
finalizer
issue,
because
our
source
of
truth
for
a
backup
is
not
the
valero
namespace,
because
the
backups
can
span
clusters
so
like
it,
we
don't.
When
you
do
a
restore,
we
don't
reach
into
the
original
cluster
and
pull
backups
out
of
that
namespace.
C
C
C
A
C
J
F
I
F
Yeah
I
mean
that's,
like
you
know
the
the
issue
like
even
like
in
g
sphere.
You
know
I
get
this,
ask
it's
like
how
big
is
the
snapshot
and
the
snapshots
are
dependent
on
each
other,
so
you
know
you
can
have
a
size
of
a
snapshot.
You
know
you
have.
You
can
have
like
three
snapshots
right
and
one
is
tiny
until
you
delete
two
because
one's
dependent
on
two
and
then.
H
F
K
Yeah
and
that's
why
I'm
saying
the
original
volume
size
is
important,
because
we
want
to
make
sure
that
like
if
we
are
doing
a
backup
product,
we
could
something
like
do
where
we
can
say
how
large
the
volume
is.
Give
them
upfront
information
about
what
it's
gonna
take.
Basically,
especially
if
they're
doing
data
movement,
that
kind
of
becomes
important.
K
F
I
would
ask
that
we
try
to
define
the
use
cases
and
that
we
look
at
across,
like
all
the
different
snapshot
technologies
that
we're
on
top
of,
because
that's
the
difficulty
of
saying
hey,
you
know,
implement
this,
and
you
know
I.
I
honestly
can't
even
give
you
that
answer
on
vsphere
right
now.
If
you
ask
me
how
big
is
a
snapshot,
the
answer
is,
we
don't
know.
F
F
That
may
be
something
where
we
need
to
do
more,
like
a
dry
run,
for
example,
where
we
may
even
go
through
and
postpone
the
data
movement
phase
until
later
go
through
snapshot
everything,
and
then
you
can
say:
okay,
here's
how
much
data
has
changed
in
this
snapshot
from
the
previous
one,
because
it
may
even
be
an
interaction
between
the
snapshot
and
the
backup
system.
Right,
because
you
do
things
like
dedupe
on
the
fly
and
you
know
we
may
not.
A
I
have
two,
so
I
have
two
questions
on
this,
so
we
are
kind
of
looking
to
deprecate.
The
volume
snapshot
api
in
favor
of
the
csi
ones.
I
I
just
asked
shing
if
there's
a
place
for
on
the
kubernetes
volume
snapshot
objects.
If
there's
a
place
to
write
this,
there
is
a
restore
size
on
the
volume
snapshot,
but
it's
optional
and
the
csi
driver
has
to
populate
it.
So
valero
could
add
this,
but
I
think
longer
term
we
want
we
would
want
to
advocate
for
rolling
this
into
the
volume
snapshot.
A
Csi
objects.
I
I
agree
that
it's
all
useful
data
and
I
also
agree
it's
all
weird-
it's
not
accurate,
so
I
wanted
to
toss
this
out
and
in
my
view
I
I
get.
This
is
important
for
like
uploads
and
things
like
that
and
on
restore
knowing,
if
you
have
enough
room,
but
also
wondering,
if
you've,
given
any
thought
to
how
this
might
work
with
rustic
or
a
file
system
level
reporter.
K
F
So
I
like
the
idea,
I
think
it's
going
to
take
some
some
thought
and
you
guys
probably
have
some
examples
you
can
bring
in
from
the
net
backup
side
of
how
you
do
this
elsewhere,
and
we
can
look
at
following
that.
I
think
we
want
to
make
this.
You
know
optional
because
we're
either
going
to
have
to
come
up
with
something
that
really
works
everywhere,
or
we
have
to
make
this
like
an
optional
thing,
because
I
don't
know
that
we
can
get
this
out
of
every
cloud
provider
even
like
you
know,
azure
snapch.
F
J
Correct
so
amber,
I
had
primarily
the
idea
about
capturing
the
volume
size
right
as
umber.
You
also
mentioned.
These
two
are
different
things:
right
volume,
size
and
snapshot
size.
So
primarily,
what
we
need
is
a
volume
size
at
present
and
that
we
can
capture
while
performing
the
snapshot,
and
we
can
persist
in
the
volume
snapshot
spec.
If
it's
a
snapshot
size,
it
has
to
come
from
the
volume
snap
shutter
plugin,
which
will
be
it
has
to
come
from
the
from
the
provider
and
right.
I
J
Would
be
yeah
that
would
be
much
we
need
to
validate
with
different
type
of
providers
right,
and
I
believe
yes,
cloud
providers
should
provide
the
size
because
the
user
gets
billed
as
per
the
data
content
within
the
snapshot.
The
other
point
that
I
think
was
discussed
is
incremental
or
full.
I
think
the
cloud
provider
internally
will
figure
out
if
it
has
to
be
the
incremental
snapshot
or
full
they
have
their
own
implementation.
As
per
my
understanding,
right.
J
J
F
Yes,
so
what
we're
going
to
be
doing
is
formalizing
our
process
for
road
map
items
and
design.
This
is
something
that
we
can
have
as
a
roadmap
item
for
maybe
one
seven.
What
we'd
like
to
have
is
a
proposal
to
put
it
on
the
roadmap
and
then
like
a
design
dock
that
goes
through
this.
One
of
the
things
to
keep
in
mind
is
the
vsphere
plug-in
is
not
a
volume,
snap
shutter,
it's
a
backup,
item
action
and
I
think
that's
one
of
your
primary
use
cases.
F
F
J
J
I
F
Paths
there's
volume
snapshotter,
which
is
what
you've
been
looking
at:
okay,
that
covers
evs
the
old
ebs
actually,
because
new
ebs
is
getting
pushed
towards
csi
snapshots,
there's
ebs,
azure,
google
cloud
and
the
old
valero
vsphere
plug-in
the
1.0
plug-in
the
csi
snapshotter
and
the
new
vsphere
plug-in
the
1.1.0
plug-in
are
both
backup
item
actions.
They
do
not
actually
create
a
volume,
was
it
volume,
status
spec?
J
Then
yeah
so
the
needs
like
I
mentioned,
we
need
to
capture
the
amount
of
data
that
has
been
backed
up,
not
in
terms
of
snapshots,
but
what
is
getting
protected
in
terms
of
source
right,
the
volume
so
yeah.
That
is
pretty
much
required,
and
so
you
want
me
to
further
explore
for
this
different
plugins
right
typically
for
the
vsphere
plugin,
that's
what
you
mentioned.
It
has
a
different
path
right.
That
needs
to
be
investigated,
so
we
can
get
this
info
like,
for
example,
the
pv.
F
F
A
So
they're
they're
when,
when
valero
restores
it
iterates
over
the
kubernetes
ammo
and
if
there's
an
annotation,
I
believe
it's
an
annotation
on
the
pv
kubernetes
yaml.
Then
it
will
go.
Look
up
the
snapshot
in
that
annotation.
So,
basically,
to
make
a
snapshot.
You
need
to
have
some
sort
of
pv,
so
we
could
probably
extend
it
to
scrape
that.
L
M
Thank
you,
nolan
for
the
approval,
I'll
just
review.
Another
pass
on
the
documentation
is
recommending
a
couple
tweaks,
making
cross
reference
a
couple
pages.
We
have
the
cluster
migration
page.
I
think
it's
worthwhile
to
point
that
we
have
this
feature
coming
along
and
make
a
cross
reference
of
the
backup
file
format
as
well.
We
we
we
left
today
the
the
current
page
tells
that
we're
gonna
address
the
restore
in.
M
M
A
M
A
M
M
A
And
yeah
for
maintainers
and
reviewers
just
like
to
note
that
this
is
a
release
blocker.
So
if
you
take
a
look
at
this,
I
in
terms
of
priorities,
I
think
we
should
get
bridget
unblocked
first,
but
in
my
opinion
I
think
this
is
pretty
much
code
complete.
In
fact,
I
wouldn't
I
wouldn't
mind
personally
if
we
addressed
these
documentation,
changes
in
a
follow-up,
but
please
give
it
a
review
and
share
your
thoughts.
A
A
This,
isn't
it's
not
super
big,
but
it
shows
it'll,
give
you
colorized
output
for
like
the
status
of
phases
and
things
like
that.
So
if
it's
failed,
it'll
be
red,
if
it's
successful
it'll
be
green
next,
we
have
one
from,
shall
we
dance
kim
and
this
fixed
a
bug
that
could
possibly
happen
in
rustic
restores
we
assumed
that
the
rustic
container
would
always
be
the
first
init
container,
but
that's
not
necessarily
true.
It
may
be
all
right.
Sorry.