►
From YouTube: 2017-09-19 17.03.50 SIG-cluster-lifecycle 166836624
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
B
C
Yep
I'm,
just
a
gentle
reminder:
ok,
everyone
hearing.
First
of
all,
oh
cool
I'm
such
a
reminder
to
add
your
sig
omen
themes
for
the
1a
release
to
the
1:8
release,
notes
draft
as
possible.
It
just
just
sentences
one
a
brief
expository
text
on
what
the
sig
is
harder
to
do
and
then
another
substance
about
what
the
sig
I
was
focused
on
for
one
eighth
and
there
are
existing
examples
from
sig
node
signature
mutation,
speed,
auto
scaling.
Six
storage
has
a
PR
up
as
well
I.
D
E
A
B
Okay,
so
last
week
we
discussed
incubation
of
keeps
well
it's
potential
graduation
and
what
it
means
for
this
SIG,
because
this
is
this
thing
that
would
be
associated
with
any
installers,
and
so
some
months
ago,
caps
cops
passed
incubation,
which
is
amazing.
It
seems
that
there's
some
sort
of
roadblock
to
allowing
any
others
through
Brian
sent
a
mail
through
recently
saying
that
she
was
any
sort
of
incubation
now,
but
we
want
to
discuss
what
what
does
this
SIG's
role?
What
is
the
SIG's
roll
with
the
installers?
B
F
Yeah
yeah
just
unplug,
my
headset,
so
I
have
to
figure
out
how
to
switch
microphone.
Yeah
I
can
speak
to
two
so
first,
why
did
we
put
things
on
hold
a
good
vote?
You
should
an
email
will
go
out
imminently
if
it
hasn't
gone
out
already.
That's
what
I
was
doing.
The
past
few
minutes
is
reviewing
announcement.
F
The
vote
for
the
steering
committee
is
happening
now,
so
we
want
the
big
scrap.
Food
strapped
committee
wants
to
postpone
changes
of
policy
until
the
full
steering
committee
can
participate
and,
in
particular,
with
respect
to
the
incubation
process.
That's
become
clear
over
as
we
exercise
a
process
over
the
past
year
that
there
are
some
major
issues
with
it,
especially
recently.
So
we
are
gonna
have
to
I
think
change
the
process
to
it
fix
some
of
the
issues
around
how
decisions
actually
made
around
projects
entering
and
exiting
incubation.
F
So
we're
just
so
you
saying
that
we
want
to
do
that
with
a
full
steering
committee.
The
boat
will
close
in
a
couple
of
weeks,
so
it
shouldn't
be
tremendously
long.
So
that's
the
reason
for
the
freeze
so
with
respects
to
the
cluster
provisioning
and
bootstrap
tools.
Specifically,
we've
had
cube
up
in
the
kubernetes
repo
from
the
beginning
of
the
project.
That
was
mostly
a
matter
of
HBO's.
Everything
started
in
the
communities
repo
in
the
P
native
time,
including
talks
and
everything
else,
and
we've
been
steadily
moving
things
out
in
architectural
roadmap.
F
The
cluster
lifecycle
tools
fall
into
the
ecosystem,
as
we
definitely
expect
that
there
was
just
one
there
outside
of
communities
proper.
There
will
be,
you
know
different
ones
for
different
cloud
providers.
If
there's
a
service
like
containers
in
particular
work
as
your
container
service
things
like
that,
there
will
be
multiple
distributions
and
so
on.
F
However,
we
do
I
feel
that
there
needs
to
be
a
reference.
Implementation
of
at
least
one
set
of
tools
on
cube
ATM
was
designed
to
decouple
provisioning
and
bootstrapping
so
that
we
could
have
a
simple
bootstrapping
mechanism.
They
would
work
on
any
infrastructure
and
Canadian
itself
provides
kind
of
a
reference
implementation.
It's
not
necessarily
the
only.
F
You
know,
if
you
have
a
large
cluster,
you
need
to
automate
paths
if
you're,
especially
if
you
are
creating
our
cluster
on
a
cloud,
you
also
need
a
provisioning
solution
which
might
be
terraform
or
it
might
be
more
sophisticated
than
that.
So
I
think
there
will
be
a
spectrum
of
tools.
Ideally,
there
would
be
building
blocks
like
ebay,
diem,
but
possibly
other
things
as
well
that
these
tools
could
share.
One
could
imagine
building
a
stack
similar
to
kubernetes
itself,
for
example
that
has
a
declarative
API.
They
could
build
see.
F
Allies
and
URI
is
another
things
on
top
today.
The
situation
is
that
if
it's
CLI
based
is
probably
a
client
only
implementation,
its
UI
based
same
thing,
and
they
don't
share
a
lot
of
infrastructure.
So
I
think
there
is
space
for
consolidation
among
solutions.
That
said,
you
know
for
something
like
cops,
which
combines.
F
Provisioning
and
bootstrapping
and
more
sophisticated
lifecycle
management
operations
into
a
single
tool.
You
know
it
has
to
have
make
some
decisions
and
have
some
opinions
about
how
it
does
things
and
which
may
not
work
for
all
environments
like
in
particular,
immutable,
VM
images
and
distract
the
updates
versus
mutable
images
and
in
place.
F
Updates
is
kind
of
a
fundamental
decision
that
is
gonna,
be
different
in
different
environments
and
I
feel,
like
keep
spraying
cops,
make
different
decisions
there
and
that's
fine
cops
for
what
it's
worth
is
the
number
one
most
active,
kubernetes
sub
project
out
of
any
kind
of
sub
project
right.
So
there's
a
lot
of
activity,
there's
being
ported
to
multiple
cloud
providers.
F
Cuba
I
think
is
still
by
far
has
the
most
cloud
providers
that
has
been
ported
to,
but
we
need
to
get
rid
of
it.
It's
a
maintenance
nightmare
and
it
definitely
needs
to
come
out
of
the
communities
repo
regardless.
What
whether
it
continues
to
exist
in
some
form
and
would
be
useful
to
have
a
an
alternative
to
Lisbon
ported
to
several
different
cloud
providers
and
solves
the
provisioning
and
management
problems
beyond
what
qadian
does.
F
As
far
as
what
we
do
with
the
the
lifecycle
tools
going
forward,
we
need
to
have
something
at
minimum
that
we
can
use
to
run
into
and
tests.
So
Cuba
has
played
that
role
in
the
past.
It
will
not
play
that
role
forever.
It
has
to
get
removed
from
the
kubernetes
repo
s
get
removed
from
the
released
bundle
has
to
get
out
of
the
intuiting
test
frameworks,
but
we
are
going
to
need
something
that
can
create
clusters
and
perform
management
operations
for
in
to
entice
for
upgrade
test
for
little
back
tests
and
so
on.
F
G
G
Have
graduated
from
incubation
via
sub-project
I'd
like
to
you,
know
to
break
that
assumption
I
mean
there's
things
to
be
active
parts
of
the
community
without
being
an
official
kubernetes
sub
project.
So
there
shouldn't
be
this
rush
to
really
get
things
through
the
incubation
process
so
that
so
that
they
can
be
official.
There
is
no
mark
of
official
'no
stare,
there's
history
that
we're
gonna
have
to
deal
with.
Here
I
mean
there
are
places
where
you
know.
G
Decisions
were
made
on
the
past
in
terms
of
sub
projects
and
there's
some
questions
and
some
clarity
that
needs
to
be
brought
there
in
terms
of
what
are
the
rights
to
those
projects.
So
that's
an
ongoing
process.
That's
going
to
take
the
steering
committee
to
actually
get
that
stuff
figured
out.
Yeah.
F
If
you
look,
there's
a
backlog
and
the
steering
repo
of
things,
the
steering
committee
needs
to
decide
on,
and
there
are
a
number
of
issues
that
relate
to
this.
For
example,
how
do
we
manage
sub
projects
that
are
significantly
different
from
the
the
kubernetes
kubernetes
repo
aren't
included
in
the
release?
Bundle
have
different
development
processes.
G
I'm
I'm
I'm
there
are
a
certain
set
of
requirements
for
a
project
to
be
successful
for
any
users
to
manage
a
cluster
over
the
lifetime
of
that
cluster
and
there's
a
certain
set
of
requirements
for
a
cluster
that
we're
going
to
really
probe
in
depth.
For
like
any
test,
where
we'll
do
a
bunch
of
really
nasty
things
to
inject
faults
and
stuff
like
that
and
and
the
number
of
options
and
sort
of
tweaks
in
the
way
that
those
things
get
tweaked.
G
As
we've
seen
sort
of
cube
up
sort
of
mutate
over
time
and
collect
more
and
more
options.
I
I'm
not
sure
that
that
those
set
of
requires
between
sort
of
something
to
replace
cube
up
friend
and
test,
and
something
that's
going
to
be
sort
of
really
useful
for
end
users.
I'm,
not
sure
that
a
single
system
can
actually
meet
both
of
those
needs.
I
think.
H
G
B
With
that
really
go,
yes,
that's
one
of
the
I
would
most
people
would
regard
the
downsides.
To
cube
spray
is
that
there
are
actually
hundreds
of
configurable
options
like
setting
CPU
limits
and
requests
and
image
tags
and
paths
for
every
single
command
is
an
option,
but
the
majority
you
don't
need
to
change
so
keeping
it
flexible,
but
trying
to
minimize
how
big
that
you
know
master
configurable
options
are
the
one
that
users
are
more
likely
to
change,
keeping
that
down
as
one
of
our
goals,
but
really
everything
is
quite
flexible.
G
B
F
B
G
And
and
again
it's
going
to
be
one
of
these
things
where
every
time
where
we
we
end
up
in
a
situation
where
there's
multiple
vendor
choices,
we
hit
this
situation
where
we
don't
want
to
pick
winner
and
that's
just
sort
of
the
nature
of
the
open-source
project.
If
you
go
through
the
guides
for
using
which
network
with
cube
admin,
you'll
see
that
there
are
pains
to
make
sure
that
it's
relatively,
even
though,
like
Luke
here,
works
for
leave
and
has
done
a
ton
of
work
to
get
cube.
G
D
E
F
And
describe
how
you
do
it
manually
and
then
kind
of
characterize
this
base
of
solutions
and
identify
solutions
that
make
sense
in
terms
of
directions
like
we
think
it
makes
sense
to
have
a
tool
that
does
it
this
way
in
a
tool?
Does
it
that
way
and
work
with
sig
testing
on
you
know
whether
those
end
user
tools
meet
the
needs
of
Lind.
B
One
comment
regarding
what
she
said
about
what
installers
should
do
that
was.
This
is
a
topic
of
the
first
sig
cluster
cycle
meeting
and
that
that
topic
was
basically
shelves
forever
because
cube
idiom
took
the
forefront,
so
that
kind
of
says
no,
the
present
part
all
install.
It
was
really
into
use
queue,
media
other.
Then,
let's
make
a
list,
maybe
pull
that
that
this
big
switch
back
to
that
team,
but
it
hasn't
and
then.
E
I
E
F
Then
operations
like
updating
a
node,
rolling
back
a
node,
getting
the
master
rolling
back
a
master
updating,
add-ons
rolling
back
out
on
whatever
those
things
will
be
tested,
and
so,
if
you
use
that
as
a
building
block,
you
know
at
least
know
that
what
you're
doing
has
more
robust
testing
like
I,
can't
tell
tell
you
how
many
issues
that
are
uncovered
just
because
the
sheer
volume
of
tests
that
we
run,
we
run
thousands
and
thousands
of
tests
a
day
that
exposes
issues
that
lighter
amounts
of
testing.
Just
don't
expose.
B
F
B
F
I
think
it
depends
on
what
you
mean
by
endorse,
though
right
like
having
a
project
under
under
kubernetes
like
a
dashboard.
Let's
look
at
the
kubernetes
dashboard.
It
is
a
kubernetes
project.
It
is
has
people
from
multiple
companies
in
the
community
working
on
it
it,
but
is
it
endorsed?
I
mean
it's.
There
are
lots
of
community
services
and
distributions
that
don't
run
the
dashboard.
They
have
their
own
you
eyes,
so
it
and
and
I'll
give
you
an
example.
I
think
I'm,
uncomfortable
I.
G
Think
one
of
the
things
that
I
want
to
figure
out
is
we
actually
sort
of
you
know
unfreeze.
The
the
incubation
sub
project
is
is
how
can
the
kubernetes
name
and
how
does
being
a
sub
project?
How
can
that
be
communicated
to
users
right
now,
helm,
for
example,
bills
itself,
as
the
kubernetes
package
manager?
G
G
Okay,
but
maybe
that's
do
we?
Let
people
say
that,
like
if
they're
a
sub-project,
they
are
the
solution
in
that
space.
I,
don't
think
that
we're
gonna
get
to
the
point
where
we
have.
This
is
the
kubernetes
installer
I
just
cards
and
I.
Don't
think
that
that's
a
good
thing
for
the
for
the
community.
Now,
that
being
said,
that's
a
discussion
for
the
steering
committee
to
have
once
it's
actually
in
and
we
can
actually
understand
and
sort
of
really.
You
think
that
the
outlines
of
what
some
projects
and
the
incubation
project
means.
G
E
I
think
the
the
responsibilities
part
is
important
that
you
touched
on,
because
I
think
that
sort
of
the
benefits
you
get
from
being
sort
of
in
the
official
kubernetes
space.
There
presumably
has
to
come
some
sort
of
responsibilities
for
maintaining
your
project,
maybe
in
some
sort
of
consistent
way
with
the
other
set
of
projects.
You
know,
hopefully,
to
be
defined
by
the
steering
committee
that
some
people
aren't
aren't
gonna
want
to
follow
those
processes
and
are
gonna
want
to
be.
You
know,
sort
of
stuck
in
that
in
that
project,
space
right,
yeah,.
F
Like
just
as
one
example,
there
is
no
consistent
place
where
sub
projects
push
their
releases,
so
the
kubernetes
kubernetes
release
lists
are
pushed
to
one
particular
place
by
other
I.
Did
a
quick
survey
of
a
few
some
projects
and
like
literally
no
two
of
them
push
their
releases
the
same
place.
So
that's
probably
not
awesome
for
people
for
use
these
things
up
and
and
determine
whether
they
are
legitimate
and
up-to-date,
and
things
like
that.
We
want
some
kind
of
policies
around
that
sort
of
thing
and
you.
G
Know
another
issue
that
I
want
to
attack
as
part
of
this
is
there
are
people,
including
the
CNC
F,
that
put
together
sort
of
participation,
statistics
where
this
company
is
participate
in
these
developers
and
all
this
stuff
as
we
move
to
a
multi
repo
thing
which
repos
are
actually
included
in
those
statistics,
you
know
how
do
we,
how
do
we
identify
which
of
those
reposts,
because
it's
more
than
just
kubernetes
kubernetes?
But
you
know
we
have
projects
that
are
significantly
different,
have
different
sort
of
ways
of
doing
business.
G
E
F
E
B
B
B
A
D
What
you
see
here
is
just
a
well-defined
process
right
for
for
when
you
know
just
a
simple
workflow
that
says
when
you
should
go
through
graduation
from
incubation
graduation
and
when
you
should
protect
actually
glom
on
to
some
other
process
that
allows
you
to
be
notified
by
the
community
that
says
you're
part
of
the
community.
Here's
where
you
can
go
and
find
the
vets
etc.
D
F
So,
just
as
an
example
in
the
incubation
process,
there's
no
clear
process
about
what
to
do.
If
somebody
disagrees
like
completely
documented
and
unclear,
so
we're
gonna
have
to
resolve
those
kinds
of
issues
like
what
does
it
mean
to
actually
graduate
from
incubation?
How
does
it
work?
How?
How
is
the
decision
made?
F
There
was
a
question
in
the
chat:
why
not
graduates
to
become
a
CNC
project,
so
as
a
member
of
the,
since
you
have
technical,
Oversight,
Committee
and
one
of
the
primary
decision-makers
in
terms
of
what
projects
get
instance,
yes,
and
not
my
position
and
I,
think
the
position
of
other
accusing
members
is
that
CN
CF
projects
are
intended
to
be
broadly
useful
in
the
cloud
native
space
not
tightly
coupled
to
kubernetes,
specifically
so
I
don't
think
there
is
a
home
for
smaller
projects
for
canary
specific
projects
in
this
yeah.
That's
not
really.
F
What
we're
looking
for
is
not
a
good
fit.
I
do
think
that
the
kubernetes
project
itself
does
need
to
have
a
home
for
ecosystem
projects,
because
it's
not
really
the
right
place
to
discuss
that
the
steering
committee
will
be
taking
up
that
issue,
but
just
as
a
comparison,
if
you
look
at
no
just
the
node.js
foundation
was
originally
designed
to
take
in
more
projects
than
just
no
GS
and
practice.
F
They
only
took
one
which
was
Express
and
otherwise
they
decided
they
didn't
want
to
take
any
more
projects,
so
other
projects
that
build
in
the
users,
based
on
top
of
no
GS,
get
punted
to
the
JavaScript
foundation
right.
So
there's
another
foundation
where
those
projects
that
want
a
neutral
home
can
land
it's
kind
of
awkward.
It's
not
a
great
either,
but
at
least
that's
the
workable
solution.
We
don't
really
have
that
alternative
here.
So
you
know.
F
D
F
E
Will
put
one
copy
out
that
no,
both
Brian
and
or
Joe
we're
saying
that
we'd
like
to
sort
of
shrink
the
number
of
some
sort
of
installers
to
list
on
our
page
and
I
think
that
as
a
sig,
we
can
set
up
criteria?
You
know
things
like
you
know
to
be
listed
on
that
page.
You
should
have
a
link
to
test
grid
where
we
can
all
look
and
see
that
you're,
a
passing
conformance
tests
and
you're
passing
operate
tests
I.
D
F
So
one
big
problem
we
had
for
a
long
time,
even
just
with
Cuba-
is
that
people
who
contributed
port
of
Cuba
to
other
platforms
do
not
keep
it
up-to-date
right.
So
we
had
this
big
table
in
markdown
and
in
kubernetes
repo,
and
there
were
some
that,
like
never
got
updated
toss
1.2,
there's
some
cases
that
states.
G
A
And
I
think,
some
time
ago
we
we
specifically
proposed
that
we
were
going
to
do
a
sort
of
sweep
of
all
of
the
tools
out
there
and
ping
the
maintainer
x'.
If
we
could
identify
who
they
were
and
say
if
your
tool
doesn't
support,
I
think
we
said
we
were
gonna
say:
if
your
tool
doesn't
support
upgrades,
then
we're
gonna,
take
it
off
the
list
and
I
think.
F
D
D
A
Okay,
so
that's
the
first
thing,
the
other
thing
I
just
wanted
to
mention
so
Brian
I
think
you
you.
You
brought
up
this
idea
of
kubernetes.
The
hard
way
have
the
responsibility
of
the
sig
I.
Do
think
that
we
have
something
that's
kind
of
going
to
be
close
to
that
I
just
wanted
to
mention,
which
is
the
documentation
for
the
q
ADM
phases,
work,
which
is
one
of
Lucas's
sort
of
ongoing
projects.
A
I
think
that
good
documentation
on
what
all
the
different
phases
are
for
the
cube,
ADM
phases
that
document
the
inputs
and
the
outputs
of
each
phase
more
or
less
add
up
to
a
sort
of
kubernetes
the
hardware
document
them
as
in
you
can
either
run
this
cube.
Adm
command,
Thank,
You,
Betty,
M,
phase
command
or
you
could
go
and
do
this
like
blah
blah
blah
document.
What
you
would
actually
have
to
do
on
the
system.
F
F
But
one
example
that
I
has
think
has
been
reasonably
successful
is
with
the
release
team,
where
we
define
specific
roles
that
need
to
be
taken
on
and
we
make
sure
that
those
roles
get
filled
and
we
ask
for
help
until
they
get
filled
right.
So
I
think
if
this
sig
could
also
identify.
These
are
the
responsibilities
of
the
sig.
F
This
is
something
that
does
steering
kameez
going
to
ask
to
be
put
into
the
charter
of
the
sig
once
we
have
kind
of
a
draft
of
what
we
want
to
see
in
a
charter,
but
expect
this
to
be
coming.
What
is
the
scope
of
what
the
sig
is
responsible
for
and
what
specific
things
are,
the
responsible
for
to
find
some
roles
around
those
responsibilities
and,
if
you
don't
have
people
to
fill
those
roles,
please
surface
that
to
the
broader
community.
F
Another
another
thing
you
know
related
to
previous
discussion:
I,
we
are
going
to
need
an
official
notion
of
sub
project,
just
as
an
example.
You
know
this
obviously
has
qadian
cops
and
other
installers
and
add-ons
and
component
take
and
whatever
else,
but
like
Signet
work.
Big
signal
work
is
an
example.
There's
pod
networking
in
network
policy
and
ingress
and
dns,
and
probably
other
things
that
I'm
forgetting
right,
but
lots
of
safes
have
multiple
sub
projects,
sometimes
overlapping
sets
that
people
work
on
them,
sometimes
not
I,
think
it
would
be
help.
F
Everyone
in
the
project
understand
what's
going
on.
If
you
have
a
better
defined
notion
of
what
the
sub
projects
are
good
Lisa,
those
sub
projects
are,
and
so
on.
So
you
know,
whereas
keep
spray
and
cops
in
qadian
seem
like
very
distinct
projects.
Other
SIG's
don't
have
as
distinct
sub
projects.
Yet
that
is
something
we're
gonna
have
to
do
is
make
sure
every
part
of
the
project.
The
broader
project
falls
under
the
responsibility
of
some
sig
and
specifically
some
sub
project
about
C.
F
So
do
you
think
about
like
what
other
sub
projects
are
under
the
umbrella
or
should
be
under
the
umbrella
cluster
life
cycle
as
well
like
just
as
one
example
that
may
not
have
occurred?
T
Minnie
Q
is
a
basically
flavor
of
cluster
installer
and
lifecycle
manager.
I
haven't
really
thought
of
a
better
sig
in
cluster
lifecycle
for
Minnie
cube
to
Landon
pretty
much.
It's
been
run
autonomously
kind
of
disjoint
from
everything
else.
F
G
B
F
F
J
F
G
Think
the
biggest
issue
I
mean
like
it's
a
great
it's
another
great
example
of
a
place
where
the
releases
don't
go
to
the
same
place.
It's
not
we're.
Not
testing
mini
cube
on
every
like
we're.
Not
I
can't
do
a
mini
queue
of
the
Lydia
stable
right
I
mean
like
it
seems
like
the
the
update
mechanisms,
for
that
are
pretty.
D
Just
want
to
be
kind
of
going
in
a
circle
here
and
a
couple
different
like
where
these
projects
will
land
and
governance
and
other
policies
I.
Think
at
this
point,
we've
pretty
much
punted
on
making
a
decision
other
than
documentation
which
we
group
on
I
are
there
other
agenda
topics
that
we
wanted
to
discuss
today.
I
just
want
to
see
if
there
are
other
things
on
the
list
that
we
wanted
to
get
to
I.
D
E
E
Simona
call
I
poked
Jeff
Grafton
about
this
a
couple
of
days
ago,
and
you
said
that
this
was
not
a
release.
Blocker
4.8,
but
at
some
point
we'll
have
to
back
port
the
fix
because
g-cloud
keeps
making
backwards.
Compatible
changes
in
braking
art
exhibition
sure
as
a
result,
so
I'm
not
sure
what
you
want
to
discuss
about
it.
Jeff
said
that
it
was
going
to
be
worked
on,
but
it's
not
urgent.
D
D
A
A
E
That
at
the
burned-out
meeting
they
linked
to
the
open
issues
for
the
1.8
milestone
and
say
that
all
of
them
are
blocking
to
release
at
this
point,
regardless
of
what
the
priority
label
is
on
them.
There
are
currently
two
for
our
sig.
One
is
the
one
that
Jason
linked
to
which
I,
don't
believe
is
blocking
that
one
8
release,
so
I
think
we
will
just
kick
that
out
of
the
milestone.
The
second
one
is
Lucas's
cube
admin,
1
8,
release
tracking
issue,
which
is
just
sort
of
our.
D
I
think
we
should
probably
send
out
a
general
PSA
for
people
to
help
review,
because,
although
we
are
writing
Docs,
what
typically
has
a
tendency
to
happen
is
we
do
a
quick
turnkey
shortly
after
the
release,
because
it
you
know
we
either
we
miss
something
or
it
wasn't
caught,
and
so
you
know
after
we
know
at
the
door.
So
if
we
want
to
do
like
an
early
PSA
announcement
to
something
something
to
the
effect
like
you
know,
we
have
updated
Docs,
we
have
everything
in
place.
Could
you
please
take
a
walk
through
it.
A
What's
really
helpful
to
have
in
those
sort
of
updates
or
requests
is
whatever
special
instructions
you
need
to
try.
The
latest
like
are
see.
What's
the
current
status
on
our
C's,
for
one
eight
I
mean
we
is
there
a
nearly
final
version
that
you
can
install
using
the
latest
cube,
ADM
or
I.