►
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
Hello
and
welcome
to
another
load,
balancer
provider
meeting
for
sig,
cluster
lifecycle
and
cluster
api,
just
a
reminder
that
this
meeting
is
being
recorded
and
will
be
posted
up
to
youtube
afterwards
and
the
general
kubernetes
community
code
of
contact
does
apply.
So
in
general,
please
be
excellent
to
one
another.
A
I
earlier
last
well,
last
week,
andy
nadir
and
myself
got
together
and
we
started
hashing
out
an
alternative
implementation
that
may
that
wouldn't
rely
necessarily
on
the
service
and
endpoint
types
specifically,
because
I
think
we've
identified
some
issues
that
would
prevent
immediate
adoption
of
a
service
based
design.
A
So
I
think
that
was
the
main
outstanding
action
item
that
we
had
previously
and
we
kubecon
this
week.
I
don't
expect
too
many
of
us
will
have
much
of
a
chance
to
make
additional
progress
this
week.
So
I'm
I'm
thinking
as
a
group.
It
might
be
good
to
instead
of
following
up
next
week,
maybe
follow
up
the
week
after.
C
A
All
right,
so
that's
out
of
the
way
are:
are
there
I?
I
don't
think
we're
necessarily
ready
to
discuss
the
proposals
and
and
long-term
and
short-term
implications
right
now.
I
think
most
of
the
work
that
we
probably
have
to
do
is
continue
hashing
out
both
of
the
designs
and
the
additional
work
around
there.
A
D
D
Just
a
question
in
terms
of
the
pre-drain
and
pre-term
hook
on
machines
is
that
is
that
a
finalizer
or?
Is
that
a
something.
A
Else
it
is
not
a
finalizer
and
when
we
were
discussing
it,
you
know
we
wanted
to
make
sure
that
it
wasn't
a
finalizer,
because
we
wanted
to
make
sure
that
there's
the
ability
for
the
load
balancer
to
take
action
prior
to
the
machine
deletion
so
that
we
can
have
kind
of
safe
removal
from
the
load
balancer
it
it's
a
proposal
that
was
merged
relatively
recently
and
implemented
by
michael
and
the
red
hat.
D
Folks,
so
you
don't
want
to
force
somebody
to
delete
the
machine
to
have
it
removed
from
a
load
balancer.
A
Oh
no,
what
it
is
is
the
pre-drain
and
pre-termination
hooks
right
now
are
annotations
that
are
defined
on
the
machine
resource
and
if
they
are
set,
it
blocks
the
actual
reconciliation
of
the
machine
until
those
annotations
are
removed.
A
Okay-
and
I
can
go
ahead
and
dig
up
the
link
to
that
proposal,
and
we
can
link
that
here
in
this
space
too.
A
Yeah
well,
the
big
difference
is,
is
the
finalizer
doesn't
prevent
reconciliation
of
the
machine
deletion
happening
and
the
underlying
infrastructure
being
removed?
It
only
prevents
the
api
resource
from
being
deleted
from
the
api
server
and
the
pre-drain
and
pre-termination
hooks
specifically
block
the
reconciliation
so
that
the
underlying
infrastructure
isn't
removed
prior
to
the
action
taking
place.
A
Sense,
thank
you
for
bringing
up
that.
We
need
to
provide
more
context
and
detail
there.
C
Yeah,
I
think
what
you
said
earlier:
jason
is
accurate,
that
this
was
just
some
brainstorming
that
isn't
fully
fleshed
out,
and
so
we
need
to
finish
doing
that
before
we
really
go
over
it
with
the
group,
but
definitely
a
good
question
motion
thanks
for
asking.
D
A
So
one
of
the
reasons,
and
and
initially
we
had
talked
about
having
it
specific
to
machine,
and
one
of
the
reasons
why
I
was
hesitant
to
kind
of
locking
specifically
into
a
machine
was
if
we
do
plan
on
going
with,
like
service
type
load
balancer
in
the
future,
it
would
have
a
way
for
us
to
transition
or
support
alternative
implementations.
A
D
Well,
so
they
can,
they
can
interact
with
whatever
the
load
balancer
ref
points
to
using
duct
typing,
so
it
must
have
a
specific
status.
D
Unless
this
is
a
pattern
that
wants
to
be
explicitly
enabled
to
have
a
load
balancer
and
then
have
a
service
infrastructure,
ref
and
a
machine
load,
balancer
infrastructure
riff
just
seems
that
there
might
be
quite
a
lot
of
objects
involved.
There.
B
B
So
I
had
a
question
in
another
subject
related
to
this.
I
guess,
since
it's
a
new
resource,
most
of
the
migration
and
adoption
of
existing
local
would
be
the
responsibility
of
the
provider.
Is
that.
A
Okay
for
the
implementation
details,
I
don't
necessarily
know
that
we've
fully
defined
that
I
think
we
had
toyed
around
with
the
idea
that
there
could
potentially
be
some
common
reconciliation
behavior,
but
I
don't
think
we
necessarily
defined
exactly
what
that
would
be
versus
the
provider
implementation
at
this
point
all
right.
C
Right
so
I
think
I
agree
with
what
mosh
was
saying
about
the
duck
typing
and
contracts.
So
if
we
treat
this
like,
we
do
the
other
types
and
the
other
references
where
doesn't
matter
if
it's
an
aws
machine
or
an
azure
machine
or
whatever.
I
think
the
same
principles
can
apply
here.
So
if
we
want
to
call
this
machine
loan
balancer,
we
can
and
have
multiple
implementations.
C
This
would
be
like
two
levels
of
implementations
where
you
would
have
the
cluster
that
points
to
some
load:
balancer
type,
that
implements
a
contract
which
points
to
an
infrastructure
aspect
for
a
load
balancer
that
implements
a
contract.
So
it
would
be
a
little
bit
different,
but
same
concept.
C
D
And
then
just
one
other
question
on
the
endpoint
url
shouldn't
that
be
in
status.
C
I
can
so
the
the
way
that
we
are
the
restrictions
that
we
have
or
that,
if
there's
anything
that
we
can't
rediscover
based
on
information
that
we
have
in
the
spec,
we
have
to
store
it
in
the
spec
and
not
the
status.
So
this
is
like.
I
think
it's
too
early
to
talk
about
this
right
now
other
than
we
need
to
do
some
r
d
to
figure
out
what
the
contract
looks
like
so
for
this
particular
one.
C
If
we
create
an
nlb
and
for
whatever
reason
we
couldn't
figure
out
what
its
dns
name
was,
it
would
have
to
go
in
the
spec.
I
think
it
probably
could
go
in
status,
but
at
this
point
I
think
that's
low
on
the
priority
list,
but
definitely
something
that
we'll
figure
out
as
we
go
through
this.
A
And
just
add
on
the
other
aspect
of
it
is:
is
we
wanted?
We
also
want
to
be
able
to
retain
the
same
behavior
that
we
have
today,
where
somebody
can
specify
the
endpoint
url
externally,
whether
it's
because
whatever
provider
doesn't
support
automatic
dns
creation
and
there's
some
external
action
that
needs
to
be
taken
or
we're
talking
about
kind
of
like
the
stage
adoption
path,
where
somebody's
not
actually
making
use
of
some
of
the
cluster
api
components
as
well.
C
E
Sure,
jeff,
on
what
you
just
said,
jake
and
I
there's
some
stories:
five:
a
and
five
b
sort
of
talk
about
the
use
cases.
For
exactly
that.
Obviously,
we
need
to
start
cross-referencing,
the
user
stories
to
requirements
to
do
our
actual
design,
but
that's
the
intent.
A
B
B
A
All
right,
if
not,
I
think
the
action
items
are
more
generally.
Let's
continue
fleshing
out
the
two
proposals
that
we
have
in
here:
let's
go
ahead
and
try
to
start
cross-linking
in
the
proposals
to
some
of
the
various
use
cases
and
requirements
that
we
have
and
I
will
go
ahead
and
schedule
a
meeting
to
reconvene
on
the
30th.