►
Description
Agenda - https://docs.google.com/document/d/1KLsGGzNXQbsPeELCeF_q-f0h0CEGSe20xiwvcR2NlYM/edit#
[andrewsy] Starting May 5th meeting will start at 9:30 PT
Walter to update calendar invite going forward
[elmiko] question about the “use-service-account-credentials” flag, how does this work, what is the history behind it?
Nckturner recently added a PR to allow custom service account names per cloud controller in CCM https://github.com/kubernetes/kubernetes/pull/103178
[cheftako] thinking of new branching strategy for KNP
AI to continue discussion in https://github.com/kubernetes-sigs/apiserver-network-proxy/issues/346
[jakub] thoughts on adding controller metrics to check if controller is running on either KCM or CCM?
[cheftako] jiahui might be the best person to follow-up with, overall sounds like a good idea
[jakub] metrics already exists https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/component-base/metrics/prometheus/controllers/metrics.go
B
Welcome
to
the
April
21st
Thursday
Sig
cloud
provider
working
group
extraction
meeting:
this
is
part
of
the
cncf
and
we
are
compliant
or
we
we
aim
to
be
compliant
with
all
of
the
cncf
rules.
With
regards
to
how
we
treat
others,
it
amounts
to.
Please
be
considerate
and
inclusive
of
all
your
fellow
participants
and
with
that
we'll
start
with
Andrew's
first
item,
which
is
moving
the
time
slot.
This
meeting
happens
at
so
it
has
traditionally
happened
at
1,
30
Pacific,
but
we've
just
recently
had
a
vote
and
Andrew.
C
D
Yeah,
so
during
an
investigation
of
some
of
our,
you
know,
KCM
to
CCM
stuff,
we
were
looking
at
this
used
service
account
credentials
flag,
which
is
a
Boolean,
and
you
know
in
a
lot
of
our
deployments.
We
just
had
it
set
to
true,
but
as
we
were
auditing
them
and
kind
of
investigating
how
this
flag
Works,
it
became
a
little
mysterious
to
us,
because
this
flag
goes
back
to
the
KCM
days
and
it's
existed,
I
think
since
2016,
or
something
like
that,
so
I
was
kind
of
curious.
C
It
uses
the
system
role
for
the
controller
as
just
a
user
agent
for
the
client,
that's
controller
uses,
and
it
just
shares
the
permission
of
the
component
itself.
So
like
keep
it.
Every
controller
gets
the
same
permissions
as
key
controller
manager,
which
is
very
privileged.
If
you
set
the
use
service
account
credentials
flag.
B
My
understanding
is
it's
about
allowing
each
controller
to
run
as
its
separate
service
account
so
that
you
can
lock
down
what
it
has
permission
to
do.
It
will
also
I
think
if
you
have
certain
other
features
like
server-side
apply
turned
on.
It
can
also
do
things
like
indicate
which
Fields,
a
given
controller,
has
has
ownership
of
via
its
service
account.
D
Okay,
so
then-
and
this
kind
of
concurs
with
some
of
the
investigations
that
you
know
my
colleagues
have
done
and
I
guess
like
the
question
then
becomes
in
a
CCM
where
we're
explicitly
giving
the
service
account
with
the
deployment
it
does.
This
flag
still
have
meaning
or
is
it
kind
of
like
an
artifact
of
the
past?
At
that
point,.
B
That's
a
great
question.
The
one
thing
I
will
comment
on
this.
One
and
I
wish
Nick
were
here.
Nick
in
I.
Am
not
this
most
recent
release,
but
the
release
before
it
actually
added
into
the
CCM
configuration.
What
I
believe
is
a
role.
It's
either
a
role
or
a
service
account
per
controller
configuration.
B
C
Right
and
like
the
the
main,
the
main
use
case
for
this
feature
is
that,
like
in
the
KCM,
the
surface
account
that
we
passed
to
controller
is
like
a
fixed
name
that
is
created
either
by
KCM
or
or
qbps
server.
So
there's
no
way
to
actually
like
manage
or
mutate
that.
But
by
doing
this,
you
can
like
force
a
surface
force.
A
certain
service
count
to
pass
into
the
controller,
and
you
can
control
the
roll
bindings
and
the
roles
that
are
associated
with
foreign
I.
C
B
D
B
B
So
what
I
would
do
is
I
would
look
in
the
cube,
API
server
log
with
the
relevant
log
level
turned
up.
You
should
be
able
to
look
at
the
mutation
requests
coming
in
and
what
you,
what,
if
you
start
playing
with
it,
I
think
what
you
may
discover
is
that
if
you
turn
it
off,
the
KCM
and
the
CCM
are
going
to
use
a
single
service
account,
whereas,
if
you
have
it
turned
on,
you
will
see
the
requests
coming
into
the
cube.
B
D
B
All
right,
one
thing
I
wanted
to
mention:
we
are
getting
to
the
point
where,
with
API
server
Network
proxy,
where
we're
starting
to
consider
wanting
to
actually
Branch
it
so
we're
thinking,
we
might
create
a
branching
strategy
and
I.
Think
Andrew
was
leading
the
effort
there
and
we
were
thinking
about
putting
a
DOT
one
branch
where
which
would
currently
be
sort
of
our
more
experimental
branch
and
then
keeping
the
zero
zero
line
for
sort
of
more
stable.
For
now,
did
you
want
to
chat
about
that
at
all
Andrew.
C
C
We
have
enough
new
feature,
requests
and
PR's
coming
in,
but
we
also
have
bug
fixes
and
issues
coming
in
at
the
same
time
and
it
might
be
good
to
Branch
it
out,
especially
when
we,
especially
because
we
have
back
Port
connectivity,
client
fixes
into
the
API
server,
and
so
we
don't
want
to
be
in
a
situation
where
bumping
a
bug
fix
in
the
country.
A
client
also
pulls
in
a
bunch
of
new
features
that
we
may
not
want
in
a
back
Port
patch
and
all
that
so
yeah
I
think
I.
B
C
I
think
my
I
mean
the
only
thing
is
like
I,
don't
think
I
have
permissions
to
create
branches
and
put
branches
there
or
maybe
I
do
I,
never
I
just
assumed
it.
But
let
me
let
me
check
that
and
if
I
do
I
might
go
ahead
and
just
make
the
branch
I
know
some
community
members
like
I
know
Joseph
actually
had
concerns
about
branching
out
because
obviously
like
there's
a
development
overhead
of
managing
multiple
branches
and
backwards.