►
From YouTube: Kubernetes SIG Cluster Lifecycle 20180523 - Cluster API
Description
10:03:16 From Kris Rousey : bad things happen when I try to record
10:13:06 From Cluster Ops : Can somebody volunteer to take notes here please?
10:31:34 From Hardik Dodiya : http://gardener.cloud/ , we use master cluster to manage worker clusters, works great !!
10:39:46 From Daniel Lipovetsky : Can someone please post a link to the kubeadm etcd spec being discussed?
10:39:52 From Cluster Ops : yes
10:40:04 From Cluster Ops : Also curious
10:42:44 From luxas : https://docs.google.com/document/d/1Sk2VW7IKaLjrjf_4a1NEU0l7X0ysZoXq9lVBvH-ruYY/edit#
10:42:52 From luxas : (also in meeting notes)
10:48:42 From Kris Rousey : krousey, kris_nova, robert bailey, and rodrigo are the admins if this break you... I will post something to slack with this regard
10:48:53 From Cluster Ops : okay thanks krousey
A
Looks
like
we
have
something
in
chat:
Oh
Chris
has
bad
things
happen
when
he
tries
to
record
okay,
so
issue
152.
We
had
brought
this
up
a
while
ago,
which
was
I
think
got
a
lot
of
good
feedback
on
it,
but
I
think
they
kind
of
got
off
in
the
weeds
a
little
bit,
which
was
the
the
ongoing
discussion
of
whether
or
not
we
ultimately
want
to
move
cloud
provider
specific
code
also
known
as
actuator
code
out
of
the
cluster
API
repository
and,
if
so
like.
A
What
does
that
that
whole
process
look
like
or
what
does
a
timeline
look
like?
There
looks
like
going
off
of
the
the
github
thumbs
up
voting.
We
had
a
slightly
larger
trend
and
the
idea
of
moving
the
code
of
the
repository,
but
we
got
quite
a
bit
of
pushback
on
possibly
doing
that
any
time
in
the
near
future,
I
think
most
folks
would
kind
of
an
agreement.
A
It
made
sense
to
sort
of
have
a
reactive
posture
here
and
actually
take
on
that
that
burden
of
work
as
soon
as
it
started,
causing
more
problems
than
it
was
solving
for
us
in
real
time.
If
anybody
has
anything
else,
they
want
to
add
to
that
I'm,
okay,
with
kind
of
writing,
a
quick
follow-up
and
I'm
calling
those
items
out
and
closing
the
issue
so
at
least
have
it
documented.
But
now
is
a
good
chance
for
anybody
to
voice
any
concerns.
If
that
does
not
sound
like
something
that
they
agree
with.
A
Going
once
going
twice,
okay,
so
lazy
consensus
dictates.
We
all
agree.
It's
a
good
idea
to
move
it
out.
We
just
don't
want
to
introduce
more
work
until
we're
necessarily
ready
for
it
cool
that
one
was
easy
next
up,
Daniel.
Is
there
a
proposal
for
managing
multiple
masters?
Server-Side
last
discussion
appears
to
be
from
February
28th,
meaning
did
M
Macy
on
post
his
master
deployment
proposal.
Any
more
information
on
this
agenda
item
would
be
helpful.
I.
B
C
A
That
would
be
a
good
starting
point
cool.
It
looks
like
you
have
the
next
one
as
well.
A
proposal
actuator
that
works
with
machines
already
provisioned
with
an
operating
system.
Actuator
would
expect
IP
hostname
in
the
machine
spec
and
use
SSH
useful
for
a
bare-metal
in
the
absence
of
pixie
rye
pixie
are
there
in
destructor
api's.
This
is
a
great
one.
A
C
D
A
Yeah
Justin
had
some
bare
bare
metal
work
in
cops.
Last
night,
looked
at
the
source
code,
which
was
ages
ago.
I
know
that
myself
and
other
folks
are
also
interested
in
some
sort
of
API
list.
Bare
metal
implementation
of
the
cluster
API
I
think
the
two
things
here
you
kind
of
hit
on
one
of
them:
let's,
let's
open
up
an
issue
and
kind
of
keep
our
scope
small
and
talk
about
what
we
are
thinking
here
and
then
I
think.
A
The
other
thing
that
we
have
to
concern
ourselves
with
is
what
robert
bailey
just
mentioned,
which
is
how
do
we
handle
potentially
because
it's
basically
going
to
be
a
new
cloud
provider
right,
which
is
how
do
we
handle
create
anyone
from
the
repository
moving
forward?
So
I
think
maybe
calling
out
both
of
those
in
the
issue,
and
we
could
we
could
start.
There
would
be
a
good
first
day,
yeah.
D
One
question
I
would
ask:
is
you
have
a
proposal
to
do
this?
Is
there
anything
with
the
current
API
that
would
prevent
you
from
doing
exactly
this
using
the
provider
config
blob,
or
are
you
just
looking
for
some
consensus
around
what
you'd
want
to
put
in
the
provider
config
blob
and
how
to
implement
it?
It's.
C
It
yeah
that
was
part
part
of
it.
You
know
we
don't
we
don't.
We
haven't
flushed
out
completely
what
the
provider
config
would
look
like
yeah
part
of
the
I
think
it
seems
feasible
to
do
you
know.
Most
of
this
is
going
to
be
sort
of
opaque
to
the
to
the
controller,
but
yeah
I
think
what
Chris
mentioned
about
you
know
how
feasible
is
it
for
us
to
write
this
the
controller
and
the
deployer
tool
and
then
have
it
live
outside
of
the
repo
I
I've
been
I've
been
run
into
some
issues.
C
D
I'm
gonna
I'm
gonna
put
him
on
the
spot
since
I
see
his
lovely
face
on
my
call
here,
sort
of
representing
the
steering
committee
slash
Sega
architecture.
If
we
do
want
to
have
the
code
outside
of
our
API
repo,
the
kubernetes
SIG's
organization
and
github,
we
should
be
able
to
create
a
new
get
repo
under
that
for
sort
of
this
new
machine.
Actuator
right
sort
of
underneath
this,
a
cluster
lifecycle
mandate
without
too
much
sort
of
overhead
in
terms
of
getting
repos,
approved
I,
would
think.
D
E
A
E
Hear
you,
okay,
I,
think
a
repo
for
every
cloud
makes
more
sense
from
a
lot
of
reasons,
but
if
for
no
other
reason
than
getting
out
of
the
way
of
people
who
are
doing
independent
work
independently
in
the
hindsight
of
the
general
cloud
controller
manager,
work
in
kubernetes
kubernetes
having
a
mondo
repo
that
has
code
from
a
bunch
of
different
providers
just
turned
into
a
nightmare,
as
the
number
of
providers
got.
You
know
close
to
10
I,
can't
even
imagine
what
would
be
like
beyond
that.
D
E
C
D
Also,
some
arguments
around
having
sort
of
a
single
binary
built
for
missing
old
github
repo
is
really
nice
terms
of
working
with
go.
We
certainly
don't
have
to
deal
with
with
Ben
or
dependency
conflicts
or
anything
if
you
start
putting
them
all
in
toward
into
a
mono
repo.
There's
there's
a
lot
of
maintenance
that
goes
down.
D
F
If
they're
a
plant,
so
let's
say
we
have
cloud
provided
GC
such
a
repo.
Can
we
host
the
cloud
controller
manager
and
this
well
repair
stuff
in
the
same
repo
or
do
we
need
like
two
repos
per
cloud
for
two
different
purposes,
both
the
cloud
controller
manager
that
is
running
on
top
of
kubernetes?
And
this
that's
right,
the
other
so.
E
E
Those
sorts
of
controllers
are
going
to
share
some
amount
of
code
and
some
amount
of
dependency,
so
it
makes
sense
and
then
it
just
becomes.
You
know
Google's
problem
to
solve
the
build
for
Google
and
Amazon's
problem,
solving,
build
for
Amazon,
etc,
etc.
So
I
think
the
answer
is
if
they
want
to,
and
we
should
encourage
people
to
do
that,
but
we
shouldn't
necessarily
require
it.
D
A
I
mean
I
think
we're
all
shaking
our
heads
here
in
agreement.
That
sounds
like
a
a
great
plan
anyway
to
go
back
to
the
original
question
here.
Daniel,
if
you
want
guidance
with
the
controller,
if
you
need
help
getting
a
new
repository
set
up,
I
have
strong
opinions
on
bare
metal
implementation,
I'm
happy
to
share
those
I'm
sure,
there's
a
lot
of
other
folks.
Here
you
can
rally
as
well
and
I
can
help
you
and
other
folks
missing
as
well.
Yeah.
D
I
guess
the
one
thing
about
setting
up
new
repository
is
that
all
sort
of
echo
from
yesterday's
cig
meeting
is
that
we
don't
want
to
set
up
new
repositories
that
only
have
a
single
owner
where
we
want
to
make
sure
that
we
have
an
owner's
list
that
is
sort
of
multiple
people.
You
know
ideally
from
multiple
sort
of
companies
right,
so
you
sort
of
have
a
shared
responsibility
for
maintenance,
and
so
you
know
it
and
also
you
know:
Tim
st.
D
D
Yeah
and
I
think
we
should.
There
is
one
I
think
right
now
for
a
cloud
provider:
GCP,
that's
for
the
cloud
provider
code
eventually
is
going
to
move,
so
we
can
either
try
to
move
the
GP
machine
controller
in
there
or
we
can
create
one
for
a
machine
controller
GCP,
and
you
know
again,
it's
tension
like
we
as
sort
of
to
Google
maintainer
need
to
figure
out
how
to
structure
those
and
whether
they
live
in
the
kubernetes
org
or
whether
they
live
in
like
a
Google
cloud
platform.
D
For
bare
metal,
if
that
is
really
a
community,
build
community
support
implementation,
we
could
reach
it
cigarette,
e-cigs
and
and
just
create
a
repo,
and
it
sounds
like
we
had
at
least
multiple
people
that
are
interested
in.
Maintaining
that
so
I,
don't
think.
There's
the
conversation
yesterday
was
there
was
sort
of
one
one
person
who
wanted
to
be
the
primary
owner,
and
that
was
was
concerning
to
Tim
in
terms
of
long-term
payments.
Yeah.
D
C
A
G
Okay,
that's
my
issue
that
I
created
this
is
to
add
support,
as
you
said,
for
using
custom
static
pods.
This
would
be
and
that's
an
alternative
to
using
the
default
pod
specs
that
cube
atom
and
it
creates
this
is
kind
of
for
power
users
who
want
more
flexibility
and
control
over
setting
up
their
control
plane.
G
So
like
it
would
like
for
cube
admin,
you
could
split
up
the
steps
that
it
executes
and
then,
like
one
of
those
steps,
is
to
set
up
the
control
plane
and
that's
where
it
generates
these
manifests.
So
if
this
config
map
is
present
and
instead
of
running
that
step,
it
would
be
using
the
the
files
that
are
in
the
config
map,
and
if
there
is
no
config
map,
it
would
just
run
the
whole
cube
admin
in
it.
G
F
G
I
think
it's
just
more
like
for
flexibility,
I
I,
don't
know
whether
there's
an
option
for
I
haven't
really
looked
into
it,
I
guess
for
how
cube
admin
in
it
like
if
you
could
just
give
cube
admin
and
it
files
that
you
want
to
run
instead,
I
thought
that
that
was
just
like
you
would
not
run
that
step
but
run
the
other
steps.
Instead,
there.
F
Are
multiple
options
but
yeah
you
can
either
like
give
the
cube
Adam
config
the
cubed
M
configuration
file.
You
can
specify
what
kind
of
setup
you
want
and
one
of
the
things
I
might
want
to
talk
about
later.
As
an
agenda
item
is
how
we
can
make
the
cuban-american
cluster
API
config
converge
eventually,
but
but
yeah
right
as
it
stands,
you
can
override
arguments,
for
example,
for
the
API
server
to
run.
H
H
Okay-
but
this
would
definitely
be
meant,
is
like
a
look
aside
for
power
users
who
don't
know
what
they
are
doing,
and
this
is
something
that,
if
Google
like
us,
that
we're
proposing
just
to
do
this.
For
us
we're
not
saying
this
is
gonna,
be
for
everyone
and
it's
purely
optional,
because
we
do
want
to
support
using
cube
ATM.
H
F
A
Okay,
I
Katie.
Did
you
get
everything
you
need
thanks?
Okay,
moving
on
Lucas,
how
do
we
converge
cube
admin
to
the
cluster
API
configuration
I
was
gonna
kind
of
mention
this
earlier
Tim
st.
Clair
pick
me
offline,
so
that
you
guys
talked
about
something
or
other
for
1.12
any
more
info.
It
would
be
helpful.
F
So
basically,
the
current
configuration
file
you
give
to
cube
at
a
minute
has
grown
organically,
and
it's
like
just
this
one.
Big
slice
with
a
lot
of
fields
basically
looks
like
many
other
other
components
before
refactoring,
so
we're
doing
that
refactoring
now.
The
first
thing
we're
doing
is
remove
all
things.
H
F
H
F
Some
minutes
ago,
25
minutes
ago,
I
went
through
all
these
fields
and
we
talked
about
whether
they
make
sense
or
not.
So
you
can
also
watch
the
recording
of
the
meeting
previously.
But
what
are
the
general
thoughts
and
so
I
check
the
current
class?
The
spec
is
basically
just
provided
config
and
some
networking.
What
are
the
plans
to
make
that
more
sophisticated
or
all
there
I
think.
F
Yeah
so,
for
example,
things
we
we
have
right
now
in
the
US
the
spec
are
like,
so
the
networking
parts
are
shared
they're
common
between
these
two.
Then
we
also
have
config
like
okay.
What
all
should
be
passed
to
the
API
server
right
now.
This
is
a
string
string
map
that
is
translated
to
flags,
which
is
unbelievably.
F
Like
we
really
want
to
use
component
configuration,
but
that
is
not
available,
because
no
one
is
working
another
on
that,
and
that
is
a
general
goal.
We
want
to
work
with
the
other
things
to
actually
execute
on,
because
using
flags
for
the
configuration
is
not
optimal
but
yeah.
That's
the
stopgap
we
have
like
these
are
the
flags
that
should
be
passed
to
the
API
server
other
than
what's
generated
by
default.
As
we
said,
we
have
like
what
is
the
kubernetes
version
in
the
the
spec.
D
F
D
If
you
look
at
the
API,
it
has
a
notion
of
a
role
that
can
be
set
to
master
or
a
node
or
both
and
I.
Think
when
we're
calling
dr.
Tate
incorrectly,
if
you
set
the
role
to
node,
it
will
register
into
a
cluster.
If
you
said
it
to
master
and
code,
it
will
register
itself
into
the
cluster
and
you
set
it
to
just
master.
It
will
run
the
control
plane
but
not
register
the
cubelet
into
that
control
plan.
D
So
it's
more
like
a
few
admin
does
for
the
master
than
what
Jerry
we
have
been
having
some
discussions
about
whether
those
roles
make
sense,
because
I
think
humanities
in
general
is
moving
away
from
this
notion
of
masters
and
nodes.
We-
and
we
know
we
aren't
sure
we
want
any
code,
that
the
control
plane,
I,
think
both
Tim
and
Brian
have
given
feedback
to
that
degree,
and
so
we're
trying
to
think
about
what
we
can
do
to
modify
the
API
to
take
those
out.
A
E
Don't
know
about
documentation,
but
there's
a
lot
of
work,
that's
being
done
recently,
not
even
recently
about
either
self
hosting
or
using
clusters
to
manage
other
clusters
or
breaking
up
the
control
plane
to
the
extent
that
most
of
it
is
just
stuff
running
in
the
cluster,
such
that
sort
of
the
idea
of
a
role
sort
of
feels
antiquated
and
I'm
I'm
reluctant
to
encode
it
into
a
brand
new
API.
If
we
can
find
a
better
way
of
expressing
it,
taints
are
sort
of
there,
but
not
quite
perfect.
E
I
would
like
to
encourage
I'm
just
coming
up
to
speed
along
the
cluster
API
stuff,
so
I
apologize.
If
some
of
this
has
been
discussed
before
I
would
like
to
encourage
that.
We
think
about
a
different
way
to
represent
the
concept
that
we're
trying
to
capture
by
role,
whether
that's
security
or
access,
control
or
privilege,
levels
or
machine.
E
D
D
I
think
Tim.
If
I
remember,
you
also
sent
out
an
email
a
while
back
saying
we
shouldn't
be
using
master.
We
should
be
talking
about
the
control
plane
right,
and
this
again
is
for
encoding.
The
notion
of
a
master
and
the
control
plane
is
something
it's
actually
sort
of
growing
over
time.
Right
as
we
historically,
the
control
plane
is
the
API
server,
the
scheduler
controller
manager,
but
as
we
do,
the
cloud
controller
manager
work
to
split
that
out.
D
D
So
the
notion
of
a
master
that
looks
exactly
the
same
that
you
can
stamp
out
exact
replicas
of
is
also
potentially
an
antiquated
concept
and
trying
to
use
that
role
thing
to
encode
all
the
different
variations
of
how
you
might
want
to
deploy
control
plane.
Software
across
machines
is
gonna,
get
overly
complex,
very
quickly.
E
And
certainly
there's
some
systemic
problems
across
kubernetes
itself
about
version
skew
and
testing
across
versions,
but
really
in
you
know
in
practice,
there's
really
not
much
difference
between
the
cube
controller
manager
and
the
nginx
ingress
controller
they're.
Both
control
plane,
components
that
are
reacting
to
the
creation
and
deletion
of
resources
in
the
API.
So
you
know,
should
we
be
treating
those
things
fundamentally
differently
or
should
would
just
be
worrying
about?
Maybe
maybe
one
a
couple
of
versions
more
tightly
for
some
components
than
other
components.
A
E
A
A
F
So
I
would
I
think
the
API
service
is
the
hard
part
like
where
is
different.
So
as
a
user
I
want
to
know
where
all
my
API
endpoints
running
and
then
the
other
is
that's
gonna
like
yeah,
that's
gonna
have
to
be
basically
fed
into
all
the
other
clients
that
are
talking
to
them.
So
if
we
don't
have
some
kind
of
load
balancer
and
then
we
don't
need
that,
then
we
do
need
some
other
field.
That
is
here
is
aggregated
place
for
every
client
to
talk
to
the
API
service.
F
So
I
think
when
thinking
about
mastering
node
I
would
say,
the
API
server
is
the
most
important
parts
and
if
we
could
say
like
I'm
not
like
right
now,
a
master
is
whether
I
say
API
service
running
and
I
mean
that's,
not
a
good
general
definition,
but
if
we
at
least
could
distinguish,
this
is
some
kind
of
more
mastery
node,
and
this
is
more
a
normal
know
that
an
extension
API
server
or
like
even
a
controller
manager.
It
doesn't
I.
E
Agree
at
the
point
of
the
where
the
central
API
server
is
pretty
important.
It
is
sort
of
the
the
linchpin
of
building
up
the
stack
of
things,
I
sort
of
disagree
about
whether
there's
a
master,
ish
thing
because
I
don't
really
know
what
master
ish
means
and
it
means
different
things
to
different
installations.
For
some
people
it
means
you
you're
not
allowed
to
ss8
to
this
machine
for
other
people.
E
It
means
that
the
machine
image
is
going
to
be
a
different
image
and
I,
don't
like
encoding
that
as
sort
of
an
intrinsic
part
of
the
identity,
I
would
much
rather
think
of
it
in
terms
of
what
are
you
actually
trying
to
express
about
it?
What
makes
something
master
ish,
yeah
I,
don't
have
a
perfect
answer
for
you
honestly
right,
I,
just
I
saw
that
field
and
I
sort
of
had
a
reaction
to
it.
So
I'm
encouraging
you
guys
to
think
about
it,
but
I
don't
have
a
great
answer
for
you.
Yet
yeah.
F
H
D
F
Also,
we
don't
we're
not
sure
yet
how
to
handle
a
TV,
but
that
is
probably
the
the
other
hard
part.
So
I
think
what
we're
gonna
do
is
like
co-locate
at
CD
together.
So
either
you
do
all
external,
like
you
just
set
the
API
sort
of
flags
like
this
is
my
external
XE
XE
D
and
here
are
the
sets,
but
if
we
do
want
to
support
something
winning,
you
bet
a
minute
and
join
and
join
master.
F
Something
then
we're
gonna
go
locate
the
API
server
and
that
CD
on
the
same
machine,
and
we
haven't
decided
how
the
API
server
is
gonna
talk
to
that
CD.
If
it's
gonna
talk
localhost
or
to
all
of
them
correctly
in
either
case,
we
need
something
that
where
should
we
put
our
CD
and-
and
we
also
need
to
think
about
like
how
do
we
upgrade
these
things
and
configure
them.
F
So
that
is
something
we
have
in
the
kind
of
proposal
or
brain
dump
in
the
cubed
M
specs
right
now,
but
also
trying
to
think
about
that
in
the
cluster
API
minimal
sense.
Is
there
some
kind
of
representation
we
should
be
doing
there?
Should
we
like
again
have
some
other
role
for
a
TB
or
like
here?
Is
the
database
back-end?
That's
people
can
talk
to
or
should
it
just
be
completely
orthogonal
today.
D
F
If
it's
local
at
tdq
bottom,
it's
gonna
treat
it
as
co-located
with
the
master
and
when
we
do
upgrade
like
blue
cubed
or
apply
it's
gonna
have
to
create
at
CD
first
and
then
the
Masters.
The
the
thing
is
like
we
might
want
to
do
things
like
only
upgrade
at
CD
first,
so
you
do
upgraded
CD
on
master
one,
upgraded
CD
and
once
the
two
and
three
and
then
upgrade
the
rest
of
a
control
plane.
We
don't
have
a
clear
answer
whether
or
what
the
support
in
that
context
or
in
the
cluster
API
context.
F
It
might
be
okay.
Well,
let's
delete
this
first
machine
that
is
a
master
or
whatever
control
plane,
endpoint
that
toasts
both
at
CD
and
the
API
server,
and
create
a
new
one
that
is
fresh
to
join
the
set
or,
if
we'd
want
to
do
in
place
upgrades
because
it's
gonna
I,
don't
know
how.
Well
we
do
test
that
either,
as
teams
are
like
the
like
versions,
Q
testing
in
AJ
mode
I
have
no
idea
how
good
that
is.
So
we
have
like
all
the
API
servers.
110
we
in-place
upgrade
180
ISO
to
111.
F
D
F
Is
there
comments
yeah?
So
the
only
thing
we
at
this
moment
is
really
support.
It's
like
okay.
We
know
that
for
cabanas
111
we're
doing
well
at
ev32
whatever,
and
if
we
upgrade
to
112,
we
might
go
to
3
3,
something
and
for
that
and
like
in-place
upgrade,
should
be
just
enough
like
just
getting
taking
a
snapshot
or
whatever
storing
it
and
then
just
3,
starting
with
the
same
data
directory
new
or
at
CD
server,
which
does
the
internal
does
the
conversation
or
conversion.
F
D
D
We
actually
had
to
run
migration
scripts
and
in
AJ
was
saying
that
Red
Hat,
you
know,
took
down
the
entire
entity
cluster,
upgraded
everything
and
then
brought
it
back
up
until
you
end
up
with
some
downtime,
even
for
your
AJ
deployments,
and
it
sound
like
it
required
quite
a
bit
of
additional
orchestration.
So
it
sounds
like
I'm
not
quite
worried
about
that.
Yet
because
we
don't
see
a
TV
for
looming
on
the
horizon.
Yeah.
F
A
A
H
Yeah
I'm
just
going
through
and
noting
so
the
SIG's
or
is
a
bit
different
as
I've
noticed
with
a
Kenny's
latest
joining
of
the
org
I
expected
that
to
give
us
like
permissions
to
assign
him
issues,
but
it
turns
out
he
needs.
The
kubernetes.
Org
is
different
from
the
kerbin
at
e-cigs
org
and
it
looks
like
they've
kept
the
kubernetes
IG's
org,
potentially
small.
H
So
what
we
had
to
do
was
add
him
as
a
collaborator
on
the
cluster
api
repo
itself
and
as
an
admin
I
had
that
privilege
and
it
seemed
like
that
had
been
done
for
a
lot
of
other
people
who
are
committing
on
it.
But
I
also
noticed
that
a
lot
of
people
have
write
permissions.
So
I
think
that
is
a
bad
situation
again.
This
is
why
we
have
all
this
automation
around
PR
management
xx,
let's
so
I'm
going.
H
This
is
just
kind
of
a
heads-up
everyone
who
has
write
permissions
now,
I
am
probably
gonna
revert
you
to
read:
I'm
gonna
leave
the
3
or
4
admins.
We
have
that
includes
you
Chris
novo,
by
the
way,
as
admins
just
as
fallbacks,
and
if
people
notice
issues
like
they
need
to
do
something
that
they
couldn't
before.
We
may
temporarily
revert
you
back
to
a
write
permission,
while
we
figure
out
a
best
way
to
solve
this
because
having
people
having
right
access
to
this
repo
is
unmaintainable
and
also
having
to
manually,
add
people
as
collaborators.
H
A
H
I'm,
removing
I
think
this
will
remove
abilities
to
create
new
labels
abilities
to
direct
commits
to
the
repo
and
all
that
stuff.
You
should
still
be
able
to
send
PR,
as
you
should
be
able
to
assign
PRS.
You
should
be
able
to
be
assigned
to
PRS
and
be
able
to
do
all
the
slash
commands
you
still
have.
This
is
removing
github
UI
interactions
and
again,
if
you
notice
issues
please
at
me,
Chris
Nova
or
Robert
Bailey
in
this
channel
and
I
can
can
I.
H
H
F
I
was
just
thinking
what
is
do
we
have
an
application
form
or
a
process
for
being
a
member
of
the
company's
stings
organization,
because
I
think
that's
a
requirement
for
being
able
to
do
slash,
commands
so,
and
we
say
something
like
everyone.
This
lady's,
a
member
in
the
Corps
kubernetes
organization,
can
join
using
this,
whatever
process
the
kubernetes
SIG's
org.
Or
do
we
have
to
have
a
separate
mailing
list
for
joining
the
kubernetes
SIG's
organization?
Ibanez
membership
mailings?
We
have
I.
H
Don't
think
there's
a
processor
that
I'm
not
that
for
me.
I'm
gonna
punt
this
to
Tim.
If
he
wants
to
comment
on
it,
but
things
I've
noticed
so
far
as
like
the
kubernetes
eggs
list
of
members
as
like
six
people
and
they
seem
to
have
kept
it
intentionally.
Small
and
it's
also
prevented
us
from
like
using
kubernetes
or
teams
to
like
reference
like
I,
would
like
to
pull
in
like
Signet
working
on
an
issue
but
I
can't
in
this
repo
and
it's
kind
of
a
bummer
yeah.
D
I'm
just
looking
right
now
there
are
five
people
and
the
career,
these
things
organization,
five
individuals,
and
there
are
no
teams,
and
none
of
the
people
on
this
call
I
believe
are
in
there,
including
Tim,
but
we
are
all
able
to
use
all
the
slash
commands
by
being
collaborators
on
this.
One
repository
yeah.
E
So
I
don't
know
what
the
plan
is
there.
Actually,
it's
a
really
good
question.
I
know
that
cross
org
group
expansions
just
isn't
something
github
supports,
so
I
think
we're
just
crap
out
of
luck.
There
I,
don't
know
why
we
would
want
to
apply
different
rules
with
respect
at
word.
Membership
for
SIG's,
then
for
the
main
organization
I
think
it's
probably
a
case
of
not
having
procedure
in
place
for
it
and
not
that
we
don't
want
to
actually
do
it.
F
It's
just
more
thinking
like
do.
We
need
one
process
or
do
we
ambition
having
many
so
like,
let's
say
we
have
now
we
have
kubernetes
cool
and
then
we
have
kubernetes
client
and
then
we
have
Combinator
six
and
then
we
have
like
whatever
kubernetes
sub
org
you.
We
have
want
to
have
n
different
membership
applications
for
for
the
people,
or
do
we
have
one
mailing
list?
Here's!
What
I've
done
here
is
the
organization
of
what
a
join
in
this
case,
both
kubernetes
and
convenience,
SIG's
yeah.
E
So
I
think
the
answer
is
partial.
I
think
crannies
and
credit
e-cigs
want
to
have
the
same
policies.
I,
don't
know
for
other
organizations
that
we
may
create
in
the
future
that
those
will
necessarily
follow
the
same
rules
like
clients
is
a
little
bit
more
guarded
because
it
is
not
a
sort
of
open
development
space.
E
It's
a
more
purpose-built
or
so
there
is
a
PR
or
proposal
of
a
PR
in
flight
from
Eric
theta,
I
think
to
add
declarative,
github,
org
management,
where
you
pull
the
org
definitions
and
team
memberships
and
all
those
things
from
a
yamo
file
and
a
bot
updates.
The
actual
get
horns
which
would
allow
us
to
synchronize
communities
and
community
SIG's
I.
Think
that's
the
intention
there.
It's
not
quite
done
yet,
but
I
think
Lukas.
What
you're
asking
like
do
we
want
one
process
is,
it
is
a
fair
question.
I
think
that's
something!
A
Okay,
the
last
thing
is
I,
did
do
a
demo
of
a
clustered
API
controller.
We
keep
a
call
last
week
before
when
I
was
out
of
town.
We
lost
the
recording
because
of
technical
difficulties.
I
we
presented
it
yesterday
at
OpenStack,
I'm,
not
sure
if
it
was
recorded,
if
it
was
recorded,
I'll
just
put
a
link
and
we
can
go
from
there
if
that's
not
the
case,
I'll
jump
aside
and
spend
30
minutes
in
the
conference
room
and
just
do
a
quick
recording
and
all
and
it's
via
the
links
here.
I
Wanted
to
shortly
mention
something
on
the
TF
deployer
and
telephony
player
as
north
as
user
potential
developer.
What's
the
current
state,
what's
on
going
there
I
seen
already
was
mostly
not
yet
supported.
Is
there
like
a
timeline
just
also
for
potential
contribution,
as
it
makes
sense
now,
is
their
ongoing
work,
which
will
be
merge
soon,
first
step,
what's
I'm
going
there
I.
H
Can
speak
to
that
a
little
bit?
It
is
ongoing
work
where
we're
playing
around
with
it
makes
validate
some
of
our
use
cases
to
make
sure
that
it's
we
don't
do
anything
like
Google
was
doing
this
to
make
sure
we
don't
do
anything
GCP,
specific
and
stuff,
like
that,
it's
in
a
pretty
rough
state,
for
instance,
I
just
submitted
a
PR
I.
Think
yesterday
that
enabled
delete
like
you
can
delete
a
machine
with
it
now,
and
that
was.
B
H
A
I
know
we
had
a
few
reservations
about
packaging.
The
binary
in
the
repository,
so
I'm
not
sure
what
happened
there.
I
remember.
There
was
a
pull
request
out
to
remove
it.
There's
also
been
talk
about
trying
to
use
terraform
as
a
library
and
not
actually
wrapping
the
binary
and
doing
a
system
exact,
so
there
might
be
some
hands
there
as
well
as
as
you
start
to
poke
around
at
it
all.