►
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
Welcome
everyone
to
the
cluster
API
implementers
meeting
on
Wednesday
at
the
24th
of
October
2018
for
the
European
time
zone,
we'll
go
ahead
and
get
started
with
any
items
that
happen
to
be
on
the
agenda,
which
ones
is
for
luck
now.
It
looks
like
we
have
no
items
on
the
agenda,
so
does
anyone
have
any
business
they
want
to
bring
to
the
meeting
today.
B
A
So
yes,
I,
didn't
see
that
I
didn't
see
that
once
we
did
the
initial
migration
on
the
OpenStack
provider,
we
worked
around
that
by
going
straight
to
112
one
and
that
seemed
to
resolve
any
issues
that
we
had.
So
we
we
had
some
issues
when
we
were
trying
to
run
one
ten
and
one
nine.
As
soon
as
we
switch
to
one
twelve
one,
everything
just
seemed
to
work
so.
B
A
D
B
E
You
know
it's
like
it
is
about
managing
cloud
resources.
Well,
in
some
it
is
also
dropping
nodes
and
like
each
provider
with
his
lamented
opinions,
but
how
how
cloud,
resources
or
managed
or
how
nor,
where
he's,
treated
and
various
other
things
like
that,
and
so
I
was
wondering
them
weather
will
be
with
us.
Other
people
are
on
the
same
pages.
We
on
up
with
respect
to
that,
and
you
know
what
are
your
thoughts
in
general
on
that
topic,
so
community
will
assuming
their
platform
I
know
what
they
do.
E
I
prostrate
nine
provider
would
be
it's
mostly
about
managing
resources,
whether
the
cloud
or
not,
and
sort
of
maintaining,
like
machines
that
they're
supposed
to
be
we're
registering
especially
then
I
think
there's
something
else
that
equalization
classroom
attention,
a
different
provider
for
action.
Reading
individual
notes
up,
because
that
is
somewhat
somewhat
cloud
independent
right
for
well,
if
you
look
at
it
incentive
way.
So
under
was
what
people
think
like
that
general.
E
A
I
think
you
cut
out
there
Lilia
your
audio
is
kind
of
sketchy,
so
I
think
we're
all
having
a
little
bit
of
a
hard
time,
understanding
everything
that
you're
saying,
but
if
I
understood
you
correctly,
basically
you're
just
talking
about
what
is
actually
in
scope
for
a
provider.
What
isn't
in
scope
for
a
provider
should
we
have
maybe
some
different
concepts
of
other
actuators
for
different
resources
with
providers
or
maybe
I
misunderstood
you.
There
yeah.
A
Yeah
I
think
that
ties
in
pretty
well
with
the
item
that
Marco
brought
last
week
about
having
some
kind
of
externalize
method
of
dealing
with
different
OS
configurations,
whether
you
happen
to
be
using
something
like
Ubuntu
or
CentOS,
or
core
OS
cloud
Linux.
Whatever
it's
called
now,
you
know
having
some
sort
of.
A
My
way
of
dealing
with
those
and
and
giving
us
some
kind
of
interface
to
to
drill
into
that
without
having
to
just
repeat
code
or
in
the
case
of
what
we
have
now
just
kind
of
smash,
random
shell
scripts
into
place
and
hope
they
work
I,
definitely
see
significant
room
for
improvement
on
that
and
and
potentially
without
going
into
deploying
packages
and
things
like
that,
having
some
kind
of
externalize
controller.
That
says
this
is
how
this
machine
should
be
configured.
So
not
just.
A
This
is
a
machine
but
doing
something
to
generate
the
configuration
of
the
machine,
whether
that
be
a
cloud
in
it,
whether
that
be
in
case
of
the
SSH
controller,
an
SSH
bash
script
that
gets
put
on
to
the
machine
cloud
in
it
for
core
OS,
something
along
those
lines
or
ignition
template
for
core
laughs.
My
apologies.
E
E
E
I'm
gonna
theorizing
here
on
my
own
around
useless
things,
unlike
that
make
sense
a
little
bit
more
on
them
yeah.
So
that's.
This
will
only
love
to
hear
there's
some
interest
at
this
topic
in
general,
so
yeah
I,
don't
have
any
more
people
opposed
already
kind
of
people.
P5
sound
good
sounds
reassuring
that
I'm
loving
my
own
increase
in
this
that
we
can
carry
on
this
discussion.
A
A
C
C
A
Yeah
for
those
of
you
who
haven't
seen
it
nadir,
just
made
a
CrossRef
and
also
put
it
into
the
chat
card,
steal
girl,
so
yeah,
that's
that's
good
and
I
definitely
think
we
should
take
a
look
at
that
and
comment
on
it
a
little
bit.
There
was
discussion
about
maybe
putting
it
into
get
this
week
so
yeah
for
those
of
you
who
are
interested.
Please
read
it
comment
on
it
and
then
we
can
go
ahead
and
and
take
a
look
at
how
to
move
that
forward.
E
Have
a
right
with
a
fun
right
way
of
talking
about
it,
so
that
you
know
we
don't
say
that
well
hold
on
now
we
all
follow
them.
You
have
to
talk
about
this
new
obstruction
that
we
all
pretty
much,
because
we
can
just
you
know,
try
to
find
a
way
to
have
a
discussion,
while
everybody's
still
making
progress
on
their
implementation
and
have
this
sort
of
you
that
we
can
start
adopting
in
the
future.
A
I
think
the
general
concept
of
the
providers
was
or
it
not
even
the
general
concept.
It
was
explicitly
decided
that
each
provider
would
start
implementing
things
on
their
own
and
we
would
bubble
things
up
as
as
we
came
to
them,
I
think
we're
all
coming
to
this
one,
and
so
it's
time
to
put
something
in
place
for
it.
It's
the
maturity
is
has
gotten
there
and
we
have
to
do
something
about
it
because
otherwise
we're
all
just
writing
a
whole
bunch
of
Ashman
I
don't
enjoy
doing
that.
A
You
all
right
does
anybody
else
have
any
items
that
they
wanted
to
bring
to
the
table.
I.
B
Have
a
newbie
question
so
from
what
I've
done
this
from
what
I
understand?
You
need
two
separate
clusters
by
namespaces,
so
you
cannot
have
multiple
clusters
in
one
namespace.
First
off.
Is
that
correct?
And,
secondly,
can
somebody
point
me
to
the
design
decision?
Why
is
that?
Why
don't
I
just
have
basically
I,
don't
know
an
owner
F
from
the
cluster
to
the
machines
or
something
like
that.
A
You
I
have
no
answer
for
you
on
that
one,
and
it
sounds
like
nobody
else
does
either
I
was
actually
maybe
it
was.
You
I
was
discussing
this
with
the
other
day
in
slack,
but
I
know
somebody
brought
it
up
in
the
slack
channel
as
well
in
the
cluster
API
and
was
asking
very
similar
questions
and
I
I
haven't
seen
any
design
doc
that
that
covers
that
or
why
we
chose
to
do
that.
A
It
may
just
be
an
artifact
of
the
history
of
cluster
API
and
coming
from
coop.
Deploy
on
down.
I
do
know
that
there
are
some
users
of
the
original
origins
of
what
became
cluster
API,
where
they
don't
deploy
the
control
plane
on
to
machines.
They
deploy
the
whole
control
plane
into
an
interface
and
as
a
result
of
that
they
had
a
cluster
per
namespace
concept
already
and
I.
Think
that
may
have
just
fallen
out
of
that
and
be
kind
of
a
vestigial
tail,
but
I'm
not
entirely
sure.
D
There's
there's
a
lot
of
notes
in
the
cluster
API
project.
No,
it's
particularly
from
June
and
previously
I.
Think
it's
a
lot
of
it.
It's
just
mad.
We
know
one
Scott
Mountie
doing
anything
about
it,
and
especially
the
ceoddi
migration
was
like
took
priority
against
something
else,
so
it
might
be
time
it's
not
talking
about
it
again.
D
A
Going
once
going
twice,
alright,
just
as
a
news
item
for
the
cluster
API
space
ecosystem,
whatever
we
want
to
call
it
are
we
actually
a
working
group
I'm,
not
sure
what
we
are
I
know.
We
belong
to
say
cluster
lifecycle
and
there
is
a
working
group
age,
but
I'm
not
sure.
If
we're
actually
working,
we
should
identify
it.
I.
D
E
B
D
E
A
Sure,
either
way,
I
think
whatever
this
page
is
that
I
just
linked
in
the
chat
this
cluster
API
working
group
page
needs
some
work.
It
either
needs
to
go
away
or
it
need
some
work.
That
being
said,
exciting
news
as
I
was
mentioning
in
the
clustering
API
eco
verse,
the
digital
ocean
provider.
Marco
has
just
made
a
request
to
move
back
into
the
kubernetes
sakes,
a
namespace.
So
congratulations,
thank
you,
awesome
stuff
from
the
guys
at
loot,
so
really
appreciate
it
so
yeah
last
chance
here.