►
From YouTube: Kubernetes SIG CLI 20220126
Description
Kubernetes SIG CLI bi-weekly meeting on January 26, 2022.
Agenda/Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=id.56xxgyzabf72
A
A
B
That's
why
they
they
introduced
this
particular
deadline.
So
it
would
be
good
to
get
them
at
least
aware
that
there
is
a
cappier
working
on
by
tomorrow,
so
that
they
can
keep
they
can
plan
ahead
and
have
folks
assigned
to
appropriate
caps.
So
they
will
be
able
to
manage
it
before
the
next
week's
deadline.
A
A
A
A
It
uses
a
an
entirely
different
object.
Called
an
inventory
object
to
keep
track
of
previously
applied
objects,
and
so
so
this
this
was
such
a
major
change
it.
It
didn't
really
make
sense
to
do
it
in
coupe
control
or
to
even
try
to.
To
I
mean
coup
control
is
just
far
too
important
to
and
mature
to
to
be
state
and
to
keep
it
stable,
and
so
in
the
cli
utils.
A
A
D
If
that's
something
we
ever
want
to
do,
because
that
that
is
a
feature
as
much
as
we
might
not
love
it
and
think
that
it
has
a
lot
of
drawbacks
in
the
implementation
as
it
is
today.
It
is
something
that
people
rely
on,
so
I
would
see
that
as
a
barrier.
So
I'm
wondering
if
this
project
can
be
used
to
help
us
move
forward
on
that
angle.
A
So
so
this
project
is
so
different.
You
know,
which
is
why
it
was
it's
in
its
own
repo,
that
it's
not
I,
I
don't
see
it
actually
being
pulled
into
coup
control
anytime
soon.
If
at
all,
I
think
it
was
more
just
to
get
some.
You
know
we
pull
whatever
learnings.
We
have
and
try
to
reimplement
in
coup
control
if
we
decide
to
go
down
that
route.
So
so
let
me
quickly
go
over.
A
C
A
That
and
it
was
in
the
previous
set,
then
we
automatically
clean
it
up.
We
automatically
delete
it,
we
automatically
prune
it.
So
the
big
question,
then,
is:
how
do
we
define
what
that
set
of
previous
previously
applied
objects
is,
and
the
current
implementation
is
with
labels,
which
is
kind
of
a
canonical
way
that
we
do
things
in
kubernetes
with
with
identifying
sets
of
objects.
A
There
are
there
are
such
significant
drawbacks
with
using
labels
to
create
and
identify
a
set
of
objects
that
it
has,
that
pruning
is
in
alpha
state
and
will
probably
never
be
beta
and
and
some
of
those
drawbacks
are
you
have
to
specific
when
you're,
when
you're
identifying
you're
using
labels,
you
have
to
identify
the
specific
gbks
and
actually
in
prune
right
now
we
hard
code
which
gdks
are
available.
It
doesn't
work
with
with
crds,
for
example,
or
custom
resources.
A
It
contains
a
whole
bunch
of
references
to
what's
been
previously
applied,
and
so
so
you
so
you
brought
up
a
bunch
of
really
good
questions,
and-
and
I
guess
my
answer
right
now-
is
that
we
are
so
far
away
from
you
know,
taking
whatever
we've
learned
and
and
built
in
this
cli
utils
and
you
know
be
able
to
pluck
use
it
for
coupe
control.
I
I
honestly
think
it
would
be
you
know,
years
before
we
would
get.
A
We
know
labels
doesn't
work
now
and
we're
experimenting
with
an
inventory
object,
which
is
one
one
of
the
objects
you
apply.
Has
a
special
label
called
with
an
inventory
id,
so
it's
it's
recognized
to
be
the
place
where
we
store
references
to
all
the
other
objects
that
are
being
applied,
but
that's
such
a
major
change
from
coupe
control
now
and
we're
so
conservative
with
what
we
do
with
coop
control.
A
D
Yeah
that
does
give
me
a
better
idea.
I
I
have
some
follow-ups,
though,
for
example
like
the
one
of
the
problems
that
you
mentioned.
That
we
have
is
is
the
situation
where
cube
control
is
actually
operating
on
multiple
namespaces
at
once,
and
the
printing
won't
won't
follow.
How
do
you
solve
that?
If
your
tracking
object
is
a
namespace
object,.
A
They
they
don't
get
cleaned
up,
and
then
this
is
a
function
of
of
how
you
call
you
know
how
you
do
a
call
to
the
the
cluster
using
labels.
You
you
have
to
specify
the
name
space,
and
so
we
we
have
to
try
to
keep
track
of
these
name
spaces
based
on
what's
currently
being
applied,
and
so
there
there's
there's
some
really
sharp
edges
there
that
don't
work,
but
as
far
as
in
namespace
itself,
cluster
scoped
objects.
Don't
I
don't
think
have
that
problem.
D
D
A
A
D
D
A
C
A
A
D
About
ownership,
more
than
necessarily
like
pipeline
strictly.
So
if,
if
I'm,
if
I'm
actor
a
and
I'm
server-side
applying
something
I
in
the
same
way
that
I
might
want
to
own
specific
fields,
I
probably
only
want
to
own
specific
object,
sets
and
say,
like
I'm,
a
controller,
and
I
generate
more
objects.
A
Yeah,
so
this
is,
this
is
actually
one
of
the
areas
that
we
need
to
iron
out
before
we'd
say
that
we
had
anything
that
we
could
show
to
anybody
like
that
works.
Well
and
that's
you
know
how?
How
do
you
write?
How
how
do
you
share
inventory
objects
and
the
way
we
do
that
now
is
if
the
inventory
id
is
the.
C
A
One
of
them
is
the
inventory
object
with
the
special
label
and
if
it
turns
out
that
somebody
else
had
pulled
out
the
code
in
git
and
it
has
that
same
label,
then
it's
going
to
use
that
exact
same
inventory
object
as
the
the
kind
of
this
grouping
object.
You
know
the
object
to
keep
track
of
what
has
been
applied.
A
There's
a
lot
to
dig
into
here:
yeah
yeah,
it's
yeah
this!
This
got
a
little
bit
more
involved
than
than
I
thought
it
would.
I
was.
I
was
just
gonna,
try
to
say:
hey
we're
doing
a
prune
experiment
over
here,
but
these
are
all
great
questions
and
and
and
we
recognize
that
the
documentation
is
not
up
to
speed-
and
you
know
it
should
be
there'd-
be
decent
enough
documentation
that
these
questions
would
be
answered
and
the
fact
that
I
have
to
answer
them.
D
One
more
question:
if
I
can
sure,
of
course,
if
we
think
it's
it's
years
out
to
improving
this,
maybe
maybe
that's
a
good
argument
to
get
started
and
see
if
we
can
get
get
anywhere
at
all.
But
I
I'm
very
interested
in
in
this
topic
myself,
as
you
might
have
claimed,
but
also,
if
it's
years
out
to
having
a
solution,
do
you
think
we
need
to
do
something
on
the
server-side
apply
existing
flag
compatibility
side
in
the
meantime,.
A
That's
a
good
question
that
I
think
I
need
to
think
about
and
I'd
like
to
dig
into
the
code.
Actually
too,
it's
been,
you
know
it's
been
a
little
while,
since
I've
been
into
the
apply
prune
code,
I
do
know
that
we've
done
this
is
tangential,
but
I
knew
that
know
that
we've
done
refactoring
so
that
the
pruning
now
in
the
apply
is
a
hook.
So
you
could
actually
you
could
either
turn
off
pruning
by
I
mean.
A
A
D
A
C
D
D
A
D
Perfect
so
customized
maintainers,
which
is
natasha,
and
I
have
been
working
on,
revamping
the
road
map
together,
and
this
is
our
plan
for
2022,
which
we
wanted
to
share
with
all
of
you
to
get
your
feedback
and
we're
going
to
merge
this
to
the
repo
in
a
markdown
file,
just
like
we
did
last
year.
But
in
the
meantime,
we
have
the
in
this
google
doc
in
an
easy
to
comment
on
format
which
to
get
access.
D
You
just
need
to
be
a
member
of
the
6cli
mailing
list,
which
presumably
we
all
are
already
so
just
to
outline
what
we
have
quickly
here.
We
have
three
objectives
which
you
can
kind
of
see
on
the
sidebar
here
same
kind
of
organization
we
used
last
time,
which
is
tasks
that
improve
the
contributor
experience,
tasks
that
improve
the
end
user
experience
and
then
tasks
that
improve
the
extension
experience,
which
is
kind
of
our
three
buckets
of
customers.
D
If
you
will
as
customized
and
the
way
that
we're
developing
this
roadmap,
we
have
a
really
small
team
right
now
on
the
customized
side.
So
this
is
sort
of
a
mixture
of
ambition
and
realism
as
to
what
we
would
like
to
get
done
this
year
and
we've
organized
it
in
terms
of
our
top
priority,
any
secondary
priorities
that
we
have
and
then
other
things
that
we
would
really
really
like.
But
realistically,
with
the
team
that
we
have
now,
we
don't
expect
to
get
done
ourselves.
D
But
if
we're
able
to
grow
the
team,
if
we
have
other
contributors
showing
up
and
excited
to
help
us,
these
are
things
that
we
would
love
for
them
to
get
involved
in
and
that
we
will
really
support
in
like
providing
training,
providing
code
review
as
a
priority.
If
we
get
if
we
get
prs
for
these
things,
so
that's
sort
of
explaining
the
organizational
principles
that
we're
using
in
developing
this
and
developing
this
roadmap.
D
A
D
Okay,
can
you
scroll
down
then
a
little
bit?
Maybe
I'll
do
contributor
community
here
natasha?
If
you
could
explain
the
end
user
experience
when
I
get
there
and
then
I'll
go
to
extension,
so
I'm
not
talking
continuously
so
for
a
contributor
community,
our
top
priority
is
working
towards.
We
don't
necessarily
expect
to
release
this,
but
working
towards
releasing
a
customization,
v1,
so
customization
being
the
api
type
of
that
central
object.
That
customize
operates
against.
D
It's
been
in
e1
beta
1
for
forever,
and
there
are
some
breaking
changes
that
we
want
to
make
eventually.
So
the
plan
here
would
be.
We
release
the
customized
v1.
We
have
this
migrate
command
that
helps
users
convert
from
one
thing
to
the
other,
wherever
possible,
which
usually
is
and
then
for
a
period.
Their
customized
cli
would
support
both
the
v1
object
and
the
v1
api.
V1
beta1
object
as
part
of
a
long
deprecation.
D
So
there's
a
bunch
of
details
there
that
I
won't
go
into
the
second
priority
that
we
have
is
to
improve
the
contributor
documentation,
notably
in
terms
of
simple
instructions,
to
upgrade
customize
and
keep
control,
because
that
is
now
a
thing
that
is
possible
and
fairly
easy,
so
just
taking
opportunity
to
help
improve
the
documentation,
because
we
know
that
there
are
big
gaps
there
and
we
really
need
more
people
to
join
us
and
we
want
to
make
that
easier.
Basically,
so
if
you
scroll
down
a
little
bit.
D
D
The
api
module
is
a
big
one.
So
that's
something
that
I
think
would
be
a
fairly
approachable
task
for
somebody
to
come
help
us
with
so
that's
kind
of
an
interesting
aspect
there
and
then
we
under
product
project
administration,
if
we
have
a
chance
to
rename
the
master
branch
to
maine,
which
is
something
that
the
community
is
looking
to
do
for
our
repos
overall,
but
involves
a
fair
amount
of
toil
and
careful
sequencing
of
operations,
all
right.
So
natasha
and
user
experience.
C
I'm
sure
so
the
end
user
experience
objective
has
been
informed
by
bugs
that
have
been
filed
by
users
over
the
last
few
months,
so
our
top
priority
is
to
fix
the
most
common
bugs
and
most
notably,
the
basic
anchor
support.
There
are
multiple
issues
regarding
that,
so
we'd
like
to
fix
that,
along
with
the
other
issues
listed
here
and
then
the
next
few
top
priorities
are
highly
requested
features
so
sending
the
customized
cli
version
number
into
coop
cuddle
through
a
cube,
cuddle
command,
improving
customized
performance
and
then
supporting
generic
resource
references.
C
Currently,
the
way
we
track
name
references
is
very
limited
and
it's
causing
a
lot
of
bugs
with
name
references
being
updated
where
they
shouldn't
be
so
we'd
like
to
fix
that
and
then.
Lastly,
we
have
a
kept
out
for
a
debugging
feature
to
allow
an
option
to
add
resource
origin
and
transformer
information
for
each
resource,
so
that
a
user
can
trace
how
their
resource
has
been
transformed
throughout
a
customization
stack
and
then
and
under
our
second
priorities.
C
C
So
in
customized
v5
we
are
going
to
drop
a
bunch
of
flags
in
favor
of
fields
that
were
adding
to
the
customization
as
well
as
drop
support
for
customization
v1
beta,
and
so
we're
not
sure
that
we're
going
to
get
to
this.
But
we
would
like
to
make
as
much
progress
as
possible
and
then
the
other
secondary
priority
is
a
very
popular
issue,
a
confusion
around
namespace
replacement,
we'd
like
to
add
some
options
to
the
namespace
transformer,
rather
than
adding
the
namespace
to
every
single
resource,
because
users
are
confused
about.
C
How
do
I
skip
a
certain
resource
or
why
is
it
being
set
when
there's
already
a
namespace
we'd
like
to
make
that
more
clear
and
then
other
things
that
are
very
valuable
to
the
project?
Generally
we'd
like
to
improve
error
messages,
our
errors
are
very
verbose
and
confusing,
and
then
there
are
a
few
other
features
here
that
we've
listed
yeah
back
to
you.
Katrina.
D
Yeah,
so
our
last
section
is
improving
the
extension
experience
we
sort
of
talked
about
this
at
jeff
jeff,
and
I
talked
about
this
a
bit
at
kubecon.
The
plan
that
we've
developed
to
promote
use
of
care
and
functions
as
extensions
and
deprecate
older
versions
of
extension
mechanisms
improve
the
way
that
care
and
functions
work
today
and
ultimately
make
extensions
work.
The
same
way
in
customizing
cube
control
as
in
customized
standalone.
So
we
have
a
whole
cap
outlining.
D
Basically
what
this
objective
is
all
about,
if
you're
interested
in
the
details-
and
we
really
just
want
to
make
sure
that
we
are
making
some
big
progress
towards
the
the
ambitious
goals
that
we
have
there
over
the
course
of
the
year-
and
the
first
step
is
that
that
we
want
to
promote
care
and
function
extensions
as
the
way
to
build
things.
But
there
are
some
significant
usability
issues
with
them.
So
the
first
thing
to
do
is
to
fix
those
in
my
opinion.
D
The
better
the
secondary
priorities
are
a
composition
cap
which
is
implementation
complete,
but
has
it's
sort
of
a
an
alternative,
orchestration
model
that
puts
third-party
transformers
so
like
the
operations
that
you
can
do,
the
puts
the
third-party
ones
on
the
same
footing
as
the
first
party
ones
that
are
compiled
into
customize,
which
has
make
opens
up
a
bunch
of
really
neat
use
cases.
But
since
that's
completely
novel,
that's
why
it's
a
secondary
priority.
D
The
implementation
is
actually
complete,
but
there's
some
significant,
some
significant
surgery
that
needs
to
be
done
to
customize
itself
in
order
to
make
it
useful,
which
I
won't
go
into
the
details,
but
they're
outlined
there
and
finally,
we
need
some
better
docs
for
the
extension
libraries,
so
any
contributions.
There
are
going
to
be
super
valuable
to
us
and
we
have
a
couple
other
priorities
there.
So
the
reserve
field
for
plug
and
run
time
information.
D
We
don't
know
for
sure,
if
we're
going
to
need
that
until
we
finish
the
catalog
cap
and
the
standard
process
for
implementing
built-in
transformers
has
to
do
with
the
deprecation
of
the
go
plug-in
style
because
we're
actually
using
that
internally.
So
we
want
to
start
setting
the
example
of
what
what
this
should
look
like
ourselves
as
well,
so
that
that
will
be
a
once.
We
set
the
standard,
also
a
set
of
good,
well-defined
tasks
for
folks
to
help
any
questions.
D
E
D
Assuming
the
contributors
touch
base
with
us
about
what
is
valuable
to
the
project,
for
instance
the
stuff
on
the
roadmap,
we're
hoping
that
will
help
by
having
these
priorities
explicitly
outlined.
We
will
prioritize
training
folks,
because
we
really
need
to
have
more
folks
on
the
team
with
us
helping
maintain
customize
for
the
long
term.
B
E
D
D
A
A
D
E
E
This
is
really
hard
to
glance
at
it's
really
hard
to
make
sense
of,
and
I
think
users
that
miss
a
lot
of
flags
I'm.
I
think
this
contributes
to
that
right.
So
lao
took
it
on
himself
to
go
out
and
open
a
pr
that
improves
to
help
flags
and
we're
we're
pretty
much
at
a
bike
shedding
moment
now.
So
we
have
a
few
different
options
to
talk
through
they're,
all
good.
E
E
So
he
took
this
as
like
a
two
column
approach,
so
we
have
the
flag
name
on
the
left
and
then
the
description
on
the
right.
So
this
definitely
looks
a
lot
better.
Some
issues
with
this
are
kind
of
how
the
calculation
is
done
in
terms
of
how
big
these
columns
are.
So
if
we
get
a
really
long
flag,
things
might
start
to
look
a
little
wonky.
E
E
E
B
I
think
that
I
commend
it
in
a
similar
vein
on
that,
pr
that
it
would
be
pretty
cool
to
do
it
this
way,
rather
than
oh
yeah.
Well,
mine
was
close,
but
I
like
the
the
proposal
from
ryan
much
more.
It
is
first
of
all
it's
something
that
people
are
already
familiar
with
going
through
man
pages
and
secondly,
you
can
quickly
you
you
are
maintaining
all
of
the
readability
that
is
lacking
from
the
first
approach.
E
E
E
B
E
A
C
D
All
right,
so
this
is
a
topic
that
we
discussed
last
week.
If,
if
you
were
there
or
if
you
watched
the
recording,
we
promised
that
we
would
circle
back
to
the
conversation.
So
that's
what
we're
doing
now
this
issue,
if
you
could
click
on
it,
sean
just
so
we
have
the
topic
visible,
is
a
bug
report
from
from
users
about
keep
control
rollout
undo,
not
doing
what
they
expect
it's.
D
What
what
they
expect
is
that
it's
going
to
take
the
target
object
and
it's
going
to
roll
back
to
the
previous
revision,
and
then
you
know
from
there
on
out
they're
fine,
but
what
actually
happens
is
an
imperative
replacement
of
the
spec
under
the
hood,
which
is
is
not
actually
rolling.
So
it's
only
rolling
back
part
of
it
essentially
running
back
spec
to
the
previous
replica
set.
It's
not
rolling
back
all
the
annotations,
and
notably
that
includes
it's
not
rolling
back.
D
My
empathy
for
the
user
in
this
case,
though,
is
like
really
talking
about
my
heart
strings
here,
like
I
really
understand
why
they
don't
think
this
sounds
unsafe.
It
sounds
like
an
emergency,
an
emergency
tool
really
and
it
like
on
the
face
of
it,
it's
promising
to
roll
back
an
object
and
like
we
totally
could
like
it's
totally
possible
to
actually
track
the
history
and
actually
do
that
roll
back.
It's
not
impossible.
D
You're
not
like
thinking
that
that
that
we're
like
promising
a
miracle
here
like
it's
doable,
so
that
makes
me
a
little
uncomfortable
with
like
refusing
to
make
it
work,
something
that
sounds
like
an
emergency
tool
refusing
to
make
it
work
on
principle,
and
so
I
like,
I
really
want
to
understand
the
risks
that
we
think
would
accompany
fixing
this.
If
and
if
we
decide
to
take
a
hard-line
stance
on
it
on
not
fixing
it
like
maybe
discuss
alternatives
as
to
how
we
can
make
folks
not
trip
over
it.
D
A
A
B
And
then
you
have
a
ci
cd
pipeline
which
manages
everything
which
is
good
for
for
auditing
purposes,
because
you
have
a
clear
history
of
what
has
changed.
Who
has
changed
and
you
can
quickly
manage
the
user
permissions
and-
and
I
was
discussing
this
with
katrina-
I
think
last
time,
last
or
two
weeks
ago,
and
we
had
a
rather
lively
discussion
on
the
topic.
B
You
should
be
good,
but
in,
if
generally
you're,
in
a
declarative
approach,
any
single
usage
of
imperative
command,
because
that
is
only
probably
one
command
and
if
you
use,
I
don't
know,
set
image
or
set
set
volumes.
I
think
we
have
also
a
couple
of
sets
and
if
you
use
one
of
those
it's
better,
you
have
auditing
on
the
api
server
enabled.
B
B
D
I
I
tried
to
look
that
up
in
the
history
and
the
the
answer
seemed
to
be
that
if
you
just
the
implementation,
is
copying
stuff
from
replica
to
deployment
right.
So
if
you
just
copy
this
over,
that
would
make
apply,
think
it
owned
replica
set
so
for
pruning.
For
example,
that
would
be
a
disaster,
not
a
good
idea.
So
when
they're
implementing
this
they're
just
like
oh
well,
we
should
exclude
that
annotation
so
that
that's
how
it
happened.
D
D
D
D
No,
not
on
the
rollout
like
once
we're
doing
the
rollout.
Sorry,
the
rollout
sorry
maybe
start
for
interrupting
it's
on
the
roll.
It's
on
the
roll
forward
to
the
to
the
next
version
that,
like
the
next
time,
they
apply
sorry
trying
to
phrase
this
in
a
way
that
will
make
sense.
When
you
do
an
apply
you
you
have.
The
last
slide
configuration
there
right.
You
do!
Your
next
apply!
You
get
the
next
last
supplied
configuration,
that's
never
propagated
anywhere
else.
D
So
once
you
are
trying
to
do
the
undo
what's
going
to
happen,
is
it's
going
to
go?
Look
at
the
old
replica
set
and
grab
its
spec
and
put
it
back
into
the
deployment,
but
the
old
last
applied.
Isn't
there
like
there's
nowhere
to
grab
it
from
because
when
that
replica
site
was
created
in
the
first
place,
it
didn't
get
the
annotation
synced
down.
D
Yeah,
that's
the
idea,
that's
what
the
situation
is
describing,
which
is
like.
So
to
your
point
about
documentation.
I
think
that's
a
great
idea
and
giving
a
talk,
and
we
do
have
a
page
on
declarative
versus
imperative,
but
I
was
actually
digging
around
here
to
try
and
see
like
what
we're
presenting
to
users
as
it
is,
and
most
of
the
tutorials
about
how
to
do
stuff.
D
They
mix,
declarative
and
imperative
commands
and
just
like
how
they're,
showing
you
do
things
if
you
look
up
how
to
roll
back
kubernetes
deployment,
how
to
roll
back
a
kubernetes,
whatever
object,
you'll
find
not
only
our
own
docs
but
other
people's
blog
posts
saying
to
use
rollout
undo,
which
is
totally
understandable.
I
think,
under
the
circumstances
that
we
have
right
now,
so
I'm
not
sure
that
that
would
be
sufficient
communication
to
prevent
people
from
running
into
a
situation
like
this.
B
So
maybe
it
would
be
better
to
help
people
differentiate
between
these
two
commands,
because
I'm
I'm
feeling
that
we're
trying
to
to
fix
a
problem.
That
is
not
there
if
you,
as
long
as
you
use
rollout
to
roll
the
app
and
then
roll
out
and
do
fine,
but
you
roll
out
through
apply
and
then
you're,
trying
to
different
to
entirely
break
the
flow
and
do
something
that
it
was
not
meant
to
do.
I
know
that
the
docs
are
not
accurate
and
we
should
probably
just
work
on
on
docks
and
improving
that.
D
I
think
that
there
are
almost
two
issues
here
like
we
absolutely
should
improve
the
docs
and
the
declarative
versus
imperative
in
general,
like
for
sure
helping
people
understand
that
and
like
the
consequences
of
trying
to
mix
them,
etc
absolutely
worthwhile,
but
this
specific
command.
I
think
it's
not
clear
to
the
end
user
coming
from
either
of
those
flows
that
it
will
or
won't
work
with
either
because
it
totally
could
and.
D
B
B
D
Just
to
play
devil's
advocate
on
that
argument,
though,
if
people
are
already
using
it
successfully,
this
way
with
apply,
which
is
a
specific
situation
that
I'm
talking
about
warning
on
then
shouldn't
we
fix
it
for
them
to
not
be
dangerous.
If
we
want
to
support
that
and
are
not
willing
to
break
it,.
B
E
D
I'm
happy
with
the
warning,
though,
at
least
as
as
something
to
help
people
realize,
and
maybe
if
we
had
that
blog
post,
we
could
address
this
case
specifically
like
here's.
What
happened
and
like
the
warning
had
even
linked
to
it,
saying
like
here's,
how
to
investigate?
What's
going
to
go
wrong
on
your
next
deploy.