►
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
So
with
that
said,
I
think
mosh
had
written
the
previous
proposal.
A
So
would
you
like
to
give
an
overview
of
your
thoughts
there
mosh.
B
Sure
so
I've
actually
been
thinking
about
this
a
little
bit
more
and
I
think
we
don't
actually
need
a
machine
load
balancer.
I
think
what
we
need
is
a
machine
service
implementation,
because
we
started
with
a
goal
of
having
a
configurable
load
balancer
for
control,
plane
and
or
ingress
nodes,
and
but
I
think
that
implementation
would
duplicate
a
lot
of
the
effort
currently
in
the
cloud
load
balances
that
are
currently
implemented.
B
So
if
we
were
to
implement
a
machine
service
that
creates
a
standard
service
without
any
selectors
and
manages
the
endpoints
underneath
it,
I'm
pretty
sure
it
will
support
a
lot
of
load
balancers
out
of
the
box,
so
I'm
thinking,
nsxt
and
cubevip
would
work
out
of
the
box.
As
far
as
I
know,
the
aws
controllers,
I
think,
and
usual
controllers-
would
probably
need
a
bit
more
work
in
terms
of
multi-account
and
multi-vpc
selection
of
where
the
load
balancers
go.
B
But
I
think
those
could
probably
be
done,
but
I
think
if
we
split
it,
it
might
make
it
easier
to
implement
and
more
maintainable
in
the
long
run.
A
All
right-
and
I
I
think
the
next
thing
would
be
a
good
overview
of
what
already
exists
today,
particularly
within
the
vsphere
implementation.
A
Oh
wait,
I
see,
hands
raised
actually
andy
and
he
has
seen
had
his
hand
up
before
me.
Sorry
go
ahead,
you
see
so.
C
Like
I
kind
of
agree
with
mosh
with
respect
of
like
just
having
a
load,
balancer
implementation
in
the
past,
we've
had
requests
that,
for
example,
cab
fee
provides
load
balancer
on
certain
ports
to
expose
system
level
services.
C
So
binary
is
running
on
the
machines
and
I
guess
like
if
we
implement
some
kind
of
either
load
balance
or
service
whatever
we
call
it
and
expose
the
notion
of
selecting
machines
and
exposing
imports
and
protocols,
we
might
be
able
to
build
control,
plane,
endpoint
support
out
of
the
box,
but
also
enabling
use
cases
for
other
folks.
D
Motion
I
was
curious
with
the
service
idea
you
just
suggested.
I
think
I
heard
you
say
that
we
wouldn't
have
a
selector
for
the
service,
and
so
I'm
wondering
like.
B
It
would
mirror
to
a
service
without
selectors
and
then
manage
the
endpoints
underneath
that
service
by
itself.
Otherwise
it
will
select
mtm,
no
endpoints,
because
there's
no
matching.
So
that's
what
I
meant
by
no
selectors.
I
don't
know
I
I
think
people
have
referred
to
it
as
a
headless
service.
There's
not
a
headless
service.
It's
like
an
empty
service
almost
or
a
mock
service.
D
B
Well,
no,
so
the
difference
being
a
machine
load
balancer
would
actually
do
the
realization
of
that
load.
Balancer,
where
a
machine
service,
all
it
would
do,
is
a
selection
of
machines
and
create
the
the
associated
service
and
endpoint
objects.
If
you
wanted
a
load
balancer
on
top
of
that,
then
you
need
to
annotate
your
service
with
whatever
load
balancer
annotations
types
that
you
want
to
get
an
actual
load
balancer
out
of
it
and
then
copy
the
the
annotations
from
the
machine
service
to
the
service
and
copy
the
ips
backup
type
of
thing.
A
All
right,
you
see.
C
Yeah,
I
think
that
another
important
thing
is
to
actually
define
the
problems
we're
trying
to
solve.
So
are
we
trying
to
automate
creation
of
load,
balancer
load
balancers,
and
are
we
also
trying
to
make
implementations
swappable
between
providers
say
I'm
on,
like
I'm
running
cab
v
on
aws?
I
still
want
to
use
the
kappa
implementation
of
control
control,
plane,
endpoint
to
use
elvs,
because
I'm
running
on
dnc,
for
example,.
A
Yeah,
I
think
that's
a
good
point,
and
I
think
that
goes
to
kind
of
the
third
item
in
the
agenda,
which
is
the
scoping
of
goals
and
on
goals.
For
this,
I
I
think
I
would
like
to
try
to
see
you
know
if
we
can,
you
know,
find
some
common
kind
of
consensus
around.
A
C
Yeah
sure
so
I
can
share
my
screen
real
quick.
If
you
want
to
walk
you
out
through
it.
A
While
he's
sharing,
do
we
have
a
note
stock
that
we're
working
in?
I
do
not
right
now.
I
do
have
kind
of
a
skeleton
dock
with
just
the
kind
of
kept
template,
and
I
can
paste
that
in
and
we
can
add
additional
notes
in
there
if
need
be.
D
C
Okay
yeah,
so
so
what
we
have
right
now,
like
on
the
tv
provider,
is
actually
an
infra
cluster
being
tied
to
a
specific
crd
through
an
object
reference.
So
whenever
you
try
to
create
a
vsphere
cluster,
you
would
have
on
your
infra
cluster
a
reference
to
a
crd
and
the
first
implementation
that
we
did
at
the
time
was
the
aha
proxy
load
balancer.
So
there's
basically
a
crd
here
that
specifies
how
to
create
a
nha
proxy
load
balancer
and
in
terms
of
reconciliation.
C
So,
if
I
look
for
reconcile
load
balancer,
what
we
do
here
is
basically
there's
a
lot
like
to
check
the
load
balancer
that
is
tied
to
this
cluster
and
at
some
point
we're
adding
the
owner
wraps
for
it
and
then
we're
basically
copying
if
it's
ready
or
not
and
remove
like
and
also
surfacing
the
status
addresses
that
are
on
the
h,
a
proxy
load
balancer
to
the
control
plane,
endpoint
that
we
want
to
use
on
the
vsphere
cluster.
C
So
this
was
done
first,
when
we
were
trying
to
implement
just
a
machine
load
balancer.
So
it
doesn't
have
all
of
the
abstractions
of
grouping
machines
that
were
not
built
into
placer
api.
C
So
that's
pretty
much
it
in
terms
of
like,
and
the
hd
proxy
load.
Balancer
is
a
controller
specific
to
h
a
proxy
so
like
the
way
I
would
see
it
is
that
it
would
be
a
like
if
we
had
to
do
it
all
over
again,
like
the
input.
The
implementations
that
we'd
want
to
reuse
would
be
standalone
modes
that
we
can
apply
and
or
remove
whenever
we're
on
a
specific
environment
that
enables
say,
h,
a
proxy
cube
whip,
elbs,
strong
directional,
advancers
of
azure
or
whatnot.
A
All
right
and
I
to
to
expand
a
little
bit
more
on
kind
of
the
delta
between
what
exists
in
vsphere
today
and
and
moshe's
concept.
Earlier,
the
big
con,
the
big
difference
there
would
be,
instead
of
everything
being
kind
of
consolidated
within
the
one
controller
and
the
one
data
type
that's
exposed
in
vsphere.
Today
we
would
kind
of
have
more
of
a
two
level
abstraction.
A
Is
that
correct?
Yes,
all
right
great!
So
with
that
said,
it
doesn't
sound
like
there's
too
much
divergence
between
kind
of
what
exists
today
and
kind
of
moshe's
idea,
other
than
kind
of
breaking
that
kind
of
the
separation
of
concerns
down
a
little
bit.
So
we
do
have
the
shared
doc.
I
did
share
that
in
chat.
A
So
let
me
see
the
next
part
was
the
scoping
of
the
goals
and
the
non-goals,
so
I
will
quickly
just
scroll
down
to
that
part
of
the
document.
Let
me
go
ahead
and
share
my
screen.
While
I'm
thinking
about
it.
A
I
know,
at
least
from
my
perspective,
having
some
level
of
reuse
would
be
nice.
However,
I
don't
necessarily
know
how
applicable
that
would
be
to
all
of
the
various
potential
cloud
provider
specific
implementations
out
there.
For
example,
I
can
see
certain
ones
that
would
be
tied
specifically
to
you
know,
specific
instances
that
wouldn't
necessarily
be
able
to
be
tied
to
kind
of
arbitrary
ip
addresses.
A
A
C
Actually,
like
the
bare
minimum
is
go
like
have
been
documentation
on
at
least
a
matrix
between
the
providers
of
cluster
api
and
the
providers
for
load
balancer
to
say
which
providers
is
supported
which,
with
which
load
balancer
provider,
and
we
could
also
imagine
either
an
api
or
something
that
says
if
something
is
supported
on
a
provider
or
not.
A
D
Think
of
a
couple
that
whether
we
spell
these
out
in
goals
or
motivation,
I
think
it's
important
to
say
that
we
want
the
load
balancer
to
work
for
the
control
plane.
D
However,
we
phrased
that
and
then
related
would
be
like
being
able
to
select
which
machines
are
backed
for
a
load
balancer
and
then
to
try
and
find
some
way
to
do.
Quiescence
when
we're
doing
rolling
updates.
D
Yeah,
I
think
we
can
think
about
it
in
wordsmith
later.
The
point
I
was
actually
trying
to
make
was
more
like
I
mean
that
one's
really
important
too,
but
that
the
load
balancer
whatever
we
end
up
doing
here,
needs
to
load
balance.
D
The
control
plane,
which
I
know
the
control
plane
provider-
is
currently
optional
and
there's
a
separate
discussion
about
making
it
potentially
required
that
doesn't
really
matter
here,
but
I
just
I
was
trying
to
highlight
that
the
purpose
of
the
machine
based
load
balancer
is
to
provide
load
balancing
to
the
control
plane
for
the
cluster.
D
Well,
I'm
open
to
arbitrary
load
balancing.
We
can
have
that
as
a
separate
goal.
If
we
want,
I
just
want
to
specifically
highlight
that
we
do
need
this
for
the
control
plane.
Okay,.
D
C
B
Just
in
terms
of
the
the
aws
cluster
api,
provided
you
see
any
any
limitations
of
using
the
built-in
cloud
provider
or
the
out-of-tree
load.
Balancer
providers.
A
Yes,
your
scene
had
his
hand
up.
I
don't
want
to
lose
that.
C
So
so,
like,
I
think
that
one
of
the
worthy
goals
to
add
is
we
need
to
ensure
that
it's
not
tied
to
kcp
and
like
if
you
have
your
own
control
plane,
we
should
at
least
try
and
see
if
we
can
make
it
work
generically
before.
A
Yes
fully
agree
and
before
we
go
too
much
further,
I
want
to
make
sure
that
I
capture
the
other
things
that
andy
mentioned,
which
is
continued
reconciliation
of
members
of
the
load
balancer.
A
And
then
there
was
one
other
bit
and
it's
a
little
great
sorry.
D
Yes,
I
think
it's
related
to
the
continued
reconciliation,
but
just
specifically
calling
out
that
we
want
to
be
able
to
acquiesce
the
connections
find
some
way
that
if
we
are
terminating
or
if
we
want
to
terminate
a
machine,
that's
a
member,
an
active
member
of
the
load
balancer.
D
A
D
Members
yeah,
I
think
it
might
not
strictly
be
for
termination.
D
A
And
trying
to
go
off
of
that
any
other
kind
of
additional
high
level
goals,
at
least,
and
obviously
we
can
wordsmith
this
and
paint
this
bike
shed
five
different
ways
afterwards,
as
well.
B
A
A
C
B
So
I'm
not
sure
if
I
agree
with
that
one,
because
if
this
is
implemented
as
I'm
not
saying
that
it
should
be,
but
if
it
is
implemented
as
a
machine
service,
then
core
cluster
api
would
be
the
logical
place
for
that,
because
there
would
be
very
limited
impact
on
implementing
it
there
and
there
would
be
no
dependency
tree
or
or
cloud
based
management.
It
would
be
a
fairly
straightforward
implementation
in
core
cluster
api
and
then
up
to
something
that's
deployed
externally,
to
actually
realize
the
implementation
of
the
load
balancer.
B
A
All
right,
I
think,
fabrizio
had
his
hand
up
first.
E
D
To
given
that
this
is
going
to
be
a
new
api
or
set
of
apis,
we
probably
should
have
a
goal
that
it's
like
optional
or
feature
gated,
or
something
along
those
lines.
While
we
play
around
with
it
before
making
any
decisions
about
making
it.
D
And
then
I
had
a
question
as
well,
so
I
don't
know
if
there's
only
three
minutes
left
in
the
original
meeting.
I
don't
know
if
folks
can
go
after
or
beyond,
but
I
definitely
want
to
hear
more
mosh
about
like
just
doing
a
walkthrough
of
your
service
or
machine
service
idea
and
the
separation
of
that
from
actually
provisioning
and
configuring
the
infrastructure.
A
Yep,
I
think
that
makes
sense
so
I'll
go
ahead
and
I'll
just
remove
this
implementation
should
not
be
tied
directly
into
core
cluster
api,
and
we
can
re
re
evaluate
that
after
we
get
more
information
on
moshe's
idea
and
the
next
step
before
we
kind
of
head
out,
I
want
to
make
sure
that
we
get
some
action
items
for
at
least
parts
of
this.
I
don't
think
we
need
to
dive
directly
into
the
proposal
pieces
yet
specifically,
because
moshe
is
going
to
write
up
some
more
of
his
ideas
there.
A
A
Is
anybody
able
to
provide
some
of
the
use
cases
and
some
of
the
requirements
around
upgrade
paths
specifically
around
vsphere.
B
A
A
And
I
can
provide
use
cases
around
equinix,
metal,
formerly
packet
and
possibly
do
and
one
of
the
things
I'll
do
is
I'll
I'll
make
sure
to
capture
the
equinix
metal
and
I'll
reach
out
to
carlos
for
digitalocean.
F
A
All
right
around
aws.
A
A
And
then
I
can
I'll
reach
out
to
cecile
and
the
azure
folks
to
see
if
they
can
provide
some
input
on
their
end
and
I'll
also
reach
out
to
the
openstack
folks.
So
I'm
not
necessarily
going
to
put
down
a
timeline
there,
but
I
will
reach
out
to
those
folks
and
try
to
get
some
impact
input.
A
Outside
of
that,
I
think
the
other
action
item
would
be
is
just
kind
of
background
on
the
goals
and
angles
that
we
have
set
and
provide
any
other
inputs
to
the
stock
that
you
want
in
that
time,
and
would
it
help
if
I
reschedule
another
meeting
in
a
week
to
pick
up
next
steps
or
do
we
want
to
go
async
from
here.
D
I
think
scheduling
one
would
be
beneficial,
certainly
to
allow
mosh
to
present
his
brainstorming
if.
A
Nothing
else
all
right
does
this
time
generally
work
for
everybody
next
week,
or
should
I
send
out
another
doodle.
A
Okay,
all
right,
I
think
that
sounded
mostly
affirmative,
so
I'll
go
ahead
and
send
out
another
invite
for
next
week
and
we
can
pick
it
up
from
there.
Thank
you
all.