►
From YouTube: Kubernetes KubeBuilder 20190911
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
So
since
we,
since
we
released
zero
to
zero
for
controller
runtime,
it
still
owns
1.14
kubernetes
versions,
so
I
submitted
I
saw
that
there
was
a
PR
for
1.15
that
was
closed
like
last
week
or
the
week
before.
Whoever
was
whoever
created,
decided.
They
weren't
gonna
continue
supporting
it.
So
I
basically
duplicated
that
and
submit
a
new
PR
last
night,
so
I'm
hoping
we
can
basically
do
that
version
bump
soon
and
make
another
release.
As
a
result,
it
looks
like
everything
all
passes
and
runs.
B
It
didn't
seem
like
it
caused
any
braking
changes,
so
it
looks
fairly
straightforward,
then,
with
116,
which
is
not
released
yet
there's
another
PR
that
that's
someone
else
open
that
basically
does
the
same
thing
for
116,
so
I
don't
know.
We
probably
want
to
go
from
115
to
116,
but
I
just
wanted
to
kind
of
bring
this
up
and
talk
about
it
to
see
what
anyone.
If
anyone
else
had
thoughts
about
it.
B
A
I
think
I
think
the
main
concern
was
just
whether
or
not
so
like
we
exposed
a
number
of
types
from
client
go
and
the
API
machinery
in
our
public
API,
and
so
the
concern
was
just
did
any
of
those
types
change
in
incompatible
ways.
So
like
did
any
of
the
interfaces
that
that
we
rely
upon
in
our
public
API
change.
If
the
answer
is
no,
then
we're
fine
and
when.
B
A
C
A
They're,
like
ancillary
changes
in
like
the
definition
of
the
interface
that
we
receive
and
we're
using
like
mostly
the
defaults,
but
technically
it
would
be
a
break
and
change,
or
something
like
that.
So
it's
just
good
to
check
those.
If
we
can
I
had
some
tooling
once
upon
a
time
to
check
it.
Usually
it's
not
an
issue,
but
we
just
wanted
to
make
sure
I
think
there's
also
tooling
in
the
go
standard
library
that
you
can
use
yeah.
A
D
E
So
Mike
I
think
that
kind
of
Justin
was
gonna,
bring
up
the
same
question.
I
was
probably
going
to
ask
next
I,
don't
know
if
this
is
where
he
was
going
as
well,
but
I
was
going
to
ask
if
we
want
to
have
some
sort
of
compatibility
matrix
where
we
back
for
patches
to
certain
releases
to
just
take
you
versions
while
they're
in
support
windows,
or
does
that
something
we
don't
want
to
do
yet,
because
that
does
introduce
a
large
support
burden
on
the
maintainer,
but
is
I
think
something
that
will
help
adoption
of
this.
A
So
I
I
have
I
have
henceforth
I
think
I've
written
about
this.
A
little
bit
before
I
have
henceforth
not
been
a
fan
of
this
idea,
just
because,
as
you
mentioned,
the
maintenance
burden,
but
in
most
think
like
like
in
most
things,
I'm
willing
to
be
convinced.
Otherwise,.
A
A
I
mean
we
could
we
could
do
0
3
0?
It's
not
it's
not
a
lot
so
so
far.
The
way
we've
been
doing,
pre
1
December
is
is
which
is
kind
of
pseudo
undefined
is
by
shifting
things
over.
Basically,
so
the
middle
version
number
becomes
the
major
version
and
the
last
version
number
becomes
both
the
minor
and
and
the
patch
version,
and
so,
like
generally,
we've
been
saving
things
like
0.2
to
0.3
for
an
indication
of
a
break.
A
C
D
Yeah
I
mean
I,
guess
that's
why
I
was
sorta
proposing
just
two
zero
three
zero.
Here's
thing
you
have
to
worry
about
it
right
like
just
looking
at
this
PR
there
is.
There
is
a
code
change
in
client
go
which
is
exposed
right,
I'm,
sorry,
which
is,
which
means
we
have
to
make
a
change
in
controller
runtime
around
the
serialize
and
it's
a
simple
change,
but
is
cooler
a
breaking
change?
Oh.
C
A
E
A
Right:
well
it
what
it
would
it's
it's
more
of.
We
choose
not
we
for
various
reasons,
some
of
which
have
very
good
justifications.
We
chose
not
to
go
like
full
in
to
go
mods
in
kubernetes
and
so
like
that
actually
has
caused
us
in
control
of
runtime
issues.
So
you
would
be
able
to
do
things
like
having
two
versions
of
client
go
in
parallel.
A
If,
if
client
go
had
fully
embraced,
go
Mott,
go
modules
but
and
and
done
like
major
version
import
pods
like
you're
supposed
to,
but
because
we
don't
do
major
version
import,
pads
and
kubernetes.
We
can't
have
two
two
versions
in
parallel.
We
can't
have
like
the
version
we
use
for
our
internal
mechanics
and
the
version
we
have
in
our
public
API,
for
instance,
support,
and
so
that's
just
not
gonna
work.
I.
A
A
So
alright,
let's,
why
aren't
we
summarized
people
that
have
let's
start
a
new
plug
for
this
and
people
that
have
strong
opinions?
Basically,
can
we
copy
them
over
to
the
bug
just
to
summarize
so
that
we
have
like
a
good
ledger
of
our
thoughts
and
why?
Why
we're
doing
this,
because
this
is
this-
would
be
a
change
to
a
change
to
our
versioning
policy.
A
B
So
just
a
so
I
can
make
an
action
for
myself.
So
just
to
repeat
that
make
sure
I
understand
the
bug
is
about
how
we
version
control
a
runtime
relative
to
the
interfaces
that
controller
runtime
uses
out
of
kubernetes
api
s
and
also
interfaces
that
other
users
might
use
that
we
indirectly
depend
on
like
alright.
Yes,.
A
Yeah
basic,
basically,
how
do
we?
How
do
we
deal
with
stuff?
How
do
we
deal
with
changes
to
client
go,
for
instance,
that
are
not
technically
part
of
our
public
API,
but
potentially
likely
to
break
people
right,
which
things
like
Syria,
like
Justin,
has
a
good
point.
Things
like
serializer,
especially
for
more
advanced
use,
cases,
are
potentially
likely
to
break
people.
D
I
there
is
a
PR
which
is
up
there,
I
felt
like
we
discussed
it
and
we
didn't.
But
anyway
there
is
a
PR
which
I
think
is
probably
in
good
shape
as
an
initial
implementation
in
coop
builder,
it
is
more
of
a
statement
of
intent
of
how
we
will
develop
these
things,
but
the
model
is
there
it's
in
process,
but
it
is
designed
to
be
easily
extractable
to
be
out
of
process
like
and
we're
just
sort
of
doing
it
as
a
development
thing.
I
added
based
on
feedback,
some
folks
fixes
for
typos.
D
Thank
you
and
I.
Read
me
and
currently
the
it
is
blocked
behind
an
environment
variable
feature
flag,
which
is
I'm
sure
we
can
debate
the
naming
and
if
we
only
do
it,
the
naming
I'll
be
very
happy,
but
it's
people
or
have
feelings.
Then
please,
you
have
a
look.
I
have
a
link.
I
have
I,
have
linked
it
in
the
agenda,
but
it
is
number
9
for
3
in
crude
water.
A
Yep
definitely
take
a
look
at
that
if
you're
interested
in
the
plugins
as
Justin
noted,
bear
in
mind
that
we
do
eventually
intend
this
to
be
the
out
of
Cree
plug-in
model.
We
just
want
to
have
kind
of
a
tightly
coupled
interface
that
people
won't
immediately
start
depending
on
it'll
eight
a
little
bit
first
and
make
sure
everything's
all
set
I
I
propose
that
the
environment
variable
must
contain
things
from
the
emoji
section
of
the
Unicode
specification.
B
Think
it's
been
a
little
bit
since
I
looked
at
it,
but
I
think
the
one
coven
I
had
is
that
there
were
some
other
use
cases
that
we
had
talked
about,
not
with
you
Justin
but
like
SDK
and
Sulley
about
also
changing
making
plugins
that
support
changing
other
files,
not
just
go
files
so
like
docker
file
and
make
file
so
I
think
that's
probably
something
that
can
be
added,
probably
without
much
trouble.
Based
on
what
I
remember,
it's.
D
Actually,
yes,
you
can
in
your
plugin,
you
are
passed
a
model
of
the
universe
which
is
like
the
inputs
and
all
the
files
here
generating
you
can
remove
files.
You
can
change
the
contents
files,
you
can
add
files
at
will,
so
even
in
the
atom.
What
you
have.
We
have
an
example
of
this,
where
we
generate
some
Yamma
files:
okay,
cool.
So
if
anything,
it's
a
little
too
haphazard
right
now-
and
it's
like
the
only
way
you
can
identify
a
file
today-
is
by
well
the
primary
way
you
identify
or
identify
a
file.
D
Right
now
is
my
path,
which
feels
a
little
bit
like.
That's
not
probably
want
to
do,
but
the
certain
of
the
functionality
is
there
and
I
think
this
is
the
interfaces
I'd
actually
argue.
We
can
continue
to
use
the
same
interface,
even
if
we
extract
it
to
an
out
of
tree
model,
because
the
model
is
you
take
a
bunch
of
llamó
in
and
you
send
a
bunch
of
Yama
out,
so
the
hopefully
like
extracting
this
to
a
separate
binary
will
be
the
same.
D
B
A
B
Other
question
I
had
Justin.
Is
it
looked
like
to
use
the
add-on
you
always
have
to
pass
or
to
use
the
pattern,
you
always
have
to
pass
a
pattern
flag.
Do
we
want
to
have
some
mechanism
of
like
embedding
the
pattern
in
the
project
file
so
that,
like
a
project,
can
follow
a
pattern?
Always
the
queue
builder
is
the
queue
builder
CL.
I
can
understand
that
that.
D
Is
potentially
a
great
idea,
I'd
say
for
the
for
the
use
case
which
I
was
building.
The
pattern
is
per
resource
rather
than
per
project,
but
obviously
like
it
would
be
surprising,
but
I
I
I
think
that
sounds
like
a
great
idea.
I
yeah
I
can
try
to
do
it
or
we
could
try
to
do
it
separately.
Let
me
sort
of
have
a
use
case.
I
guess:
I
I.
A
Like
that
idea,
I
think
we
should,
let's,
because
this
is
behind
a
feature
flag
and
everything.
Let's
get
parts
merged
incrementally
so
like
merge.
What
I
think
merge
what
Justin
has
and
then
we
can
merge
a
follow-on
PR
to
go
based
off
of
the
just
like
stuff
and
and
get
it
to
the
point
incrementally
where,
where
we
think
we're
we're
good
to
go
as
opposed
to
trying
to
do
it
all
on
PR,
because
then
you
just
get
the
derivative
never
ends,
and
you
know
I
think
we've
all
been
there.
Yeah.
D
Sorry,
the
pattern
flag
does
not,
but
the
the
that
Shane
you
could
chain.
In
theory,
you
could
chain
plugins
together,
so
obviously
it's
not
implemented,
but
the
you
know,
there's
no
reason
you
can't
put
those
put
them
like
model
in
model
out
model
a
model
out
in
a
pipe
as
long
as
you
want.
If
I
find
as
long
as
you
want.
Okay.
A
All
right,
if
nobody
else
has
any
comments
on
that
I
think
we
have
one
more
thing
and
yes,
I
do
appreciate
the
table.
Flip
emoji
in
the
middle
of
the
plugins
environment,
variable
alright,
Joe
I!
Think
you
had.
You
have
a
one
lap,
one
more
thing
about
the
queue
builder
operator:
SDK
integration,
yep.
B
So
slowly
I
think
you
asked
last
week
or
the
week
before.
Can
we
put
up
a
doc
that
basically
says
what
we
plan
on
doing
and
kind
of
what
we
talked
about
on
San
Francisco,
so
I
wrote
something
up,
have
a
PR
open
for
basically
our
plan
to
integrate
queue,
builder
and
SDK.
So
definitely
whoever
is
interested
in
that
take
a
read
comment.
Let
us
know
what
you
think
really
that's!
That's
that's
about
it
for
that.
B
If
you're,
if
you're,
not
aware
of
the
plan
to
do
the
Builder
and
operator
SDK
integration
that
we've
been
talking
about,
basically
what
it
is
is
we
realized
that
SDK
and
queue
builder
are
doing
substantially
the
same
things
for
co-operators
SDK
has
one
implementation
in
one
COI
queue
builder
has
a
different
implementation
with
the
different
CLI
but
they're
both
scaffolding
out
and
go
operators.
They
use
controller
runtime.
B
So
the
idea
is
like,
let's
stop
duplicating
all
that
effort,
and
the
plan
is
for
SDK
to
start
making
use
of
builder
more
for
go
operators
and
then
we'll
start
up
streaming
all
of
the
the
go
code
that
that
is
currently
an
SDK
that
can
be
used
more
broadly
by
any
go
operator
developers
backup
into
cube
builder
or
controller
runtime
or
control
tools,
wherever
it
makes
sense.
So
we've
already
gotten
started
on
that.
There's
some
examples
of
those
things
that
we're
doing
and
then
part
of
the
discussion
is
also
with
this
pattern.
B
So
for
things
like
like
it
open,
shipped
specific
customizations,
you
might
want
to
do
in
in
Red,
Hat,
open
Shepley,
and
we
might
have
a
plug-in
that
openshift
users
can
use
with
cue
builder
that
can
customize
a
project
to
do
open
space,
open,
shipped
specific
things,
and
then
the
last
ideas
there's
a
lot
of
documentation
that
we
that
we
have
that
overlaps
quite
a
bit.
So
we're
going
to
try
to
unify
the
documentation
as
well.
A
If
anybody
has
any
questions,
you
can
feel
free
to
ask
them
here
or
ask
them
on
the
issue.
We
have
a
project
tracking
board
for
immediate
tasks
that
need
to
be
accomplished
as
part
of
the
up
streaming
effort.
So,
if
you'd
like
to
help
out,
you
can
take
a
look
at
the
project
tracking
board
if
anything's,
not
clear
or
if
it's
not
clear
or
something
like
is
a
good
first
issue
or
there's
not
a
lot
of
detail,
because
a
bunch
of
the
cards
were
created.