►
From YouTube: Kubernetes SIG Apps 20190923
Description
Led by: Janet Kuo
Co-hosts(s): Kenneth Owens
Announcements:
- Steering committee elections are happening now. See your email for a ballot. If you didn’t get one but should have see the announcement at https://groups.google.com/forum/#!topic/kubernetes-dev/kHt8BbN6MQA
- App CRD released https://github.com/kubernetes-sigs/application/releases
Discussion:
- Status Standardization KEP - https://github.com/kubernetes/enhancements/pull/1246 [@barney-s]
- Replicat Set replacement - https://github.com/kubernetes/kubernetes/pull/80004
- Stateful Set Volume Resizing https://github.com/kubernetes/enhancements/issues/661
- ReplicaSet expectations https://github.com/kubernetes/kubernetes/pull/82572 , state of expectations in general, status updating
- CronJob GA - https://github.com/kubernetes/enhancements/pull/978
A
A
A
C
Well,
we've
been
trying
to
get
the
release
together
for
a
while
we
merged
two
last
PRS,
and
we
released
this
at
Oh
8
Oh,
basically
because
we
had
made
several
major
kind
of
iterations
on
already,
but
it's
not
quite
1.0
1.0
we'd
like
to
be
the
GA
the
v1
release
and
that's
probably,
what
we'll
work
toward
next
on
the
project.
I
think
there
is
more
relevant
work
that
Barney
we'll
talk
about
later
with
respect
to
generic
status
and
supporting
that.
A
C
C
So
this
is
somewhat
of
a
major
change,
but
in
other
ways
it's
actually
not
that
huge
rate
so
like
the
one
of
the
issues
that
we
have,
particularly
with
network
load
balancers
in
kubernetes,
is
that
when
you
set
up
an
NLB
and
a
network
would
balance
or
as
far
as
I
know,
is
primarily
an
AWS
construct,
but
but
it's
applicable
pretty
much
to
any
layer
for
load
balancing.
So
when
you
set
the
NLB
up,
it's
going
to
add
a
health
check
to
the
individual
node.
C
If
you
use
a
deployment
and
all
of
the
pods
in
that
deployment
are
removed
from
the
node
eventually
that
net
health
check
is
gonna,
start
failing
and
the
nodes
going
to
get
removed
in
the
interim
between
when
the
health
check
fails,
and
there
are
no
pods,
traffic
actually
gets
dropped,
which
isn't
the
best
thing.
I
think
when
we
thought
about
how
local
services
work
and
how
this
would
kind
of
be
done.
Well,
I
can
speak
to
the
way.
I
generally
always
do.
C
This
is
by
using
the
daemon
set
on
a
specific
nude
pool
of
capacity
that
has
an
ingress
set
up
that
forwards.
Traffic
into
the
cluster
from
there
so
from
I,
don't
personally
generally
encounter
this
issue
because
for
the
network
load,
balancers
they're
pretty
much
always
terminated
and
the
pod
doesn't
ever
go
away
and
if
you
were
to
drop
the
pod,
you
would
just
get
another
set
in
that
capacity.
However,
people
are
using
NL
B's
to
expose
deployments
and
it
seems
to
be
actually
a
very
common
use
case.
C
What
this
does
is
when
a
deployment
scales
down
a
replica
set
and
scales
up
another
replica
set
in
order
to
like
do
a
rolling
update
it
first
is
gonna,
try
to
consider
scaling
down
and
deleting
the
pod
on
the
same
node
as
another
pod.
So
you
could
imagine
if
you're
surging
and
you
create
two
pods
in
the
same
node
one
pod
at
v1,
one
pot
at
v2
before
it
kills
a
pot
on
any
other
node.
It's
gonna
attempt
to
kill
the
pot
on
the
B
one
node.
C
Now,
that's
not
going
to
stop
it
from
considering
another
pod,
if
basically
30.
If
that
condition
isn't
met,
if
there
aren't
two
pods
in
the
same
node,
so
the
reason
I'm
kind
of
in
favor
of
it
is
one
it
does
it's.
If
you
look
at
the
PR,
it's
not
a
huge
modification
and
it
does
actually
solve
a
problem
that
real
users
have
today
and
on
the
other
side,
it
has
a
nice
property
of
kind
of
making
rolling
updates
a
slightly
a
little
bit
more
resilient
individual
node
failures
during
the
rolling
update.
C
So
you
could
imagine
the
property
that
I'm
going
to
take
down
one
pod
on
a
node.
That
already
has
one
means
that
I'm
the
likelihood
that
another
node
failure
coming
along
and
reducing
my
capacity
further
is
slightly
lower.
I,
don't
think,
that's
too
much
of
a
real
problem
most
of
the
time,
but
it
is
kind
of
a
nice
property
and
a
half
but
I
wanted
to
get
feedback
from
sig
apps
at
large.
Before
we
do
this,
because
it
is
kind
of
changing
the
semantics
slightly
of
a
v1
object.
A
C
C
Right
this
is
adding
some
modification
to
the
semantics,
like
replica
set,
will
basically
try
to
destroy
a
pod,
that's
co-located
with
another
pod.
If
that
is
possible
to
do
so
like
for
anything
existing
that
isn't
expecting
the
behavior,
it
doesn't
actually
change
it,
which
is
why
I'm
pretty
okay
with
it.
D
Yeah
like
technically
right
now
we
are
rounding,
so
if
we
make
some
order
and
don't
think
any
guarantees
around
it,
we
don't
break
in
expectations
there.
So
I
think
this
is
okay.
I
feel,
like
denote,
failover,
think
if
you
have
20
pots
on
one
note
and
the
rest
is
plate,
and
you
start
deleting
the
five
that
are
on
the
other
nodes
and
the
one
big
comes
down.
C
D
A
C
C
So
I
mean
if
I'm
looking
at
it.
It's
basically
first
kills
something
that's
unassigned,
then
the
order
is
like
basically
kill
a
pending
unknown
before
running,
kill,
not
ready
if
it's
before
ready
and
then
just
after
that,
they're
gonna
do
doubled
up
after
not
doubled
us
that
it
is
before,
like
the
the
notion
of
doubled
up
and
not
doubled
up
is
introduced
before
doing
the
one
where
you're
looking
for
which
one
has
been
ready.
The
longest.
C
It's
it
looks,
correct
I
would
like
some
other
people
to
the
Clayton,
took
a
look
at
the
PR
and
left
some
comments,
but
primarily
all
around
code
structure
and
testing.
I
didn't
see
anything
major
in
terms
of
like
in
correctness,
and
there
were
unit
tests.
Put
it
put
in
I.
Think
one
of
the
challenges
with
this
PR
is
the
end
to
end
testing
would
be
difficult.
I,
don't
actually
think
we
we
do
e
two
E's
on
on
any
of
this,
and
because
we're
not
specifying
any
real
guarantee
for
the
ordering
I.
C
Don't
know
if
we're
required
to
do
e
two
E's
like
if
we
did
eby's
that
would
probably
lock
the
behavior
and
and
formalize
it
from
a
comportment
standpoint,
which
I'm
not
sure
we
want
to
do
so.
It
would
be
good
if
people
could
take
a
look
at
the
PR
and
leave
thoughts
and
we
need
another
reviewer
yeah.
D
C
E
E
D
A
A
A
F
F
So
the
crux
of
the
problem
is:
we
have
standardized
metadata
across
all
kubernetes
objects
which
help
the
tooling
to
deal
with
theorem
any
care,
untied
caramels
cumulative
results,
whereas
we
don't
have
any
standardized
status
that
allows
the
tooling
to
deal
with
any
care
untyped.
The
result
most
of
the
tooling,
especially
automation,
that's
built
around
kubernetes
need.
E
F
Be
type
aware
and
they
need
to
have
logic
per
type,
to
deal
with
readiness
of
kubernetes
objects.
So
today
you
you
can
use,
apply
or
a
controller
to
throw
a
bunch
of
objects
over
the
wall
to
the
API
server,
and
we
don't
know
when
it
is
ready
when
whatever
we
last
applied,
is
completed
and
available
for
the
user
to
improve.
On
that
situation,
we
are
proposed
to
standardize
status
for
all
the
coal
resources
and,
by
extension,
for
CR
DS
as
well.
F
So
the
goal
of
this
cap
is
to
understand
the
state
of
things
with
the
respective
status,
which
we
already
know.
It's
just
to
summarize
it
here
and
propose
a
standardized
set
of
conditions
versus
fields.
We
are
leaning
towards
conditions
and
discuss
out
all
the
tooling
can
make
use
of
it
by
tooling
I
mean
it
could
be
cube
CTL,
it
could
be
a
controller,
it
could
be
virtual
systems,
it
could
be
CI
CD
systems
any
of
the
clients
that
given
a
task.
F
So,
overall,
we
looked
at
holistically
what
status
conveys
for
kubernetes.
So
today,
a
survey
of
the
status
fields
there
are,
they
are
either
informational
like
IP
lists
in
surveys,
or
they
reflect
the
actual
current
state
like
ready,
replicas
on,
and
there
is
a
set
of
conditions
that
that
a
few
resources
support
the
status
section
has
no
conventions
today,
there
are
no
standardized
recommendations
and
everybody
implements
it
in
a
different
way,
but
how
status
is
being
used
is
kind
of?
There
is
a
convention
on
how
status
is
being
used.
F
It
is
used
as
a
kind
of
guarantee
like,
depending
on
what
controller
provides
the
status
of
an
object,
provides
certain
guarantees.
It
could
be
behavioral
guarantees
and
things
that
can
be
improved
over
time
and
status
is
a
point
in
time,
snapshot
which
is
expected
in
a
system
that
has
a
reconciliation
loop
where
the
status
may
change
every
time
you
reconcile.
So
that
is
given
just
wanted
to
call
it
out
and
this
and
what
the
status
conveys
depends
on
the
resource.
Today,
a
for
a
pod
ready
is
different
from
a
stateful
set.
F
It's
different
from
a
CRD
and
the
status
also
depends
on
the
source
that
is
providing
the
guaranty.
So,
for
example,
we
have
cubelet
which
provides
the
status
for
pod
conditions
and
we
have
code
controllers
which
provide
status
for
the
core
resources
and
we
have
custom
controllers
which
provide
status
for
CR,
DS
and.
F
One
of
the
decisions
could
be
for
a
virtual
system
to
go
to
the
next
step
after
deployment
is
tough,
so
the
proposals
we
have
is
discussing
conditions
versus
fields.
It's
a
brief
discussion
which
is
better,
which
is
extensible,
and
we
are
leaning
towards
conditions,
because
it's
extensible
and
you
can,
it
doesn't
have
effect.
The
API
server
fails
once
conditions
are
supported
on
all
the
core
resources.
F
F
F
All
right
so
ready
qualifies
the
readiness
after
results,
as
defined
by
the
controller,
and
it
can
be
used
for
aggregation.
For
example,
a
pod
can
be
ready.
A
stateful
set
can
be
ready.
A
custom
CRD
that
deploys
a
database,
for
example,
can
be
ready
it.
It
means
it
did
whatever
the
controller
needs
to
done
and
needs
to
do
has
been
done.
Isn't
that
settled
by.
F
F
It's
a
readiness
is
a
more
stronger
guarantee
than
settle.
That's
correct.
A
help,
meanwhile,
is
something
that
tells,
for
example,
if
you
are
deploying
a
C
or
D
that
has
elasticsearch
the
pods
could
be
ready.
The
state
food
set
could
be
ready.
Quite
overall,
the
application
may
not
be
healthy
because
it's,
it
is
still
replicating
some
shards
or
for
example,
or
it
it
may
enter
a
condition
where
it
is
under
replicated.
So
these
are
the
this.
F
F
Yes,
you
could
use
ready
for
a
custom
CR
to
reflect
health,
but
I
just
wanted
to
call
it
out
separately
and
then
have
a
discussion
around
it,
and
progress
is
something
that
is
useful
for
those
objects
which
have
a
notion
of
completeness
like,
for
example,
a
job
can
be
in
progress
and
then
when,
when
it
is
done,
the
progress
condition
can
be
false.
So.
F
C
F
It
for
the
core
controllers
and
then
get
a
broader
discussion
in
the
community,
so
that
is
people
I
thought
this
was
the
right
forum
to
do
it.
So
application
theory
talks
about
only
application
C
implementing
in
the
application
theory
right
so,
but
this
is,
the
goal
of
this
gap-
is
to
eventually
start
opening
up
peers
against
individual
core
objects
to
implement
these
conditions
were.
F
C
F
C
G
C
Really
works
so
well
for
node
right,
okay,
like
we
don't
want
to
start
down
the
path,
that's
irrevocable
and
it
like
you,
use
conditions.
It
probably
isn't
right,
because
you
can
pretty
much
change
them
without
breaking
people.
The
problem
with
that
will,
according
to
our
definitions
of
backward
compatibility,
they're
allowed
to
be
changed.
Yeah.
G
C
Architecture,
okay,
bring
it
up
there
and
then,
like
I,
would
think
figuring
out
which
resources
actually
convey
status.
That
you'd
want
to
add
really
cuz
like,
and
you
mentioned
service
in
the
document,
but
service,
particularly
for
settled.
It
gets
really
tricky
because
anything
with
the
network
programming
in
most
clouds
is
completely
asynchronous
right.
Yeah.
C
Really
doesn't
know
whenever
it's
done
all
I
do
is
like
yeah
I
programmed
whatever
cloud
networking
functionality,
whether
it's
like
be
sphere
or
whether
it's
Google
firewalls
or
whether
it's
AWS,
networking
and
I.
Think
it's
good.
But
in
terms
of
like
actually
knowing
that,
for
instance,
if
you've
added
a
new,
a
record
that
a
record
is
propagated
through
our
DNS
and
is
reachable
at
the
service
controllers.
Don't
know.
F
Yeah
I
agree,
so
there
is
a
section,
a
call
out
below
which
may
be
useful
for
those
scenarios,
I'll
just
scrub
through
the
document
quickly
to
give
an
idea
of
what
else
is
there?
So
we
are
calling
out
the
standardized
conditions
here
and
then
we're
also
proposing.
If
you
need
fields,
they
could
be
these
fields
that
can
be
used.
F
F
Alright,
so
there
was
so
the
the
intent
right,
so
there
is
a
consistency
that
we
need
to
maintain
between
the
status
on
the
spec
that
can
be
achieved
by
having
the
observed
generation,
but
there
were
some
open
peers
that
that
said
that,
though
the
observed
generation
has
said,
the
status
does
not
reflect
that
observed
generation.
Apparently
they
are
setting
the
observed
generation
at
the
beginning
of
the
reconcile
look
or
not
at
the
end,
I'm,
not
sure
if
that
is
what
of
the
generation
is
supposed
to
do
so.
D
Yeah
observed
generation
is
a
bit
ambiguous
at
the
time
and
every
controller
probably
claims
different
guarantees
about
it.
Okay,
we
have
the
same
in
openshift
as
well,
and
what
I
think
the
most
common
denominator
is
the
lowest
one.
So
observed
generation
means
that
the
controller
has
seen
the
generation
may
not
have
acted
upon
it.
It
will
update
status
like
say
for
application
control.
It's
easier
than
example:
okay,.
D
Replication
control-
and
you
see
hey
those
many
replicas
already.
Those
many
are
unhealthy
and
you
just
sync
the
status:
that's
the
lowest
lowest
conformance
for,
observe
generation.
You
don't
like
say
you
would
have
to
create
a
new
controller
Asian
or
something
you
may
have
failed
them,
but
you
have
already
observed
how
many
votes
are
there?
How
many
are
available
and
you
can
update
status
with
it?
You
don't
have
to
complete
the
loop
that
some
controllers
actually
do.
Yeah.
F
Either
we
call
it
out
strongly
in
the
API
documents
to
implement
absurd
or
just
have
some
conventions
around
it,
and
it
can
be
a
bug
on
the
controller.
But
if
that
is
something
that
cannot
be
called
out,
then
we
need
to
propose
reconcile
generation
which
explicitly
captures
the
natural
notion
that
this
generation
has
been
reconciled
and
that
can
be
used
as
an
indicator
for
status
and.
D
F
D
A
deployment,
okay,
it
is
considered
to
be
consult
if
it
creates
a
new
replica
set
for
debtor
world.
It
doesn't
mean
the
road
has
finished,
so
we
are
like
two
states
of
reconcile.
What
one
is
eight
I
have
created
the
objects
for
debtor
world
and
the
other
one
is
hey.
All
the
replicas
went
through
yeah.
That
is
true.
So
more
specific.
F
About
that
yes,
so
it
is
only
the
deployment
controllers
loop,
so
it
doesn't.
If
the
underlying
replica
sets
are
not
ready,
it
would
be
reflected
in
the
readiness
of
deployment
right.
We
are
okay,
so
there
is
an
example
here,
I
called
out
how
the
deployment
does
it.
So
it
looks
at
the
current
of
that
generation.
It
looks
at
the
replicas
are
equal
it.
It
looks
at
all
the
conditions
that
are
that
are
available
in
a
deployment
today.
I
do
hear
what
you're
telling
maybe
we
need
to
record
like
I,
updated.
C
C
Loop
is
saying
as
far
as
this
controller
is
concerned,
the
users
decorative
intent
is
reconciled
so
like,
if
you
added
this
field
to
the
status
of
replica
set
and
deployment,
it
might
mean
slightly
different
things
like
I
would
I
would
assume
that
deployment
couldn't
be
fully
reconciled
until
all
the
replica
sets
that
are
supposed
to
be
at
a
specific
scale
are
fully
reconciled.
Okay,
I
would.
F
D
F
Okay,
so
where
do
we
propose
that
these
standard
standardized
conditions
of
our
fields
recite?
We
have
three
locations,
it
can
be
bought
a
metadata,
skated
I'm,
just
calling
it
out,
but
I
don't
think
that'll
go
to.
It
can
be
a
separate
namespace
field
under
status.
It
can
be
state
of
stock
matter
or
it
can
directly
reside
under
status,
which
is
the
preferred
way
I'm
just
calling
what
the
pros
and
cons
that.
C
Thing
is
I
mean
from
from
a
processing
perspective
because,
like
you
could
just
look
so
you
could
look
for
a
list
of
conditions
and
if
the
conditions
aren't
there,
it's
not
breaking
right
and
then
membership
of
a
particular
condition
inside
of
conditions
is
very
generic.
When
you
don't
you
with
that
is,
you
could
never
have
like,
like
if
you're
looking
to
do
this
as
a
like
a
sub
resource
of
status
in
the
same
way
scale
does
that
might
be
problematic.
Okay,.
F
C
Don't
know
what
that
looks
like,
but
I
mean
it's
not
to
say
that
couldn't
be
done,
I'm
just
a
short
time,
I'm
having
trouble
wrapping
my
head
around
like
how
we
could
do
a
common
sub
resource
that
reflected
this
information
globally,
and
that
was
usable
in
the
same
way.
That
scale
is
okay
and
I.
Don't
know
if
it's
as
valuable
as
like,
because,
like
scale
is
used
by
a
horizontal,
otters,
can't
wolf,
any
type
of
auto
scaling
to
try
to
like
say:
okay
I
want
to
scale
this
up
or
scale
this
down
like.
F
Think
the
yeah
I
think
it's
mostly
going
to
be
read-only
and
we
have
a
status
of
resource
already.
Yeah
yeah,
it's
just
having
the
standardized
ones
under
a
field
under
status,
or
it
can
be
directly
under
status
like
that
status
conditions
can
be
used,
and
then
we
just
standardized
the
condition
types
and
what
they
mean.
F
So
so
far
we
looked
at
what
condition
types
can
be
standardized,
and
then
it
is
just
proposal
to
improve
the
source
part
of
it
we
could
use.
We
could
use
external
controllers
approach
to
argument
top
status,
then
this
could
be
useful
in
the
case
where
network
programming
is
asynchronous,
but
we
have
an
external
probe
that
checks
that
it's
all
programmed
correctly
and
all
the
ports
are
reachable
and
then
slips
the
bit.
F
F
F
Once
we
agree
on
standardized
conditions
for
cortex,
we
can
propose
the
same
for
CR
DS,
so
that
the
client
tooling
will
continue
to
work
with
CR
DS
as
well,
and
it's
just
a
list
of
tools
that
we
looked
at
and
how
they
are
implementing
state
s,
checks
on
the
client
side
and
yeah.
That's
pretty
much.
It.
D
Ok,
so
thinking
about
this
can
maybe
you
know
better,
but
if
I
recall
reading
like
the
API
conventions
and
all
of
those
proposals
that
are
in
SiC
architecture
and
we
standardized
the
conditions,
maybe
the
change
should
be
sent
there
as
well
like,
instead
of
our
see
gaps,
it
should
go
to
sick
architecture
and
the
API
conventions
somewhere
around.
It
sounds
like
where
all
the
rest
of
standardizing
status
observed,
generation
and
other
stuff
is
explained.
C
C
C
That
sounds
reasonable,
I
mean
I,
think
we
should
take
it
up
there
and
get
feedback
more
than
anything
else
and
see
what
the
thought
is,
but
my
only
concern
about
letting
architecture
ona
is
that
they're
really
trying
to
push
this
thing
decision-making
down
to
the
SIG's
as
opposed
to
owning
everything
at
a
high
level?
They
don't
want
to
be
a
blocker.
C
Maybe
they
do
so
I
mean
I
would
say
like
bringing
it
up
to
cig
architecture
and
then
getting
getting
feedback
there
to
see.
If
this
is
something
that
needs
to
be
owned
at
that
level
or
if
it's
something
that
can
be
collaborated
on
independently
by
SIG's.
If
we
all
agreed
in
the
direction
is
generally
correct,
I
don't
mean
like
if
80%
of
the
work
is
really
gonna,
be
on
the
workloads.
C
D
D
C
D
Wonderful
comment:
I
had
use.
You
said
you
would
update
it
from
multiple
controllers.
Just
a
note
that
would
be
kind
of
problematic
because
observe
generation
stop
have
its
meaning.
So
you
don't
have
to
have
observed
generation
or
a
controller
that
is
writing
into
the
status
that
gets
complicated
at
least
okay,
but
in
general
I
think
we
should
flush
out
the
difference
between
the
readiness
for
the
deployment
or
the
reconciliation
and
like
royalty
is
done
versus
I
real-world
has
been
started
and
the
controller
has
seen
it
so
right.
C
H
C
F
C
C
C
Does
anybody
know
okay,
I
mean
I,
guess
like
either
via
mailing
list,
which
we
can
watch
or
via
just
generous
like
adding
yourself
on
the
cap,
saying
I'm
interested
in
working
on
this
we'd
like
to
find
people
who
are
interested
in
collaborating
on
moving
this
forward?
We
think
that
it's
going
to
be
non-trivial
basically
because,
like
adding
shared
informers,
the
cron
job
is
pretty
much.
D
D
There
is
an
issue
with
expectations
that
probably
someone
just
needs
to
review
that
PR,
but
if
I
replicas
are
disarray
created
or
replication
controller
because
they
are
the
same
now
if
they
are
recreated
I,
so
did
I
say
it
on
my
own
as
well,
and
this
was
reported.
There
is
some
issue
linked
there.
It
gets
stuck
like
at
least
for
30
seconds
to
five
minutes.
Ivan
recalled
the
exact
day,
but
the
replication
controller
doesn't
act
on
the
replica
set
at
all.
D
C
D
D
I
D
D
Well,
so
we
are
totally
sure
that
our
infirmary
will
see
it,
and
there
is
some
UID
tracking
stuff
in
to
expectations
in
replica
set
I
looked
into
it
like
a
week
ago,
so
I
figure
half
of
it
look
like
it
pretends
to
track
you
IDs,
but
it's
actually
just
tracking
keys.
It
doesn't
make
you
IDs.
The
created
puts
four
creates
yeah,
and
we
also
wait
for
all
the
expectations
to
be
satisfied
before
we
have
a
status
like
the
replica
said,
could
be
more
proactive
in
reporting
its
status
like.
D
D
Yeah
and
they
described
it
in
detail,
I
won't
go
into
it
there,
but
if
you
see
the
linked
issue,
like
the
order
of
events,
sorry
you
have
never
of
events
is
described
there.
I
think
I'll
link
it
here.
There
is
fixes.
There
is
no
comment
for
NCDC
and
you
will
see
the
full
description
there
and
we
probably
want
to
fix
the
expectations
in
general.
I
hope
to
get
some
time
to
send
a
PR
for
it.
If
you
agree,
that's
it's
broken.
C
No
I
get
the
problem
that
it
solves
like.
Basically,
you
can
overwhelm
the
control
plane,
you
can,
you
can
surge
capacity
and
basically
eat
up
way
more
capacity
than
you
intend
to
the
I
feel
like
the
way.
The
way
it
solved
makes
like
what's
actually
happening
under
the
hood,
really
opaque
from
a
rehabilitation
point.
Yeah.
D
D
A
I
Hi,
my
name
is
Simba
I,
something
back
I
created
a
PR
and
I'm
facing
an
issue
with
respect
to
some
of
the
tests
are
failing
and
fortunately,
I
haven't
been
able
to
understand
or
make
a
headway
into
those
tests.
If
you
could,
please
help
me
out
understanding
why
the
tests
have
failed,
how
to
get
them
to
green
status,
that
that
would
help
me.
You
know
not
only
this,
but
also.