►
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
Rules
and
we
will
all
behave
as
good
people
know
that
this
meeting
is
being
recorded
and
will
be
posted
to
the
Internet.
So
say
things
that
you
want
people
to
hear
you
say
again
and
with
that
said,
I'm
gonna
bring
up
the
agenda,
I
pasted
the
agenda
in
the
chat,
and
so,
if
you
have
any
items
to
add
I
added
two
items
that
I
thought
would
be
of
general
interest.
A
One
is
the
extraction
of
the
cloud
provider
from
Cuba
news,
Cabernets
repo
and
the
other
was
to
discuss
progress
on
items
that
we're
tracking
for
the
kubernetes
1.18
milestone.
So
if
anybody
has
anything
else
to
add
to
the
agenda
feel
free
to
add
it
to
that
doc
and
I
see
a
few
more
people
joining
great
welcome
everybody.
A
A
A
A
B
C
A
Okay,
so
that's
no
questions
there
on
the
credential
provider,
so
the
credential
provider
is
being
extracted.
There
is
a
separate
issue
being
tracked
on
the
board
and
there
is
an
open
PR
for
doing
the
work,
but
it's
not
nobody
is
currently
working
on
it
is
that
something
anybody
here
is
interested
in
picking
up.
C
A
A
B
A
A
A
A
A
A
A
A
Some
of
it
has
already
been
cherry
picked
to
various
patch
releases
for
prior
versions
of
kubernetes,
and
additional
work
is
ongoing
right
now.
The
latest
issue
that
has
been
discovered
has
been
around
the
challenges
when
you
scale
up
clusters
and
use
internal
load
balancers
within
Hazar
and
actually.
A
Alby,
it's
any
lb
30
jack,
so
we
just
discovered
it
specifically
on
clusters
that
we're
using
the
internal
load
balancer
configuration
okay
thanks
for
that
clarification,
it's
someone
who
knows
more
than
I
about
the
the
resolution.
That's
being
undertaken
right
now,
speak
to
that
I
know
a
nish
and
Jackie
both
been
involved
in
that
I.
Think.
B
C
C
Yeah,
so,
basically,
as
a
short-term
fix
in
118,
we
are
going
to
introduce
some
delays
instead
of
making
all
the
VM
instance
updates.
Concurrently
and
PR
has
been
approved
and
it's
being
in
the
process,
so
it's
in
the
process
of
being
merged,
and
after
that
the
short-term
fix
would
then
gradually
get
cherry
pick
until
1.15,
and
once
that
is
done,
the
long-term
fix
in
1.18
is
when
we
have
multiple
VM
instances
that
we
want
to
update.
C
The
update
request
would
be
sent
sequentially
and
once
all
the
sequential
update
requests
are
done,
we
would
wait
concurrently
for
all
our
pets
to
get
complete.
So
that
way
we
won't
have
any
conflicts
by
sending
multiple
requests
of
this
in
time,
and
the
reason
that
this
change
would
only
be
in
118
is
because
the
way
the
clients
have
been
rewritten
in
one
eighteenth's
can
be
done,
but
it's
big
enough
that
it
cannot
be
cherry-pick
two
older
versions,
so
the
short-term
fix
will
be
applicable
for
with
hundred
fifteen
sixteen
and
seventeen
and
from
1.18.
C
B
Wonder
if
it's
worth
kind
of
clarifying,
since
we're
being
recorded
for
the
record,
that
this,
the
what
you
observed
about
fixing
load
balancer
for
versions
prior
to
118,
initial
I,
wonder
if
that
is
going
to
apply
more
generally.
So
if
we
can
expect
that
there
will
be
fewer
cherry-picked
fixes
to
the
cloud
provider
for
these
kinds
of
changes
due
to
the
the
client
refactor.
That
happened
with
118.
Now.
C
Yes,
that
made
sense
like
because
and
there's
been
a
major
defect
in
terms
of
the
way
the
clients
are
called.
The
plans
are
implemented
and
also
a
lot
of
the
caching
logic,
because
of
which
not
everything
that
can
be
done
in
118
can
be
cherry-pick,
but
I
think
for
this
particular
problem.
We
have
found
the
way
to
have
it
implemented
in
118
and
also
cherry-picked
in
previous
versions,
but
I
mean
going
forward.
I
think
that's
something
that
it's
not
always.
B
A
A
C
I
mean
just
outside
of
all
this,
like
I,
think
one
other
thing
that
would
one
of
the
change
that
will
be
happening
in
cloud
providers,
basically
supporting
just
a
single
static
ipv6.
So
most
of
the
changes
have
already
gone
gone
in
as
part
of
the
dual
stack
implementation,
but
they
are
also
feature
gated.
So
most
of
the
changes
right
now
check
if
it
is
a
dual
start
cluster,
so
those
changes
would
be
those
feature.
Gate
checks
would
be
removed
so
that
we
can
start
supporting
singles
time
right.
Give
me
six.
That's.
A
Okay,
that's
the
agenda.
I
prepared
I
want
to
open
up
the
discussion
for
anything
else.
One
thing
I
would
like
to
maybe
they're
out.
There
is,
since
we're
nearing
the
close
of
118
work.
You
know
we
could
start
talking
about
what
we
want
to
try
to
accomplish
in
119,
for
example,
but
I'd
like
to
open
it
up
to
other
folks.