►
From YouTube: Kubernetes KubeBuilder Meeting 20200910
Description
KubeBuilder Meeting for 2020/09/10. See https://sigs.k8s.io/kubebuilder for more details.
A
B
Hi
there
camila
do
you
want
to
get
started
or
I'm
happy
to
introduce
as
well.
Let's
go,
you
can
go
gabi.
Are
you
sure
thank
you
so
camila-
and
I
were
talking
yesterday
about
just
formalizing
a
bug
triage
process
for
qbuilder,
because
we
like
she
brought
up
that
there
are
about,
like
almost
20
outstanding,
bugs
that
we
would
like
to
carve
time
out
to
investigate.
B
So
our
plan
was
to
just
come
up
with
another
bi-weekly
meeting.
That
would
probably
be
shorter
than
this
one
about
30
minutes
in
which
we
just
triage
and
assign
bug
issues
to
folks
to
investigate.
C
Yeah,
I
just
would
like
you
to
say
one
thing
I
gabby
and
I
was
searching
jesus
like
a
camilla
community
contributor.
It
doesn't
know
the
the
opinion
of
the
thing
that
I
work
in
the
redhead
just
to.
A
I
think
a
triage
meeting
sounds
like
a
reasonable
idea.
I
I
definitely
think
we
could
give
it
a
try
at
the
very
least
for
a
couple
of
meetings.
A
I
think
the
these
tend
to
depend
on
like
how
how
much
how
much
people
actually
end
up
falling
through
on
them,
but
I
think
I
think,
having
a
triage
meeting
would
be
a
good
idea
to
try.
Definitely.
C
D
We've
been
doing
triage
meetings
in
6th
july,
eddie
zanski
has
been
running
those
and
it's
been
pretty
pretty
successful,
at
least
at
having
discussions
around
the
topics
and
making
sure
that
they
are
at
least
responded
to
the
my
big
takeaway
is.
D
It
requires
like
a
lot
of
work
on
eddie's
part
to
like
prepare
for
the
meeting
to
the
extent
where
they
kind
of
have
a
plan
to
go
through
and
moderate
and
make
sure
every
two
weeks.
We
do.
We
do
one
every
other
week,
but
if,
if
you,
you
could
probably
reach
out
to
eddie
too
and
ask
them
if
they
have
any
tips.
C
A
I
think
we
now-
I
don't
know
if
you
all
saw,
but
I
think
we
now
have
official
like
triaged-
needs
triage
labels
and
stuff
that
the
project
as
a
whole
is
going
to
be
using
and
possibly
something
that's
auto,
assigning
them
that
we
could
turn
on
so
that
might
at
least
help
with
keeping
track
of
things.
A
Sorry
for
clarification,
the
mailing
list,
I
think,
was
the
kubernetes
mailing
list.
I
think,
is
where
I
saw
that
the
kubernetes
dev
one
so
there's
a
lot
of
mailing
lists
in
this
project.
I
should
probably
be
specific.
A
All
right
does
anything
else.
Anybody
else
have
any
input
they
would
like
to
add
or
camilla
or
gabby.
Do
you
have
anything
else?
You
want
to
add.
A
A
First,
I
I
all
right,
I
think
phil
has
a
cool
project
that
he's
been
working
on
now
that
he
wanted
to
talk
about
briefly.
D
Yeah
thanks
sally,
I
put
some
links
in
there.
I
share
my
screen,
but
I'm
tethering
right
now
because
of
internet
challenges
at
home,
but
the
the
idea
is
looking
at
the
apa.
D
The
there
is
the
api
server
builder
project
that
was
started
some
time
ago
and
was
the
kind
of
precursor
to
coup
builder,
and
it
does
a
lot
of
has
a
lot
of
ideas
that
were
developed
before
kind
of
the
experience
of
controller
runtime
and
relies
a
lot
on
code
generation
and
these
sorts
of
things
and
I've
been
exploring
if
those
ideas
were
really
necessary
or
if
we
could
apply
the
ideas
in
coup
builder
and
controller
runtime,
and
I
think
I've
been
relatively
successful,
you
can
open
up
the
sample
link.
D
The
second
one
will
bring
you
to
kind
of
the
main
program
of
what
this
looks
like
for
a
sample,
and
it
follows
the
controller
runtime
builder
pattern,
for
instance,
of
adding
resources
and
these
sorts
of
things
the
motivations
for
this
there's
basically
three
high
level
ones
that
I
think
are
interesting,
wins
that
aren't
addressed
by
series:
the
the
crds
and
the
coup
builder
libraries
as
they
stand
today.
D
One
is
if
you,
if
you
want
to
create
a
virtual
api
that
doesn't
have
storage,
and
you
really
just
want
a
rest
interface.
I
think
that
we
already
have
some
of
these
in
the
kubernetes
project,
where
the
like
events
may
not
be,
I'm
not
sure
if
it's
events
or
something
else
solid,
probably
knows,
but
but
there's
at
least
one
where
what
was
that.
D
Metrics,
thank
you
there.
It
is
events
use
a
different
at
cd
instance
or
something
yeah
so
like
metrics
would
be
an
example
of
this.
D
A
second
in
related
piece
would
be:
maybe
you
want
to
store
something,
but
at
cd
isn't
the
right
storage
because
of
the
size
limits
of
the
of
the
of
the
values
or
because
maybe
you
want
better
indexing
or
you
want
a
managed
service,
so
you
want
to
use
just
like
postgres
compatible
api,
or
something
like
that
that
you
could
just
spin
up
on
a
different
cloud
provider,
and
so
that
would
give
you
different
properties,
but
still
the
ability
to
create
a
kubernetes
api
and
crd
wouldn't
really
support
that
case.
D
Well
and
then
the
third
case
is
around
creating
arbitrary
sub
resources.
I
know
that
the
the
kubernetes
the
crds
are
looking
at
different
sub
research
support,
and
so
that
may
be
available
in
crds
at
some
point
in
time,
but
the
the
api's
for
variation
definitely
supports
it
now
and
those
don't
necessarily
require
storage.
So
you
may
have
a
sub
resource
for
something
that
that's
really
just
modifying
an
object
stored
through
a
security
or
something.
So
that
would
be
a
fun
way
of
doing
that.
And
then
I
guess.
D
The
fourth
thing
I
haven't
really
listed
here
is
that,
besides
the
if
you
take
out
the
at
cd
storage
piece,
but
if
you're,
if
you're,
looking
at
the
complexity
of
building
a
crd
with
maybe
a
validating
web
hook
and
a
mutating
web
hook
for
defaulting
and
then
type
conversion,
so
you
have
conversion
web
hooks
and
so
you're
you're
stitching
together,
like
a
lot
of
different
potential,
potentially
stitching
together
like
a
lot
of
different
services
and
web
hooks
and
configuration
and
that
it
it
could
be
simpler.
D
So
that's
the
motivation
behind
this.
The
implementation
is
really
I
just
forked
the
sample
api
server.
That
demonstrates
api
server
aggregation
and
I
put
in
a
couple
lines
of
hooks.
So
there's
a
couple
areas
where
there's
a
code
specific
to
the
types
in
there,
and
so
I
replaced
those
with
essentially
variables
that
you
can
add
to
like
maps
that
has
the
apis
instead
of
hard
coding,
the
apis.
D
So
there's
really
just
a
couple
places
where
that
was
necessary
and
then,
in
addition
to
that,
I
built
a
porcelain
library
that
then
exposes
a
bunch
of
niceties
around
how
to
register
into
those
like,
for
instance,
one
thing
it
does
is
it
makes
heavy
use
of
interfaces
for
types,
so
you
can
implement
instead
of
like
defining
a
strategy
with
the
namespace
or
something
like
that.
You
just
implement
an
interface
on
the
types
and
so
then
the
porcelain
will
go
and
automatically
configure
the
api
server.
Accordingly,.
D
So
I
guess
what
I'm
asking
or
bringing
this
to
this
meeting
for
is,
if,
if
there's
interest
from
the
group
to
host
this
as
part
of
a
coup
builder
sub
project,
would
we
want
to
put
this
like
have
a
repo
for
this?
If
not
there's
interest
in
the
api
server
builder
subproject
to
host
it
there,
so
that
like
that,
would
be
a
possibility.
D
But
I
think
if,
if
we
see
this
being
more
widely
used
or
if
there's
interest
from
the
coup
builder
community
in
adding
this
to
the
list
of
tools,
then
co-builder
would
probably
be
a
better
place
for
that.
Repo.
A
A
For
historical
context
and
for
anyone
who
isn't
super
familiar
with
the
kind
of
org
structure
of
our
sub
project,
so
cube
builder,
is
under
the
sub
project,
called
the
server
sdk
sub
project
of
sig
api
machinery.
A
The
kind
of
most
active
parts
of
this
are,
I
believe,
the
cube
builder
project
projects
and
I
think
api
server
builders
alpha
is
still
being
maintained
and
then
there's
also
like
the
sample
api
server
and
sample
controller
repos,
which
demonstrate
like,
if
you
are
writing
from
scratch,
how
you
might
write
a
controller
or
an
aggregated
api
server.
D
The
the
hope
is
that
the
api
server
builder
or
sorry
yeah,
the
api
server
builder-
could,
for
instance,
swap
out
all
of
its
code
generation
for
for
this
approach
and
then
become
a
much
simpler
project,
and
if,
if
this
was
done
as
part
of
I
guess
sorry,
are
you
thinking
that,
regardless,
if,
if
a
kubernetes,
if
the
server
sdk
wanted
this,
it
would
probably
be
under
coup
builder,
regardless
of
whether
it's
you
know
more
closely
tied
to
the
api
server
builder
portion
of
it
or
the
controller
runtime
portion
of
it.
A
C
What
what
about,
if
we
put
a
design
a
dock,
we
see
an
example
over
how
to
solve
what
kind
of
problems
could
you
be
so
vegetarian's
approach?
How
do
you
know
the
users
would
use
it
is
with
a
kobe
builder?
Maybe
would
it
be
easier
to
get
its
advantage?
What
do
you
think.
D
C
Yeah,
I
think
in
the
in
the
in
the
complete
builder,
has
a
design
dock,
but
anything
because,
at
least
for
me
sometimes
the
ideas
is
a
little
bit
obstructed.
You
know
I
can
get
to
the
goal,
but
I'm
I'm
not
sure
if
I
understood
what
a
hundred
percent
your
motivations,
you
know
anything
how
you
think
that
the
users
would
use
that
with
the
two.
C
D
Why
don't
we
try
this
I'm
going
to
try
to
share
my
screen
and
then
we're
going
to
see
if
the
bandwidth
deities
are
are
being
kind
today.
A
D
A
D
I
don't
have
a,
I
wouldn't
have
a
preference
like
I.
I
guess
why
I
should
say
I
suspect
the
the
thing
that
seems
cleanest
to
me
is
its
own
repo,
like
a
sibling
of
controller
run
time.
It's
the.
I
know
that
people
are
using
api
server
builder.
D
And
doing
a
major
version
with
a
branch
in
there
I
think,
might
be
more
challenging,
especially
since
there's
the
name
of
the
maybe
because,
like
I
can
like,
we
have
coup
builder
and
controller
runtime,
and
so
I
think
of
this
as
like
the
controller
runtime
equivalent
of
which
api
server
builder
doesn't
have
one.
So
even
if
we
were
to
do
a
version,
two
mirroring
that
structure,
I
think,
would
still
make
sense
to
me.
D
I
don't
have
any
objection
to
putting
it
as
part
of
like
controller
runtime.
If
there
was
a
if
you
felt
if
you
had
a
preference
for
that,
I
probably
would
lean
against
it
simply
because
the
I
wouldn't
want.
I
know
that
the
controller
runtime
is
a
more
mature
right
and
it's
versioned,
like
people
have
come
to
expect
certain
things
about
it's.
D
Maybe
it's
versioning,
and
if
we
put
this
as
its
own
repo,
we
can
version
it
as
like
zero
one,
zero
and,
and
then
people
understand
the
level
of
maturity
to
expect.
A
Okay,
I
think
I
think
that
I
think
we're
kind
of
on
the
same
page.
I
think
I
think
those
are
those
are
good
arguments.
I
think
a
separate
repo,
maybe
api,
server
runtime,
makes
sense.
D
Yes!
That's
exactly
what
it's
named
now,
so
that
that
was
my
initial
thought
as
well.
D
So
camilla
or
does
any
any
other
thoughts
there
sally
or
should
I
show
the
code
a
little
briefly
here.
A
A
We
have
time
for
a
brief
code.
Demo
go
ahead.
D
All
right
I'll
go
through
just
real
real
quickly
here,
so
here's
like
the
main
page,
if
you're
able
to
see
it.
This
would
be
like
what
your
main
looks
like
you
can
see
lines
32
to
37,
look
familiar
with
the
controller
runtime
builder,
and
it
has
a
similar
approach
where
we
register
you
know
instances
of
the
types
and
then
it
does
kind
of
auto
registration
for
you,
this
one
there's
a
couple
different
ways:
I've
been
looking
at
this.
This
is
kind
of
the
simplest.
D
What
I'm
trying
to
demo
here,
but
there
are
more
powerful
and
flexible
ways
it's
much
like
controller
runtime,
it's
built
on
layers
in
this
case,
what
I've
done
you
can
see
the
types
here.
I've
made
the
option
to
put
a
lot
of
the
logic
directly
on
the
type,
so
it
looks
more
like
a
rails
application
or
your
typical
rest
service
building
approach.
This
is
not
required.
D
It's
just,
and
you
can
always
split
this
out
later,
so
it's
not
a
hard
decision,
but
I
think
it
gives
a
nice
simple
demo
and
it's
easy
to
understand
as
your
first
step.
D
D
What
it
does
is,
it
runs
the
fortune
command
and
then
prints
out
a
fortune
for
you
and
then,
if
you
give
it
a
name,
you
get
a
name
to
fortune,
then
it
will
find
a
fortune
that
has
that
string
as
part
of
the
fortune,
and
if
you
do
a
list,
you
can
you'll
get
a
list
of
fortunes
so
rather
than
while,
you
can
still
continue
to
do
the
way
the
api
server
works
by
default.
In
this
case,
we've
decided
to
just
register
implement
these
interfaces.
D
The
storage
interfaces
directly
on
the
type
again
this
wouldn't
work
as
well.
If
you
wanted
to
export
these
types
as
a
api,
but
if
you're
building
just
your
own
api
for
usage,
this
may
be
a
good
way
to
go
so
there's
this
convert
to
table
that
does
the
printing,
for
instance,
and
so
it
automatically
when
you
call
control
git,
it
will
make
sure
that
this
gets
invoked.
D
And
it
implements
list
right
so
this,
rather
than
registering
at
cd
storage,
this
gets
invoked
same
thing
with
git,
so,
whatever
functions
you
happen
to
implement,
get
invoked,
you
can
see
here
doing
the
fortune
exact,
for
instance,
and
then
it
implements
these
other.
These
other
functions
to
just
make
it
so
that,
instead
of
having
to
wire
them
from
other
pieces
of
the
code,
you
can
the
type
itself
knows
all
the
data
required
to
expose
its
endpoint.
D
So,
for
instance,
it
rather
than
like
passing
in
explicitly
here's
a
new
instance
function
for
this
thing,
like
the
object
itself
knows
how
to
create
a
new
one.
So
just
by
passing
in
an
instance,
it
knows
how
to
register
both
the
new
and
new
list
functions.
It
would
give
to
the
the
storage
same
thing
with
namespace
scoped
it
just
instead
of
having
to
put
this
as
part
of
a
strategy,
you
do
it
here.
D
One
thing
we've
done
is
gotten
rid
of
the
internal
versions,
so,
instead
of
having
a
hub,
that's
like
its
own
internal
version
in
the
vast
majority
of
cases
like
a
one
of
the
external
versions,
would
have
been
totally
sufficient
and
actually
would
solve
a
lot
of
issues
where,
like
libraries,
work
against
the
internal
version,
but
other
folks
want
to
use
those
libraries
and
now
they
can't
use
those
libraries
because
they're
internal
right
and
so
by
just
using
an
external
version
everywhere
and
just
picking
one
of
the
external
versions
as
the
hub
that
that
problem
goes
away.
D
D
You
get
the
object
metadata.
This
is
used
by
there's
a
lot
of
places
where
otherwise
they're
hard
coded,
like
just
getting
the
object
metadata
and
taking
out
the
labels
or
something
so
rather
than
hard
coding,
the
type
to
get
the
object
meta.
We
just
implement
an
interface
same
thing
here.
This
tells
us
where
to
register
it,
so
this
is
how
the
the
machinery
is
able
to
register
it.
D
So
that's
like
a
more
complicated
type
that
implements
its
own
sort
of
rest
thing:
here's
like
kind
of
the
the
ones
from
the
sample
api
server,
what
they
look
like.
So
these
are
much
simpler.
D
This
just
takes
regular
storage
and
but
instead
of
having
to
implement
strategies
and
all
this
and
strategies
and
rest
stuff,
you
just
implement
these
six
functions
about
how
to
get
a
new
list
object,
having
a
new
object,
whether
it's
a
namespace
scoped,
whether
we
should
use
this
as
the
hub
get
the
object
metadata
and
actually
this
one's
optional,
you
don't
even
need
to
implement
that
one.
D
All
right,
this
is
done.
Most
of
the
logic
is
in
this
builder
package,
and
so
the
builder
implements
a
bunch
of
different
stuff
like
it.
So
I
just
show
you
the
with
resource,
but
if
you
really
want
to
have
the
strategy
as
a
separate
thing,
there's
like
a
with
resource
and
strategy,
so
you
can
decouple
those
or
there's
with
restores
and
handler,
which
is
effectively
the
storage.
D
But
I've
called
it
handler
because
I
think
the
users
will
think
of
it
as
a
rest
handler
and
it
doesn't
necessarily
store
an
object
and
then
there's
with
resource
and
storage,
and
that
does
this
that
changes
actually
the
generic
storage,
rather
than
so,
it
uses
a
storage
function.
D
There's
also
some
resources
for
registering
so
you'd
register,
the
parent
and
then
the
path,
and
then
the
request,
object
and
then
strategy
and
and
handler
look
pretty
much
this
somewhere
there
and
then
there's
a
number
of
different
options
for
doing
deep,
customizations
right.
So
you
can
swap
you
can
modify
the
server
options
for
the
generic
api
server
just
in
time
before
those
are
built,
and
you
can
add
additional
schemas
and
different
installers
into
those
schemas
by
default.
D
We
do
we
try
and
do
clever
stuff
right
like
so
again
looking
at
kind
of
the
way
the
the
interfaces
work
right
if
you
implement
a
defaulting
function
on
the
type
instead
of
us
making,
you
register
it
with
the
scheme
as
kind
of
boilerplate
code
that
you
copy
and
paste
when
we
register
that
resource
we
just
check.
Are
you
a
default?
Do
you
implement
defaulting?
Okay?
Yes,
let's
just
register
your
defaulting
function
for
yourself,
so.
E
A
Sure
does
anybody
have
any
thoughts
that
they'd
like
to
add
or
anything
else
they
want
to
talk
about.
A
It
doesn't
sound
like
it
in
that
case,
I'll
see
y'all
either
in
a
couple
weeks
or
when
we
figure
out.
If
we
figure
out
the
triage
meeting,
and
we
schedule
that
for
next
week
I'll
see,
you
then
wait.
A
F
I
thought
you
meant:
is
there
anything
else
to
talk
about
about
that
particular
agenda
item
beforehand?
Okay,.
F
Oh
you're,
fine
yeah,
so
I
have
a
pr
up
for
adding
v1
web
hook
and
crd
sport
to
cue
builder.
F
I
just
want
to
make
that
known
for
anybody
who
is
thinking
about
making
the
switch
themselves
for
their
controller
projects,
and
I
want
to
discuss
here
some
of
the
ux
around
leaving
v1
beta
1
support
in
builder.
F
Will
be
deprecating
or
has
deprecated
now
that
it's
released
v1
beta,
1,
crds
and
v1
beta
1
web
hook?
Configs
have
been
deprecated
since
116.,
so
it's
a
prime
time
to
just
switch
over
to
these
things.
By
default,
there
were
a
few
dependencies
that
needed
to
be
worked
on
like
controller
gen,
generating
v1
web
hooks
and
yeah.
So
so
now
that
those
dependencies
have
been
resolved,
this
pr
can
move
forward,
but
we
also
probably
should
continue
to
support
scaffolding
patches
and
customize
configs
for
v1
beta1,
my
books
and
crds.
F
F
Or
do
you
want
to
just
allow
scaffolding,
one
version
or
the
other
or
just,
and
I
guess
the
most
restrictive
case
that
I
don't
think
we
want
to
do,
but
I'll
put
it
out
there
anyway.
Only
allow
v1
web
hooks
and
crds
to
be
scaffolded,
and
then
we
don't
have
to
worry
about
any
of
the
ux.
It's
just
done
for
us
and
that's
basically
what
we
have
right
now,
but
for
v1.
F
So
are
there
any
thoughts
on
this?
I,
I
guess
I'll
also
say
that
the
way
it's
done
right
now
is
kind
of
option,
two,
where
you
can
choose
between
v1
or
v1
beta1
for
both
web
books
and
crds,
and
that
is
that
choice
is
available
through
flags
on
all
three
or
all,
two
creation
commands
and
init,
and
the
reason
that
there
are
so
many
flags
on
so
many
commands
is
that
there
are
several
pieces
of
code
and
the
init
commands
that
require
a
choice
between
those
two
versions
and
in
create
api.
F
Obviously
we're
creating
crd
patches
and
customizations,
so
that
choice
needs
to
be
made
for
crds
and
then
for
web
books.
Same
thing.
A
F
That
is
something
that
I
thought
about.
Do
you
have
like
off
the
top
of
your
head
right
now?
Do
you
have
an
idea
of
like
where
you
would
want
to
see
that
story.
A
Probably
in
like
the
resource
information
section,
but
I
don't
really
have
much,
I
I
don't
really
have
a
super
strong
opinion
off
the
top
of
my
head,
but
that
is
the
like
kind
of
the
the
oh.
We
have
this
flag
value
that
must
match
between
three
different
commands
is
is
is
like
the
one
of
the
prime
use
cases
for
why
we
have
the
project
files.
F
Right,
so
if
we
don't
so,
that
would
kind
of
imply
that
we're
asking
on
create
api
right.
F
Yeah
right,
so
we
also
need
to
store
webhook
version
information,
and
I
don't
necessarily
know
if
that,
like
would
would
we
store
both
the
crd
version
and
the
web
version
in
the
resource.
A
I
mean,
I
think
I
I
don't.
I
think
that
seems
like
probably
a
reasonable
approach,
as
as
a
brief
aside,
I
think
it
would
be
nice
potentially
to
be
able
to
have
multiple
version
support,
but
that
might
be
that
might
be
a
might
be
fairly
complicated
and
b.
We
might
be
hitting
like
the
limits
of
of
how
complex
a
customized
con
config
set
one
any
given
human
can
like
actually
wrap
their
brain
around.
F
Yeah
I
was
playing
with
it
a
bit
and
it's
not
not
fun.
The
internal
logic
is
a
little
bit
complex
to
implement
and
I
don't
want
to
do
like.
I
don't
want
to
make
things
too
complex,
because
then
it
becomes
unmaintainable.
F
I
I
will
say
that
if
you
just
put
all
v1
beta1
stuff
like
in
a
subdirectory
of
where
it
normally
goes
in
config,
so
if,
for
example
like
for
v1
patches,
you'd
have
config
crd
patches
and
then
for
v1
beta
1
patches,
you'd
have
config
crd
v1,
beta
1
patches
and
then
you'd
also
put
a
separate
customization.yaml
in
that
beta1
v1
beta1
folder.
F
So
you
basically
just
separate
everything
out
and
then,
if
you
want
to
change
or
your
default
config
slash
default
for
example,
then
you
would
just
add
that
subdirectory
to
each
one
of
your
like
resource
paths
and
there
you
go,
you've
got
that
covered
or
if
you
want
to
just
copy
the
default
directory
and
make
a
separate
one
for
v1
beta
1,
then
you
would
basically
do
the
same
thing.
C
F
C
Yeah,
it's
like
it.
Now
we
have
the
multi
groups.
We
have
a
simple
path
without
the
group
weighing
misconfusion
in
api
and
he
has
not
much
multi-group
support.
The
pfe
has
not
the
name.
We
don't
have
a
director
with
the
name
of
the
group.
C
If
we
have
just
one
kind
of
a
version
for
the
crg
api,
we
don't
need
a
director
with
the
versions
in
the
same
way.
So
it
doesn't
know
if
he,
if
she
was
your
idea
already,
but
she
do
something
like
the
same.
If
I
want
a
complex
configuration
where
I
want
to
both,
be
you
be
one
and
bet
everyone
have
a
like
a
multi-version
support
equals
to
in
the
project
file,
and
then
we
started
to
discover
the
things
different.
E
F
Not
what
I
was
thinking,
because
it
would
be
nice
to
preserve
the
current
directory
structure,
no
matter
what
happens
so
the
top
level
manifests
will
always
be
your
like
primary
version
that
you
care
about
whether
it's
v1
or
v1
beta1
and
then
you'll
have
a
subdirectory
that
you
can
use
as
your
secondary
one.
F
But
I
I
mean
I'm
I'm
open
to
both
options.
It's
just
the
multi-group
situation
is
quite
complicated
because
you
are
completely
changing
the
project
structure
rather
than
adding
onto
it.
A
I
I
am
just
to
completely
throw
a
wrench
in
things
I
have.
I
have
kind
of
a
leading
suggestion
or
a
comment,
which
is
to
say
it
at
some
point
in
the
future.
D
I
I
second
that
actually,
the
I've
been
I've
been
exploring
as
part
of
the
api
server
runtime
some
alternatives
and
using
just
writing
a
program
that
generates
the
configuration
actually
turns
out
to
be
a
relatively
clean
solution.
I
think.
A
Yeah
interesting,
I
I
also
know
people
have
like
explored
tooling
around,
like
writing.
Writing
like
here's
the
program
and
then
here's
it
can
still
apply
some
additional
patches.
If
you
need
to
apply
patches
to
the
output
or
something
like
that,
so
we
could.
We
could
think
about
doing
something
like
that.
A
D
I
can
yeah,
I
have
a
bit
of
of
a
foot
in
the
configuration
side
and
so
there's
I
I
could
give
a
technical
talk
or
on
some
of
the
approaches
that
are
probably
going
to
be
better
fits
if
anyone's
interested.
A
I
I
think
that
would
be.
I
don't
know.
I
think
that
would
be
wonderful.
I
think
we
could
either
do
that
next
meeting
or
we
could
schedule
a
separate
sub
meeting
depending
on
meeting
fatigue
and
and
how
excited
people
are,
and
they
just
really
want
to
do
it
next
week
versus
waiting
a
couple
weeks
or
something.
D
D
Happy
to
do
it
next
next
week,
before
the
community
meeting.
F
A
C
F
Some
times
down
like
daddy's
or
if
you
build
their
slack
channel
it'd,
be
awesome.
D
Yeah
that
sounds
great
I'd
be
or
I
I
I'm
notoriously
bad
at
any
sort
of
coordination
as
sally
can
tell
you
from
many
experiences,
seeing
me
flail,
but
if
someone
else
would
put
a
call
together,
I
would
be
happy
to
participate.
A
C
A
I
I
think,
maybe
if
it's
not
too
much
work,
maybe
put
together
a
little
like
prototype
pr.
That
shows
what
you
meant
with
the
multiple
directories
for
versions
or
something
like
that.
A
F
Yeah
and
yeah,
so
that's
that's
exactly
what
exists
right
now,
the
other.
So
I
had
two
other
things
that
I
want
to
bring
up
related
to
this
one
relates
what
you
were
just
saying
about
adding
the
versions
on
a
resource
basis.
F
You
also
need
to
specify
these
versions
during
init,
because
you
need
to
configure
the
make
file
and
then
one
other
thing
that
I'm
not
thinking
that
I'm
not
able
to
take
over
right
now.
So
that
would
be
like
a
project-wide
configuration.
A
F
F
I
think
that's
and
then
the
third
one
or
I
guess
the
second
one.
F
What
I
was
saying
is
that
I
started
to
like
write
some
end-to-end
tests
and
code
generation
tests
for
this
stuff
and
came
to
the
realization
that,
because
we
have
two
different
plug-in
versions
with
two
different
controller
gen
versions,
it's
really
difficult
to
write
tests
in
the
current
test,
suite
that
don't
have
version
conflicts
between
the
binaries
in
your
gobin,
and
so
I've
had
to
do
a
bunch
of
work
around
that,
and
I
think
that
I'm
almost
there,
but
obviously
the
tests
aren't
passing
because
of
that
right
now.
F
So
I
need
to
go
back
and
fix
some
things,
and
I
I've
noticed
that
in
some
parts
of
the
code
that
we
just
straight
up,
remove
the
binaries
from
the
path
to
get
around
this
issue
and,
like
I'm,
not
happy
about
doing
that.
But
if
it
solves
things
much
more
easily,
then
I
actually
can't
even
think
of
what
we
can
do
to
solve
it
without
drastically
changing
how
we
install
controller,
gen
and
customize.
A
Yeah,
I
think,
for
for
existing
for
existing
project
structures,
especially
the
ones
where
we
don't
explicitly
have
like
an
escape
patch
for,
like
you
know,
like
installing
controller
gen,
into
like
a
tools,
module
or
something.
A
I
think
we
might
just
have
to
continue
doing
that
kind
of
hacky
like
make
sure
things
aren't
on
the
path
or,
like
make
sure
controller,
make
sure
the
version
we
want
is
the
last
thing
on
the
path
for
that
test,
or
something
like
that
think,
maybe
in
the
future,
making
sure
we
have
like
an
escape
patch
in
all
of
our
versions.
We're
like
just
installing
controller
gen
in
like
a
separate
sub
module
or
something
for
tools
is,
is
a
good
idea.
F
A
A
All
right,
I
think,
with
that
we
will
we're
just
about
at
10
anyway.
So
I
think
that's
perfect
timing.
I'll
see
y'all
at
some
point
next
week,
probably
for
the
talk
by
phil
about
configuration.