►
From YouTube: Kubernetes KubeBuilder Meeting 20201217
Description
KubeBuilder Meeting for 2020/12/17. See https://sigs.k8s.io/kubebuilder for more details.
A
A
All
right
looks
like
we
actually
have
quite
a
few
things
on
the
meeting
today.
I
think
the
first
thing
is
from
eric
so
eric.
Why
don't
you
take
it
away.
B
Sure,
thanks
yeah,
I
wonder
if
this
has
been
addressed
before
I'm
not
sure,
but
I
have
a
feeling
that
we
we
can
solve.
One
of
the
problems
of
like
having
to
wait
on
a
bunch
of
breaking
changes
in
master
to
be
cut
into
a
minor
version.
B
Release
for
kubernetes
version
pumps
by
somehow
creating
a
like
a
branching
scheme
to
or
like
a
tagging
scheme
to
cut
older
minor
releases,
new
releases
for
older
minor
releases
with
kubernetes
version
pumps
and
I'm
wondering
if
people
think
that's
even
feasible
or
if
that
client
go
changes
enough
between
minor
versions
that
this
is
problematic.
B
B
First
bumps
up
until
the
point
that
the
client
go
api
breaks
or
any
of
the
upstream
api
dependencies
change
and
the
main
reason
for
doing
this
is
once
again
because
it's
difficult
to
have
all
these
breaking
changes
accompany
each
kubernetes
minor
version
change
for
downstream
dependencies
and
downstream
users
of
controller
runtime.
B
It's
not
the
end
of
the
world.
If
we
can't
do
this,
but
I'm
wondering
if
anybody
thinks
that's
feasible
or
if
that
is
too
complex
to
do
yeah
any
any
thoughts
on
that.
A
I
was
so
I'd
maybe
raise
a
counter
question
which
is
like
have
have
we
gotten
through
with
most
of
the
breaking
changes
that
we
wanted
to
make
before
1.0?
Is
it
time
to
slow
down
with
the
breaking
changes.
A
I
I
do
kind
of
feel
like
at
some
point
we
need
to.
We
need
to
slow
back
down
with
those
because,
like
just
in
general,
it's
not
great
to
make
too
many
of
those
either
we
made
a
lot
in
0.7
because
there's
a
lot
of
things
we
needed
to
change
before
we
hit
stable,
but
I
I
don't
know,
maybe
that's
two
separate
concerns,
but
well
perhaps
this
is
symptomatic.
C
B
That's
that's
a
great
point
and
I
think
they
they
are
related
mainly
because
if
we
release
1.0
then
next
time
we
want
to
make
breaking
changes.
We
release
a
2.0,
but
for
the
one
dot
yeah
so
like
the
we
will
be
able
to
release
kubernetes
version
bumps
as
minor
versions
of
the
1.0
tag
and
also
be
able
to
release
2.0
tags
at
the
same
time.
So
I
think
that
would
solve
this
problem
and
sorry
just
to
be
clear.
D
This
is
gel,
so
just
like
one
thought
on
this
is
how
are
the
developers
and
how
are
the
users
thinking
about
this?
If
the
developers
are
thinking
of
this
as
truly
being
pre-100
development,
then
I
would
expect
their
model
to
be
like
we're
trying
to
we're
trying
to
change
anything
that
we're
not
happy
with
to
get
to
1-0,
but
if
users
are
seeing
it
like
as
a
de
facto
like
I'm
using
this
thing
as
though
it
is
a
1.0
plus
quality
thing,
then
their
model
might
be
like
breaking.
Changes
are
really
disruptive
for
me.
D
C
No,
I
I
think
a
lot
of
users
like
to
opportunity
to
kubernetes,
but
he
I
think
it's
a
common
complaint
that
they
need
to
you
know,
do
changing
their
projects
because
they
break
chains
and
sometimes
they
feel
that
it's
hard
to
upgrade
because
the
brake
chains
so.
D
Also
from
users,
a
good
question
to
ask
yourself
is:
would
you
be
willing
to
accept
fewer
new
improvements
because
developers
are
spending
more
time
making
sure
all
the
changes
are
backwards
compatible
right?
It
is
a
trade-off
right
like
if,
if
the
devs,
if
the
devs
treated
as
a
1.0
plus,
then
you'll
probably
see
less
breaking
changes,
but
it
will
probably
be
more
expensive
for
them
to
do
what
they're
doing
so.
Is
that
acceptable
right?
C
Would
it
be
hard
we
like
a
shaky
all
changing
the
backlog,
maybe
in
the
issues
that
are
breaking
chains
into
the
two
things
that
is
required
to
do
to
you
know,
delivery,
1.0
and
you
do
the
you
know
playing
to
do
which
is
good
or
because
it
would
be
it
is
achievable.
Do
you
think
that
we
have
too
much
to
to
change
to
stabilize.
A
I
think
maybe
that's
a
good
idea
for
like
that.
Could
that
would
be
a
great
subject
for,
like
the
next
q
builder
triage
meeting,
just
make
that
entire
triage
meeting
about
like
try
to
quickly
go
through
our
our
controller
runtime
backlog
for
features,
anything
that's
its
kind
feature
and
just
like
not
not
triage
it,
except
for
like
check
to
see
if
it's
breaking
or
not
breaking
and
it's
breaking,
we
assigned
a
label
called
breaking,
and
then
we
can
go
through
at
the
end
and
figure
out
like
really
figure
out
later.
A
D
Yeah,
as
a
user,
I
would
be
really
happy
to
see
something
like
that
on
a
project
where
it's
like
this
is
the
burn
down,
and
then
the
dev
community
basically
says
at
1.0.
There's
going
to
be
there's
going
to
be
this
series
of
breaking
changes
and
we're
doing
them
so
that
after
1.0
you're
going
to
see
a
lot
fewer
breaking
changes
as
a
user.
I'd
be
really
happy
to
see
that
I'm
like
okay.
I
do
this
one
thing,
and
now
I'm
in
post,
100
state.
A
A
I
don't,
I
definitely
don't
have
all
of
controller
runtimes
q,
builder
stuff
or
all
of
control
runtimes
issues
in
my
head,
but
a
number
of
the
changes
that
we
made
were
like
things
that
I
had
wanted
to
address
before
1.0
or
things
that
I
thought
we
needed
to
address.
So
that's
maybe
a
good
thing.
D
That
way,
you
can
kind
of
like
start
to
you.
Can
you?
Can
you
basically
create
a
burn
down
list?
These
are
the
things
going
in
everybody
gets
a
couple
chances.
You
know.
Maybe
the
next
two
meetings
or
whatever
people
are
reminded
that
they
need
to
get
things
on
that
list
and
then,
like
you,
kind
of
close
it
and
short
of
something
really
exceptional.
You
try
and
really
hold
the
line.
B
Yeah-
and
we
we
also
shouldn't
be
shy
about
you-
know,
cutting
major
versions
like
obviously
we
don't
have
version
20
of
control
runtime
by
the
end
of
2021,
but
I
think
in
combination
with
slowing
down
on
the
braking
changes.
B
Plus,
you
know
releasing
more
major
versions.
Then
we
can
make
everybody
happy.
D
D
One
thing
right,
like
you're,
probably
going
to
have
to
find
a
way
to
get
by
and
then
accumulate
that,
and
it's
going
to
be
part
of
the
2.0
thing
that
comes
at
some
point,
so
you're
going
to
deal
with
development
a
little
different
but
like
there
will
be
a
2.0
like
you
will
be
able
to
clean
up
mistakes
later,
but
it'll
just
be
a
little
different.
B
Yeah
yeah
this
is
so.
This
is
great.
This
is
even
better
than
the
outcome
that
I
was
hoping
for
from
this
topic,
so
that
was
a
great
idea
sully.
A
Awesome
all
right,
yeah,
oh
you
want
you
have
the
next
thing.
It
looks
like
too.
You
want
to
talk
about
that.
B
Yeah
just
before
we
move
on
so
we
have
actual
items
of
having
the
next
two
meetings
being
discussing
1.0
stuff,
and
then
I
guess
that
means
around
february.
We
want
to
strive
for
1.0.
B
Cool
if
somebody
could
create
like
a
dated
milestone,
obviously
the
date
doesn't
need
to
be
hard
like
if
we
figure
out
that
there's
a
bunch
of
stuff
that
we
do
want
to
get
in
before
1.0,
we
have
to
push
it
back
totally.
Fine,
but
just
having
some
sort
of
date
would
help.
E
Thank
you
hey.
As
a
suggestion
should
we
send
an
email
to
the
gift
builder
group
saying
that
we
are
like
gonna,
have
a
freeze
for
new
features
for
controller
runtime
1.0
in
like
two
weeks
or
maybe
four
or
whatever
we
choose
so
that
people
that
are
not
here
in
in
this
meeting
realize
that
they
need
to
submit
their
their
ideas
before
that
date.
C
And
the
last
thing
about
the
triage:
do
you
think
that
is
valid?
We
spend
your
time
to
trying
to
like,
as
you
said,
not
to
triage,
accept
or
not,
but
is
break
change
or
not,
and
you
put
maybe
one
hour
or
two:
do
you
think
it
would
be
enough.
B
E
A
Yeah,
I
I
think
I
think
the
ones
during
the
holidays
will
probably
skip
the
meetings
during
the
holidays.
I
wasn't
anything
that
falls
over
the
next
two
weeks
is,
I
think,
probably
cancelled.
Actually,
if
whoever
owns
the
meeting
could
cancel
the
ones
for
for
cube
q
builder,
that
would
be
great.
B
B
Yeah,
I
I
think
if
even
if
whoever
owns
it
can't
cancel
it,
then
people
will
know
that
the
january
first
one
will
not
be
heavily
attended.
Hopefully,.
B
Okay,
I
think
that's
it
anything
else
for
this
particular
agenda
item.
B
Okay,
moving
on
yeah,
so
this
this
next
one
is
just
discussing
replacing
kuber
back
proxy
with
network
policy
and
seeing
what
people
think
about
that.
So
some
a
little
bit
of
background
network
policy
can
control,
egress
and
ingress
to
set
some
pods
with
labels,
namespaces,
etc.
B
And
that
is
basically
doing
a
super
set
of
a
slightly
different,
but
still
a
super
set
of
the
job
that
kubar
back
proxy
is
doing
protecting
certain
pods
that
you
care
about,
and
I
I
think
that
it
is
possible
to
replace
cooper
and
cooper
back
proxy
with
network
policy.
B
One
of
the
problems
is
network
policy
is
only
supported
by
it's.
It's
supported
by
the
the
cni
plug-in
for
a
cluster,
and
if
you
have
certain
cni
plug-ins
like
flannel
that
are
plugged
into
your
cluster,
then
you
won't
have
access
to
a
network
policy,
so
that
doesn't
make
the
solution
as
general
as
q
bar
back
proxy.
B
But
at
the
same
time,
I
guess,
if
you're,
using
if
your
cluster
is
using
a
different
network
policy
or
sorry
different,
cni
plug-in,
then
you
there's
probably
some
other
way
to
control
access
to
pod,
endpoints
and
control
pod
networks
and
maybe
because
you're
using
a
different
cni
plug-in
you
don't
care
about
protecting
pod
networks
in
that
fashion.
So
maybe
that's
a
move
point
and
I
wanted
to
get
people's
opinions
on
this
change.
B
I
think
it
would
be
pretty
beneficial
because
you
are
using
a
native
kubernetes
resource
to
control
access
to
your
pods
and
also
you
are
not
depending
on
a
third-party
resource
anymore,
which
is
the
kubar
backpoxy
image.
So
you
have
to
worry
about
versioning
your
security
issues
there
and
I
think
it
simplifies
things
to
just
about
in
people's
I,
I
guess
my
first
like
specific
question
is
in
people's
experience.
B
Does
anybody
like
use
network
policies
in
production
personally?
Do
they
know
much
about
this
like
cni,
plug-in
problem?
Is
it
like
a
very
widespread
thing
to
use
a
different
cni
plug-in
in
your
cluster,
etc?.
A
I
don't
know
how
how
many
people
have
it
turned
on
or
not,
but
that's
at
least
a
data
point.
B
Zero
I
mean
another
solution
is
to
have
network
policy
enabled
as
phase
two
plug-in.
When
that
all
happens,
so
there's
yeah,
there's
there's
that
option.
It
doesn't
need
to
be
the
default.
B
And
we
don't
need
to
have
like
a
definitive
answer
on
this
right
now.
I
just
wanted
to
like
kind
of
get
a
feel
and
see
if
anybody
has
any
knowledge
that
I
don't
about
this.
C
Have
noted
the
default,
I
think
it's
not
good,
because
we
would
need
to
maintain
both
solutions.
You
know
doc
mage,
both
solutions,
so
this
is
the
only
cones,
but
you
put
as
therefore,
which
means
that
you
we
need
two
supports
to
work
with
different,
very
soft
apis,
v1,
beta
and
gtb1
as
well.
C
Yes,
the
very
song
I,
if
I'm
not
wrong,
they
supported
the
better
one
before
so
like
a
crg
using
the
baby
hooks
after
some
cluster
version,
the
same
thing
happens
with
another
vendors,
so
shows
that
she,
the
api,
the
has
the
v1
but
blah
blah
blah
that
was
deprecated
and
she
sent
vendors
will
support
you
after
ex
versus
any
others
before
you
know,
we
need
you
to
choose
and
see
if
it
both
works
in
the
same
way.
You
know
the
previous
version,
the
latest
one.
B
Yeah,
I
I
guess
I
personally
I
just
I
think
using
v1
is
probably
fine,
though
it's
been
supported
since,
like
before
kubernetes
2010,
so
I'm
I
don't
really
want
to
use
v1
beta
1
when
I
can
avoid
it
and
if
you're
using
openshift,
it's
probably
a
very
like
open
shift,
4.3
or
below
it's
probably
pretty
easy
to
just
change
v1
to
v1
beta1.
I
don't
think
there
are
any
api
changes
last
I
looked
it
if.
A
It's
if
it's
been
like
v1
since
1.10,
that's
like
well
out
of
our
support
range
like
our
standard
support
range
for
keybuilder
yeah.
Exactly
so,
I
think.
Maybe
one
thing
we
could
do.
We
could
send
out
a
mailing,
an
email
to
our
mailing
list
and
be
like
hey.
We
were
thinking
about,
maybe
including
network
policy
or
switching
network
policies
to
the
default.
A
How
many
of
you
would
appreciate,
or
very
much
not
appreciate
this
change?
How
many
of
you
have
network
policy
on
in
your
cluster
and
just
try
to
figure
it
out
like
that,
or
maybe
get
data
points
like
that
at
the
very?
A
At
the
very
least,
it
might
be
an
interesting
thing
to
post
to
plug
in
and
and
be
like
hey
if
you
use
this,
can
you
let
us
know
like
we're
thinking
about
where
we're
thinking
about
whether
or
not
this
should
be
the
default
or
our
back
proxy
should
be
the
default
and
we'd
like
to
get
some
data
points
from
y'all.
B
Yeah,
that's
a
great
idea
also
when
it
comes
down
to
it,
and
this
does
become
a
place
you
plug
in.
I
do
not
mind
maintaining
it
but
yeah.
Let's,
let's
start
with
this
mailing
list
question:
how
actually
I'll
follow
up
with
you
after
this
on
how
to
do
that?
B
E
My
face
ends.
I
think
that
the
main
advantage
of
of
this
approach
is
removing
the
dependency
of
our
back
proxy
and
if
you
are
doing
it
as
a
plugin
and
offering
both
options,
that
advantage
disappears
because
you
have
to
maintain
also
the
their
back
proxy.
So
you
still
have
the
dependency.
E
E
Go
ahead,
no
go
ahead.
Probably
the
work
involved
in
maintaining
the
the
plugin
for
the
network
policy
won't
be
that
hard.
So
it's
not
as
important
as
as
I
may
think
right
now,
but
I
don't
know,
I
don't
see
if
there
are
other
advantage
that
we
should
consider
before
considering
both
both
approaches.
At
the
same
time,.
A
Yeah,
I
think
the
the
main
the
main
thing
about
running
two
would
just
are
having
both
rather,
which
would
just
be
like.
We
could
publish
it
and
then
like
basically
give
people
a
note
that
says
like.
Let
us
know
if
you
use
this
and
if
it
worked
out,
if
it's
more
easy
for
you
to
deploy
or
whatever
we
can
kind
of
do
that,
theoretically,
just
by
sending
out
a
mailing
list
without
having
it
available.
A
Yeah
kind
of
I'm
I'm
actually
curious
do
have.
Has
anyone
like
I
I
maybe
this
is
information
we'll
get
from
the
mailing
list
I'll
be
curious
to
see
if
anyone
has
like
every
once
in
a
while,
we
consider
a
change
like
this
and
someone's
like.
Oh
yeah.
I've
already
been
doing
that
by
hand
for
a
while.
Now
it
works
great
or
something
like
that.
So
I'm
curious
to
see
if
we
got
any
of
that.
C
I
also
think
that
it
would
be
easy
if
you
have
the
alpha
plugin,
because
it
should
allow
people
cry
out
in
other
vendors,
because
they,
you
know
a
lot
of
people
can
say
yeah
it's
nice,
but
you
never
use
it.
So
if
you
have
the
alpha
the
present
thing,
actually,
you
know
try
to
deploy
the
project
with
that.
A
All
right,
I
think,
maybe
let's
move
on
since
we
still
have
a
few
things
on
the
agenda
for
today.
I
think
the
rest
of
yours
are
or
the
rest
of
them
are
yours,
camilla.
So
do
you
want
to
just
start
those
in
whichever
order.
C
Sure
you
try
okay,
so
my
my
next
one
is
like
in
the
plugin
very
soon
supported
by
support
a
village
policy.
It's
like
hey
more
for
we
discuss
if
you
should
support
the
less
the
lasers
very
strongly
or
like
two
versions
ago.
C
My
thoughts
on
that
is
like
we
supported
those
two
delays
as
the
one
versus
booking.
I
would
not
like
to
support
two
versions
back,
because
he,
I
think
he'll
be
harder
to
maintain,
but
I
would
like
to
know
watch
the
other
things
as
well.
B
B
Bet
I
just
use
six
months
as
an
example.
I
would
imagine
that's
around
the
turnaround
time
for
a
plug-in.
Maybe
it's
longer
who
knows,
but
maintaining
two
plug-ins
is
like
yeah.
It
does
increase
complexity
a
little
bit,
but
it's
also
not
that
bad,
especially
when
we're
not
adding
we're
not
like
breaking
a
bunch
of
stuff
in
those
plugins
anymore,
because
we
can't.
C
A
So
to
to
be
do
we
do
we
mean
too
too
stables
and
and
and
nightly
so
to
speak?
Or
do
we
mean
one
stable
and
one
nightly
when
we
say
like
when
we
say
m
minus
one
or
minus
two
right,
like
nightly
being
whatever
someone
decides
to
build
off
of
our
development
branch
right
like.
E
I
think
that
we
also
have
to
consider
that
we
can
have
deprecated
versions,
so
we
can
have
unstable
ones.
That's
the
developing
one,
the
nightly
one.
Then
we
can
have
either
one
or
two
stable
ones
and
the
deprecated
one,
which
won't
receive
any
change,
but
we
should
leave
it
at
least
for
another
cycle.
C
C
A
Oh,
I
was
just
gonna
say
I
think
we
can
also
like,
perhaps
a
little
bit
more
confusingly
if
we
need
to.
If
we
really
want
to
say
something
like
we
could
say,
you
know,
n
minus
two
gets
bug,
fixes
n
minus
one,
gets
bug,
fixes
and
opportunistic
back
ports
right
so
like.
If
someone
says,
can
you
backport
this
feature?
A
We
say
yes,
we'll
do
it
to
n
minus
one
and
then
obviously
nightly
gets
features,
bug
fix
or
or
or
like
maybe,
n
minus
one
always
gets
features
as
long
as
the
back
port
is
is
easy
and
minus
two
only
gets
features
when
people
specifically
ask
for
them
or
whatever
right
like
we
could
we
could
we
could
we
could
have
that
policy
like
the
the
number
of
minuses
we
go
back
depend
on
what
the
type
of
change
is,
and
that
might
make
things
easier
for
us.
D
So
that's,
like
you
know,
you're,
probably
going
to
be
on
one
slightly
older
than
you
want
to
be,
while
you're
waiting
for
the
new
one
to
get
to
the
place
where
you
can
actually
swap
over
to
it.
You
can
only
swap
over
to
it
once
it
exists.
So
if
you
kind
of
have
to
have
like
usually
n
minus
two
just
to
do.
D
E
I
kind
of
agree
with
that
with
that
approach
like
having
for
the
nightly
one,
the
stable
one,
one
in
like
end
of
life,
that
it's
only
receiving
book
fixes
and
then
the
other
one
would
be
deprecated
and
after
that
cycle
it
would
be
removed.
D
A
Okay,
so
does
every
is
everyone
sound?
Anyone
have
any
objections
to
what
was
just
proposed,
where
we
we
go
with
like
nightly
and
then
features
and
bug
fixes
for
n
minus
one
and
then
just
bug
fixes
for
n
minus
two.
D
B
Just
before
we
go
on
are
you?
Are
you
gonna,
take
the
liberty
of
writing
that
up
camilla,
or
do
you
want
somebody
else
to
do
it.
A
D
C
Can
we
move
it
for
the
next
one
or
I
have
someone
any
other
input
about
cheese?
One.
E
C
Okay-
next
one,
I
utilize
kitchen
in
kobe
builder,
is
called
forge.
They
go
like
ci
lynch.
That
is
the
mostly
usage.
C
It
is
the
same
niche
that
we
have
in
the
content
time
in
sdk
and
kobe
builder,
and,
however,
the
idea
would
be
just
shelter,
helping
the
making
file
engine
day,
also
scaffolding,
its
config,
which
would
be
basically
they
could
be
building
the
same
configuration
using
the
kobe
builder
and
the
advantage
the
motivations
to
do
that
is
like
to
promote
good
practices,
help
the
users
know
how
they
can
improve
the
quality
of
their
projects.
C
C
They
try
to
link
to
our
the
projects
that
are
built
with
the
tool,
because
it
shows
that
they
are
not
pricing
the
linker.
So
if
we
add
the
help,
we
will
test
that
automatically
in
the
ci
now,
which
I
think
is
the
most
important
thing.
The
helper
itself
just
ensure
that
the
project
that
you
provide,
the
scaffold
that
we
provide
for
the
users
are
linked.
A
So
I
I
kind
of
I'm
gonna
my
my
opinions
on
this
is
is
I
have
kind
of
two
split
opinions?
I
think
I
think
linting.
What
we
produce
like
in
our
ci
is
a
good
idea.
I
think
we
can
say,
like
our
scaffolded
stuff,
conforms
to
the
same
lengths
that
we
we
use
on
the
q
builder,
codebase
or
whatever,
and
we
make
sure
that's
aggressively
true
for
us.
A
A
I'm
not
necessarily
against
it,
but
I'm
not
convinced
that
we
should
how
much
we
should
scaffold
out
the
golang
c
island
lint
for
our
users
by
default,
because
not
all
of
those
are
so
we
say
widely
accepted
and,
like
I
guess
we
have
we
have.
We
certainly
have
opinions
in
cube
builder
on
on
what
to
do,
but
I'm
not
sure
how
annoying
that
would
be
out
of
the
box
for
people,
because
I
I
definitely
know
there's
ones
that
are
are
like.
E
Also,
I
could.
I
would
like
to
also
mention
that
there
is
another
issue
here.
If
we
choose
to
go
with
a
golang
ceiling,
that's
choosing
one
vendor,
that's
and
it's
not
choosing
a
vendor
for
our
own
code,
but
it's
choosing
a
vendor
for
users.
E
C
C
I
don't
I
don't
care
about
somebody
bts
vendor
or
not,
because
I
believe
that
is
the
most
used.
I
agree
with
the
rules.
Each
person
has
itchy,
it's
very
opinionated,
so
the
config
it's
hard
to
achieve
their
consensus.
C
E
C
A
C
Pictures:
okay,
sorry
for
the
grammar
or
anything
it's
just
you
for
right.
Remember.
I
hope
that
makes
sense
the
text
to
the
child,
the
other
one.
It's
it's
easy,
it's
more
than
nice.
We
have
two
issues,
maybe
it's
easier
if
we
just
shopping
these
issues
in
the
screen,
but
we
have
two
issues
to
recognize
the
content
on
time.
C
One
of
them
is
to
to
change
the
default
place.
Where
invites
you'll
be
looking
for
the
binaries
that
are
required
for
each
now,
it
is
looking
at
place
that
today,
users
need
to
do
the
sudo
permission
to
push
change.
It
has
other
problems
as
well,
which
are
listed
in
the
issue
into
the
other
one.
It's
about.
C
Should
we
transform
the
scripting
a
goal
model
to
simplify
the
usage
in
kobe
builder,
because
now
we
have
a
making
file
test,
so
if
that
is
not
very
understandable
and
readable
for
the
indie
users,
so
my
opinion
would
be
better
on
the
model
approach
and
today
I
would
like
to
know
if
you
can
like
keep
your
eyes
that
change
booty
for
the
next
milestone
to
try,
you
know
so
far.
Is
that
also?
It
should
be
a
break
change
for
the
1.0
cuts.
C
Ng
could
be
builder
users
with
the
v3
plugin.
We
are
not
able
to
debug
and
troubleshoot
the
tests
that
you
are
discovered
by
the
food
using
the
idea
or
try
to
run
the
tests
outside
of
the
making
fire
test
that
is
provided
as
well.
You'll,
not
work
as
well.
Because
of
this,
these
changes
in
the
configuration
are
not
working.
Now,
if
you,
I
could
not
explain
properly.
A
Yeah,
so
I
I
think,
like
my
my
position
on
this
is,
I
think
it
would
be.
A
I
think
if
we
change
where
we
store
the
binaries,
we
should
have
accompanying
like
default
search
path,
changes
for
controller
runtime,
and
we
should
tackle
as
much
of
this
in
controller
runtime
so
that
all
our
users
can
get
the
benefit
of
what
we
do.
A
and
b
we're
not
like
we're
we're
continuing
to
kind
of
rely
on
the
default
behavior
of
controller
runtime,
as
opposed
to
like
scaffolding
out
more
and
more
code
for
search
paths,
specifically
in
cue
builder
projects.
A
A
Yeah
we
can,
we
can
maybe
also
like
you
know,
depending
on
what
we
do
to
the
search
path
and
whatever
we
can
at
the
very
least
we
can
hint
like.
Hey.
Did
you
remember
to
set
you
know,
q
builder
underscore
assets?
If
not,
do
you
have
q
built?
Do
you
have
the
control
plane
binaries
in
your
go
bin
path?
A
C
F
A
C
C
I
can
go
there
and,
for
example,
the
book,
which
is
a
common
approach
for
the
users,
a
lot
of
people.
The
idea
is
all
codes
or
calling.
However,
then
cheesy
work
only
if
I
have.
C
D
C
C
C
C
If
I
try
to
do
the
same,
and
you
face
the
echo
and
today
for
the
users,
in
my
opinion,
for
the
users
know
that
changing
tests
he
uses
the
binary
things
blah
blah
blah.
It's
like
a
cheaper,
it's
like
requiring
a
deeper
knowledge
and
you,
the
biggest
part
like
just
don't
want
to
date.
You
know
just
you
want
to
use
this
style
things
developing
their
tests
with
shelter
care,
actually
how
the
things
really
works.
You
know.
A
So
I
I
want
sorry
when
I
said
bin-
I
didn't
mean
user
local,
cue
builder
bin.
I
meant
go
bin.
I
I
think
there
was
talk
on
that
other
issue
you
mentioned,
of
of
making
it
so
our
tooling.
A
Downloads
into
gobin,
and
in
that
case,
we'd,
have
a
well-known
path
and
instead
of
like
scaffolding
out
new
search
paths
or
whatever,
the
only
thing
we
need
to
do
would
be
to
scaffold
out
like
maybe
have
a
have
have
a
package
that
was
just
like
the
default.
The
current
default
kubernetes
version
to
run
m
test
with
for
this
project
or
something,
and
if
you
didn't,
if
in
that
way
like
because
I
I
I
I'm
definitely
in
favor
of
just
being
able
to
run,
go
test
and
and
being
able
to
get
reasonable
results.
A
A
C
Yeah,
I
agree
with
you
one
less.
We
would
like
that.
They
know
they
be
aware
that
we
have
that
these
beings
are
required
and
they
are
set
in
some
place.
They,
I
think
the
best
approach
would
be.
We
try
to
it's
called
fold.
C
There's
one
line
that
you
decide
to
depend
in
the
here
in
the
in
the
switch
test,
which
is,
let's
see,
should
I
have
it
here?
What
requests
maybe
to
be
the
context
for
the
others
as
well.
A
A
Yeah,
so
I
think,
for
as
a
little
bit
extra
context,
I
think
they're
v
v3
was
changed
to
download
into
local
directory
sash
bin
right
for
m
test
asset
or
into
a
like
a
tools,
module
or
something.
Okay.
I
I
don't
remember
one
of
the
v3
folks.
B
A
I
had
suggested
that
we
download
into
gobin,
with
like
version
suffixes,
that
way
we're
like
if
people
have
a
lot
of
projects
or
whatever
we're
not
downloading,
like
50
copies
of
the
control
plane,
because,
like
the
control
plane's,
not
small,
it's
it's
in
the
order
of
like
hundreds
of
megabytes,.
A
And
if,
if
we
did
that
like,
we
could
instead
of
scaffolding
out
like
additional
search
paths,
we
could
just
have
like
a
here's.
The
global
kubernetes
version
to
use
for
this
project
from
m
test
somewhere
like
as
a
const
and
then
the
scaffold
would
be
like
const.
A
C
My
only
concern
about
that
is
the
time.
Do
you
know,
because
he
a
lot
of
people
raised
his
these
questions
for
me,
sometimes
or
in
the
channel,
and
you
saw
that
in
the
sdk
survey
a
lot
of
users
saying
I
I
would
like
to
troubleshoot
and
to
debug
my
tests.
C
C
Now
we
have
a
cheesy
scripture.
Do
you
know
so
the
approach
would
be
like
a
first
show.
Where
is
the
cheese?
One?
Sorry,
that's
the
chocolate
fact.
The
first
hos
I
saw
the
explain,
we
changed
the
default
place,
it's
looking
in
the
goal
being,
which
is
this
issue
into
the
second
one?
Try
to
improve
sorry
for
my
mess.
C
A
C
Yeah,
I
agree
if
you
really
realize
that
it's
fine,
the
other
option
that
should
be
like
he
is
a
lie,
more
squeeze
you
to
be
like
with
scaffolds
just
cheese.
Do
you
know
and
you
pass
the
path
for
the
configuration,
and
today
we
are
also
making
clear
for
the
users
that
it
is
stuff.
You
require
some
assets,
something
you
know
because
someone
that
you
get
to
the
code.
C
You
look
she's
required
something
that
she
is
in
my
being
directory
by
the
phone
now
and
also
you'll
solve
the
problem
when
they
want
to
use
the
specific
variation
per
project
changing
not
to
solve
globally.
C
So
I'm,
okay,
if
you
don't
scope
forward
to
that,
but
I
think
we
need
you
to
prioritize
and
advantage,
in
my
opinion,
just
comfort
that
is
like
improve
the
learning
curve
demonstrated
that
it
is
staffing
by
nervus
and
it
is
binaries,
are
in
the
beam
and
they
can
change
that
as
they
wish.
If
it
is,
is
something
that
we
consider
important.
B
B
So
by
doing
this
now
we'll
probably
have
to
remove
it
pretty
quickly
afterwards,
because
we
are
prioritizing
this,
and
this
will
be
resolved.
I
think,
before
3.0.0
stable
is
released,
I'm
I'm
willing
to
work
on
it
in
controller
runtime.
If
nobody
else
is.
C
Yeah,
I
think
I
will
have
no
time
to
to
work
on
that,
because
this
I
I
decided
to
like
first
of
all
raise
the
the
scenarios
in
the
meeting
before
we
make
it
clear
the
problem
that
I
believe
that
she's
now
very
clear,
and
he
described
you-
know
the
the
issues
and
to
see
if
someone
can
help
on
that.
Because,
okay,
if
you
don't
want
discomfort
that
I
agree,
I
understand
to
the
motivations,
I
believe
that
the
biggest
priority
of
the
users
don't
need
to
know
that
at
all
you
know
it's
simple.
C
A
I
mean
yeah,
we,
and
we
would,
we
would
still
have
like
it
would
still
be
a
hierarchy.
So
if
you
set
cue
builder,
assets,
we'd
still
go
from
key
builder
assets,
probably,
and
that
that's
gives
you
continues
to
give
you
the
escape
hatch
for
like.
I
need
to
use
this
particular
version,
or
this
particular
binary
that
we
have
today.
C
A
No
camilla,
we
we
do
both.
So
if
q
builder
assets
is
set,
we
use
q
builder
assets
if
q
builder
assets
is
not
set.
We
look
at
you
know:
go
bin,
slash,
blah
blah
blah
blah
right
like
if
that's
not
set,
we
use
user
local
cube
builder
and
then,
if
none
of
those
are
set,
we
throw
an
error
message
that
says:
hey
could
not
find
control
plane.
Binaries
we
really
need
them
here
are
here
are
three
places
that
they
should
be.
A
C
A
Yep,
it's
it's
1003,
so
I
think
we
got
a
break
but
yeah.
A
Yep
thanks
thanks.
Everyone
see
y'all
in
the
new
year,
have
a
good
new
year
and
happy
holidays.