►
From YouTube: 20200702 SIG Arch Community Meeting
Description
GMT20200702 181037 SIG Archit 1920x1080
A
Or
it's
some
other
defined
condition.
It
takes
automated
action
to
remove
that
instance
from
the
cloud
and
have
another
controller
machine
set
controller
that
will
give
us
another
instance
from
time
to
time.
An
administrator
might
want
to
do
maintenance
on
for
one
reason
or
another.
One
example
is
for
our
bare
metal
users.
They
might
want
to
pair
off
the
machine
to
replace
like
a
stick
of
RAM
or
something
like
that,
and
so
we
don't
want
to
trigger
all
these
automatic
processes
to
delete
the
instances
or
reprovision
things
or
move
storage.
A
Another
use
case
is,
we
do
in
place
updates
on
open
ships.
So
we
have
we
call
machine
configurator,
so
we
update
the
configuration
of
a
node,
those
updates
get
pushed
out
in
the
node
reboots.
That
can
take
a
couple
minutes
then
same
thing.
We
don't
want
any
automated
process
to
go
back
behind
us.
While
we're
doing
this
update
and
say
hey
this
notice,
broken
I
need
to
get
rid
of
it.
Then
some
other
use
cases
are,
let's
say:
I'm
an
administrator
and
I'm
investigating
some
problem
with
the
node.
A
A
What
we're
trying
to
do
is
have
an
ability
for
these
different
things
to
coordinate
actions
to
nodes
in
a
way
that
they
don't
have
to
know
about
each
other.
So
you
have
different
existing
components
like
no
problem
detector
and
they
have
different
mediators.
We
have
machine
code
checkers,
you
know
on
the
while
people
are
picking
and
choosing
all
these
different
components.
C
For
readers
of
the
cup,
is
it
basically
advocating
for
a
new
sub
project
within
kubernetes
to
be
sponsored
by
a
cig
to
be
determined
that
would
implement
the
core
controller?
Is
the
desire
to
integrate
this
with
the
node
lifecycle
controller
itself
within
the
Brunei's
or
one
of
the
other
val
provider,
projects
that
think
that
may
be
the
I?
Guess
the?
What
is
the?
Where
will
the
code
live,
that
that.
A
Did
you
have
that
was
kind
of
like
some
of
the
I
yeah
I
answered
some
of
those
questions
just
with
like
some
answers
that
seem
like
good
choices
to
me,
I
think
would
be
acceptable
as
far
as
like
creating
a
new
work
group
or
signo
I
think
this
could
live
in
either
cluster
lifecycle
or
node
I.
Don't
think
it's
really
a
major
component
that
needs
a
whole
lot
of
life.
A
Cycling,
I,
think
this
is
one
of
those
things
that,
like
it's
a
voluntary
thing
that
things
are
coordinating
on,
but
it's
not
fundamentally
altering
the
behavior
of
any
existing
thing
would
be
like
opt-in,
behavior,
but
the
cross
section
of
code
I
think
is
very
small.
So
where
does
a
code
live?
Well,
the
bulk
of
the
code
kind
of
lives
in
the
controllers
that
are
implementing
the
acquire
lease
mechanism,
but
the
actual
changes
to
like
core?
A
Yes,
I,
think
the
node
lifecycle
controller
makes
some
sense
as
far
as
creating
the
lease
object
that
everyone's
going
to
consume
and
then
I
want
to
say
it's.
The
API
I
left
a
link
to
the
where
I
believe
we're
creating
some
default
namespaces
today.
So
I'm
proposing
that
we
just
create
this
new
default
namespace
in
the
same
manner
so
to
catch
everyone
up
I'm,
proposing
we
create
a
new
default
namespace
called
cube,
node
maintenance,
and
in
that
namespace
we
create
a
lease
object
in
the
there's.
One.
A
Lease
object
per
node,
similar
to
what
we
do
with
the
I,
can
never
remember
what
the
existing
lease
is
called.
But
it's
basically
like
the
liveness
check
or
whatever
for
the
nodes,
and
that's
that's
pretty
much.
The
changes
I
want
to
make
to
core,
and
then
the
bulk
of
the
usefulness
is
really
how
consumers
are
utilizing,
that
lease
object.
C
C
Personally,
don't
have
a
issue
of
either
a
Signet
or
cluster
lifecycle
wanted
to
sponsor
the
sub
project.
But
if
the
question
is,
do
we
want
this
to
be
inherent
to
every
kubernetes
distribution
and
a
part
of
like
core
conformance
like
I?
Don't
maybe
that's
as
where
this
sake
could
come
in
and
talk
through,
but
I,
don't
think
the
idea
has
probably
been
proven
out
enough
to
to
demonstrate
that
yet
and
so
I'll
pause
here
and
see
if
others
have
perspectives
on
it.
D
D
B
B
The
sequence
life
cycle
perspective:
we
discussed
that
this
is
covering
up,
definitely
a
gap.
Let
me
see
for
some
use
cases,
but
if
the
court
is
going
to
live
in
core,
we
are
hesitant
to
own
the
feature
because
you're
not
going
to
own
the
call.
If
you
know,
if
it's
an
external
controller
like
in
the
case
of
the
sitcom
operator,
we
are
okay
to
own
this.
E
A
For
any
kubernetes
deployment
in
the
future,
the
whole
point
of
this
cap
is
to
have
something
that
everyone
can
rely
on
to
coordinate.
I
just
feel
like
that's
like
a
really
big
missing
feature
right
now.
Obviously,
I
could
build
something
that
looks
like
this
and
behaves
like
this
and
modify
different
components
to
use
whatever
that
thing
is
so
making
it
optional
and
making
it
owned
by
a
separate
controller.
A
That's
not
always
deployed
kind
of
removes
some
of
the
value,
because
now
I
have
to
make
sure
that
I've
deployed
that
thing
and
then
that
these
other
components
are
integrating
with
that
thing,
and
so
now
we're
just
creating
like
a
chain
of
dependencies
and
I.
Don't
think
that
the
functionality
that
we
need
to
introduce
as
far
as
managing
the
lifecycle
of
this
thing
is
complex
enough
to
need
its
own
separate
component
like
there's,
really
there's
no
CR
DS,
there's
really
nothing
to
reconcile,
there's
nothing
to
really
lifecycle.
D
I
feel
like
I
feel
like
there's,
maybe
some
prior
art
here
in
terms
of
like
some
of
the
discussions
that
we're
done
around
virtual
notes
and
stuff,
because
I
feel,
like
my
personal
feeling
is.
This
gets
a
bit
far
into
lifecycle
management
in
ways
that
I
think
are
making
some
assumptions
that
maybe
don't
necessarily
enough
align
with
all
the
use
cases
out
there
I
mean
I,
definitely
I
see
the
need
for
something
like
this,
because
the
coordination
aspects
are
are
tricky,
but
something
out
of
tree
I
feel
like
just
from
an
implementation.
D
Standpoint
makes
a
lot
more
sense.
I
just
feel
like
this.
This
seems
relatively
straightforward
on
the
outside,
but
I
think
that,
once
you
start
digging
into
some
of
the
use
cases
that
it's
gonna,
that
it
could
become
much
more
thorny
and
it's
definitely
not
something.
I
think
that
everybody
wants
necessarily
I,
think
it's
something
that
there's
probably
a
subset
of
folks
that
what
this.
C
I
I
guess:
what
on
what?
What
I'm,
observing
as
the
core
tension
is.
C
C
Does
this?
Does
this
ache
wanna
provide
a
forum
for
a
small
sub
project
to
explore
lists
and
then,
if
there
are
a
large
enough
set
of
actors
that
want
to
consume
it
and
build
around
it,
then
the
value
will
become
clear
but
I
think
I
think
it's
probably
difficult
to
say
within
this
group
that
it
should
be
there
by
default
everywhere
and
that's
probably
the
best
like
like
it's
right
now
than
cigars.
Maybe
James!
Do
you
wanna
see
what.
G
Thanks
James
I
I
just
have
a
couple
of
minor
points,
but
I
think
there
may
be
worth
going.
I'd
like
to
reiterate
Jason's
point
about
the
namespace.
We
already
have
a
lot
of
problems
with
webhooks,
causing
problems
on
leases
when
they're
in
the
cube
system,
namespace
and
I-
think
putting
them
anywhere
other
than
Hakeem
system.
Namespace
is
actually
gonna
make
this
system
less
functional,
so
I
I
would
just
+1,
and
if
anyone
wants
to
know
why
I
can
give
a
lot
more
details.
I
would
also
say
on
me
trying
to
make
this
thing
used.
G
So
we've
got
a
lot
of
controllers
that
this
is
gonna
need
to
touch
and
I
think
it
isn't
useful
unless
it
touches
many
of
them.
Just
as
an
example,
we
talked
about
the
node
lifecycle
controller,
but
there
are
two
of
those
at
least
that
I
know
of
so.
Presumably,
if
you
wanted
to
put
it
in
there,
you'd
want
to
put
it
in
both
places,
because
you
have
choice,
of
which
one
of
the
two
you're
gonna
run
and
we've
also
I
mean
there
are
a
lot
of
weird
things
about
the
lease
object
itself
and
leader
election.
E
E
A
Well,
certainly,
we
can
do
any
kind
of
experimentation.
I,
don't
even
think
we
need
any
software
to
do
experimentation
I
mean
we're
talking
about
creating
a
lease
object
and
nothing
reconciles
it
so
I
could
create
a
namespace
and
I
could
create
a
lease
object
in
like
ten
seconds.
Really,
the
bulk
of
the
value
is
integrating
other
components,
so
I
guess
what
I'd
like
to
see
is:
if
we're
going
to
iron
out
any
details
like
the
namespace
thing,
what
I?
A
A
C
The
qubit
does
maintain
a
lease
and
we
did
go
through
the
work
of
our
si.
Getting
a
new
name
space
for
that.
Have
you
thought
about?
Is
there
any
opportunity
to
piggyback,
on
top
of
the
existing
lease
that
cubelets
renewed
to
to
do
something
there
like?
Is
there
an
anything
we
do
around
an
annotation
or
something
to
explore
the
thought
without
meaning
a
secondary
name,
space
or
lease
itself?
C
A
Don't
think
that
would
be
really
great
reusing
the
same
name.
Space
is
a
problem
from
the
user
experience
point
of
view.
If,
if
I'm
an
administrator
and
I
want
to
control
this
lease
myself,
then
then
I
need
something
other
than
the
node
name
as
the
leases
name
for
this
lease,
because
there
can
only
be
you
know,
one
thing
of
one
kind
in
a
name
space
so
with
the
same
name
so
yeah.
C
C
Maybe
the
other
thing
to
be
helpful.
Is
you
identified
a
set
of
potential
consumers?
I,
don't
know
if
it
was
captured
in
the
cap,
but
for
those
that
might
want
to
review
this
in
greater
detail
afterwards?
Is
there
a
list
of
like
known
potential
consumers
that
be
interested
in
this,
that
we
could
emerge
the
kept
with
to
know
that
there's
people
who
would
want
to
leverage
it
or
projects.
A
A
A
So
for
the
node
shutdown
cap,
it
looks
to
see
like
this
notice.
Shutdown,
because
is
the
cloud
provider?
Is
it's
still
there
and
then
kind
of
take
corrective
actions
based
on
that
information
and
some
of
those
corrective
actions
might
be
fine,
taints
or
doing
other
things,
whereas
this
that
component,
that's
being
proposed,
could
look
at
this
lease
and
say:
hey
it's
mission,
doing
maintenance
to
this.
This
is
probably
an
expected
situation.
H
C
Maybe
one
final
question:
is
there
I
need
to
think
in
my
head
a
little
bit?
I'm?
Sorry
if
this
was
capture
dozen,
the
idea
here
is
you
needed
a
single
owner
who
says
I'm
doing
maintenance,
and
so
the
reason
that
you
couldn't
say
propagate
a
new
condition
into
the
node
object
itself
is
that
you
don't
know
who
the
maintenance
holder
is,
and
you
think
more
than
one
actor
is
going
to
try
to
do
maintenance
at
a
time.
A
Well,
who's
setting
the
status.
If
it's
all
these
different
components,
they
need
to
be
updating.
The
node
object
directly
in
that's
certainly
feasible
from
a
technical
standpoint,
but
it's
my
understanding
that
there's
a
little
bit
of
a
bigger
hurdle
to
allowing
all
these
things
to
read
and
write
from
the
node
object.
We
have
our
back
considerations
and
things
like
that.
Is
that
a
path
that
we
want
to
pursue
I'm
perfectly
happy
to
pursue
that
path.
I
mean
to
me.
A
It
makes
sense
that
if
you're
going
to
be
doing
disruptive
things
to
the
node,
then
then
do
this
on
the
node
itself.
One
one
drawback
to
putting
in
the
status
object
is
if
an
administrator
just
wants
to
say:
hey
I
need
nobody
to
touch
this
right
now,
there's
not
really
a
great
easy
way
to
do
that
in
the
status
field.
A
C
So
I
think
it's
first
one.
Thank
you.
Michael
for
frame
a
topic
to
the
Saiga
probably
was
presented
to
a
new
audience
that
hadn't
reflected
on
this
I'm,
not
sure
we'll
get
a
resolution
today,
but
I
think
people
were
presented
with
a
new
problem,
maybe
that
they
hadn't
reflected
on
before,
and
maybe
some
ideas
will
come
out
of
it
or
others
who
had
similar
challenges.
C
A
Definitely
think
that's
fair,
that's
a
lot
of
what
I'm
searching
for
here
is.
If
I
think
we've
identified
this
as
a
as
a
need.
What
I
want
is
everyone
to
put
their
brains
together
and
come
up?
I,
don't
really
care
what
the
implementation
looks
like
I
just
know:
I
maintain
components
that
need
something
that
looks
like
this
and
I'd.
Rather,
everyone
standardize,
so
I
don't
have
to
do
it.
E
Twice
yeah
I
kind
of
agree
with
what
you're
saying
it's
just
that
if
we
find
a
specific
problem
like
the
noted
on
cap
which
can
use
this
thing
that
you're
proposing
here,
like
an
I/o
library
that
you
mentioned
here
and
get
some
specific
consumer
lined
up,
then
I
think
we'll
be
able
to
make
more
progress
here.
I
think.
H
A
E
A
C
C
Okay,
so
I
think
Michael,
thanks
for
trying
to
find
the
consumer
and
I
think
I.
Think
it's
fair
to
say
there
are
a
wide
variety
of
cluster
life.
Cycling,
solutions
that
are
successful
and
having
a
standard
that
folks
could
use
to
signal
when
maintenance
might
be
occurring
is
probably
valuable
and
so
thanks
for
presenting-
and
we
can
allow
folks
on
the
call
to
reflect
to
see
if
they
have
use
cases
that
come
to
mind
as
they're
celebrating
the
fourth
of
July
or
having
a
great
weekend
wherever
else
they
live.
So
for
the
next
topic.
C
B
I
I
I
I'm
really
happy
with
the
progress
we've
made.
This
is
the
existing
site
and
you
can
see
over
the
past
few
releases,
we've
gone
from
less
than
near
twenty
twenty
two
percent,
something
all
the
way
up
to
over
forty,
which
is
really
great,
and
this
is
our
stable
GaN
points
that
are
lacking
conformance
next.
I
We
also
have
this
extra
grey
line
here
that
we
added
there
were
four
end
points
that
we're
not
going
to
be
testing
for
conformance
because
they're
not
eligible.
Yet
there
are
some
conversations
around
adding
profiles
and
they
are
solidifying
much
closer.
I
know
that
Aaron
is
bringing
forth
sand
something's,
probably
incoming
week,
or
so
that
will
help
address
some
of
that.
I
That's
tested,
endpoints,
that
are
the
technical
debt
getting
paid
off.
The
new
tested
means
that
there
were
endpoints
introduced
in
that
release.
That
came
with
their
conformance
test.
This
is
really
the
only
growth
we
want
to
see
long
term.
The
growth
we
to
see
it
to
get
rid
of
the
red
is
the
growth
and
the
green.
The
dark
green
at
the
bottom
and
the
red
is
our
technical
debt,
the
stuff
we
want
to
completely
eliminate.
I
It
may
be
a
little
hard
to
read
and
I
apologize,
for
that
is
the
new
untested
and
you
can
see
in
our
earlier
releases.
We
had
new
end
points
added
that
don't
have
pests
I
think
we
would
have
one
currently
inside
of
them
this
release,
and
this
is
the
stuff
we
want
to
kind
of
create
a
gate
for
to
ensure
we
don't
get
these
new
end
points
coming
in
and
I
think
that
became
a
policy
some
kind
of
in
about
one
114
115,
so
we're
doing
a
pretty
good
job
of
it.
I
I
Our
current
setup
projects,
beyond
writing
tests
to
promote
for
conformance,
is
putting
up
a
conformance,
CNC,
okay,
its
conformance
gate,
which
we're
we're
nearly
done
with
I'd,
say
we'll,
probably
finish
this
next
week,
where
we
needed
to
set
up
a
Proustian
CF
I/o
instance
that
was
not
2kk,
putting
the
other
kate's
in
for
working
group,
but
maybe
something
like
a
CNC
F
in
for
working
group
that
we're
still
talking
about.
We
also
have
our
KK
conformance
gate.
That
is
what
we
will
be.
I
These
are
the
ones
that
have
been
added
by
the
community
and
big
shots
out
to
Liggett
for
making
sure
that
all
of
the
end
points
that
hits
his
groups
have
been
a
part
of
our
coming
with
their
tests
and
they
all
link
back
the
API
snoop
to
show
that
coverage
super
happy
in
this
increase
in
coverage.
Up
to
forty
one
point:
two
there's
been
a
big
conversation
around
watch
tooling.
I
That
I
think
has
as
impact
that
our
velocity
thus
far,
and
some
of
that
is
us
needing
to
get
quicker
feedback
from
possibly
different
SIG's,
rather
than
relying
on
the
very
few
people
who
show
up
and
do
PR
reviews
for
the
the
test-
writing
team
here
at
I/o.
So
we
may
modify
our
process
to
include
before
we
approve
work,
ensuring
that
we
have
sponsorship
nearly
for
a
test
to
see
that
that
sig
can
provide
some
reviewers.
I
I
The
last
thing
I
want
to
leave
you
with
is
we
have
this
PR?
That
is
just
for
conversation,
and
it
is
our
endpoint
coverage.
You
know,
I'm,
not
sure
if
you
can
see
the
raw
point
on
that,
but
this
is
what
we
plan
to
use
something
like
this,
possibly
out
of
tree,
where
we,
if
new
endpoints
get
promoted
from
as
they
go
from
alpha-beta
the
GA
ascending
notes.
We
noticed
you
don't
have
tests
for
these
yet
by
the
way
to
get
to
Jay
you'll
need
them
until
they
get
to
the
GA
point
to
say:
you're.
I
J
J
I
H
E
I
Want
to
point
out
that
we
that
help
is
how
do
you
see
this
this
green
here?
That's
all
Liggett
and
crew
and
I
think
this
was
also
some
of
so
we
don't
have
did
the
when
it
rises
here.
This
solid
green.
This
is
our
progress.
This
is
solid
progress
and
it's
gonna
go.
You
know
if
it
stays
the
same
speed,
I'm,
hoping
to
speed
it
up
right,
but
I'm
I'm.
Happy
with
that.
I
So
I
wondered
if
there's
a
way
when
we
engage
with
a
sig
to
have
sponsorship
for
the
text
and
whether
that's
just
something
we
do
informally
by
trying
to
speak
to
the
the
chairs
of
those
SIG's
to
say:
can
can
I
kind
of
get
a
couple
of
hands
to
to
review
PRS.
You
know
within
a
you
know,
two
to
four
day
turnaround
versus.
Sometimes
it's
like
two
to
four
weeks.
I
K
Being
in
how
worked?
Oh,
they
were
yeah,
that's
the
old
Nicole,
it's
3:00
a.m.
for
them
to
join
this
meeting.
So
we
had
a
discussion
on
the
secret
base
and
a
brief
conversation
the
sick
note.
So
they
asked
us
to
come
to
seek
architecture,
to
talk
about
the
support
and
there's
already
them
the
artifact
there.
It's
just
of
a
matter
like
how
we
reflected
the
support
in
which
way
you.
C
L
C
If
this
was
raising
sig
note,
is
there
an
existing
standard
that
your
your
team
and
engineers
are
meeting
that
you
feel
is
sufficient
or
are
you
looking
and
or
do
you
have
a
recommended
standard
you
feel
like
you
could
reach,
and
that
would
be
what
you'd
recommend
the
coronaries
project
hold
itself
to?
That's,
probably
what
I'm
what
we
in
cigarettes
would
be
looking
to
get
feedback
from
from
your
team.
K
C
C
I'm
sorry,
I
wasn't
working
there
I
think
I
think
what
we're
trying
to
find
is
a
a
a
bar.
We
can
hold
all
others
too,
and
so,
if
your
existing
capability
could
be
enumerated
as
a
basis
that
we
could
potentially
evaluate
others
against
which
I'm
not
sure
we
have
enough
in
front
of
us
right
now
on
this
topic
to
talk
to
that's
a
starting
point
and
then
the
other
following
question
is
like:
is
there
a
clear
contact
point
that
is
responsive
to
errors
such
that?
C
If
that
signal
is
not
passing,
that
the
release
is
actually
able
to
still
release
and
not
confuse
the
users
who
are
pulling
from
the
community?
And
so
there's
probably
two
two
topics
when
you
talk
through
like
which
is
what
is
the
level
of
support
and
what
is
the
level
of
ongoing
engagement
and
responsiveness
to
when
that
signal
shows
an
error?
And
so
so.
K
The
first
question
the
level
of
support
is,
we
are
in.
We
have
a
dedicated
team
to
support
I'm
sixty-four
support
for
this
instruction
set
architecture.
A
second
point,
I
can
be
the
main
contact.
My
colleague
is
robbing
and
how
we're
here
was
on
the
court
with
three
people
are
responsible
for
any
arrests.
If
it
happens
in
the
signal.
K
C
And
so
maybe
the
best
thing
we
can
do
is
to
do
a
more
thorough
dive
on
this
topic
in
the
next
meeting,
where
you
can
come
forward
with
what
you
feel
is
an
appropriate
bar
and
it
sounds
like
you've
identified,
something
that
seems
reasonable,
and
so
we
can
then
hold
it
up
against.
Maybe
the
folks
from
it
almost
who
wanted
to
have
that
discussion
and
say
are
we?
Are
we
holding
everybody
to
the
same
standard
and
again
I
thought?
C
H
Tim,
sorry,
okay,
Tim's
now
this
is
a
really
interesting
topic
to
me
and
I
have
every
confidence
that
you
guys
are
all
in
and
that
you
feel
on
the
hook
to
support
it.
I'm
still
concerned
about
the
broader
community
and
procedures
around.
You
know
what
do
I
do
in
sig
network.
If
somebody
reports
an
issue
and
I
think
it
might
be
arm
related,
do
we
like?
Are
we
gonna
build
a
so
laze
around
response
time?
H
You
know
those
sorts
of
questions
right,
I,
don't
want
to
get
to
a
place
where
we
say
well,
you
have
to
have
people
on
call
otherwise
we're
gonna.
Kick
you
out
of
the
supported
tree,
because
that
seems
wrong,
but
I
also
don't
want
to
be
in
a
place
where
we're
throwing
it
back
and
forth
at
each
other.
Saying
well,
I
can't
reproduce
to
not
Intel.
So
it
must
be
an
arm
problem
and
you're,
saying
that
this
can't
possibly
be
an
arm
problem.
K
A
K
E
So,
as
for
myself,
I've
been
helping
out
bin
loo
every
time
there
is
a
question
or
a
query
around
what
to
do.
What
are
the
next
steps?
That
kind
of
thing
so
I'm
like
I,
do
want
to
thank
you
all
for
the
work
you've
already
done,
and
one
thing
that
I
wanted
to
check
with
you
is:
did
cig
release?
Give
you
guidance
around
what
kind
of
test
that
they
would
like
to
see
in
either
the
blocking
or
the
informing
dashboards
before
you
know,
they
can
declare
thumbs
up
on
supported.
K
C
So
I
think
I,
Tim's,
question
and
I
think
there's
probably
like
what
does
say.
Architectures
responsibility
have
in
the
space
which
I
assume
is
basically
saying
is
sake,
architecture
responsible
for
saying
which
architectures
itself
kubernetes
can
should
or
desire
to
run
on,
and
then
that's
probably
a
separate
question
from
then
figuring
out
the
if,
if
a
desire
is
deemed
worthy,
how
is
how
our
problems
isolated
and
handled
and
then
there's
the
third
question
on
if
an
architecture
is
deemed
desirable
and
worthy
and
we
have
a
clear
way
of
handling
problems
among
groups?
C
E
E
No,
it's
just
that,
so
what
we
have
done
already
is
we
made
sure
that
all
conformance
tests
have
the
images
with
manifests
so
arm
is
definitely
supported
there,
and
then
we
made
sure
that
the
conformance
image
also
is
you
know
the
fat
manifest
base,
and
we
also
made
sure
that
you
know
anybody.
Running
e
to
e
test
can
run
on
arm
architectures,
so
we
have
done
all
the
legwork
as
such
already
so
what
is
probably
left
is,
in
my
view,
signal
ease.
Having
confidence
that
they'll
be
able
to.
C
So
then
Jen's
a
sounds
like
you.
So
thank
you
for
that
summary.
What
I
guess
is
missing
in
the
project,
then,
is
the
D,
so
you
want
to
add
support
for
a
new
architecture
and
kubernetes
document
that
kind
of
hits
all
those
checkpoints
you
just
discussed,
and
so
that
feels
within
the
domain
of
sake,
architecture
to
produce
is
there
an
existing
set
of
documents?
C
Maybe
Tina
and
your
team
had
been
sourcing
before
to
help
navigate
your
way
through
these
problems
that
we
could
better
coalesce
and
then
maybe
make
more
prominent
that
we
could
talk
through
and
then
I
still
think,
there's
the
general
tension
among
the
SIG's
on
problem
identification.
That
I
probably
needs
a
deeper
discussion
on.
C
Like
does
everything
itself
need
to
have
a
representative
associate
of
that
architecture
to
know
that
things
are
working
or
not
to
reason
through
these
things?
Basically,
is
there
a
document?
We
can
look
at
that
more
crisply
identifies
the
problem
we
could
be
talking
through,
and
can
we
produce
that
as
a
next
step,
and
is
that
something
maybe.