►
From YouTube: testing-commons 2018-02-07
A
A
Right
first,
like
question
is
kind
of
the
first
couple.
Questions
are
about
like
reviews
and
policy,
for
how
we
want
to
deal
with
this
repository.
I.
Don't
have
strong
feelings,
I,
don't
think
we
need
to
label
anything
because
everything
in
this
repository
already
is
directly
applicable
to
this
smaller
group
of
people
or
sig
testing
itself.
So
I
know
I.
Have
this
comment
up
here,
but
I'm
I'm
happy
to
remove
it.
So
in
have
any
comments
about
labeling,
PRS.
A
B
A
It's
usually
the
way
the
upstream
upstream
works.
This
is
kind
of
like
a
downstream
sub-project.
Come
on
contact
is
that
the
upstream
will
always
add.
Let's
you
know
a
list
to
get
to
poke
the
right
people
I
think
it
makes
sense
to
do
sig,
testing,
PR
reviews,
because
I'm
on
that,
or
are
you
on
that
list.
A
A
C
C
D
A
A
A
E
A
A
A
Can
you
can,
but
it's
all
it's
all
a
matter
of
how
you
do
your
massive
github
filter
apparatus,
whatever
that
may
be
I
have
filters
for
filters
that
further
filter
things
so
I've
been
on
this
project
for
too
long
but
yeah.
It's
it's
completely
up
to
you.
If
you
want
to
subscribe
or
add
the
members,
but
the
members,
the
useful
thing
there
is
it
just
cause,
not
people
to
to
help
do
reviews
and
you
can.
You
should
be
able
to
join
so
I'll.
A
B
There
was
no
not
much
progress
in
the
last
week
because
we
had
to
deal
with
other
stuff,
but
that's
definitely
an
our
list,
and
if
we
like
progress
with
our
framework
with
the
functionality
of
the
framework,
we
will
definitely
have
a
look
on
what
we
can
steal
and
I.
Think
awesome.
Maroon
already
gave
us
some
some
points
as
to
other
stuff
which
we
could
potentially
steal
or
have
a
look
at
so
yeah
I'm
not
much
progress
right
now,
but
we
it's
it's
in
the
back
of
our
heads.
A
As
part
of
that
bit,
Maru
and
I
were
talking
and
I
was
also
talking
with
Liz
about
this.
It
would
be
ideal
if
we
had
a
very
simple
abstraction
layer
that
for
its
integration
tests,
that
basically
said
give
me
a
cluster
of
this
shape
and
on
the
backend
it
could
be
whatever
right.
We
don't
really
care.
We
don't
want
to
be
prescriptive,
but
then
you
get
back
a
hand.
A
client-side
handle
that
your
tests
can
actually
run
against.
Then,
ideally,
one
of
the
implementations
for
that
back-end
would
potentially
be
one
of
them.
Many.
C
Well,
I
mean
there's
to
be
there's
kind
of
like
a
simplest
thing,
is
of
an
API
server
and
then,
if
you
want
to
get
more
complicated,
you
could
have
an
API
server
and
some
controllers
anyone
even
more
complicated.
You
could
add
some
holo
notes.
You
want
to
get
more
complicated.
If
you
add
darker
darker.
C
It's
like
to
me:
it's
like
there's
these
layers
of
complexity.
That
I
think
should
be.
You
could
be
able
to
do
just
something
simple,
because
then
the
execution
and
the
failure
domain
is
really
tiny
you
need
to,
but
I
guess.
If
I
I
do
think
that
Tim's
point
about
whatever
setup.
You
call
you
know
passing
whatever
configuration
and
then
you
get
back,
not
a
client
I
realize,
but
a
configuration
I've
been
kind
of
working
on
some
integration
testing
around
aggregation
and
it's
like
you
just
want
the
configuration.
C
A
client
is
very
specific
because
it's
like
oh
I'm,
pointing
to
the
cube
API,
but
you
could
be
pointing
to
an
aggregated
API
as
well.
There
could
be
other
things
in
there.
You
don't
know
what
client
you
need,
but
if
it's
config
then
whoever's
consuming
this
can
decide
what
client
they
want
to
target
it.
Beautiful
yeah.
C
But
the
problem
is
that
the
clients
are
configured
anyway,
so
whether
we
hide
that
detail
or
not
I
mean
I'm,
not
saying
that
we
shouldn't
have
something
where
it's
like
get
cubed
client.
What
I'm
saying
you
need
the
option
of
getting
cute
config,
so
you
can
configure
other
api's
to
the
cluster.
That's
all
just.
B
To
to
understand
the
thing
you're
talking
about,
when
you
say
a
config,
you
actually
mean
the
cube,
config,
yellow
thingy,
or
are
you
talking
about,
for
example,
the
rest
of
config
thing
that
go
structure?
Are
you
actually
talking
about
file
or
the
contents
of
the
file
which
can
be
used
as
a
cube,
convict
I.
C
Am
probably
talking
about
it
in
memory
config,
but
it
could
be
I
mean
it's
they're
translatable,
so
it's
like
whether
I
have
an
in
memory
config
or
something
that
would
be
serialized
to
a
file.
The
point
is
that
I
need
something
to
be
able
to
configure
an
in-memory
client
like
in
maybe
in
the
case
of
testing
cube
cattle,
that's
not
the
case,
but
for
testing
any
third
party
API
server.
You
just
need
a
cute
config
object.
I.
A
I
as
a
consumer,
an
external
consumer
I,
don't
care
about
the
internal
in
ones.
I
do
think
that
the
cake,
a
repo,
will
definitely
care
about
the
internal
component
configurations,
but
as
a
consumer
I
really
don't
care.
I
really
just
want
a
some
predefined
prescriptive
way.
For
me
to
stand
up
a
in
environment,
that
gives
me
back
a
config
or
a
client
that
I
can
then
run
an
exercise.
My
tests
against
that
is
as
close
to
reality
without
me,
having
to
blast
out
a
full
cluster.
A
We're
working
on
so
the
the
component
configuration
in
memory
or
in
on
cluster
config
is
a
work
in
progress.
Right
and
people
are
working
on
that.
So,
like
the
long
term
goal
of
a
lot
of
the
cuvette
DM
into
cluster
lifecycle,
work
is
to
have
component
configuration
for
each
of
the
individual
elements
live
as
an
in-memory
on
cluster
configuration.
That
can
be
dynamically
changed
on
the
fly,
so
it's
so.
C
A
So
long
as
you
have
the
API
for
that
component,
you
should
be
able
to
change
and
modify
it
and
restart
it
and
do
everything
else.
You
need
to
do
that's
kind
of
the
way
as
a
requirement
for
whom
a
DM
to
go
to
GA.
We
absolutely
require
that
the
couplet
have
the
dynamic
Google
configuration
be
bheegi,
bheegi
aid,
because
what
happens
with
the
kulit?
Is
you
bootstrap
it
and
it
could
change
over
time?
And
you
don't
want
to
deal
with
that.
A
C
C
That's
ok,
but
I
think
the
implication
of
in
cluster
config
right
now
for
me,
is
expecting
to
have
like,
via
the
downward
api,
like
access
to
the
API,
like
I
automatically
acquire
our
required
credentials
to
get
to
the
API
server
and
I
want
to
make
sure
that
it's
possible
to
run
things
standalone.
Yes,
absolutely
and
I
should
say:
I've
heard
that
some
people
don't
even
want
to
enable
that,
because
they
want
to
discourage
people
running
that
absolutely
well.
A
Can
you
give
me
more
specific,
there
I'm
a
little
I'm,
a
little
fuzzy
by
what
you
mean
by
stand
alone,
because
the
way
the
minimum
bar
for
almost
everything
in
qadian
is
the
couplet
is
the
kicker
for
the
components
right
and
that's
like
the
minimum
bar
is
that
the
couplet
controls
the
process
use
from
there.
It
can
control
one
to
end
processes
that.
C
Useful
for
some
types
of
testing,
but
requiring
that
I
am
running,
say
a
controller
that
I'm
trying
to
test
in
a
container
I.
Don't
think
that's
always
a
good
idea.
I
think
sometimes
I
want
I
want
to
be
able
to
say,
run
a
debug
version
and
I
don't
want
to
have
to
be
in
a
container
space.
Speak
to
it
again,
right
to
me,
it's
like
that.
I
think
there
is
a
there's.
A
split
between
like
I
want
to
run
this
in
production.
C
I
want
to
manage
by
the
cubelet
and
I
want
to
be
able
to
validate
that
in
some
kinds
of
testing.
I
also
want
to
just
run
this
controller.
You
know
targeting
an
API
server
that
I'm
composing
in
a
great
integration
test,
and
so
I
want
that.
Can
I
want
that
component,
whether
a
controller
or
something
else
to
be
able
to
source
this
configuration
from
somewhere.
It
doesn't
require
it
to
like
use
it
down
on
the
API.
I
guess
is
what
I'm
saying.
A
It
doesn't
require
to
use
the
downward
API
wise
I,
don't
see
that
this
is
a
barrier
to
like
the
interface
layer
and
there
could
be
multiple
implementations
right
like
and
we
could
have
layers
for
the
implementations
over
time.
I
just
wanted
to
get
to
Cambrian,
but
it'd
be
nice
to
know
the
requirements
for
that
restriction
and
why
I
would
like
to
hermetically
seal
as
much
as
possible
because
it
just
makes
things
more
convenient,
but
I
understand
the
desire
to
want
to.
C
I
guess
my
point
is,
though,
that
today,
like
yes
component
config,
is
an
end
goal,
but
for
things
that
don't
have
that
yet
I
guess,
if
we're
expecting
component
config
to
be
available,
you
know
they've
been
a
reasonable.
You
know
time
frame.
That
means
that
we're
just
going
to
duplicate
configuration
details
in
this
Rico
well
really.
A
A
The
way
it's
done
in
coop
ADM
today
and
I
think
it's
actually
the
best
of
worst
solutions
right
like
there's,
there's
no,
it's
a
Kobayashi
Maru
right!
There's
no
good
answer
to
this.
So
it's
it's!
The
best
solution
to
a
bad
problem
is
that
it
composes
the
yeah
Mille
for
a
pod
and
the
args
that
are
specified
there,
and
then
it
submits
the
components
whether
it
be
the
controller
manager
or
the
scheduler,
based
upon
the
input
arguments
that
allow
you
to
override
the
default
configuration.
A
C
C
I
mean
if
I
am
I'm
saying
like
if
the
end
goal
is
like
I
want
to
have
a
component
config.
That's
version
that
if
I'm
writing
a
test
against
I'm
been
during,
you
know
the
frameworks
repo.
My
tests
aren't
going
to
break
because
some
binary
decided
to
change
his
arguments.
I
have
to
go
figure
out
:.
How
oh
this
version
you
know,
I
have
to
use
this
version
of
the
binary.
Otherwise
these
flags
aren't
going
to
be
there
like
I,
don't
I,
don't
know.
I
know
this
is
a
little
bit
hypothetical
but
I'm
like
that's.
A
Crazy,
that's
specific
to
the
test,
though
I
think
at
this
point
in
time.
Like
you,
we
can
abstract
a
framework
that
totally
doesn't
even
care
and
then
does
call-outs.
You
know
I
think
I,
think
we're
kind
of
in
the
weeds,
I.
There's
a
lot
of
thorns
on
how
you
can
deal
with
configuration
of
the
components
like
right
now.
I,
don't
even
know
how
many
parameters
do
you
guys
ever
has
anymore?
Is
it
like
60,
but.
C
I
guess
my
might
I
mean
when
I'm
thinking
about
I
want
to
run
a
cluster
yeah.
There's
a
lot
of
configuration
you
can
set,
and
are
we
going
to
just
we're
not
going
to
take
any
responsibility
for
providing
saying
ways
to
manage
that
configuration
if
I
want
to
do
like
an
SSL
server
like
like
secured
Transport,
then
I
have
to
like
generate
certs
and
do
all
the
sort
of
stuff
what
if
they
want
to
override
any
of
the
parameters
of
them,
setting?
How
do
they
do
that?
That's.
A
C
A
A
That's
where
I'm
saying,
like
the
abstraction
layer
stops
here
right
and
we,
the
implementation
of
a
versus
B,
is
completely
up
to
us
right,
I.
Think
over
time,
I
have
no
way
of
saying
you
know.
I
have
no
way
of
saying
all
the
different
ways.
People
are
going
to
stand
stuff
out.
That
is
it
so
it's
too
many
right,
but
I
think
if
we
can
agree
upon
an
interface
layer
and
what
arguments
would
get
back
and
then
agree
upon.
Like
you
know,
this
is
one
method,
a
and
here's
another
method.
A
A
A
There
is
no
unified
configuration
file
that
exists
today.
The
closest
thing
is
like
the
cluster
API,
which
would
gives
you
like
I
can
I
can
specify
a
set
of
configs.
That
gives
me
the
shape
and
the
idea
of
what
it
would
look
like
if
you're
looking
for
a
declarative
model
for
how
you're
going
to
state
what
the
cluster
will
be.
Is
that
what
you're?
Looking
for
I
guess.
C
Talked
about
having
like
I
want
a
cluster
and
it
will
you
know:
I
wanted
to
have
X
nodes.
Okay,
that's
pretty
simple
and
we'll
fire
it
down
to
say:
kubernetes
dine,
pluster,
it'll
provision,
something
if
I
wanted
to
actually
configure
like.
I
wanted
to
have
certain
configuration
values
set
for
that
cluster.
How
do
I
provide
that?
And
that's
only
just
for
one
like
implementation?
What,
if
I,
have
something
uses,
hollow
notes
and
doesn't
use
to
you
ATM
to
deploy?
A
C
A
I,
don't
disagree
with
you,
I
think
the
the
problem
of
configuration
it
is
is
weird
today
right
because
it's
a
it's
a
mashing
of
component
config
as
well
as
command-line
arguments.
You
get
it
configured
the
way
you
want
it
to
be,
and
it's
not.
Ideally,
we
would
have
a
set
of
well-defined
component
configs
with
a
well-defined
set
of
API.
Is
that
would
allow
you
to
say,
like
it's
gonna
look
like
this
right
and
these
are
they're
gonna,
be
the
arcs.
A
If,
if
people
want
to
the
the
scheduler
and
controller
manager
and
kulit
all
have
these
pieces
of
the
puzzle
done
there
in
different
grades
of
alpha-beta
quality
right,
so
I'm
not
concerned
about
those,
the
EPI
server
is
the
thorny
one
that
everyone
kind
of
like
backs
away.
Slowly,
because
it's
got
so
many
parameters,
and
so
many
arguments
that
it's
very
difficult
for
people
to
want
to
commit
to
that
work.
It
isn't
it
is
a
non-trivial
large
block
of
work
that
will
require
a
sustained
effort
across
multiple
release
cycles.
I
got.
C
That
I
I'm
just
to
me
the
the
effort
that
we're
gonna
have
to
put
into
enabling
configuration
in
a
nice
way
for
that
is
probably
not
dissimilar,
like
I
think
at
least
there's
some
overlap
between
those
that's
kind
of
like
well.
If
we
want
to
enable
good
testing,
I
mean
if
someone
was
starting
out
with
this,
and
they
wanted
to
enable
good
testing
at
day
one
they
would
have
done
this
already
saying
this.
Is
it
there
wouldn't
be
10,000.
A
C
Sorry
I'm
my
yeah,
the
last
thing
I'll
say
but
I
guess
when
I
look
at
this
problem,
I
see
like
we
can
paper
over
the
problem
and
not
taking
any
responsibility
for
it,
but
I
mean
a
good
integration
framework
is
gonna
have
some
of
the
characteristics
that
we
would
want
in
the
API
server
itself.
Any
terms
of
configure
building
I'm.
C
E
C
A
I
think
what
we
can
postulate
and
socialize
part
of
this
is
social
judo
right.
We
need
to
make
make
our
idea
their
idea
and
their
ideas
brilliant
across
the
board
right
and
the
the
social
judo
required
here
is
to
basically
say,
like
people
want
to
have
a
well-defined
component
config
for
the
API
server.
Many
people
want
this,
but
it's
not.
No
one
has
signed
up
to
do
this
work
I
think
if
we
start
to
socialize
the
importance
of
it
and
the
desire
from
many
parties,
it
will
start
to.
A
You
know
the
whispers
come
from
many
years
right,
not
just
one
group
but
from
many
groups
and
that's
when
the
the
the
single
lone
dissenting
voice
becomes
a
large
chorus
and
I
think
we
need
to
play
that
that
card
as
well
right,
because
right
now,
API
machinery
for
the
most
part
is
myopically
focused
on
certain
sets
of
problems
and
not
necessarily
focused
on
this
particular
space
and
I.
Think
I
think
we
need
to
maybe
poke
that
bear
to
address
this
issue
because
it
is
a.
A
It
is
a
long-standing,
a
very
large
block
of
technical
debt
and
I
I.
Do
think
that
we
need
to
solicit
and
rally
on
that
bit
to
try
and
make
it
go,
but
I
think
what
we
can
also
do
is,
as
we
draft
proposal
is
to
point
this
out
in
glaring
fashion
and
then
bring
it
up
with
other
folks
right
I
can
bring
it
up
in
sega
architecture
and
basically
say
like
hey
guys.
We
really
need
this
thing
and
here's
this
proposal.
That
outlines
the
reasons.
Why
does
that
seem
like
a
fair
attack
pattern.
C
A
So
I
think
what
we
can
probably
do
from
here
is
craft
a
a
proposal
in
a
Google
Doc
and
share
amongst
the
group
for
to
solicit
requirements,
and
maybe
for
our
next
meeting.
We
can
have
a
at
least
a
fully
commented
file
that
we
can
talk
about
more
succinctly
with
each
other
to
try
and
make
progress
on
this
and
I'm
happy
to
get
that
started
and
also
I'm
gonna
talk
with
Liz
about
you
know,
trying
to
help
drive
that
piece
of
the
puzzle,
because
there's
a
desire
on
our
side
to
have
this
integration
framework
go.
A
C
So
I
guess
my
thinking
on
how
to
like
leave
the
bar
is
we
framework?
That's
the
starting
point
makes
it
easier
to
write
these
tests.
You
need
good
examples
of
the
frameworks
use
and
then
we
have
to
go
and
individual
sakes
that
are
test
heavy
and
we
need
to
work
with
the
developers
as
reviewers
or
otherwise
to
get
them
like
2.0,
hey,
you're,
writing,
something
that
could
be
done
better
or
differently.
Please
do
it
this
way.
So
to
me,
that's
kind
of
a
pattern.
C
A
I
agree:
there
needs
to
be
hey.
We
want
to
do
this
and
hey
look
at
how
much
it
makes
your
life
better.
There's
there's
a
sales
pitch
for
sure,
but
we
need
to.
We
need
to
get
the
ball
rolling
on
at
least
a
design
that
we
can
agree
on
for
some
pieces
of
the
puzzle
that
that
works
for
our
use
cases,
because,
as
people
want
to
sprit
the
repo
I,
don't
see
how
they
can
even
do
that
without
this.
A
C
I
mean
my
my
work
is
centered
around
enabling
integration
testing
for
cluster
registry
and
Federation,
and
that
involves
using
the
fixture
that
exists.
The
frameworks
repel
for
spinning
up
the
net
CD
and
API
server,
but
then
also
I'm
working
on
enabling,
like
aggregation
of
an
in-memory
thing
and
I'm,
hoping
to
be
able
to
contribute
that
back
to
the
framework
we
go.
C
A
C
A
A
B
A
C
C
My
my
point
would
be
that
I'm
fine
with
having
this
repo
being
developed
in
this
way
in
the
near
term,
but
if
we're
actually
going
to
use
it
for
KK
I
could
honestly
see
us
having
to
pivot
to
being
a
staging
Rico
as
much
as
I'm,
not
saying
it's
not
a
good
thing
to
be
in
KK.
There's
a
lot
of
problems,
because
then
you
got
irritated
by
a
whole
bunch
of
on
my
French,
but
I
don't
see
us
resolving
that
dependency
problem
could
be
just
becoming
a
staging
recall.
C
C
C
A
I
think
one
of
the
requirements
that
we
should
probably
specify
in
the
design
dock
for
all
this
stuff
is
that
we
need
to
have
a
dag
model
of
inclusion
and
meandering,
because
they're
they've
spent
copious
amounts
of
time
to
untangle
the
dag
and
now
I've
created
like
a
untangle
the
circle
dependencies
because
they
were
in
one
repo.
So
they
were
able
to
do
it
before,
and
we
should
be
very
mindful
of
that.
C
C
When
I
say
ven
during
staging
repos
I'm,
never
talking
about
sourcing
stuff
from
the
kubernetes
repo,
it
may
be
clear
about
that.
But
my
point
is:
if
I
was
today
to
vendor
in
the
frameworks
repo
into
kubernetes,
because
I
wanted
to
reuse
the
integration
framework
that
repo
is
depending
on
certain
versions
of,
say,
client
go
and
API
machinery
which
are
not
guaranteed
to
be
in
sync,
with
the
staging
versions
that
are
in
the
image
and
kubernetes
tree.
Okay,.
A
C
All
I'm
saying
is
until
those
repos
are
developed
entirely
out
of
tree,
because
we're
not
depending
on
kubernetes
committees,
we're
just
depending
on
the
stage
and
repos
that
are
happening
to
live
there,
so
I'm
saying
it
may
be.
That
is
a
short-term
thing.
Until
those
repos
are
at
a
tree,
we
may
actually
have
to
also
do
a
drink.
That
makes
sense
if
we're
to
be
reused
by
KK.
Yes,.
A
But
I'm
gonna
that-that'll,
that's
a
bridge
that
I'll
cross
when
we
get
there
right,
I'm,
totally
fine
with
living
outside
the
main
line
for
a
while
in
doing
this
separately
and
building
up
the
corpus
of
information,
as
well
as
the
requirements
and
then
cross
that
road
when
we
need
to
but
I
get
your
point,
I
understand
it.
I'm.
C
A
Agree,
I,
agree
and
I
think
I.
Think
honestly,
this
will
probably
be
more
beneficial
to
external
consumers
at
first
and
that's
kind
of
the
that's
kind
of
the
main
point
at
this
point
is
like
there's
a
bunch
of
people
who
want
to
test
their
integrations
with
kubernetes,
and
it
is
a
ginormous
pain
in
the
butt
to
do
so.
A
A
Okay,
so
I
don't
think
we
have
any.
Are
there
any
of
more
agenda
topics
if
we
kind
of
think
the
horse
is
sufficiently
beaten,
visit,
there's
a
how
about
by
next
week,
I
have
a
document
in
place
that
we
can
gather
on
and
I'll
work
with
Liz
too,
as
well
to
kind
of
spec
out
what
our
requirements
are,
because
we
have
a
concrete
use
case
so
that
that
helps
to
you
know,
solicit
requirements.
A
Then
we
can
iterate
on
those
requirements
for
the
broader
state
space
of
things
and
try
to
push
up
a
cap
for
broader
conversations,
so
I
think
getting
getting
a
document
to
everyone
to
comment
on
by
next
week
and
then
having
a
discussion
for
the
next
meeting
seems
like
a
reasonable
time
frame.
Is
that,
okay
with
other
folks,
he
just
gives
me
a
thumbs
up.
C
A
That
was
kind
of
the
plan,
but
you
were
talking
in
very
generic
things
and
I
wanted
to
entertain
the
idea.
So
in
the
back
of
my
head,
it
was
like
there
this
this
most
of
this
exists.
It's
not
as
fine-grained
as
people
would
like
right,
because
what
happened
with
it,
what
happens
today
is
I,
get
all
the
PRS
I'm
reviewing
for
cube.
Idiom
like
literally
this
week
are
all
about
like
we
need
an
extra
knob
for
this.
A
C
Okay,
I
guess
like
I'm
a
little
bit,
oblivious
but
including
into
the
fact
that
if
somebody
else
is
already
duplicating
you
know,
I'm
at
a
configuration
mechanism
duplicating
the
creating
that,
then
you
could
just
use
that.
But
how
do
we
is
it
possible
to
consume,
hitting
cube
ATM
about
vendor
in
KK?
Yes,.
A
Comedian
was
all
the
code
that
goes
into
comedian
was
designed
to
that.
It
was
meant
to
be
an
external
thing,
and
currently
we
currently
it's
a
it
lives
in
the
repo
only
for
expedience
and
because
the
facilities
didn't
exist,
but
it
is
wholly
separable
and
you
can
configure
it
without
any
knowledge
of
kubernetes.
For
the
most
part.
A
A
C
A
That's
kind
of
the
purpose
of
the
cluster
API.
The
cluster
API
is
meant
to
be
like
this
thing
that
lives
above
cuvee
DM
that
could
blast
out
a
cluster,
but
there's
still,
if
you
want
to
make
it
so
it
stands
up
components
of
the
picture
as
well
as
the
other
pieces.
There's
some
work.
That
still
needs
to
be
done
to
do
that.
A
But
we
can
we
can
do
we
can
do
generic
stand
up
easily
with
a
configuration
file,
but
that's
going
to
stand
up
all
the
pieces
and
there
are
definitely
use
cases,
as
you
mentioned,
for
standing
up
just
two
of
the
pieces
or
just
one
of
the
pieces
right
and
that
we
can
do
it.
But
it's
not
all
clean
right,
I.
C
Guess
I'm
still
puzzling
over
a
wanting
to
I
guess
I
just
need
to
reconcile
in
my
head,
like
the
difference
between
I'm
using
qVM,
to
stand
up
a
cluster
versus
I'm
community
using
something
like
QV
DM
to
figure
like
mitigation
cluster,
and
it's
certain
characteristics
of
like
a
more
integration
focus
cluster
that
maybe
I'm
too
fixated
on.
Well.
A
A
Right,
okay,
well,
I
think
what
I'll
do
then
is
I
will
make
it
an
action
item
to
follow
up
by
next
week
and
send
out
an
email
to
this
group
as
well
as
broader
group
of
people,
to
try
and
solicit
some
feedback.
Well,
maybe
I'll
do
that.
Second
I'll
just
send
it
to
this
group
to
get
feedback
on
the
initial
requirements
and
instead
of
a
design
sketch
and
then
then,
once
we've
distilled
it
down,
we
can
send
it
out
to
a
broader
group
whose
I
seem
fair,
okay,
cool
all
right.