►
Description
- Last Known Good (LKG) design doc is now public
- Webhook implementation in CCM. Ask for help.
A
A
A
Fundamentally,
the
idea
here
is:
we
know
that
a
fair
chunk
of
our
testing
rely
today
for
the
kubernetes
kubernetes
repo
relies
on
cloud
providers.
We
have
a
couple
of
flags
today
in
feature
gates
that
will
basically,
once
those
feature
gates
are
turned
on
so
they're
alpha
and
they're
turned
off
by
default
today,
but
once
they
are
turned
on,
they
will
not
allow
the
cubelet
the
cube
controller
manager
or
the
cube
api
server
to
come
up.
If
the
cube
api
server
or
the
credential
provider
cloud
provider,
specific
credential
provider
code
is
enabled.
A
So
right
now,
if
you
turn
them
on
all
of
our
tests
begin
to
fail.
Obviously
we
want
to
get
past
that,
and
so
a
lot
of
the
lkg
work
is
looking
at
how
we
can
go
about
running
those
tests
where
the
code,
the
other
bit
of
the
code,
that's
necessary.
Like
the
cloud
controller
manager
or
the
credential
provider,
are
cloud
provider
specific,
builds
and
require
cloud
providers,
specific
clusters
to
run
those
tests,
and
with
that
I
will
turn
it
over
to
kermit.
B
Well,
yeah
thanks
walter
yeah,
so
I
think
I
know
some
of
you
all
are
asking
about.
You
know
the
design
doc.
I
think
it
was
last
meeting
when
we
had
the
presentation
you
know
about.
You
know
the
lkg
and
you
know
stuff
like
that.
So
now
it
should
be
public.
I
think
everyone
should
have
at
least
comment
access.
So
if
there's
you
know
questions
that
any
of
you
will
have
about
it
or
anything
like
that,
or
you
know
things
that
you
might
want.
B
You
know
added
or
things
that
you
have
questions
about
should
be.
You
know,
should
be
able
to
to
have
that
from
the
document
in
terms
of
new
information.
That's
on
there.
I
think
the
the
design
doc
goes
into
a
couple
different
things
that
the
slides
didn't
talking
about
things
like
go
mod,
in
addition
to,
I
think,
in
terms
of
how
we're
also
updating
other
dependencies
as
well.
B
B
Using
this,
that's
still
part
of
the
work
in
progress,
but
let's
see
what
else
to
cover
it
also
was
working
on
getting
the
actual
work
of
lkg
worked
out
so
that,
hopefully,
for
anyone
who's
interested
in
contributing
to
the
general
okay
gf.
We
should
have
you
know
a
list
of
tasks
relatively
shortly.
I
think
that
that's
about
it,
I
think.
That's
all.
I
really
wanted
to
cover
if
you
all
had
questions
about
the
design.
A
C
Yeah
one
comment
on
the
permissions.
I
had
one.
I
had
one
colleague
who
tried
to
read
the
doc
and
I
think
they
might
have
had
an
issue
because
they
were
asking
me
if
they
needed
to
be
part
of
a
particular
google
group
to
read
it.
So
maybe
I
don't
maybe
if
we
get
a
double
check
on
the
permissions
there
and
then
I
guess
you
kind
of
answered
my
second
question
but
yeah.
If
we
have
issues
or
questions
about
this,
should
we
just
leave
comments
directly
in
the
doc.
B
Yeah
yeah
comments
on
the
on.
There
would
be
great
you
can
also
reach
out
to
me
via
slack.
If
it's
you
know
something,
you
want
to
ask
me
directly,
although
if
it's
found
a
comment
on
the
document,
then
that
way
everyone
can
see
it
in
terms
of
permissions.
I
think
anyone
that
the
I
the
group
I
shared
the
permissions
with
was
a
kubernetes
state
cloud
provider
that
google
group,
so
anyone
inside
that
group
should
be
able
to
access
it.
C
B
C
E
Yeah,
so
the
idea
is
that,
and
this
is
for
cloud
provider
gcp.
This
is
what
we
want
to
do
there
and
other
cloud
providers
can
decide
what
they
want
to
do.
We're
not
prescribing
what
other
cloud
providers
do
we
want
to
if
our,
if
our
background
processes
that
are
looking
for
new
lkgs
are
failing,
we
actually
want
to
stop
prs
from
merging
into
our
branch
until
we
get
that
figured
out.
E
If
you
have
a
cloud
provider
and
you
want
a
different
policy-
that's
entirely
up
to
you
like
you
could
you
could
just
say
you
could
still
have
it
so
that
you
can
see
here
that
it's
failing,
but
you
could
all
you
could
not.
You
could
not
refuse
pre-submits.
You
could
ignore
the
solvent
completely.
It
would
be.
You
would
be.
You
know.
You'd
have
to
configure
it,
but
you
could
figure
configure
it.
How
you
want.
A
E
You
are
a
developer,
submitting
prs
there
us
as
the
people
that
are
doing
development
on
or
setting
up
cloud
provider.
Gcp
are
going
to
make
that
blocking
for
that
repo
yeah
we're
not
going
to
do
anything
for
kubernetes
we're
not
going
to
do
anything
else
for
any
of
the
other
cloud
providers.
Another
cloud
provider
decides
to
turn
on
this
functionality
as
part
of
turn
it
on
they're
gonna
have
to
make
a
decision
on
whether
or
not
they
want
to
add
this
pre-submit
at
all.
Whether
or
not
they
want
to
make
a
blocking.
A
Yeah
and
awesome,
that's
kind
of
what
I
wanted
to
hear.
We
can.
There
is
a
side
conversation
or
a
conversation
in
sig
release
going
on
about
all
of
this,
but,
and
so
I
cannot
speak
for
sick
release,
but
I
am
fairly
certain,
despite
not
being
able
to
speak
for
them,
that
we
are
not
going
to
be
able
to
get
any
of
this
testing
in
pre-submit
in
the
short
term.
A
You
know
problems
with
problems
with
flakiness,
etc
need
to
be
resolved,
and
I
think
we're
going
to
have
to
have
a
even
a
given
cloud
provider
is
going
to
have
have
to
have
a
fairly
strong
track
record
of
having
stable
testing
before
sig
release
is
likely
to
be
even
amenable
to
talking
about
making
any
of
those
tests.
Pre-Submit.
A
A
A
A
But
you
know,
I
know
at
the
same
time
when
I
say
that
other
there
are
other
use
cases
for
web
hooks,
which
may
not
be
as
directly
part
of
this,
the
core
kk
concept.
But
as
an
example,
I
know
google
has
a
small
number
of
web
hooks
that
they
install
for
gke
and
I'm
guessing
that
other
managed
services
do
similar
things
so
making
it
easier
to
to
centralize
that,
I
think,
will
be
beneficial
to
a
lot
of
folks.
A
We
have
a
cap
basically
describing
how
we
can
go
about
that,
and
we've
been
approved
to
go
alpha
in
this
release.
That
gives
us
about
four
weeks
of
development
time,
so
I
am
hoping
after
kubecon.
Really
it
gets
gets
done
to
actually
start
working
on
this,
but
that
doesn't
give
me
much
time.
So
if
anyone
is
interested,
please
reach
out,
there
are
a
couple
of
other
people
as
well,
who
I
know
are
somewhat
familiar
with.
A
This
cc
has
certainly
done
quite
a
bit
of
work
on
extending
the
the
core
ccm
code
to
make
it
sort
of
more
generically.
Extensible
and
nick
has
also
very
recently
added
some
changes
to
make
the
core
ccm
code
more
easily
extensible
for
cloud
providers.
So
anyone
who's
interested
reach
out
to
me
or
you
can
always
try
pinging
on
the
channel
and
either
necro
cc.
Might
you
know
I
don't
want
to
volunteer
them
but
might
be
willing
to
help
so
yeah?
There's?
Definitely
some
interesting
work
there
to
be
done.
C
A
A
A
So
that's
this
doc.
I
wrote
a
while
ago
called
making
ccn
easier
to
consume
and
it
sort
of
go
when
we,
when
ccm
was
first
written,
it
was
sort
of
one
ccm
and
then
modify
it,
and
then
it
became
very
painful
to
because
every
time
we
try
to
upgrade
the
ccm.
What
happens
is
all
the
cloud
providers
who
had
modified
this
were
like
now.
C
That's
really
awesome,
I'm
curious
about
that
doc
and
I
guess
at
the
risk
of
kind
of
heading
off
into
a
little
bit
of
a
non-sequitur
here,
that
the
merge
hell
you're
talking
about
like
I'm
currently
working
with
a
cloud
provider
who
has
a
ccm
and
I
don't
want
to
name
names
but
like
their
ccm,
is
kind
of
like
half
based
on
the
upstream
cloud
provider.
Library
like
it
uses
functions
from
that
library,
but
I
can
see
that
they've
tried
to
like
dive
in
to
some
of
the
functions
and
like
implement.
C
You
know
pieces
of
it
on
their
own
and
I'm
just
curious
like
in
general.
Like
should
we
be?
Should
we
be
trying
to
promote
that
people?
Writing
new
ccms
should
use
that
cloud
provider
library,
as
as
the
basis
for
everything,
and
that
that
is
really
going
to
help
them
avoid
some
of
these
issues.
I
mean
I'm
just
I'm
just
curious
how
I
can
kind
of
promote
them
to
go
in
that
direction.
You
know
absolutely,
and
I
don't
know.
A
A
We
want
different
service
accounts
than
the
defaults
for
some
of
these
controller
loops,
and
I
could
just
go
in
and
hack
the
core
code
that
I
copy
over.
But
then
I'm
going
to
explain
I'm
speaking
for
nick,
you
are
welcome
to
take
over
at
any
point
and
speak
to
yourself,
nick,
but
basically
nick
came
to
me
and
said:
hey,
I
really
don't
want
to
be
going
through
merge
hell.
Would
you
be
okay
with
making
the
configuration
of
the
service
account
used
to
run
the
controller?
A
C
Yeah
that
and
that's
a
great
suggestion,
thanks
for
bringing
that
up
about
like
if
we
need
extension
points
and
whatnot,
and
you
know
first
of
all
I'll
say
it
it.
The
first,
the
you
know
the
organization
I'm
working
with
is
not
represented
by
any
of
the
clouds
who
are
on
this
call.
So
it's
nobody,
it's
nobody
who's
in
the
room,
but
I
still
you
know,
discretion
being
the
better
part
of
valor
here.
So
it's
interesting.
C
You
mentioned
the
service
account
because
that
was
actually
one
of
the
areas
where
they
had
written
a
lot
of
custom
logic
around
how
to
use
the
credentials
from
the
service
account
and
we
like,
we
ran
headlong
into
that.
So,
okay,
I
I'll
talk
about
them
with
this
and
yeah.
If
there's
any
extensions
that
they
think
they
need
that
they're
not
getting
today,
yeah
I'll
just
come
back
to
the
group
and
see
if
we
can
figure
something
out,
then.
A
C
I'll
look
at
that
yeah
I
mean
like
big
props
to
nick
I've,
been
I
mean
really
at
everybody.
I've
been
I've
been
using
aws
as
one
of
the
referees
and
examples
I
keep
going
back
to
and
looking
at,
but
I've
also
been
comparing
with
like
gcae
and
openstack
and
whatnot.
So
I've
been
trying
to
look
at
a
bunch
of
these
things
to
see
what
the
common
patterns
are
and
it
starts
to
become
apparent
like
who's,
not
kind
of
following
those
patterns.
A
I
also
I
want
to
say,
like
huge
props,
to
cc
and
joe,
like
the
very
first
version
of
cloud
provider,
gcp
ccm
I
threw
together
and
quickly
and
just
to
get
it
off
the
ground
and
they
were
the
ones
who
had
to
suffer
through
that
first
merge
hell
where
it
was
like.
Oh
we're
going
to
upgrade
from
the
the
kubernetes
117
to
118
code,
and
I
I
should
I
hopefully
I
will
never
do
anything
that
bad
to
anyone
else
again.
C
C
A
No
call
me
out
call
me
out,
like
I
have
been
promising
to
do
this
for
two
weeks
now,
and
I
mean
I
my
excuses
were
bit
I'm
busy,
but
you
know
everyone
here
is
busy,
so
that's
a
pretty
lame
excuse.
Yeah
I
will.
I
will
try
to
make
sure
I
get
those
recordings
out
and
yeah
if
I
don't
have
them
up
by
monday,
just
ping
me
on
slack
and
tell
me
to
stop
being
a
slacker.