►
From YouTube: Kubernetes KubeBuilder Meeting 20210225
Description
KubeBuilder Meeting for 2021/02/25. See https://sigs.k8s.io/kubebuilder for more details.
A
A
B
Yeah
I'll
do
that
all
right,
so
this
is,
I
think
I
demoed
this
a
couple
months
back
and
I've
spent
some
time
on
it.
It's
using
the
customize
functions
as
kind
of
a
way
of
getting
abstraction
when
generating
configuration
instead
of
kind
of
low
level,
semantics,
commenting
and
uncommenting
patch
files,
and
so
I'll
go
through
a
couple
of
examples
like
from
the
user
side
of
how
you
use
this,
it
has
can
be
either
used
standalone
so
I'll
cd
into
the
config.
B
B
B
A
programmatic
way
of
just
just
invoking
it
and
you
can
write
that
to
a
file
or
write
that
to
apply
or
something
like
that,
and
then
it
has
kind
of
this
cute
little
feature
here,
which
you
shouldn't
leverage
too
much.
But
if
you
want
to
do
something
like
I'll
patch,
this
output
right
and
you
you
want
to
simply
just
say:
okay,
I
want
the
replicas
to
be
different
or
the
cpu
or
memory
to
be
different.
B
You
can
apply,
you
can
just
hand
a
list
of
additional
files
and
those
will
be
interpreted
as
patches,
and
so
you
could
so
you
can
see
that
the
replicas
gets
patched
there.
So
this
is
kind
of
like
the
simple
way
that
a
user
might
interact
with
this
when
they're.
First,
if
they're
doing
development
and
just
want
to
get
it
working,
they
might
use
a
standalone
approach.
B
And
then
the
question
is
like:
how
does
this
then
relate
to
maybe
the
customized
workflow
and
the
sophisticated
stuff
we've
already
kind
of
developed?
Or
you
want
variants,
and
you
want.
Sometimes
you
know
certificates
to
be
enabled
and
generated
for
local
testing,
but
in
the
cluster
you
want
circ
manager
running
or
something
like
that,
and
so
here
we
have
using
that
exact,
same
exact,
same
format,
but
as
a
customized
transformer
in
that
that
command
the
the
builder
alpha
config
command
here
can
actually
work.
B
Just
as
a
customized
function,
there's
a
couple
ways:
customized
functions
work.
This
is
kind
of
the
the
most
mature
and
kind
of
well
understood
and
well
documented
approach,
which
would
be.
It
looks
like
a
couple
steps
but
effectively.
This
just
creates
a
little
script,
with
a
particular
name
in
a
particular
location
that
invokes
tubular,
config
alpha
and
so
now.
B
B
B
B
I'll
come
back
to
this
because
clearly
I
screwed
something
up
in
my
local
environment,
but
the
idea
here
is
that
the
second
extension
will
be
similar
to
the
q
builder
project,
we'll
just
run
from
customize,
and
so
users
can
combine
different
sorts
of
extensions
for
for
different
types
of
environments,
and
I
have
two
examples
of
how
you
write
these
there's
a
framework
to
help
right
making
writing
them.
Simple.
B
The
first
one
uses
like
a
way
more
familiar
to
helm
and
customize
users,
which
is
you
you
define
like
patches
here
and
the
patches
can
be
templatized
from
some
api
spec
right.
So
in
this
case
we
have
an
api
that
has
replicas,
and
then
you
have
you
know
this
replicas
field,
and
then
you
define
a
template
and
then
it
pulls
out
the
replicas,
and
then
you
have
like
a
selector
for
what
that
patch
is
so
in
this
case
it
would
say
the
whole
extension
does
something
very
simple
which
is
apply.
B
You
can
do
more
sophisticated
stuff
like
this
one,
where,
instead
of
just
operating
on
patches,
you
maybe
do
something
lower
level,
and
so
in
this
case
it.
This
does
the
exact
same
thing,
but
it
operates
on
a
list
of
resources
rather
than
just
defining
resources
and
patches
and
uses
that
same
sort
of
selector
approach
where
it
finds
a
deployment
and
controller
manager
out
of
that
resource
list
and
then
for
each
match
it
finds
it
goes
and
says,
look
up
the
spec
dot,
replicas
field
and
then
set
its
value.
B
This
way
right,
so
this
would
allow
you
to
potentially
do
stuff,
like
iterate,
all
over
a
bunch
of
resources
first
and
generate
patches
based
on
other
resources.
You
found
right
so
find
this
resource
annotated
with
this
value,
get
its
name
then
wire
its
name
into
the
field
of
this
other
resource.
Here
right
so
like
the
way
we
do
name
prefixing,
for
instance,
you
can
do
more
sophisticated
versions
of
that.
B
If
there's
a
secret,
that's
generated
and
you
wanted
to
wire,
get
the
secrets
value
basic
c4
encode
it
put
that
in
a
field
of
one
resource
and
then
wire
the
secret's
name
into
another
resource.
That
should
definitely
be
done
using
this
approach,
because
it's
more
dynamic,
real,
quick,
like
what
are
some
of
the
things
that,
like
that
that's
like
api,
provides
in
this
case.
B
C
C
B
B
Just
have
crds,
and
in
this
case
you
disable
namespace
controller
manager
and
rbac
generation,
and
this
actually
supports
using
component
config
as
well.
So
I
think
component
config
is
one
of
those
things
that
requires
like
changing
a
couple:
different
files
and
multiple
patches
and
that
sort
of
stuff,
and
so
this
actually
just
has
it
as
a
high
level
value
where,
if
you
want
to
use
component
config
you'd
create
like
this
component,
config
file
reference
it
and
then
it
would
generate
the
configuration
based
on
on
that
and
wiring.
That
component
config.
B
The
way
it's
implemented
is
done
using
this
a
couple
different
things
here,
where
it's
a
combination
of
pretty
sophisticated
stuff
like
a
controller
gin
piece
that
generates
the
crds
from
the
controller
controller
tools
or
a
we
have
another
one
that
does
search
generation
and
will
wire
inserts
for
development.
This
has
been
a
really
sticking
point
for
some
people.
B
I've
worked
with
where
it
took
them
like
a
day
just
to
get
all
the
certificate
like
the
the
different
stuff
installed
and
configured
correctly,
due
to
a
combination
of
complexities
around
like
getting
their
certificate
manager
right
and
the
customized
config,
uncommented
and
all
that
stuff.
So
this
is
an
alternative
there
for
development.
B
B
So
that's
the
demo
update
on
this.
I
know
there
were
some
questions
in
the
pr
about
how
extension
works
and
and
how
this
is
run.
I'd
love
to
to
field
those.
Now,
if
anything,
was
unclear
about
how
you
would
extend
this
using
this
approach
through
composition
to
layer
on
like
operator
sdk,
for
instance
like
this,
would
be
operator
sdk
right
or
something
like
that,
and
it
would
compose
with
this.
D
C
C
B
Right,
the
the
second
example
I
mean,
there's,
there's
other
ways
like
it
that
we
could
do
extension,
but
but
this
the
second
example
is
like
kind
of
my
preferred
mechanism
for
extension,
which
is
through
composition
rather
than
like
plug-ins
in
this
particular
case,
like
plug-ins,
make
sense
in
certain
contexts.
But
if
you
can
get
away
with
just
composing
two
things,
I
think
that's
oftentimes
preferable.
C
B
Yeah
with
the
second,
so
one
nice
thing
about
the
second
example
is,
I
think,
you're
right
we're
like
and
there's
a
feature
request
that
says
like.
Can
you
config
create?
Can
you
make
the
configuration
generated
this
way
right,
like
whatever
it
is
like?
Let's
say
the
certain
thing
right,
so
I
happen
to
include
the
cert
installation
there.
But
let's
say
I
didn't,
and
we
didn't
want
to
include
that
as
a
teacher
and
someone
said,
can
you
make
it
so
that
it's
simpler
to
do
web
hooks
for
development
by
automatically
just
configuring
it?
B
C
B
C
B
Yeah,
I
don't
think
that
changes
much
from
what
the
flow
today,
in
the
sense
that
today,
you
just
like.
I
believe
that
config
is
generated
from
controller
tools.
So
we
don't
encourage
users
to
directly
modify
the
output
of
that
file
and
you
would
do
a
customized
patch,
and
so
that
would
be
like
exactly
the
same
in
the
sense
that
you'd
end
up
here
right
with
patches.
C
Yeah,
I
I
think
the
only
thing
like
it:
okay,
she's
we
don't
have
all
options,
yet
it's
a
proof
of
concept
in
stage
I
I
understand
that,
of
course,
it's
just
she
to
prove
that
it's
possible
to
do
all
this
stuff,
but
hey.
I
think,
for
example,
now,
if
you
we
put
all
custom
resources,
if
you
put
to
the
custom
resource
in
the
same
file,
for
example,
the
way
that
we
are
drawing
out
the
files
would
not
be
compatible
with
the
making
file
targets.
C
The
controller
chain
also
we
set
in
the
making
files
so,
for
example,
go
v2
using
one
versus
gold.
V2
supports
another
version,
so
we
would
need
to
also
write
the
files
in
the
same
way
that
you
write
today,
angela
to
the
contour
thing
generation,
the
crs
directly.
Do
you
know
what
I'm
trying
to
say.
C
A
Oh,
I
I
assume
we'd
end
up
needing
to
do
a
different
like
scaffolding
version,
or
something
to
support
this
right
like
this.
Would
if
we,
if
we
when
it
like,
if
when
we
adopted,
could
say
jen
we'd
we'd
end
up
with
a
different
scaffolding
version
completely
different,
like
a
different
definition
of
make
manifest
or
whatever.
B
Yeah,
you
know
what
here's,
how
I
kind
of
think
of
this,
like
in
the
battle
days
before
controller
run
time,
there's
like
one
cut
at
providing
what
could
build
it
provides
today
was
code
generation
right
where
we
scaffolded
it
out,
like
a
bunch
of
files
for
informers
to
get
the
instead
of
having
libraries
right,
and
so
that
meant
users
had
a
bunch
of
stuff
on
disk
and
and
they
had
kind
of
this
dance.
They
had
to
understand
like
what
stuff
did
we
scaffold
for
them?
B
That
would
prefer
this.
This
sort
of
approach
give
them
the
option
to
say
we're,
not
scaffolding,
anything
we're,
not
writing
anything
to
disk.
Like
all
the
stuff,
we
would
scaffold
exists
inside
this
library
effectively
and
if
you
want
to
modify
low-level
details
that
is
available
to
you
in
the
form
of
patches,
in
the
form
of
you
know,
creating
a
new
function,
type
and
composing
it,
but
we
are
not
going
to
encourage
folks
to
directly
modify
files
that
we
are
generating
for
them
at
some.
B
You
know
lines
that
get
modified.
I
think
that
is,
that
is
like
a
state.
We
actually
want
to
move
away
from
right
instead
of
having
like
the
having
a
stable
set
of
files,
be
the
api
that
that
are
customized
it'd,
be
moving
to
having
a
stable
set
of
you
know,
resource
like
the
the
emitted
resources
right
and
driven
by
annotations
or
or
selected
label
selectors,
or
that
sort
of
thing.
C
So
I
I
have
two
concerns.
One
of
them
is
like,
I
believe
that
is
very
powerful
and
you
can
solve
a
lot
of
needs
for
a
lot
of
the
users,
mainly
for
like
people
with
a
bigging
influence
tutorial
that
you
need
to
do
different,
subcodes
different
pets
for
different
environments
of
the
same
product
like
development
production.
This
is
very
powerful.
C
The
other
thing
is
like
we
have
users
that,
for
example,
I'm
not
sure
if
all
users,
they
you,
would
you
like
to
do
a
patch
to
update
the
the
custom
resource
they
know
and
change
the
values
like
the
address,
the
name
and
the
you
know.
The
attributes
of
the
custom
resource
requires
to
do
a
page
which
is,
could
you
be
hard
for
them?
So
I
believe
that
we
have
two
kinds
of
people
actually.
C
People
I
I'm
saying
that
she
has
a
lot
of
different
people
that
are
using
the
tool
with
a
different
needs
and
it
has
people
that
has
needs
like
that
that
it
is
like
very
powerful
and
you
help
them.
However,
a
lot
of
users
just
want
at
the
end
of
the
day,
deploy
and
to
make
something
I
imagine
running
in
on
the
cluster.
They
don't
want
to
learn
all
stuff,
it's
very
hard
for
them
to
understand
how
the
kubernetes
api
works,
it's
very
hard
for
them,
implementing
a
controller
in
the
song.
C
They
are
overwhelmed
about
the
things
that
they
need
to
learn.
So
we
fought
one
year
ago
in
the
plug-in
system
to
try
to
provide
like
things
for
escortful,
to
discover
the
code
for
the
helpers,
because,
if
you
think
the
watch
the
the
users
are
asking
for
us,
like
I
use
the
kobe
builder
or
sdk,
I
create
a
project.
I
scroll
forward
to
the
apis
and
then
copy
builder
doesn't
help
me
anymore
because
could
be
don't
don't
provide
helpers.
C
E
It
sounds
like
what
you're
describing
literally,
is
this
project,
though,
because
once
you
scaffold
out
a
config
directory
q
builder
doesn't
do
anything
else.
I
mean
q
builder
will
add,
like
some
new
samples
files
and
some
other
stuff
based
on
marker
comments,
but
q
builder
doesn't
really
help
you
update
that
directory
at
all.
But
what
philip
is
suggesting
is
a
tool
that
does
actually
do
that.
So
I
I
think
it's.
C
F
C
Yeah,
yes,
exactly
my
point
is
like
one
year
ago
we
started
to
make
the
design
the
plugin
system.
Now
we
are
in
a
in
a
point
where
we
can
release
that
in
like
in
a
good
state,
but
a
very
primary
stage.
We
cannot
change
this
plugins.
We
cannot,
we
still
not
adding.
We
are
not
in
the
point
that
we
can
save
for
the
community,
come
on
here
and
contribute
with
these
projects.
Creative
plugins,
to
integrate
with
your
projects.
Do
you
know
so?
C
My
concern
here
is
not
to
not
accept
his
ideas,
not
to
choose
the
point,
but
the
point
is
we
need
to
maintain
the
goal
plugins,
the
institute
that
we
have
today,
plus
we
started
to
work
on
cheese,
alpha,
filtery
and
today.
I
believe
that
we
need
to
put
a
plane.
You
know,
because
we
need
to
start
to
edge
evaluating
the
two.
We
need
to
give
you
the
opportunity
for
the
community
put
things
like
things
to
integrate
the
things
things
to
help
the
test
things
that
we
use
comfort
this
stuff.
C
So
we
will
have
two
things:
two
parallel
things
running
that
we
need
to
keep
in
mind
then,
and
you
don't
have
more
than
five
people
contributing
to
the
project.
So
my
concern
is
like
how
how
you
will
make
it
easier
for
us.
Do
this
process,
because
in
tutus
being
a
station
that
you
can
do
the
replays.
E
And
two
I
mean
if
you
have,
if
you
have
some
ideas,
I
think
they're
worth
writing
down
in
an
issue.
We
should
probably
move
on
to
the
next
agenda
item
just
because
we're
getting
pretty
off
topic
here
but
like.
If,
if
you
really
do
have
concerns
about
this,
then
I
would
definitely
start
documenting
them.
No.
C
Okay,
just
let
me
finish
the
points
that
I'd
like
to
raise.
I
think
it
we
need
to
like
it.
We
need
to
accept
cheese
and
you
take
like
a
year
before
we
make
which
is
stable
enough,
for
you
make
the
change
from
the
config
engines,
and
now
we
are
in
a
moment
that
we
are
like
okay,
how
you
will
do
the
plugins
for
let
the
people
contribute.
C
So
I
believe
that
we
need
you
started
to
think
it
doesn't
know
how
we
read
the
rest
that,
but
we
need
we
are
grouped
together
and
to
think
about
this
strategy.
How
you
will
do
this
stuff,
because
we
need
to
this
value
now.
We
need
to
provide
the
helpers
for
the
people
and
we
cannot
say
for
the
people,
okay,
duchess,
plugging
in
the
next
year.
They
need
to
implement
everything.
C
Do
you
know
we
need
to
think
in
our
way
to
keep
the
both
ideas
running
together
until
we
will
be
able
to
do
cheese
switch
and
the
things
that
the
people
you
contribute
with
need
to
be
easily
change,
adapt
to
to
the
new
way
just
make
sense.
This
is
my
concern.
Do
you
know
how
what
you
will
be
playing
for
the
next
year,
how
you
will
be
there,
you
know:
how
do
you
think
about
that
or
wait.
A
B
C
Oh,
I
I
think
it's
very
nice.
I
think
we
need.
You
accept,
change,
marriage,
your
alpha
part.
You
know,
I
think
we
are
very
closer
to
do
that.
She
has
few
things
like
ensure
that
we
have
attaches
things
like
that
before
we
be
able
to
grow
your
idea
and
you
put
to
choosing
a
stable
stage.
I
just
think
that
it
will
get
time
because
we
are
speaking
about.
We
need
to
the
documents,
explain
how
to
use
all
options
we
need.
C
B
A
G
I
added
it.
I
didn't
write
my
name.
Sorry,
we
are
pretty
close
to
releasing
version
3.
I
would
say
that
we
can't
even
release
it
right
now.
I
don't
know
what
the
what
you
folks
think
about
that
there
is.
There
may
be
an
issue
with
the
with
the
release
process
that
I
have
to
talk
with
eric,
but
I
don't
need
to
write
it
here
in
the
meeting,
but
I
think
that
we
are
ready
to
to
deploy
to
release
version
three.
G
G
A
A
G
There
is
a
a
release
issue
with
the
james
log
that
we
have
to
to
update
with
sorting
some
of
the
pull
requests,
but
if
anyone
has
any
concern
about
their
release,
please
use
that
issue
to
to
raise
them
so
that
we
can
block
it
or
not
do
it
on
monday
and
if
no
one
has
anything
else
to
say
about
that,
I
will
go
on
because
we
are
already
pretty
late.
So.
E
G
G
G
I
said,
then,
on
tuesday,
that
if
anyone
has
a
any
concern
about
this,
please
raise
them,
and
I
wanted
to
to
also
tell
it
here
in
this
meeting,
because
there
were
some
people
that
couldn't
attend
the
the
triage
meeting.
So
the
basic
idea
is
to
expose
that
directory,
because
there
are
several
third-party
libraries
that
would
that
are
copying
it
and
using
it.
So
if
we
expose
it
and
we
define
an
api,
I
think
it
would
be
easier
for
the
third
party
libraries
like
operators,
decay
or
similar.
G
We
have
a
q
builder
release
tools
repository
that
well,
they
are
the
same
reviewers
from
cube
builder
and
approvers,
but
it
has
like
really
low
activity
and
there
are
some
issues
that
are
pretty
easy
to
review.
So
I
would
kindly
ask
if
you
can
like
take
a
look
and
give
it
a
few
minutes
and
try
to
also
review
that
and
not
only
control,
runtime
and
thank
you
builder,
and
with
that,
that's
all
the
points
I
had
in
the
agenda.
We
can
proceed
to
the
to
the
next
one.
C
E
My
two
cents
is
yes.
This
is
really
important
because
kubernetes
likes
to
change
things
in
between
minor
releases
and
sometimes
in
release
like
they'll,
remove
or
they'll,
remove
some
api
and,
if
you're,
an
operator,
developer,
you're
or
controller
developer
in
general,
you're,
probably
targeting
as
many
kubernetes
versions
as
possible.
C
H
E
C
So
this
is
another
point
that
maybe
we
need
to
start
to
consider
as
well
publish
more
frequently
the
versions
of
the
kobe
builder,
because
we
have
not
been
doing
that
for
so
long.
So
maybe
we
need
see
how
you
work
with
the
cycle
you
know
like
in
shk.
We
have
a
courage
to
to
do
that
three
weeks.
I
believe.
E
Yeah,
I
think
part
of
the
reason
is
that
cute
builder
is
a
lot
more
stable
because
it
only
supports
one
operator
controller
type
and
doesn't
provide
cli
tools
to
work
with
clusters
directly.
So
I
think
the
release
cadence
doesn't
need
to
be
as
quick
as
for
operator
sdk,
but
that
that
being
said
like,
I
would
definitely
like
to
see
more
releases,
specifically
around
controller
runtime
versions.
E
A
A
A
We
could
also
also
have
the
front
end
in
place,
and
you
know
see
if
people
want
to
start
see
how,
like
users
want
to
start.
If
users
want
to
start
playing
around
with
the
idl
syntax
that
I
had
proposed
itself
or
alternative
front
ends,
we
could
look
at
that,
but
the
kind
of
the
general
question
is
like:
would
that
be
amenable
to
people
to
people?
A
D
Okay,
yeah,
I
would
also
be
willing
to
like
test
it
out
with,
like
my
projects,
crds
and
that
kind
of
stuff
and
play
around
with
it.
I
guess
my
question
is:
is
it
is
the
thing
that's
holding
it
up
like
user
testing
and
that
or
is
it
more
on
the
actual,
like
administrative
side
of
kubernetes
than
not
wanting
to
own?
This
thing.
A
We
have
a
track
record
of
owning
stuff
like
this,
so
I
thought
it
might
be
reasonable
for
us
to
kind
of
own
it
in
the
meantime,
but
I
also
just
didn't
want
to
unilaterally
be
like
hey
we're
going
to
do
this,
because
that
that
wouldn't
be
great.
So
I
wanted
to
make
sure
like
see,
if
see,
if
see,
if
this
was
reasonable
or
amenable
to
folks,
to
kind
of
like
experiment
around
with
this,
as
like,
a
a
new
kind
of
a
next-generation
version
of
controller
tools,.
A
With
with
the
caveat
of
like
we're,
not
immediately
replacing
controller
tools
or
anything
this,
this
is
just
like
hey.
We
have
this
out
there
play
around
with
it
because,
like
obviously
I'd
also
like
to
get
more
user
feedback
and
like
here's,
here's
a
place,
we
can
hack
on
it
and
then,
if
we
decide
it's
stable,
if
we
decide
you
know,
we
want
to
stick
with
this
front
end
or
whatever,
or
if
we
decide
we
want
to
merge
certain
parts
back
into
the
base.
We
could
do
that.
D
A
A
G
A
G
Yeah,
the
idea
is
yeah.
The
idea
is
a
bit
to
to
move
it
to
to
a
separate
repository,
also
because
the
test
data
matrix
is
getting
big
only
with
a
couple
repositories,
and
once
we
start
adding
there,
it's
it's
gonna,
get
pretty
big
and
also
to
allow
people
to
contribute
theirs.
But
I
don't
know
I
haven't
still
make
my
mind
on
how
to
allow
people
to
contribute
their
owns
and
all
that.
So
it
was
just
a
an
initial
idea.
A
A
F
C
I
And
we
give
folks,
I
guess
direction
on
how
they
can
publish
their
own
or
they
can
be
used.
So
that
way
we
don't
have
to
maintain,
because
I
agree
with
sully
what
would
happen?
Is
you
get
code
dumps
that
are
abandoned,
that
you
end
up
having
to
maintain?
That
is
just
I've.
I've
had
that
problem
before
right,
but
if
you
have
a
mechanism
where
oh
I've
created
a
plug-in
here's
my
repo,
if
you
want
to
use
it,
then
here's
instructions
on
how
to.
C
I
put
in
the
documents,
probably
before
the
next
meeting
the
metadata
show.
We
see
all
things
that
we
have
everything
think
about
the
plugin
existing
so,
in
my
mind,
go
to
be
like
kobe.
Builders
should
provide
ways
for
people
to
create
the
things
we
could
in
the
future
have
like
a
incubatory
stuff,
which
we
are
not
responsible
for,
like
it's
totally
community.
Think
and
the
things
are
there
only
there
the
people
can
do
everything
that
they
want.
However,
we
don't
officially
support
angie.
C
A
D
A
I
C
Because,
let's
think
the
operator
is
uploading
right,
we
have
the
helm.
If
you
want
ansible
v1
both
are
plugins,
enjoy
heavy
plugins
that
you
are
from
the
two,
so
sgk
exactly
has
plugins.
That
is
strategy
for
both
plus
the
and
looking
it's
validation
for
all,
but
the
others
can
be
specific
to
to
help
or
specifically
to
ansible
they
need
to
live
in.
The
do
you
know,
divide
the
the
responsibility.
What
is
specific
for
one
thing,
you'll
be
in
that
thing.
I
believe
that
is
the
idea.
A
Yeah-
and
I
I
would
love
to
see
them
as
like,
I
think
they
make
very
good
examples
of
test.
Cases,
as
as
like
here
is
a
plug-in
here
is
how
it
can
live
in
its
own
repository
kind
of
thing,
and
so
like.
I
think
it
would
be
a
little
bit
of
a
shame
to
co-locate
them.
Just
from
a
perspective
of
here's,
a
demonstration
to
the
community
of
how
you
can
like
manage
a
plug-in
repository,
yeah.