►
From YouTube: 20180807 sig cluster lifecycle
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
A
So
just
as
a
PSA
for
the
first
part
before
I
get
into
the
details
is
the
the
Charter
has
been
submitted
for
Cinco
stroller
cycle
and
we're
I
think
we're
just
waiting
for
feedback
from
Bryan.
Otherwise,
we've
done
one
quick
turn
and
some
initial
feedback
and
then
we'll
we'll,
probably
I'll
patch
everything
else
up
and
wait
for
Bryan's
feedback
before
I.
A
Do
the
next
update
the
first
topic
that
I
added
the
list
for
today
was
the
multi
harch
manifest
issue
and
the
reason
I'd
kind
of
push
back
on
this
particular
PR,
which
I
think
one
of
the
VMware
folks
is
working
on?
Is
that
we
don't
have
this
stuff
documented
because
there's
multiple
consumers
of
both
Kubb
ATM
and
as
well
as
the
testing
artifacts
like
we
need
to
have
a
document
that
has
a
planned
migration,
because
it's
almost
like
implied
semantics.
A
B
C
Do
we
have
we
exposed
like
a
sort
of
contract
for
what
these
images
are
going
to
be,
or
do
we
search
it?
This
is
an
implementation
detail
and
if
people
are
relying
on
it
today
as
part
of
the
migration
plan,
but
it
makes
sense
to
turn
it
into
either
a
contract.
We're
gonna,
stick
to
or
explicitly
make
it
an
implementation
detail
and
tell
people
not
to
depend
upon
exam,
I
change
again
in
the
future,
like
a
bunch
of
stuff,
a
risky
thing
to
do
to
depend
upon
the
specific
image
names
deserty.
A
We
have
this
implicit
contract
versus
having
an
explicit
contract
and
people
do
depend
upon
some
implicit
behavior,
which
is
kind
of
common
among
stuff
like
this,
so
I'm
totally
fine
with
somebody
writing
up
a
doc
in
getting
a
proposal
in
place
and
making
this
go
just
make
sure
that
we
don't
like
if
somebody's
got
all
this
automation
built
up
for
pulling
images
and
getting
other
stuff
ready,
we
don't
just
break
a
ton
of
people,
because
rubidium
is
now
the
backend
for
a
bunch
of
different
installation.
Folks
and
that's
the
last
thing
I
want
to
do.
A
C
We
we
have
automation
that
that
we
maintain
that
pulls
the
existing
images
down
from
people
do
offline,
installs,
I
think
there's
been
some
chatter
and
slack
about
that
the
last
couple
days.
Presumably
we
would.
We
would
keep
that
up
to
date,
some
people
we're
using
our
automation
for
image
going
to
be
fine.
It's
just
if
you
will
about
their
own.
It
would
be
a
problem
right.
Yes,
so.
A
We
added
the
image
pulling
in
111
so
previously
before
that.
If
people
were
doing
sort
of
air-gapped
installation
processes,
they
would
typically
do
their
own
image
full
and
lists
down
the
listing
of
the
images
with
the
tags
specifically
for
those
versions,
and
they
would
include
the
arch
for
those
tags
like
if
a
person
was
doing
automation
for
doing
verification
and
harm,
they
would
do
it
that
way
because
they'd
always
add
the
arm
tag
right.
A
C
Well,
another
question
so:
presumably
the
fat
images
there
I
think
what
Lukas
explained
to
me
is
that
they're,
basically
redirects
where
you
don't
actually
pull
down
an
image.
That's
gonna
be
three
or
four:
it's
bigger!
You
just
pull
down
the
image
for
specific
architecture,
but
how
does
that
work
for
the
copying
to
a
private
registry
desire
autumn-like?
We
have
that
set
our
animation
to
actually
pull
both
the
manifest
and
all
the
individual
images
and
copy
that
across
because
otherwise
this
isn't
going
to
work.
C
Yes,
what
I'm
saying
as
the
automation
for
for
copying
things
internally
is
gonna,
be
a
lot
trickier
with
the
manifest
list
than
it
is
with
straight
up
images
right
exactly
and
I,
don't
we'd
have
to
make
sure
we
got
that
right
and
you
know,
like
Tim,
was
saying
anybody
else.
Patients
gonna
have
to
do
something
similar,
so.
D
D
A
So
I
put
a
hold
on
the
PR.
It's
just
basically
saying
like
there's
a
bunch
of
issues
here
that
are
deeper
than
just
this
individual
change
that
requires
addressing
I.
Think
the
the
proper
thing
to
do
maybe
would
to
have
a
proposal,
and
we
can
agree
upon
for
how
we
want
to
do
this
and
think
about
it.
A
little
more
detail
before
we
execute
on
it.
I
think.
C
B
Oh
so
I
have
a
question
here.
So
if
the
current
behavior
for
pulling
images
is
by
applying
an
architectural
suffix
by
introducing
manifest
lists
and
not
sure
how
this
is
going
to
break
for
users,
because
they
can
still
pull
the
original
architecture,
specific
image,
I
think
even
if
the
manifest
lists
exist.
I.
B
B
E
Usually
the
manifests
I
haven't
looked
into
the
specifics
from
qadian,
but
from
my
work
on
Sona
boy,
the
manifests
push
to
different
repositories,
the
native
images
and
then
a
manifest
is
pushed
to
the
original
repository
that
combines
both
of
those
images.
So
I
think
the
whole
process
would
become
slightly
different.
E
B
E
A
B
A
B
A
A
B
B
A
A
The
problem
that
exists
is
I.
Think
not
necessarily
that
we
don't
wanted
the
idea
that
we
don't
want
to
do
it.
It's
just
the
technology
choice
and
how
we
go
about
doing
it.
That
is
the
conundrum
it's
very
unclean
for
lack
of
a
better
word
or
turn
and
not
systematic
of
how
it's
done
inside
of
the
code.
If
we're
gonna
do
flight
overrides
and
there
are
other
tools
that
may
be
cleaner
or
there's
other
policies
we
can
approach
here.
A
So
I
wanted
to
have
a
conversation
about
how
we
want
to
merge
this
topic
in
general
because
it
will
ripple
across
all
this
other
component
config
work
that
you
know
the
proposal
that
we
want
to
have
a
unified
way
of
how
we
deal
with
give
me
a
config
use
these
flag
overrides
and
have
a
unified
technology
choice
eventually
for
these
other
pieces,
because
we
don't
want
to
have
Kubb
adn
behave,
weirdly
different
than
the
couplet,
they
gave
weirdly
different
than
the
proxy.
Now
that's
a
global
concern.
B
So
I
have
a
comment
here:
I
kind
of
already
made
a
comment
in
the
issue:
I
think
the
couplet
did
the
right
thing,
even
if
it's
like
difficult
to
handle
and
the
idea
is
to
eventually
deprecated
everything
in
terms
of
flags
because
without
override
we
get
chaotic
behavior.
If
you
look
at
the
cookie
proxy
right
now,
the
flags
in
configure
mutually
exclusive,
which
is
pretty
bad
and
if
we
fall
in
the
steps
of
the
community
I
think
we
can
basically
start
slowly
deprecating,
but
I
am
open
to
another.
E
I,
don't
like
the
idea
of
getting
rid
of
Flags
altogether.
It
seems
a
lot
like
decreasing
user
experience
for
the
purpose
for
the
purpose
of
making
development
easier.
I
think
it
makes
a
lot
of
sense
for
the
cubelet
to
do
it,
because
the
number
of
times
you
invoke
the
cubelet
by
hand
is
its
minimal.
Like
the
the
standard
usage
of
the
cubelet.
Is
you
set
it
up
in
a
conflict
file
somewhere?
E
E
Anything
like
that,
because
it
doesn't
make
a
lot
of
sense
and
I
think
requiring
people
to
edit
a
config
file
for
something
that
they're
going
to
run.
Maybe
once
or
twice
a
year
is
too
onerous.
I
agree
that
the
like
more
advanced
options
should
go
in
a
config
file
and
I
think
there
are
use
cases
where
that
makes
a
whole
lot
of
sense,
but
I
think
having
just
a
couple
of
basic
Flags
that
override
a
config
file
is
is
still
a
good
idea.
E
A
Agree
with
that
sentiment,
I
think
what
what
I
think
what
I
take?
What
I
have
problems
with
with
the
current
PR
is
kind
of
the
technological
solutions.
Now,
there's
there's
there's
many
opinions
about
VIPRE,
but
VIPRE
solves
this
problem
cleanly
and
that
has
explicit
ordering
you
know
of
config
through
flag,
config,
env
Flags
right.
So
that
way
you
have
now
we
don't
need
to
use
VIPRE.
You
can
use
some
other
technology
that
we
could
rally
on,
but
that
doesn't
exist
inside
of
the
kubernetes
codebase
right.
A
The
kubernetes
code
base
is
has
every
combination,
oddities
that
exists
between
those
different
ways
to
pass
parameters.
So
I
would
like,
as
sort
of
the
folks
who
have
submitted
the
proposals
for
unification
of
config,
to
start
to
formulate
an
opinion
for
better
for
worse
about
having
rallying
around
the
standard
practice.
C
So
trying
to
compare
cube
a
minute
at
cubelet
is
not
the
right
comparison
which
we
prepare
to
to
cube
cuddle
I
may
we
should
be
super-hearing
cubelet
to
the
API
server
or
the
controller
manager,
and
try
to
make
those
consistent,
I
sort
of
had
sort
of
two
groups
of
things.
We
want
to
be
type
consistency
around.
One
is
system,
components
that
we
never
expect.
People
to
run
and
the
other
is
things
we
expect
people
to
interact
with
so
I,
don't
I,
don't
know.
If
does
like
the
cubelet
I
know
it
takes
lots
of
different
flags.
C
You
can
point
to
different
places.
You
can
set
environment
variables,
maybe
we
should
be
talking
to
60
Li
and
see
if
there's
any
sort
of
coherent
plan
around
where
that
is
or
where
it's
going
and
tried
to
align
with
them.
Instead
of
trying
to
align
with
the
component
configuration
plan,
which
is
anything.
G
D
D
B
So
the
problem
with
4x
is
I'm
gonna
measure
this,
like
I've,
seen
discussions
around
6000
about
koto
I
mean
they
have
problems
with
flags.
They
have
too
many
facts
and
facts
are
difficult
to
maintain
and
they
are
like
Michael
Dauphin
is
saying
there
they
do
not
hold
abortion,
so
I
mean
that's
part
of
the
bigger
picture.
The
problem
with
flags
account
we
maintain,
but
I
do
agree
that
if
you
use
flags
from
the
command
Winnetka
medium,
it's
much
easier.
E
E
But
I
also
don't
think
that
we
want
to
end
up
in
the
situation
where
you
have
to
write
out
a
config
file
before
even
initially
can
get
most
of
a
working
cluster
out
of
cube
ADM
in
it
with
no
arguments
is
a
very
powerful
thing
and
I
don't
think
we
should
get
rid
of
that.
I
think
we
need
a
policy
about
what
is
a
flag
and
what
is
a
config
variable
instead
of
making
all
of
those
decisions.
E
A
Yeah
I
I
do
think
some
rallying
point
of
conversation
would
be
helpful,
whether
it
be
proposal
or
some
individual
document
before
it
gets
to
proposal
form.
That
says,
like
you
know,
in
the
eye,
here's
the
problem
statement
here
are
some
proposed
ideas
and
how
we
want
to
address
it
in
some
technological
choices
that
exist
in
the
trade-offs
between
them,
because
this
isn't
made
a
problem
right.
A
E
I
C
C
C
E
Definitely
don't
want
to
be
in
the
situation
where
you
know
somebody
submits
a
PR
and
it's
their
first
PR
and
everybody
in
the
everybody
in
the
project
decides
that
now
is
the
time
to
have
a
super
important
architectural
debate
about
it.
So
I
think
I
would
lean
towards
getting
their
thing
merged
now,
as
long
as
it's
not
you
know
completely
heinous
I,
don't
have
a
lot
of
background
on
this
particular
PR.
I,
don't
know
what
we're
referring
to,
but
just
like
in
general
I.
C
As
I
was
trying
to
figure
out
what
the
path
forward
was
and
the
path
forward
could
be,
we
need
a
design
or
we
need
more
context
or
reading
something
else
like
not
just
merge
code.
We
don't
want
to
maintain
forever
I.
Think
that's
the
other
thing
we
need
to
be
careful
with.
Is
you
know?
Maybe
we
should
set
expectations
that
if
you
just
come
by
and
send
a
large
PR
it
that's
not
going
to
be
a
successful
way
to
start
contributing.
You
should.
C
A
J
Thought
earlier,
when
talking
to
my
father,
I
thought
this
would
be
the
way
we
do
stuff
for
other
components,
convict
that
in
migrate
in
the
migration
from
only
flags,
the
convict
plus
flags
flags
would
have
higher
priorities
and
config
and
most
of
the
config
or
like
eventually
in
like
QB,
two
or
whatever
we
would
get.
We
would
actually
be
able
to
get
rid
of
most
of
the
flags
and
only
use
config
for
most
of
stuff.
J
So
that
was
my
or
that's
what
it
says
in
the
doc
like
how
you
do
components,
config
kind
of
official
doc.
At
the
moment,
if
we
intend
to
chain
that
policy
which
I
wasn't
aware
of
and
I've
been
like,
focusing
this
stuff
anyway,
so
I
don't
know,
I,
think
it's.
Ok,
you
better
to
do
this
and
I
just
guess
that
people
were
a
bit
scared
of
the
complexity
that
and
today's
I'm
time
to
actually
look
at
how
complex
it
is.
I.
Think.
A
This
is
only
one
flag
and
the
pearl
of
rights
and
I
think
the
idea
that
for
the
other
flags
and
I
have
a
unified
policy
for
cubanÃa
would
require
a
lot
more
changes
and
be
unwieldy
and
I.
Think
the
stopping
point
for
me
that
a
comment
that
I
made
is
like
I'm
torn
by
this
I
understand
what
you're
trying
to
do,
and
so,
but
things
like
Viper
solved
this
problem
in
much
cleaner,
more
general
way
and
I.
A
D
J
J
So
that's
that's
exactly
the
kind
of
problem
we
as
a
community
need
to
solve
in
some
way
like,
and
it
also
is
this
thing
with
instance
specific
like
Chile
instance
specific
stuff
have
its
own
config
file,
or
should
it
only
accesses
flags
or
whatever
so
yeah
I
I?
Think
it's
if
I'm
personally,
okay
with
this
and
I
kind
of
want
this
as
well
like
the
exact
code,
might
have
to
be
rewritten
a
little
or
or
like
polished,
but.
A
You
there's
just
one
I
think
the
next
topic
was
the
the
log
file
view.
It
was
originally
called
as
I
think
I
said
something
in
a
conversation
and
then
it
was
logged
in
the
issue
as
a
central
file,
but
it's
just
a
log
for
how
what
Coby
diem
does
for
the
different
operations
I
want
to
unblock
that
PR,
because
again,
I
was
reviewing
PRS
this
weekend.
So
I
want
to
get
that
unblocked
for
that
person,
but
I
know
that
live
Amir.
You
had
conversed
to
try
and
get
that
moving.
Oh.
B
Yeah,
so
it's
partially
our
fault,
because
we
had
a
discussion,
we
check
about
it
and
you
think
that
this
should
be
called
the
Center
for
bits.
It's
more
like
a
st.
enough,
how
it's
not
exactly
set
so
I
went
with
the
same
name
and
I
think
this
is
just
wrong.
Maybe
we
should
change
it,
but
I
guess.
The
question
here
is:
if
you're
not
gonna,
be
named
the
center
of
all.
How.
A
Think
just
a
comedian
that
log
file
seems
fine
and
it's
basically
a
log
of
the
operations
of
how
somebody
used
Covidien
I,
think
it's
useful
for
some
people
who
file
issues
to
be
able
to
submit
that
log
file
as
the
canonical
list
of
things
they
did
because
sometimes
when
they
log
issues,
they've
done
everything
they
can
think
of
and
by
the
time
they
log
the
issue.
We
don't
know
the
set
of
parameters,
that's
actually
been
specified.
We
only
get
a
subset
of
the
information.
That's
there.
A
B
B
E
E
A
You
can
also
explicitly
specify,
because
when
people
post
logs,
which
is
part
of
the
submission
template,
they
typically
sanitize
the
logs
of
the
information
that
they
care
about
and
those
logs
do
contain.
You
know
IP
at
or
information
as
well
as,
like
you
know,
host
endpoint
information,
bunch
of
other
stuff,
yeah.
E
That's
true,
it's
possible.
Maybe
we
could
have
a
just
like
a
scrubber
or
something
that
they
could
use.
That
removes
that
information
from
log
files,
but
I
think
asking
users
to
do
it
themselves
is
an
undue
burden,
especially
if,
like
you
said,
Tim
they've
run
two
or
three
dozen
commands
trying
to
figure
out
what
actually
works,
and
you
know
how
many
times
have
you
seen
somebody
post
their
private
key
on
github
because
they
didn't
quite
know
what
their
doing
and
we're
trying
to
get
help
troubleshooting
something
so.
A
E
B
So
something
else
about
this
Canadian
Walk
file,
so
some
commands
require
sudo
access.
So
if
you
write
to
the
work
file,
you're
writing
sensitive
data
also
to
the
work
file.
But
then
should
we
basically
make
this
file
accessible
to
everyone
like
everybody
outside
of
roads?
Can
they
see
it
still
see
the
log
file.
A
A
E
E
No
because
if
you
execute
a
command
with
sudo,
it
still
shows
up
in
the
in
the
user.
Who's
executed
its
bash
history,
no,
it
doesn't,
but
the
the
fact
that
you
executed
a
command
with
sudo
with
all
of
the
arguments
does,
unless
you
like
person
or
something
yes,.
B
E
B
E
E
Just
like
one
of
us
can
write
that
feature
and
we
will
like
we
can
merge
this
PR
now
and
then
somebody
else
can
write
the
the
filter.
If
we
don't
get
the
filter
written,
then
the
onus
is
on
the
user
to
sanitize
their
file,
which
is
not
ideal,
but
it's
I
think
it's
still
a
step
in
the
right
direction
and
we
can
try
to
get.
We
can
try
to
get
this
sanitization
done.
Yeah.
B
C
This
on
here
last
week,
because
right
before
the
meeting
I
was
getting
pinged
about
test
failures
and
I
was
just
looking
at
test
grade
and
I
can't
find
anything
under
sig
release
with
1.12
tests,
so
I
assume
that
they're
just
the
the
master
tests.
At
this
point,
the
master
branch
were
calling
1.12
alpha
and
there
were
some
tests
on
master
blocking
that
people
were
paying
me
about
I'm
Karen,
if
they've
been
fixed
since
last
week,
have
I
checked
this
yeah.
B
We'll
have
everything
fixed
I
submitted
a
couple
of
beers
and
also
I've
inked,
a
bunch
of
people
from
GC
qua
provider
to
help
it
some
other
work
and
I
think
everything
is
green.
We
only
have
one
flaky
tests
in
the
release
blocking
and
I.
Think
Tim
pepper
is
here.
He
can
probably
give
more
details
about
really
smoking
stuff.
I
C
B
B
G
G
So
the
work
so
far
has
been
around
making
sure
that
our
end-to-end
testing
and
all
the
other
pieces
that
we
have
I
are
able
to
support
the
architectures
right.
So
that's
the
first
step.
Previously
there
were
teams
working
on
s/390
and
power
which
had
hit
some
roadblocks.
So
we
are
at
a
point
where
we
are
unblocking
that
work.
So
now
we
have
to
go
back
to
those
teams
and
tell
them
look.
We
are
ready.
Now
you
can
start
trying
as
well.
G
Those
are
the
two
teams
that
are
interested
and
then
from
arm
there's
a
few
people
who
have
been
trying
to
use
so
no
boy
with
arm
so
so
we
can
hopefully
get
some
people
who
are
interested
in
arm
as
well
from
there.
So
those
are
the
three
architectures
that
I
know
of
for
sure
that
there
are
people
who
are
interested
in
trying
things
out.
G
But
what
I
don't
know
is
how
much
they
are
willing
to
work
on
on
setting
up
the
CI
system
and
then
publishing
results
tested
so
yeah
that,
and
once
we
have
that
in
place,
then
we
can
go
to
the
release
team
and
like
officially
make
them
release
blocking,
and
things
like
that.
So
at
this
point,
let's
get
the
base
infrastructure
ready
and
then
it's
up
to
people
who
come
to
do
the
work.
That's
where
we
are
right
now
we
are
almost
there.
G
We
have
four
PRS
that
are
open
right
now,
where
we
have
to
push
the
container
images,
and
then
we
have
to
fix
any
bugs
that
show
up
from
that.
And
after
that
we
are
good
I'm
hoping
to
get
this
work
done
this
week.
So
basically,
we'll
have
a
full
set
of
end-to-end
images
that
are
multi
are
capable,
but
then,
when
somebody
actually
tries
it,
then
we'll
know
if
there
are
any
bugs
in
there
yeah.
G
Or
they
might
see
like
a
stray
binary
somewhere,
which
is
still
MD
64,
and
then
we
have
to
go.
You
know
find
out
where
the
sources,
so
so
we
have
a
manifest
go.
The
first
attempt
is
to
make
sure
that
all
the
things
that
are
listed
there
are
supporting
multi
art
stuff.
Also.
The
related
thing
here
is
the
cube.
Api
server
and
container.
There
are
container
images
in
the
CI
system.
Those
are
actually
multi
arc.
G
At
this
point,
what
is
not
multi
arc
is
the
images
that
we
push
out,
that
I
used
by
end-users
when
we
do
a
milestone
or
a
final
release,
so
that
PR
is
still
pending,
I'm
hoping
to
get
some
people
to
look
at
that.
That's
been
pending
for
a
while
now,
but
I
don't
want
to
mess
with
any
of
the
releases
that
are
going
on
now
in
111
branch
or
110
branch,
or
anything
like
that,
so
I'm
holding
off
till.
G
B
B
A
I
think
it
would
be
great
if
we
could.
You
know,
maybe
at
some
points
during
the
off
kabhi
DM
office
hours
for
Caribbean,
specific
stuff
or
even
close
to
AP
I
could
do
separate
individual
things
of
where
they
want
help
and
I
think
following
up
on
it
would
be
really
useful
because
there
are
different
areas
that
I
think
are
languishing,
that
we.
It
would
be
nice
to
folks
who
are
interested
in
contributing
and
want
to
get
involved
to
have
that
well-defined
and
scoped
for
them
to
just
be
able
to
engage.
Oh.
A
I
think
the
last
thing
on
the
agenda
for
today
is
the
I
want
to
do
a
quick
PSA
that
we
sent
an
email
to
the
list
with
regards
to
the
clustering
API
in
the
AWS
implementation
for
cluster
API,
we're
gonna
weave
respect
out
the
repo,
and
we
want
to
start
committing
and
I
know.
There's
a
broader
coalition
of
folks
who
are
interested
in
getting
involved.
I'll
send
out
an
invite.
I
was
thinking
about
for
the
afternoon.
No
one
has
said
that
this
time
doesn't
work.
A
L
I
just
had
one
question
this
currently
one
issue
and
one
PR
in
the
repo
and
I
wondered
and
there's
also
a
design
doc,
which
is
not
linked
anywhere
in
the
repo
England
I
wondered
if
there's
any
other
background
information
people
might
want
to
have
before
that
meeting.
Just
come
come
with
your
laundry
list
of.
C
Tim
I
think
you
mentioned
something
at
the
very
beginning
about
the
the
Charter
which
is
always
spent
last
week.
Working
on.
Do
you
want
a
for
people
that
may
have
missed
the
meeting?
I
came
in
I
think
halfway
through
that
do
any
have
a
quick
update.
So
a
few
minutes
left
I
saw
that
Brian
left
a
bunch
of
comments.
Yesterday,
ok,
I,
don't
know
if
we
wanted
to
go
through
those
as
a
group
or
if
I
think
some
of
them
seemed
easy
to
fix
and
some
of
them
may
or
may
not
require
discussion.
I.
A
Haven't
taken
a
look
yet
on
Brian's
comments,
so
I
have
not
seen
it
yet
I'm
triage
the
backlog,
so
I
think
if
I
think
I
could
probably
fix
the
ones
that
are
easy
to
fix
and
maybe
loop
in
other
folks
who
are
already
on
the
issue.
I
think
everyone
who
had
heartaches
in
the
major
points
of
creating
the
doc
are
actually
already
looped
it
on
the
issue.
So
I
don't
know
if
we
need
to
discuss
broader
things
with
the
group
right
now
until
unless
there's
something
contentious,
I
haven't
looked
yet
so
I
don't
know.
A
Should
we
say
user
experiences
that
have
UX
to
avoid
jargon,
I
see
that
otoscope
second
below
but
I
prefer
to
make
the
this
more
specific.
If
possible,
there
aspects
of
user
experience.
Many
tasks
involve
cluster
administration.
I
think
this
is
just
vernacular
one
more
language
nit,
that's
easy
to
do
easy
to
do.
B
C
A
A
C
A
You
want,
if
there
are
things
that
you
think
are
worth
discussing
in
the
broader
context,
please
chime
in
on
the
PR.
It's
community
PR
number,
two
four
or
five
six
paste
it
and
send
the
select
channel
to
as
well.
C
M
A
M
G
Right
so
I
think
the
first
thing
that
we'll
target
is
making
sure
that
arm
only
cluster
will
fully
work,
for
example,
power
cluster
by
itself,
where
everything
soup-to-nuts
is
power,
works
fine
and
then
we
will
think
about.
The
next
step
would
be
to
think
about
the
mixed
clusters,
but
until
we
have
CI
systems
for
any
of
these,
we
cannot
say
that
we
support
anything
it's
up
to
them
to
free.
You
know
bigger
figure
out
what
works.