►
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
B
Oh
yeah,
I'm
jimmy
I'm
from
d2iq
working
on
some
of
our
our
platforms
with
daniel,
especially
daniel
lewis,
so
yeah
nice
to
meet
you.
A
Doesn't
look
like
okay,
so,
let's
start
with
our
agenda
items.
A
A
A
So,
let's
start
the
first
item
on
the
agenda
is
a
semantic
versioning.
A
kappa
will
adopt
so
cluster
api
is
gonna,
have
a
1.0.x
releases.
I
just
wanted
to
ask
all
of
you
guys
if
you
want
to
follow
the
same
versioning,
which
is
similar
to
kubernetes
versionic,
or
we
want
to
do
a
courser
versioning
like
we.
We
won
that
zero.
Then
we
won
that
one
going
just
with
minor
releases.
A
D
My
my
take
is
we
for
now
anyway,
like
the
changes
that
we've
come
in,
are
not
breaking
changes
of
any
sort.
So
I'm
quite
happy.
D
We
just
do
minor
releases
as
we
add
functionality
and
not
bother
with
the
patch
release.
Until
we
get
to
a
point
where
there's
going
to
be
deviation,
I
mean
my
ideal
preference.
Is
that
we're
aggressive
on
versioning
but
go
modules?
Make
that
difficult,
so
not
sure
what
the
best
answer
is
yeah,
my
preference
would
have
been
any
breaking
change.
We
increment
the
major
version
and
then
carry
on
but
yeah.
I
think
that
might
be
difficult
for
people
in
rendering
the
code.
D
I
personally
don't
see
a
reason
to
release
a
one
zero
x,
given
what
we
have
we've
got.
Some
new
features
added,
look
like
the
next
one
should
be
a
1.1
and
I
don't
see
a
need
to
backtalk.
E
D
So
we
use
that
in
the
vmware
tanzini
framework,
which
is
also
open
source
now,
so
it's
been
used
directly
there.
Another
thing
that
we've
been
talking
about,
I
haven't
created
an
issue.
Yet
is
we've
done
all
this
work
around
multi-tenancy,
there's
an
idea
that
other
controllers
might
use
it,
so
we
might
want
to
move
that
into
a
package,
so
I
think
there
are
going
to
be
use
cases
for
rendering
going
forward.
On
a
slightly
related
note,
I
think
we
should
also
look
at
what
cappy
is
doing
and
moving
code.
E
I
also
wanted
to
follow
up
on
the
on
the
api
vendoring.
I
I
this
is
kind
of
more
like
a
maybe
a
macro
discussion
for
maybe
philosophical
in
a
way,
but
it's
it's
kind
of
odd
that
that
the
api
that
someone
would
vendor
the
apis,
because
the
the
the
api
packages
right
there
they're
sort
of
their
their
go
implementations
of
the
the
api
contract
which
is
supposed
to
be
in
the
in
you
know,
defined
by
the
crd
and
it
it's
just
yeah.
E
I
mean
I
think
this
is.
This
is
the
case
that
sorry
vendoring
apis
like
the
go
implementation
of
the
apis
is,
is
is
kind
of
common,
but
it's,
it
seems
like
it's
just
a
product
of
sort
of
like
everyone
using
go
and
and
sort
of
assuming
that
like
oh
well,
I
can
just
you
know,
import
these
api
types,
but
really,
I
think
what
we
want
is
is
yeah
the
head
to
be
able
to.
You
know
I
guess
generate
clients
to
generate
code
from
from
crds.
I
think
there
was
right.
E
There
was
an
effort
with
the
this
intermediate
or
I
guess
interface.
I
don't
know
definition
language.
There
was
a
cap
out
for
that
that
I
think
was
was
closed,
but
anyway,
that's
sort
of
on
that
on
that
topic.
D
Yeah,
I
I
totally
agree
with
that.
I
think
one
of
the
constant
art,
so
we
were
going
through
this
on
the
cavity
backlog
grooming.
You
know
the
continuer
asks
for
to
have
that
api
separate
from
cluster
api,
so
you
can
import
it
without
controller
one
time
and
I
think
go
doing
what
you're
saying
daniel
is
it's
actually
the
correct
process
and
I
think
people
import
api
more
out
of
convenience
than
like
a
genuine
need.
A
So
if
no
one
has
any
other
comments,
so
from
my
understanding
we
are
gonna,
follow
a
more
aggressive
versioning
going
forward
than
a
capital
loss.
D
Yeah,
I
don't
know
if
we
can,
but
I
think
is,
is
there
an
action
item
that
we
should
update
the
contributing.md
to
at
least
match
cappy's
versioning,
at
least.
B
Thing
just
wondering
you
said
like
it
needs:
if
we,
if
we
bump
the
major
version,
it
requires
its
own
directory
and
then
the
modules-
I'm
not
sure,
that's
that's
strictly
true.
It's
just
the
the
module
path
needs
to
change.
The
directory
can
still
be
the
same.
It
doesn't
have
to
change
anything
in
the
directory
structure.
It
just
needs
to
have
the
tags,
have
the
correct
format
and
the
module
path
in
the
go.
B
Mod
needs
to
be
have
that
subdirectories,
but
you
don't
actually
have
to
change
your
directory
structure
in
your
repo
for
that,
so
I
think
it's
it's
not
a
big
deal.
Personally,
I
do
like
using
major
versions
for
signifying
breaking
changes,
or
I
think
probably
most
of
us
do
but
yeah.
A
Okay,
thanks
jimmy
next
topic,
is
around
linux
foundation.
Mentorship
program,
so
richard
last
month
brought
up
about
having
collecting
ideas
for
having
interns
for
kappa
project,
and
I
checked
the
next
cycle
starts
in
march.
A
They
don't
have
a
march,
they
don't
have
a
cycle
in
the
next
month.
The
current
cycle
ends
in
november,
but
they
have
a
gap,
probably
due
to
new
year's
holidays
and
yeah.
I
was
thinking
about
having
a
project
for
automating
image
release
process,
so
that
would
be
a
self
explanatory.
Like
I
mean
it
would
be
a
good
project
to
finish
in
three
months.
A
A
Cool
and
next
topic
is
jim,
reject.
F
Sorry,
just
on
that,
I
didn't
get
around
to
to
pinging
anyone
about
how
the
the
stipends
work.
If
it's
an
official
program
with
the
official
mentee
program,
do
we
need
to
find
out
about
that
as
well?
Should
I
say
that,
as
an
action
item.
A
A
Maybe
the
application
is
different,
I
don't
know
but
yeah
we
can.
We
definitely
need
to
know
more
about
how
to
proceed.
F
A
We
can
create
an
issue
and
collect
the
ideas
there.
If
that's
my
fault,.
B
Oh
yeah,
so
we've
been
using
using
capra
quite
a
lot
now
and
one
of
the
things
that
we
hear
is
is
naming
collisions.
I
discussed
this
with
with
richard
on
slack
and
he
said
we
could
bring
it
up
here,
but
this
issue
has
been
open
for
a
very
long
time
since
the
beginning
and
if
you
create
two
clusters
with
the
same
name
in
either
two
namespaces
in
the
same
management
or
bootstrap
cluster,
or
if
you
create
these
clusters
in
two
separate
bootstrap
clusters.
B
In
the
same
with
using
the
same
aws
account,
then
you
end
up
with
naming
collisions
that
one
or
the
other
clusters
can't
come
up.
It's
like
a
race
right.
At
the
same
time,
I
don't
think
there's
any
issues
around
deleting
stuff,
but
there's
I
had
some
concerns
around
that
if
you
deleted
a
second
cluster
with
the
same
name,
how
does
that
impact
on
the
resources
created
from
the
first
cluster?
B
So
for
me
it's
a
really
big
issue
and
I
was
just
wondering
how
people
are
avoiding
this
because
to
me
it's
something
that
you
know.
I've
only
been
using
in
kappa
for
a
few
months
and
I've
been
hitting
it
quite
regularly
and
you
have
a
number
of
users.
So
what
are
people
doing
to
avoid
it,
and
should
we
fix
it.
D
D
Unless
you
create
the
same
cluster
name
in
two
different
name
spaces,
or
do
you
that
one
still
exists,
so
that's
been
handled
slightly
differently
by
another
layering
project.
So
it's
still
an
open
issue.
So
another
thing
called
transmission
control
and
that
one
random
slightly
randomizes
the
class
name.
So
when
it
generates
a
cluster
instead
of
using
name
use
generate
name
in
the
metadata
and
then
that
will
append
it.
D
I
can't
remember
the
history,
but
that
might
have
been
ultimately
why
it
got
ignored
at
the
time,
but
I
don't
know-
and
maybe
it
was
worth
resolving.
I
know
there
was
another
problem
like
when
I
was
reviewing
the
ignition
pr
and
that
one
was
even
more
problematic
in
the
fact
that
to
create
the
sv
buckets
have
to
be
globally
unique
across
all
regions
for
all
aws
users.
So
if
you
have
aws
cluster
try
and
create
the
bucket,
it
has
to
be
globally
unique
in
the
universe
of
aws
inside
the
aws
partition.
D
So
it's
we
have
to
give
stronger
guidance.
I
think
for
providers
implementations
that
you
should
never.
You
should
find
ways
around
this
and
then
yeah.
I
think
we
probably
do
need
to
come
to
the
solution,
but
we
need
to
be
do
it
in
a
way
that's
going
to
be
backwards,
compatible
as
it
doesn't
break
existing
ones.
I
don't
know
if
someone
wants
to
take
that
up.
B
F
Yeah
yeah,
we
had
a
related
issue
when
we
were
implementing
dks
as
well,
and
that's
why
we
ended
up
with
the
namespace
prefix
on
the
eks
cluster
name.
So
it's
sort
of
laid,
but
probably
just
saying
that
just
for
everyone's
awareness.
A
Right,
our
next
topic
is
from
danielle.
E
Thanks,
yes,
the
topic
right,
oh,
I
noticed
that
there
was
a
pr
that
there
was
a.
I
think
it
would
look
like
an
automatic
backboard
and
it
it
was
closed
with
a
comment
that
it
wasn't
needed
and
I
was
just
I
I
just
didn't
understand
why,
because
it
looked
like
a
fix,
as
opposed
to
a
new
feature.
E
So
I
was,
I
was
just
curious.
If
there
are
you
know
what
what
the
what
the
criteria
is,
do
we
do
we
have
that
written
down
somewhere
can.
Can
I
help
write
that
down?
That's
yeah,
that's
what
I
mean.
D
I
I
think
it
ties
into
previous
discussion.
I
actually
considered
that
a
feature
because
we
didn't
explicitly
support
that
mode
of
operation
before
so
I
in
my
mind
that
was
a
feature
and
then
I
was
thinking
I
just
used
the
cherry
pick
but
immediately
and
then
thought
hold
on.
I
don't
actually
need
to
bat
boys
that
that
was
what
that
was
about.
D
A
That
was
my
understanding
too.
That's
why
I
didn't
not
need
it,
but
if
we
consider
that
as
a
bug,
we
can
recreate
it.
E
Oh
okay,
yeah
yeah,
I
so
there's
this
you
know
bring
your
own
elb
or
you
know.
Re
use
existing
use,
an
existing
elb
feature
that
is
developed
on
top
of
main
or
you
know
the
the
one
one
over
release
and
the
b1
beta
one
types,
and
I,
even
though
it
is
a
feature
I
wanted
to
just
bring
up.
You
know
the
question:
would
we
consider
adding
this
this
feature
to
the
release?
E
Doing
that
from
what
I
understand
would
would
mean
adding
a
field
to
v1
alpha
4,
and
that
would
also
require
that
we
update
the
conversion
code
in
1.0,
because
I
think
right
now
it
it
assumes
that
that
field
does
not
exist
in
in
v1
alpha
4..
So
definitely
you
know,
there's
more
yeah,
there's
there's
there
would
be.
There
would
be
some
work
in
sort
of
in
both
branches,
but
just
just
wanted
to
ask
you
know
what
what
we
think.
E
D
I'm
not
going
to
be
super
strict,
I
mean
personally,
I'm
I'm
not
going
to
be
super
strict
and
asking
for
motivations,
considering
we
haven't
been
especially
stripped
in
the
past,
so
I
think
it'd
be
unfair
to
d2
iq
to
place
a
harsh
requirement
unless
we
apply
that
consistently
to
ourselves
as
well.
So
I'm,
okay,
potentially
with
this
being
backboarded
yeah,.
D
F
So
we
had
a
similar
scenario
with
eks
add-ons
when
they
were
first
released,
that
we
actually
backported
the
feature,
because
there
were
sufficient
a
number
of
users
that
were
wanting
to
use
eks
add-ons
with
with
the
previous
version.
F
A
My
only
comment
is
that
we
really
need
to
be
careful
about
conversion.
I
similarly
went
through
a
similar
process
about
fixing
a
capital
internet
facing
elb
and
commercial
books
were
very
problematic,
so
we
may
want
to
have
lots
of
unit
testing.
C
D
C
D
D
Yes,
so
it's
quite
handy
that
jimmy
brought
up
all
the
ancient
issue
969,
we
need
to
go
through
the
backlog
like
we
need
to
go
through
the
similar
processes
that
we've
been
doing
in
cluster
api
over
the
last
two
weeks,
where
we've
spent
an
hour
and
a
half
each
time
and
just
gone.
What
the
hell
is,
this
ancient
issue?
Can
anyone
remember,
did
we
plan
to
do
anything
about
it?
When
do
we
plan
to
do
something
about
it?
D
D
A
I
think
this
time
is
ever
played
for
european
folks,
maybe
before
this
time
would
be
better.
What
do
you
think
richard.
F
This
is
a
very
quick
one:
someone's
requested
the
ability
to
customize
the
the
services
cider
block
for
eks
clusters,
and
then
it's
got
me
thinking
about
how
closely
we
follow
the
api
constructs
of
upstream
capi.
So
there
is
a
services.
F
Services,
api
in
upstream,
and
essentially
it
just
results
in
a
a
string
slice
to
specify
the
the
side
of
blocks.
We
don't
actually
have
the
equivalent
in
kappa.
F
So
it's
it
got
me
wondering:
do
we
actually
follow
the
the
same
same
api,
con
construct
and
actually
use
the
network
range
structures
as
they
do
or
do
we
do?
We
can
we
deviate
from
that
and
actually
give
a
better
user
experience,
because
the
way
it
currently
stands
is
it
doesn't
actually
indicate
whether
it's
ibv
4
6
cytoblock?
F
If
we
don't
just
use
a
string
slice
that
has
nothing
on
there
so
that
that's
that's
more
of
the
question
as
or
or
discussion
point,
but
as
a
wider
change,
actually
specifying
services
side
of
blocks
in
for
eks
is
an
am,
is
a
mess
so,
depending
on
whether
you've
got
ibv
four
or
six
you
have
to
specify
in
two
different
locations,
one
is
via
the
api
call
when
you
create
the
cluster,
when
the
other
one
is
actually
via
the
bootstrap
shell
script,
when
you
actually
bootstrap
a
a
node
into
the
cluster
yeah.
F
So
that's
really
discussion
point
there.
A
F
A
D
We
should
fix
this
and
cappy
if
cappy
is
lacking,
ipv6
support
and
we
know
it
is
and
dual
stack
support.
We
need
to
fix
the
api
in
cafe
this
kind
of
relates
to
one
that
I
bought
last
week,
there's
like
a
whole
in
the
capi
office
hours
around
like
handling
api
server,
poor
and
the
meaning
of
it.
We
need
to
strengthen,
we
need
to
make
stronger
provider
contracts
and
fix
issues
in
the
capi
api,
and
I
we
should
get
away
from
working
around
that
downstream,
so
to
speak
in
kappa,
because
this.
F
D
F
A
Otherwise,
we
can
start
backlog
trading
for
a
bit
until,
at
the
end
of
this
meeting,.
A
Cool
should
we
continue
recording
or
should
I
stop
recording,
because
this
will
be
basically
triage.