►
From YouTube: 2020-08-20 CAPZ Office hours
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
Cool
hello,
everybody
and
thanks
for
attending
the
bi-weekly
cluster
api
provider
for
azure
meeting,
which
is
also
known
as
capsi
office
hours.
This
meeting
is
being
recorded
and
we
will
post
it
to
our
youtube.
Playlist.
A
I'm
sharing
the
screen,
but
let
me
post
a
link
and
zoom
here
to
the
meeting
agenda
as
well.
Oh
boy,
if
I
can
figure
out
how
to
do
that,
I
can
do
it
better.
Oh
thanks!
It's
it's
yeah!
Anyway.
What
else
this
is
a
kubernetes
community
meeting.
So
please
abide
by
the
code
of
conduct.
A
We
have
a
link
to
it
in
the
document
there,
but
basically
it
boils
down
to
try
not
to
interrupt
each
other.
Try
to
be
kind.
A
We
try
to
raise
hands
here
rather
than
talk
over
each
other,
although
it's
probably
not
going
to
be
a
big
issue
with
only
a
few
of
us
here,
cool-
and
please
add
your
name
to
the
attendees
section
in
the
meeting
agenda
notes
document
just
so
we
have
a
record
of
who
is
here.
A
A
B
Yeah,
just
an
fyi,
the
next
release
of
cluster
api,
zero,
three
nine,
which
is,
I
think,
coming
out
in
the
next
week
or
two:
it's
gonna
have
a
new
version
of
start
manager.
There
was
a
pr
that
I
think
is
getting
commerce
today
or
is
it
about
to
was
approved
or
something
there's
a
link
with
the
pr
I
it's
not
supposed
to
make
any
difference
to
us.
I
don't
think,
but.
A
C
It's
in
tilt,
it's
it's
in
a
few
places
yeah
that
kind
of
brings
up
a
kind
of
corollary
to
that
is
like
it
would
be
really
awesome.
Maybe
if,
like
we
had
like
a
versions
file
or
something
so
that,
like
I,
I've
seen
a
few
pr's
come
through,
where
we
update
a
version
of
some
some
dependency
that
isn't
like
a
godapp
and
then
we
have
to
you
know,
change
it
up
in
a
few
places,
particularly
like
cappy
dependencies
stuff,
like
that
yeah.
That
makes.
B
D
D
B
A
A
Good
cool
thanks
for
taking
notes,
cecile
the
next
one
is
just
something
lazy
I
put
in
so
maybe
we
should
do
the
capsi
roadmap
dock
first.
D
We
kind
of
like
started
planning
the
milestones
like
a
month
ahead
of
time,
and
so
that's
a
good
thing
for
us
as
developers
to
like
see
what
things
we
commit
to
in
the
next
month
and
what
should
be
like
higher
priority,
but
it
doesn't
really
give
a
good
overview
to
people
coming
into
the
repo
who
are
new
and
are
wondering
like
when,
when
can
I
expect
to
see
this
feature
coming,
and
so
I
think,
having
milestones
ahead
of
time
might
be
a
bit
more
overheads,
but
maybe
we
can
try
something
like
cappy's
doing,
which
is
having
a
roadmap
document
and
the
roadmap
docs
kind
of
release
less
per
quarter.
D
What
we
expect
to
get
done
and
the
things
that
are
like
on
our
backlog
and
mostly
like
big
features,
not
not
so
much
like
bug,
fixes
or
development
improvements,
just
like
the
features
that
would
be
relevant
to
users.
So
I
guess
this
was
more
like
a
question:
does
anyone
have
thoughts
on
the
format
of
that?
Like
does
a
roman
document,
sound
good?
Does
anyone
have
any
reasons
why
they
think
we
should
do
milestones
instead
or
any
other
ideas
of
how
we
could
do
this.
C
Is
this
perhaps
a
I'm
sorry,
I
should
have
raised
my
hand,
but
is
this
perhaps
a
artifact
of
our
like
issues
not
being
feature
focused
enough
like
if
we
were,
if
we
really
had
features
in
issues
or
maybe
something
was
a
little
bit
more
consumable,
would
that
be
enough
for
milestones
or
do
we
really
actually
need
to
show
something
more
like
a
longer
focus
like
multiple
quarter
kind
of
road
map.
B
I
put
in
the
chat
an
example
of
what
the
post
copy
one
is
for
me.
I
think
it
would
be
nice
to
just
like
see
what
kind
of
the
thinking
or
what
is
an
important
thing
if
or
for
somebody
coming
in
and
like
not
sure
what
to
work
on.
If
everything
in
the
milestone
is
already
kind
of
is
in
progress,
it'll
be
nice
to
have
an
idea
of
what
the
future
is.
It's
not
like
a
must-have,
it's
just
a
place.
D
I'm
sorry,
I
think,
the
sorry,
I
think
the
difference
between
the
issues
in
the
repo
like
in
the
issue
list
and
having
this
would
be
more.
The
timing,
because
issues
tell
you
what
they
don't
tell
you
when
and
so.
Unless
we
started
like
having,
we
could
also
have
labels
on
issues
like
q1
2020,
or
I
mean
q4,
2020,
q1,
2021
and
like
label
them.
D
That
also
works,
and
I
think
that
actually
is
better
in
terms
of
like
keeping
things
up
to
date,
because
I've
seen
like
the
document
in
cappy
getting
out
of
date
really
quickly
when
things
change
in
the
repo.
But
we
forget
to
update
the
doc.
But
at
the
same
time
the
dock
is
maybe
more
user-friendly
because
they
can
just
land
on
it
and
read
it
and
not
have
to
go
through
issues.
C
B
D
Yeah,
I
guess
the
idea
was
just
to
be
more
broad
and
just
say
like:
oh,
we
expect
windows
notes
to
land
in
q1
2021.
You
know
things
like
that,
but
not
like
every
single
thing
that
we're
going
to
work
on,
and
I
guess
the
risk
of
doing
milestone
planning
is
that
then
we
end
up
having
to
triage
smaller
ones.
That
aren't
necessarily,
you
know
relevant
to
someone
who
just
wants
to
know.
When
is
this
feature
gonna
land.
A
C
Yeah,
I
I
agree
the
I
think
what
we're
actually
leading
towards
is
what
are
the
things
that
are
big
enough,
boulders
that
we
should
put
into
this
backlog
like
some
of
the
smaller
like
features
and
issues
and
stuff
like
that.
Those
are
great
in
the
milestones.
But
when
we're
talking
about
like
these
bigger
things
like
like
what
just
said,
when
is
windows,
support
going
to
land,
there's
tons
of
like
dependent,
probably
like
dozens
of
little
features,
that
will
probably
come
in
as
part
of
that
across
multiple
projects.
C
So
what
does
that
big?
Boulder
look
like?
Maybe
this
is
like
an
indication
of
when
things
start
in
proposal
form
and
when
they
intend
on
landing
and
when
what
their
progression
looks
like.
So,
in
our
proposals
we
often
will
put
in
there.
You
know
this
thing's
gonna
start
off
in
experimental
after
a
couple
releases.
C
We
want
it
to
land
into
ga
eventually
or
we
want
this
to
be
a
released
feature
in
this
release
and
we're
targeting
kind
of
this
quarter
or
this
this
this
month,
or
I
don't
know
what
the
date
is,
but
it's
a
big
enough
chunk
that
it's
going
to
you
know
we're
projecting
it
out
and
we
thought
it
was
impactful
enough
to
have
a
proposal
for
it.
Perhaps
that's
that's
kind
of
an
indicator
for
us.
I
don't
know
what
it
would.
What
do
folks
think.
D
For
that
doesn't
mean
it
has
to
continue
like
that,
but
it
doesn't
to
me
it
doesn't
really
matter
the
format
of
how
it's
communicated
as
long
as
the
what
is
timing
of
bigger
chunks
of
features,
and
so
we
could
do
milestones
and
just
try
to
focus
on
the
ones
that
are
like
stories
and
try
to
like
really
keep
it
to
like
bigger
features,
or
we
could
do
a
document
and
duplicate
that
information.
Like
those
issue,
titles
into
a
doc.
C
I
kind
of
like
the
dock,
though
the
more
the
more
we
talk
about
it,
the
more
it
makes
it
consumable
like
it's
more
targeted
for
maybe
not
technical
consumption,
but
more
just
informational.
Like
I
mean
I'm
a
cons,
I'm
a
user
of
this,
not
necessarily
a
contributor,
not
a
maintainer,
I'm
a
user,
and
I
want
to
have
something
easily
digested
so
that
I
can
tell
like.
Maybe
you
know
my
product
team,
you
know
we
can.
A
Does
that
make
sense
like
more
user
focused,
it
totally
does
and
that's
really
how
cecile
introduced
this
whole
thing
was
someone
coming
into
the
project
who's?
Not
you
know
who's,
just
a
user
or
doesn't
isn't
familiar
with.
It
needs
a
document.
So
I
think,
I
think,
having
a
simplified
doc
is
really
should
be.
The
focus.
D
A
Oh
yeah
there's
a
hot
key
for
muting
yourself
on
teams.
It's
not
the
same
one
as
zoom
now
I
know
both
of
them.
Sorry
yeah.
So
I
just
kind
of
put
this
in
lazily
because
I'm
assuming
my
assumption
is
always
you
guys
are
more
plugged
into
kubecon,
and
things
like
that
than
I
am
so,
and
I
know
cecile
gave
a
talk
yesterday
with
nadir.
A
So
anyway,
is
there
anything
other
talks?
We
should
go
back
and
watch.
Is
there
any
news
that
came
out?
I'm
just
curious.
D
So
from
what
I
know
there
are
so
there
are
two
cluster
api
talks,
there's
one
that
kd
from
american
express
gave.
That
was
two
days
ago,
and
hers
is
more
from
the
perspective
of
a
user.
So
it's
really
interesting.
So
I
recommend
watching
that
it
does
cover
a
lot
of
the
basics,
so
there
is
some
overlap
with
the
one
that
nader
and
I
gave
as
part
of
the
maintainer
track,
and
so
that
one
is
more
like
how
to
contribute
and
here's
how
the
basics
of
the
project
work.
D
So
I
think
both
are
good
introductory
talks,
but
then
the
american
express
one
is
more
like
user
focus
and
then
the
one
we
did
is
more
like
maintainer
focused
and
then
I
know
the
windows
folks
also
talked
briefly
I'm
I
haven't
watched
it
yet,
but
in
the
description
I
talked
about
cluster
api,
so
I'm
not
really
sure
that
might
be
interesting
to
watch.
That's
something
I'm
gonna
watch
for
sure.
I
don't
know
if
anyone
else
has
any
suggestions.
B
I
noticed
there
was
one
earlier
this
morning
I
haven't
seen
about
azure
cloud
provider
like
a
deep
dive
or
something,
but
it
was
like
super
early
in
the
morning.
So
I
was
like
planning
to
check
it.
C
D
C
So,
since
all
right,
so
I
started
working
on
a
pr
to
add
some
machine
pool
support
to
the
test
framework
in
capi.
C
Part
of
this
work
is
to
help
us
to
be
able
to
test
machine
pools
and
to
end
in
cap
c.
Hopefully
this
will.
This
will
help
others
to
test
machine
pools
as
well
part
of
this
work.
I
think
I'm
gonna
end
up
having
to
build
machine
pool
support
into
the
docker
infrastructure
provider.
C
Does
anybody
know
of
any
ongoing
work
there,
or
is
this
something
that
just
hasn't
come
up?
I'm
just
I'm
just
curious
before
I
go
diving
in
and,
like
start
writing
stuff,
I
was
just
curious
if
anybody
had
any.
C
Has
anyone
built
anything
into
the
docker
infrastructure
provider
like
basically
I'm?
I
think,
I'm
going
to
go?
Add
machine
pool
support
into
the
infrastructure
provider
so
that
we
can
see
end-to-end
tests
passing
in
cabi
for
machine
pools.
I
I
think
this
will
be
a
major
part
of
getting
machine
pools
out
of
experimental
and
then
also
helping
others
to
know
that
the
end-to-end
tests
pass
for
machine
pool.
D
So
I
was
actually
thinking
about
that
recently,
and
I
was
wondering:
is
that
possible,
because
machine
pool
relies
on
the
fact
that
the
infrastructure
provider
has
a
native
support
for,
like
a
scaling
group
type
object
right.
So
how
are
you
gonna
like
simulate
that
with
docker?
What's
the
abstraction.
C
Cool,
so
no,
I
I
don't
think
anything
like
that
needs
to
actually
happen.
So,
if
you
look
at
like
the
the
docker
infrastructure
object
behind
it
like
it's
just
creating
a
docker
machine
like
it's
just
a
node,
that's
running
right!
So
what
if
like
when
the
machine
pool
like
the
docker
machine
pool
gets
created?
It
just
says
all
right:
hey
I'm
gonna
go
say:
go
create
me
these
two
replicas
that
I
want,
because
it's
really
just
a
machine
deployment.
So
behind
the
scenes
it
could
just
know
itself
hey.
C
This
is
where
my
docker
machines
are
and
I'm
okay
with
it.
So
we
could
go
as
far
as
to
create
a
docker
machine
infrastructure.
Customer
resources.
If
we
wanted
to
model
them
as
machines
and
have
the
machine
pool
controller,
be
be
aware
of
these
machines
and
track
them
or
we
could
just
have
the
machine
pool
controller,
create
the
docker
machines
and
just
keep
a
reference
to
them.
C
C
Should
these
these
actually
be
modeled
as
machines
under
the
covers,
or
should
they
actually
be
modeled
as
a
machine
pool?
So
I
don't
know
that
that's
kind
of
to
me
that
feels
like
uneven
ground
and
I'm
not
exactly
sure
how
to
tread.
D
On
yeah,
I
think
easy
way
sounds
good.
I'd,
probably
mention
it
to
fabrizio
before
starting
that
work
in
case.
There
are
big
objections
to
that,
because
I
know
he's
like
he's
done.
D
A
lot
of
work
in
the
end-to-end
test
framework
he's
usually
my
go-to
person
when
I
have
framework
questions,
but
I
think
the
talk
about
having
machines
represent
like
missionable
instances
is
maybe
a
bigger
discussion,
and
I
don't
think
we
should
block
end-to-end
tests
on
that,
because
end-to-end
test
is
pretty
critical
for
getting
machine
pull
out
of
alpha
or
out
of
experimental.
D
A
A
If
no
one
else
has
anything,
I
guess
I
wanted
to
talk
really
briefly
or
ask
for
ideas
about
the
e2e
test.
So
we
you
know,
we
I'm
sure
you're
aware
we
disabled
the
part
of
the
elb
test,
which
is
really
the
most
important
part.
A
Can
I
connect
to
the
service
externally
because
it
was
failing
consistently
and
we
had
so
many
pr's
waiting
to
make
it
through
the
queue
that
we're
passing
on
everything,
but
that
test
that
we
went
ahead
and
tucked
our
tail
between
our
legs
and
hid
the
test,
and
so
I've
been
trying
to
figure
out
what
was
going
wrong
and
I'm
just
unable
to
reproduce
it.
It
succeeds
locally
all
the
time
which
is
very
strange
and
it
succeeds
in
our
ci
systems.
A
Sometimes
we
saw
yesterday
it
succeeded
once
and
failed
once
on
the
same
pr,
so
I'm
just
throwing
things
at
the
wall
trying
to
extend
the
logging
as
much
as
possible
so
that
when
it
fails
in
our
ci
system,
I
get
some
clues
to
what's
going
on
and
I
have
a
change
I'm
putting
out
there
now,
but
short
of
that
it
seems
like
it
may
be.
An
environmental
difference
between
the
way
I
run
things
locally
and
what
we
do
in
ci,
and
so
basically
I
just
want
to
update
you
with
that.
A
I
am
working
on
it.
I'm
scratching
my
head
because
I'm
not
able
to
reproduce
it
and
I'm
curious
if
anybody
has
any.
A
C
Hey,
I
I
really
like
that:
you're
adding
a
bunch
of
logging
to
it.
We
need
to
be
able
to
diagnose
these
things,
we're
going
to
come
across
more
flaky
issues
like
this,
and
if
we
don't
have
the
laws
to
do
to
diagnose
it,
it's
we're
going
to
be
useless
right.
So,
if
there's
that
that's
a
ton
of
value,
so
you
mention
it
as
in
it,
it
was
kind
of
like
you
know.
You
were
just
throwing
stuff
at
the
wall
and
extending
walking,
but
that
is
huge.
C
A
Yeah
yeah
I,
but
I
actually
meant
the
relative
to
the
logging.
That's
in
there
right
now,
I'm
throwing
stuff
at
the
wall
and
current
vr.
Also
I
found
there
was
a
bit
of
an
issue
with
closure
nesting.
So
the
thing
that
we're
logging
right
now
is
not
actually
the
fully
fledged
object.
So
I
have
some
changes
to
make,
but.
A
But
even
so
the
next
thing
I'd
like
to.
D
A
You
would
do
because
I'd
like
to
just
do
cube
ctl
describe
the
deployment
or
the
service,
but
that's
not
so
easy
from
clientco
anyway.
That's
where
we're
at.
If
anybody
has
any
ideas,
let
me
know.
D
A
D
B
A
Should
I
try
share
screen
again
yeah?
Let's
do
it.
C
No,
no,
please.
D
Carlos
merger,
pr
to
add
the
service,
but
it's
not
actually
hooked
up
to
the
apis.
Yet
so
it's
not
done,
but
it's
yeah.
I
don't
know
if
he's
actually
actively
working
on
it,
but
it's
started.
A
D
Sure,
okay,
I
don't
know
if
we
need
to
go
into
each
one
like
individually,
but
so
we're
halfway
through
the
milestone.
We
have
two
weeks
left.
I
think
we're
kind
of
in
a
similar
situation
as
last
time
where
there
are
a
lot
of
open
issues,
but
all
of
them
are
sort
of
assigned
in
progress,
but
a
lot
of
them
are
bigger
than
they
should
be,
and
so
they're,
probably
taking
longer
than
a
few
weeks.
So
ipv6
is
still
in
progress.
D
C
Would
I
would
drop
it
for
this
one
and
put
it
out
to
you
next
and
the
reason
I
say
that
is
they're
finishing
up.
The
new
zealand
team
is
working
on
the
code
generator
and
they're
really
close
to
having
the
code
generator
completed.
So
I
would
prefer
to
drop
this
out
and
actually
use
their
generated
code
for
cancer
azure
service
operator
as
the
prototype.
E
Oh
okay,
yes.
D
E
D
D
All
right,
azure
cni,
so
I
have
been
looking
into
this
one
a
lot
this
week
and
it's
not
straightforward.
D
So
I
don't
know
if
that's
going
to
be
done
in
this
monster.
I
think
I
I'm
considering
this
milestone
as
a
spike
and
like
research
like
what
needs
to
be
done,
how
hard
it
is.
What
do
we
need?
There
are
a
few
things
right
now
that
I'm
I'm
talking
to
the
the
team
that
maintains
it
about
maybe
having
it
as
damon
said,
so
we
don't
have
to
install
it
as
a
binary.
Things
like
that,
which
might
make
it
easier.
David
is
saying,
perhaps
a
proposal.
D
Yes,
I
think
that
makes
sense,
but
at
this
point
I'm
still
at
the
I
don't
even
know
if
we
want
this
or
how
we
want
it
staged
so
once
we
figured
that
out
and
I'm
like.
Yes,
we
want
this,
then
maybe
I
can
write
a
proposal
for
it
and
the
how
part,
but
I
think
that
we're
not
even
there.
D
C
D
D
Cool
okay,
bootstrap
failure,
detection.
I
will
ask
pink
jack
about
that.
I
don't
know
if
he's
still
working
on
the
dodge,
but
I
think
we
wanted
to
have
a
dog
out
soon
and
from
last
time
I
talked
to
him.
We
had
a
pretty
good
idea
of
what
we
wanted
to
do,
but
still
have
to
write
it
up
any
feel
free
to
interrupt.
If
you
have
questions
by
the
way,
machines
should
have
accelerated
networking
enabled
what
is
that
end-to-end
test?
Oh,
that's,
the
pr
matt
you
have
a
pr
open
for
that.
A
I
think
it's
blocked
on
the
on
the
e2e
failure.
I
was
talking
about
earlier.
A
D
All
right,
refactor
remaining
services,
so
we're
actually
really
close
in
that
one.
You
can
see
14
out
of
16.,
so
the
skill
sets
one
is
open
and
then
we
have
two
more
they're,
both
in
experimental,
so
they're
not
like
super
high
priority,
but
we
have
agent
pools
and
manage
manage
control
planes.
I
think
so.
I
think
those
two
are
already
assigned
to
david.
I
don't
know
if
david
that's
too
much
for
this
milestone,
because
you're
already
tracking
a
few
other
things,
we
can
push
that
back
to
the
next
milestone.
D
The
refactor
for,
can
you
click
on
the
refactor.
C
Yeah
so
vmss
got
there
yeah
when
is
when
is
the
milestone
closed.
C
This
might
be
optimistic.
I
I
still
think
I
can
get
there
they.
So
this
week
has
been
a
little
bit
rough.
There's
there's
been
a
lot
of
stuff
going
on
outside
of
my
normal
contributions,
so
I
I
feel
oh
actually
no
bump.
This
outfit
is,
I
will
be
out
be
from
august
28th
till
september,
7th.
D
C
C
Coming
up
so
just
just
if
I
get
to
it,
it'll
be
optimistic,
I'm
hoping
to,
but.
D
I
will
do
that
yeah
no
problem
and
also,
if
you
don't
think
you
can
get
to
it,
feel
free
to
on
a
sign.
Also
that's
okay,
but
I
no
rush
on
the
experimental
packages.
I
think
we
got
the
biggest
chunk
out
of
the
way
and
those
two
are
also
packages
that
don't
get
touched
very
often,
so
there's
less
churn.
So
that's
okay,
because
they
won't
come
in
the
way
of
other
contributions
as
much
thanks
for
knocking.
D
Yep,
well,
I
got
a
lot
of
help.
So
thanks
everyone
who
helped
okay
end-to-end
test
should
bring
more
debug
output.
That's
very
current
matt!
I
assume
that's
what
you're
working
on.
A
So
yeah
I
mean,
I
think,
we're
there,
although
I
just
have
a
few
tweaks
that
I
want
to
make.
So
we
can
probably
close
this
the
next
day
or
two.
D
Okay,
I'll,
let
you
do
that
once
you're
done,
nginx
text
is
flaky
still
looking
at
that,
yes
end-to-end
test
for
availability
zones
fairly
domains.
We
have
a
pr
open.
It's
actually
really
close.
I
just
asked
for
like
a
minor
change,
I'll
see
if
the
author
responds
but
yeah,
I.
B
Know
that
was
on
vacation,
so
oh.
D
B
Yeah,
I
think
he's
out
next
week
too.
So
if
we
imagine,
I
can
just
like
make
a
follow
up
to
remove
that
file.
D
Okay
yeah,
we
might
just
do
that
then
cool
network
describer
interface.
I
mean
we'll
leave
that
in
there
ace
was
looking
at
the
credentials.
He
has
a
pr
in
progress.
I
believe
it's
just
missing
some
unit
tests,
which
I
think
was
sort
of
related
to
this
and
yeah.
This
is
kind
of
this
is
like
a
follow-up
to
the
refactors
yeah
reflect
your
subscription.
A
I
think
there's
a
good
chance
yeah,
I
think
I'll
be
able
to
get
to
this
in
the
next
week.
So,
let's
leave
it
up
there.
Okay.
D
C
That
I
thought
this
might
be
real.
Oh,
is
this
this
provider
one,
or
is
this
the
the
one
that
was
related
to
the
watches.
D
A
Sorry,
I
should
just
stay
unmuted
yeah,
the
15
minutes
thing
is
very
suspicious.
C
Thing
to
dump
the
cloud
provider
laws
would
probably
we
might.
We
might
see
this
issue
sprouting
from
there.
D
All
right,
speed
up
end
to
end.
I
don't
know
if
that's
really.
I
think
this
is
more
of
a
follow-up
to
improving
end.
I
don't
think
we
should
work
on
like
improving
the
parallelism
if
we're
going
to
refactor
the
tests,
so
maybe
we
should
either
put
that
in
next
or
put
that
in
like
as
related
to
the
other
one.
D
Okay,
I'll
just
put
it
in
next
month.
Oh,
I
just
wrote
next,
it's
monster
next
and
then
what
was
the
one
that
was
well,
there
are
a
few
others
yeah,
oh
later,
the
route
table
thing
we're
still
working
on
that
right.
I
think
the
pr
is
there.
B
F
D
C
A
little
side
note
about
the
performance
improvements
in
ete.
I
really
like
the
way
that
kathy's
tests
are
structured
with
the
like.
Spec
builds
a
cluster
and
then
tests
underneath
it.
I,
I
think,
that's
kind
of
the
way
that
we
can
go.
I
I
I
kind
of
like
that
right
now.
That's
what
I'm
leaning
towards
if
there's
wrong
opinions
as
into
the
issue,
but
it
seems
the
structure.
C
I
I
I
would
love
to
hear
other
opinions
on
it
and
the
quicker
that
we
can
execute
tests
better
right.
So.