►
From YouTube: Kubernetes SIG Cloud Provider 2019-02-20
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
B
Looks
like
another
sink
is
logged
in
with
their
their
sig
account.
What
I
discovered
is
that
if
you,
if
you
have,
if
your
unzoom,
even
if
you're
logged
in
on
the
app
on
your
personal
account,
if
you've
logged
in
on
the
web
with
with
a
different
account,
it
will
switch
to
that
when
you
start
up
zoom.
So
you
need
to
log
out
on
both
your
app
and
on
your
and
in
your
browser
to
be
able
to
get
back
to
your
original
user.
If
anyone
else
has
been
running
into
that
yeah
yeah.
C
D
B
Yeah
well
just
I
guess
we
can
probably
just
get
started
now:
I've
dropped
a
link
to
the
Google
Doc
in
into
the
zoom
chat.
Everyone
can't
see
that.
Let
me
know
and
I'll
drop
it
in
again,
and
here
we
go
so
on.
The
agenda
initially
was
supposed
to
go
first,
but
it
looks
like
she
hasn't
arrived
quite
yet
on
the
update
for
the
steering
committee
proposal
for
consolidating
provider
SIG's.
B
A
So
this
is
a
new
thing:
I'm
trying
there's
a
lot
of
issues
in
the
core
cuneta
repo,
there's
just
a
lot
of
issues
that
are
related
to
our
sake
that
we
have
kind
of
ignored,
just
just
cuz
like
just
a
big
mess
and
no
one's
willing
to
kind
of
go
through.
So
one
thing,
I'm
doing
right
now
is
going
through
that
backlog
cleaning
it
up
a
bit
trying
to
summarize
those
issues,
kind
of
back
pouring
them
into
the
cloud
provider
repository
and
so
I
think.
A
The
main
motivation
for
me
doing
the
is
that
I
think
it'll
help
us
kind
of
categorize
milestones
for
the
next
release
is
coming
up,
so
I
have
two
months,
so
I
kind
of
copied
this
from
sick
cluster
lifecycle,
so
there's
gonna
be
two
milestones
next
and
the
the
next
and
one
dot.
Whatever
version
is
coming
out
for
kubernetes,
and
so
this
is
I
guess.
The
goal
here
is
to
try
to
narrow
down
and
focus
more
on
what
what
are
the
top
priorities
for
the
next
for
the
upcoming
kubernetes
version.
E
E
B
A
I
think
I'll
be
able
to
get
it
set
up
115.
The
only
places
I'll
need
help
is
some
of
the
issues
require
some
historical
context
as
to
why
certain
things
were
done.
The
way
they
were
back
in
I,
don't
you
know
like
way
back
so
I'm,
a
ping
people
on
the
issues
to
kind
of
gather
that
extra
context,
and
so
it
would
be
super
helpful
if
people
are
responsive
on
those
issues,
but
other
than
that.
B
B
F
F
The
the
straw,
men,
aiya
straw,
person,
ideas,
I
came
up
with
were
some
sort
of
exec
plug
in
some
sort
of
GG
RPC
type
plugin.
Maybe
we
move
it
centrally
into
like
something
we
do
a
something
we
make
a
web
type,
an
HP
type
cold
too,
or
maybe
we
have
some
sort
of
kubernetes
controller
that
like
injects
their
credentials
into
a
secret
just
in
time,
or
something
like
that,
but
I
kind
of
I
kind.
G
Of
like
some
of
the
proposals
around
the
exact
service,
I
thought
a
little
bit
about
the
remote
thing
that
I
mean
clearly
I've
been
doing
too
much.
Okay,
this
I
worry
a
lot
in
really
large
fleets
and
a
lot
of
poblanos
that
you
you'd
cause
a
scalability
bottleneck.
If
you
tried
to
push
it
out
to
some
external
remote
service,
I
know,
at
least
on
Google
and
AWS
and
I
believe
OpenStack,
most
of
the
credential
providers
stuff
just
pings
kind
of
a
local
service,
that's
bound
to
a
local
loopback
interface
and
I'm.
B
That's
fair,
yeah
I
mean
one
of
the
one
of
the
things
that's
nice
about
breaking
out.
Credential
providers
is
that
that
the
provider
itself
becomes
more
widely
usable
for
for
other
projects.
You
know
like
and
I
know
that
OpenStack
has
talked
about
it
and
I
just
pinged
our
channel
to
see
if
anybody
has
actually
done
work
on.
D
B
G
A
That
is
not
the
cloud
provider,
but
that
also
complicates
a
lot
of
like
it
complicates
the
efforts
we
have
going
on
because,
like
AWS,
for
example
like
it
already,
it
assumes
that
it
can
only
load
or
the
provider
assumes
that
it
would
only
load
the
credential
provider
if
the
provider
is
set
so
like
I
guess,
we
should
probably
scalp
the
problem
to
know.
If
do
we
want
to
really
support
this,
or
should
we
kind
of
draw
a
line
somewhere
and
just
be
like
we're?
Not
gonna
support,
cross
provider,
credentials
I,
don't
know,
I,
think.
G
It's
a
migration
step,
it's
probably
okay,
to
say
that
we
want
to,
but
we
want
to
externalize
these
things
without
changing
their
behavior,
but
I
think
we
should
also
think
through
kind
of
going
forward
what
it
means
to
allow
multiple
cloud
providers
to
have
credential
extensions.
That's
what,
in
my
opinion,.
A
A
It
would,
but
at
least
it
kind
of
puts
like
I
guess,
like
the
the
first
thing
we
have
the
first
priority
we
have
right
now
is
to
stage
the
providers,
and
that
assumes
that
we
can,
we
would
stage
providers,
but
it
would
still
be
linked
in
all
the
same
places
so
like
it's
still
progress
in
terms
of
like
where
the
code
lives,
but
in
terms
of
like
where
it's
imported
its
I
don't
expect
that
to
change
in
the
near
term.
Anyways
that
makes
sense.
G
A
F
A
G
Now,
there's
a
so
right
now:
there's
a
hard-coded
list
of
regions
in
a
cloud
provider.
I
have
a
PR
somewhere.
This
probably
isn't
it
that
uses
the
a
degress
SDK
to
fetch
the
regions
instead
of
hard-coding
that
that
hard-coded
list
of
regions
are
shared
with
the
credential
provider
and
the
credential
provider
needs
to
also
get
the
same
list
of
regions
from
the
SDK
and
then
the
current
region.
It
kind
of
works
around
an
edge
case.
The
only
way
to
get
the
current
region
for
an
instance
is
to
read
it
from
the
metadata.
A
G
It
registers
all
the
regions,
including
the
current
one,
though
the
issue
of
the
current
region
is,
if
you're,
using
an
older
version
of
kubernetes,
that's
compiled
against
an
old
version
of
the
AWS
SDK,
and
you
try
to
launch
your
cluster
into
a
new
region
that
AWS
has
added.
Since
that
version
of
the
SDK.
The
credential
creditor
will
fail
because
it
doesn't
know
about
that
region
so
in
the
region
for
the
metadata
I'm.
Just
adding
that
we
kind
of
work
around
that
with
a
kind
of
a
big
hammer
solution.
In
my
opinion,
and.
F
A
And
so
like,
if
you're
saying
that,
like
yeah
so
Jordans
problem
with
the
PR
was
that
we
would
be
doing
the
network
and
file
calls
like
in
the
credential
provider
and
a
bunch
of
other
components
that
would
never
need
it
or
in
a
that,
would
never
run
the
AWS
provider
so
like
Mike.
What
you're
saying
is
that
to
remove
the
current
region
check
altogether
and
just
to
register
all
the
regions,
but
what
it
is
that
is
the
edge
case
of
running
a
kubernetes
cluster
in
a
new
region.
Not
gonna,
be
a
problem
for
that.
That.
G
Edge
case
is
still
going
to
exist.
It's
just
gonna
fail
in
this
case.
I
think
there
might
be
I
think
there
might
be
another
issue
too,
and
that
there's
some
assumption
that
we're
calling
the
metadata
service
the
latest
version
of
this
patch
doesn't
do
that
anymore.
It
does
some
really
lightweight
sis
reads
to
determine.
If
you
even
look
like
AWS
and
if
you
don't
it
skips
all
of
that,
so
I
don't
think
we're
doing
anything.
A
G
B
D
Sure
and
I'm
so
sorry
for
being
late.
Stephen
thanks
for
thank
you
yeah,
so
this
proposal
I
think
he
is
looking
fairly
complete.
Now
there
are
some
changes
requested
by
Fabio
and
Stephen.
Primarily
it's
around
how
we
are
going
to
name
and
list
these
sub
projects
under
six
llamo.
But
basically
we
all
are
agreeing
on
collapsing
these
six
as
under
say
cloud
provider
and
listing
all
the
sub
projects
under
sick
cloud
provider.
D
Again
we
will
maintain
the
zoom
channels,
as
is
we
are
just
going
to
rename
them
so
as
to
indicate
to
folks
that
these
six
don't
exist,
but
they
exist
as
user
groups
and
I'm
using
the
word
user
groups,
because
I
don't
have
a
better
word
for
that
and
everything
will
continue.
As
usual,
we
will
try
to
also
work
with
CN
CF
to
have
a
user
group
meeting
in
every
cube.
Con
that'll
continue
as
usual.
D
D
The
problem
with
making
this
functional,
even
if
the
steering
committee
agrees,
is
that
all
the
CFPs
have
already
been
submitted
for
a
guy
and
Barcelona.
So
the
time
we
can
actually
implement
this
is
going
to
be
in
to
con,
not
America
2019
run.
We
should
work
towards
that
and
also
I
do
want
to
point
out
that,
even
though
we
have
brought
up
this
release,
cadence
discussion
out
of
tree
features
again.
Stephen
and
I
agree
that
this
should
be
out
of
scope
for
the
cloud
provider
team.
D
B
There
was
we
had,
there
was
actually
another
and
I
guess.
I
probably
should
have
included
this
on
here
too.
In
related
to
the
releases
we
had,
we
had
a
meeting-
I,
don't
know,
maybe
four
or
five
months
ago
with
and
with
Tim
about
what
we
do
with
artifacts
and
how
it
effects
are
discovered,
and
you
know,
you've
shown
to
users
since
all
since
all
the
providers
are
going
to
become
externalized,
you
know
having
a
having
a
place
to
build
an
upload
or
releases.
B
D
B
B
It's
actually
I
think
the
name
space
is
like
you
know
cloud.
It's
actually
called
like
kubernetes
cloud
provider
right
now
in
stack.
This
is
the
only
release,
that's
happening
inside
of
there,
but
you
know.
If
there's
you
know,
if
everybody
is
going
to
be
releasing
at
the
same
time
and
pinning
their
releases
to
the
kubernetes
releases,
because
you
essentially
have
to,
since
you
know,
to
match
of
API
changes,
you
know
having
it
having
a
single
place
where
people
know
they
can
find.
B
E
So
I
think
that
that
is
important,
but
it's
out
of
scope
for
this
proposal.
I
think
we
should
try
to
focus
on.
So,
as
part
of
the
reason
I
said,
we
shouldn't
talk
about
release
cadence
here,
it's
a
it's
going
to
be
an
active
discussion
and
it's
a
project
wide
discussion
same
with
the
artifact
management.
There's
an
open
cap
for
it
if
it
hasn't
already
been
merged
around
doing
artifact
management
for
the
entire
project
and
I
think
we
should
let
that
kind
of
like
settle
out
before
we
pick
it
up.
D
Then
does
have
their
sort
of
weird
behavior
around
this
and
I
say
it
weird,
because
I
saw
it
in
AWS
right.
The
way
we
publish
our
container
images
for
any
sub
project
has
to
be
document
up
that
we
own,
and
there
is
a
security
check
that
we
do
in
there
for
all
our
releases
have
to
be
under
change
logs,
and
then
we
during
the
docker
hub,
where
the
container
images
at
it-
and
there
is
no
way
that
either
obvious
will
get
around
it.
E
D
E
D
Some
project
ad
seg
AWS,
owns
all
the
code,
but
if
you
want
to
deliver
a
specific
container
image
built
out
of
that
codebase,
then
that
container
image
will
be
pulled
from
a
docker
hub
repository
that
EWS
holds.
It
is
a
security
thing
that
we
have
and
we
can't
get
around
that
and
so
the
changelog
the
code.
Everything
is
open.
D
G
Would
say
that
it's
open
to
discussion
on
our
side
that
policy
is
around
eight
of
us.
Security
has
some
very
strong
opinions
about
things
that
AWS
is
producing
and
handing
to
our
customers
that
they
they
meet
a
very
high
bar
for
security.
If
we
wanted
to
change
the
way
those
are
produced
or
whose
vending
those
we
may
be
able
to
work
around
it,
but
I
think
that's
a
conversation
better
had
kind
of
in
a
different
venue
than
this
doc.
I
agree.
D
H
We
should
work
to
improve
the
process
of
building
and
releasing
open-source
kubernetes
to
make
it
much
more
secure
and
trusted.
One
example
is
signing
poll
requests
or
signing
the
artifacts
that
come
out
of
the
buildin
release
process.
I
think
would
go
a
long
way
from
our
own
internal
conversation,
so
we
should
strive
to
make
that
the
best-in-class
that
there
is
and
meet
those
security
concerns
in
that
way,
rather
than
trying
to
convince
multiple
multinational
corporations
to
just
believe
us,
yeah
yeah.
G
Don't
want
to
drag
us
too
far
off
topic,
but
one
of
the
things
that
we
do
internally
at
AWS
is
we
do
a
security
review
on
all
the
code
we
open
source
or
that
we
contribute
to
open
source.
So
our
security
team
does
get
involved,
part
of
helping
build
that
trust
might
actually
to
be
to
have
a
good,
solid
kind
of
documented
process
for
how
the
community
treats
security
reviews
and
what
we
do
around.
That.
B
D
Have
to
tackle
the
easiest
low-hanging
fruits?
Yes
only
action
item,
that's
remaining
is
I
think
we
have
to
fix
a
date
with
steering
committee
for
the
review
and
I
have
Adam
and
Steve
to
see
us
on
the
call.
So
sorry,
I'm
putting
you
on
the
hot
seat,
need
your
comments
and
review
on
the
document
and
then
Steven
and
Fabio
I'll
resolve
the
open
comments
with
you.
Both
offline,
just
again
agreement
on
that
before
next
week
and
I
think
otherwise.
We
have
a
dream
in
from
happy
ones.
Sir,.
E
E
Yeah
so
I
mentioned
in
the
talk
that
you
know:
I,
don't
think
that
the
goal
of
some
of
them,
like
a
user
group,
so
basically
the
the
way,
we're
organizing
kubernetes
the
people
who
own
code
are
sub
projects
right,
some
projects,
reporting
to
SIG's
and
so
on
and
so
forth.
Right.
So,
if
we're
going
to
say
that
a
like
week
so
like
by
the
governance
standards
like
we
can't
say
that
a
user
group
owns
code
write
it,
that's
only
that's
only
delegated
to
sub
projects,
so
by
default.
I
think
that
we
should.
E
We
should
organize
the
sub
projects
and
then,
if
people
decide
as
a
user
group
or
whatever
you
want
to
call
the
group,
they
don't
want
to
own
code
within
the
kubernetes
they
should
not
be.
They
should
be
fine
to
organize,
as
a
user
group
or
whatever
group
they
to
decide
to
organize
this.
But
it's
the
second
day
own
code,
their
sub
projects,
yeah.
D
Is
nothing
like
that
and
I
went
in
double-checked
what
the
user
group
definition
is.
I
agree
with
Stephan
that
can't
own
any
code
and
also
there's
another
problem
that
user
groups
have
still
not
been
conceptualized.
So
there
is
a
lot
of
work
to
be
done
in
order
to
even
get
that
going.
This
process
gets
us
to
the
end
goal
and
really
doesn't
change
anything
that
we're
doing
so.
I
do
think
that
the
word
user
group
versus
sub
projects
we're
just
getting
into
the
nitty-gritty
of
it.
F
I'm,
just
I
guess
my
view
is
that
like
sig
AWS
has
two
collections
within
it
two
sets
within
it.
There
is
a
group
that
will
naturally
identify
with
the
AWS
sub-project,
the
coding
type
one,
and
there
is
a
mostly
this
or
there's
another
group
that
would
prefer
end
up
in
the
a
diverse
user
group
and
we
should
be.
We
should
try
to
give
continuity
and
I.
F
E
What's
the
what
are
the
what's
like?
What's
the
the
focus
of
the
user
group
like
what
it?
What
purpose
is
that
serving
because,
if
like
because
technically
that
user
like
while,
while
they
may
organize,
currently,
they
don't
technically
exist
within
the
concept
of
governance
and
kubernetes
right?
So,
if
they're
going
to
organize
somewhere,
they're
organizing
under
either
the
cig
or
the
sub-project
right,
this.
F
Does
predate
the
governance
so
I,
don't
think
that's
entirely
fair,
say
that
the
government's
I
think
if
we
were
to
point
fingers
I,
think
the
government.
The
point
of
the
fingers
should
point
to
the
governance.
That's
totally
fair.
I
mean
I.
Think
that
the
that
the
these
are
people
I
think
that
are
not
necessary,
is
interested
in
sort
of
steering
committee
issues
or
coding
issues,
but
I'm
more
interested
in
running
kubernetes
on
AWS
I.
Don't
think
we
should
leave
them
homeless.
D
They're
covered
in
the
scope
of
the
existing
sake,
AWS
user
group.
We
continue
having
bi-weekly
meetings,
we
continue
having
our
slack
Channel,
nothing
changes
were
just
renaming
stuff
and
we're
making
it
easy
for
the
folks
who
actually
work
in
the
entry
release
team
or
the
steering
committee
to
have
lesser
things.
To
worry
about
we're,
actually
not
saying
that
the
user
group
is
removed
at
all.
E
D
E
So
the
user
group
just
functionally
operates
under
sig
AWS
as
it
is
and
I
think
like
for
for
sig.
After
it's
kind
of
the
same
right,
a
bunch
of
the
Microsoft
people
hang
out
in
the
Azure
channel
and
just
organize
there,
because
they
don't
have
an
official
venue
to
do
that
right.
So
I
was
like
come
on
in
hang
out
in
the
channel.
There's
like
I
mean
I
like
I
I
would
want
to
understand
a
little
bit
better
like
what
the
purpose
of
the
user
group
is
so.
H
I
can
swing
at
and
then
I
think
other
existing
things
that
our
provider
specific
can
jump
in
some
of
the
benefits
we
talked
about
in
previous
cloud
provider.
Discussions
that
we
want
to
maintain
for
those
groups
are
things
like
the
slack
channels
sessions
@q
con.
The
ability
to
be
a
speaker
at
Q,
Khan
and
get
rooms,
and
so
on,
and
this
set
of
people
that
Justin
is
describing
being
homeless
is
essentially
about
those
types
of
benefits.
B
H
Something
sorry
Justin
just
one
more
comment
and
then
I'll.
Let
you
talk
that
the
user
group
I
think
as
written
is
intended
for
the
contributors
to
the
code
that
runs
in
that
cloud
provider
and
the
user
group
is
for
the
end
users
who
run
their
own
workloads
in
on
that
cloud
provider
and
have
some
kind
of
issue.
They're.
Looking
for
guidance
and
a
bug,
so
they're,
two
different
profile
of
user
and
we're
trying
to
distinguish
here
is
we're.
H
Trying
to
discuss
here
is
are
all
the
meet
needs
of
both
of
those
groups
met
a
big
current
proposal.
It
sounds
like
we
have
the
user
group,
the
contributors
part
settled,
and
we
have
a
promise
to
flesh
out
the
answer
for
the
user
group,
but
not
consensus
that
it's
satisfactory.
The
way
it
is
today.
So
what
so?.
B
Why
can't
it
cover
both
it's
like
as
I
guess
what
I'm
asking,
because
a
lot
of
time
these
things
are,
are
linked
together
that
that
there
are
developers
or
consumers
of
the
provider
code
and
they're,
also
just
users
with
one
or
fun
things
and
right
now
that's
captured
as
the
umbrella
like
say:
OpenStack
Corsa
gave
it
AWS
captures
everybody
in
that
group.
So
why
would
a
user
group
not
capture
then
set
with
the
recognition
that
there
are
two.
H
D
D
E
Yeah,
so
I
think
that
this
is
another
scope.
Creepy
thing
right
here:
it's
not
our
job
to
define
what
a
user
group
is.
That's
the
job
of
steering
right.
So
if
we
have
opinions
on
what
that
should
be,
we
should
document
those
opinions
and
present
them
to
steering,
but
I.
Think
it's
separate
from
this
proposal,
like
I
I,
think
that,
like
the
the
avenues
that
we
have
to
to
communicate,
I
think
we're
all
saying
that
we're
still
going
to
mean
gain
those.
H
Not
sure
I
totally
agree
only
because
of
past
experience
trying
to
ask
steering
committee
to
answer
difficult
questions.
What
they
I
have
found
is.
Typically,
they
delegate
that
to
the
most
appropriate
saying
at
which,
in
this
case,
would
be
that
sick
cloud
provider,
which
is
made
up
of
the
folks
who
are
also
leads
on
the
specific
cloud
providers
things
so.
E
H
Get
demote
from
being
sinks
to
being
sub
projects
and
where
we've
gotten
friction,
so
that
that's
what
inspired
this
reaching
out
to
individual
sig
leads
to
figure
out.
What
are
the
benefits
that
you
trying
to
maintain
its
an
open,
honest
conversation?
It's
not
a
fight
or
anything
it's
just
trying
to
get
information
so
that
we
can
maintain
those
benefits.
Why.
H
D
I
I
E
I
E
I
E
F
Like
I,
at
least
from
my
perspective,
I,
don't
think
I
imagined
what
was
what
we
currently
close
to
gave
us
would
be
I.
Guess
your
Stephen,
the
sort
of
water
cooler
that
the
cool
space
I,
think
that
sounds
great
right,
so
user
group,
AWS
or
eight
of
us
users
on
slack
and
I'm
less
concerned
about
the
the
slots
of
cube
Connell,
except
that
users
seem
to
ask
for
them
and
seem
to
be
surprised
when
they
aren't
there
and
they
send
me
card
well
attended.
But
we
can
figure
that
out
and
moving
the
code.
F
I
A
user
group
can
replace
it.
Some
of
us
have
done
that
already
I
mean
I
know
for
a
fact
cloud
provider
vSphere
is
already
under
state
cloud
provider
as
a
code
as
a
sub-project,
so
this
can
be
done
without,
like
any,
you
know,
any
people,
any
user
noticing.
This
can
be
done
right
away.
I
guess
in
you
know
all
those
sessions
for
Shanghai
and
Barcelona
already.
You
know.
Cfp
is
closed,
so
they're
gone.
So
this
is
something
that
will
eventually
affect.
I
E
B
Be
it
will
be
closed
and
that's
and
that's
not
to
say
that
you
know
I
mean
there's
there
still
I
mean
Barcelona
is,
is
is
set
set
in
stone.
What,
but,
but
Shanghai
is
gonna
take
time
for
them
to
finalize
the
schedule,
and
so
I
think
it
is
possible,
collaborating
with
this
during
committee
in
the
CN
CF
to
incorporate
some
of
these
changes
into
the
schedule.
My
recommendation
is
that
for
anybody
who
is
not
a
cig,
I,
honestly
I
would
I
would
submit
anyway.
E
So
one
thing
to
delineate
there
is
the
the
request
for
the
request
for
proposals
over
the
requests
for
submissions
for
the
maintainer
track.
All
right,
those
are
cute.
Those
are
two
separate
emails
that
go
out
and
two
separate
audiences
right,
so
that
so
people
who
want
to
organize
around
providers,
they
won't
even
have
the
opportunity
to
see
that
because
I'd
only
get
sent
to
sig
leads
right.
So
that's
something
to
consider
as
well.
Okay,.
D
Sorry
I'm
going
to
push
back
a
little
bit,
then
a
lot
of
effort
to
get
it
to
this
level.
I
do
think
that
we
should
continue
down
this
path
and
maybe
rename
the
slack
channel
the
way
we
want
to
indicate
to
users
that
it's
both
friendly
for
contributors
and
end
users.
That's
not
a
problem
and
Justin
wherever
you
want
to
make
that
suggestion,
just
go
through
the
doc
and
put
it
but
I,
don't
think
we
should
stop
right
now
and
pull
this
proposal
up,
because
we
want
to
figure
out
exactly
how
this
approach
should
divide.
I
H
D
I
Not
actually
talking
about
that
I'm,
not
even
considering
that
as
a
I
think
actually
from
the
proposal
that
new
demarcation
line
between
who
can
presume
and
can
propose
something
that
has
to
do
with
the
cloud
provider
has
actually
very
well
done,
and
it
makes
sense
so
every
basically
every
sub
project
gets.
You
know
a
potential
session.
The
cube
kind
of
makes
perfect
sense.
Actually,
I
put
a
comment
asking
if
this
is
something
that
can
be
replicated
for
other
umbrellas
things
like
stick.
Cloths
life
cycle
were
to
have
cluster
API
provided
for
every
provided.
I
You
know
very
similarly
to
what
we
have
here.
I
think
this
is
more
like.
If
we
user
groups
is
something
that
has
to
be
done.
Because
did
we
have
users
and
nisha?
You
were
you
know,
speaking
about
that
before
users
in
the
feedback
loop
from
end
users
into
the
cloud
provider
and
other
than
their
specific
thing
that
we
do
in
kubernetes
is
extremely
helpful.
So
it's
not
something
when
see
gone
and
it's
something
that
we
actually
want
to
foster
with
users.
I
E
So
I
agree:
there
I
think
that
I
I
would
almost
want
to
discourage
multiple
groups.
Organizing
around
the
same
effort
like
I,
think
that
I
think
that
developers
and
contributors
to
kubernetes
are
still
users
as
well
and
there's
like
there's
a
point
to
be
made
for
having
everyone
organized
in
the
right
place.
I
But
don't
we
go
back
to
the
stake,
so
we
had
six
before
where
we
add
that
and
we
want
to
get
away
from
six.
So
now
we
have
two
groups.
Well,
actually
we
have
one
group:
now
we
have
user
groups
and
we
have
sub
projects
for
a
differencing,
so
I
think
it
makes
sense
from
an
organizational
perspective
we
just
have
to
have
both.
Do
you
actually
think
it
hasn't
so.
E
Soda
so
to
put
a
finer
point
on
it,
I
don't
think
we're
trying
to
get
rid
of
cigs
I
think
what
we're
trying
to
do
is
like
build
consistency
around
the
way
we
develop
for
every
provider
right.
So
it's
not
like
we're
not
getting
rid
of
a
cig.
We're
just
saying
that
we
should
all
organized
in
the
same
way.
Well.
B
We
are
getting
rid
of
things
actually,
I
mean
that
is
actually
six
brawl
is
one
of
the
goals.
You
know
livin
a
ting
six
for
all,
so
that
everybody,
everybody
who
wants
to
show
up
doesn't
get
their
own
sake
and
there
are
there,
there's
more
limitations
on
the
expectation
to
be
part
of
the
cloud
provider
or
to
have
or
to
have
the
user
group.
So
I
would
disagree
that
we
just
say
that
we,
you
know
it's
saying:
oh
we're
not
getting
rid
of
six,
because
that's
actually
the
entire
purpose.
E
Of
this
well,
the
purpose
is:
the
purpose
is
to
decrease
SIG's
Brawl
right
and
also
provide
a
consistent
framework
for
doing
this
in
the
first
place.
Right.
The
like
the
end,
like
the
end
effect,
is
that
we're
getting
rid
of
SIG's,
but
it's
not
because
the
SIG's
were
a
bad
idea
in
the
first
place.
It's
because
it's
because
they
weren't
organizing
consistently
right
so
we're
trying
to
fix
that
right.
The
the
results
of
that
is
getting
rid
of
SIG's,
but
it's
not
that
it's
not
like
the
strict
reason
we're
doing
it.
D
Are
not
getting
rid
of
the
user
group
stuff
I'm,
not
talking
about
new
user
group
definition
and
governance,
we're
not
getting
rid
of
users.
That
includes
two
personas
developers
as
well
as
the
end
users
want
a
use
case.
They'll
all
have
the
same
forums
which
was
renamed
the
slack
channel,
reorganize,
the
sub
projects
and
the
labeling,
but
so.
A
B
If
they
don't
I,
don't
I
don't
stop
good
discussion.
That's
going
on,
but
I
also
want
to
make
sure
that
we
he
saw
two
topics
left
in
the
last
ten
minutes
and
and
so
I
guess
I
guess
where
I
want
to
do.
The
discussion
right
now
is
I
know
that
an
issue
wanted
to
schedule
this
to
go
to
the
steering
committee.
E
Think
I
think
this
personally
I
think
this
is
close
to
being
ready.
I
have
I
have
questions
around
the
way
that
we
give
quarterly
updates.
Initially,
there
was
a
it's
change.
Now
it's
an
umbrella,
update,
but
I
think
Chris
yeah.
You
mentioned
that
we
should.
We
should
have
extra
time
right.
So
I
think
that
in
this
in
the
slots,
when
we
do
umbrella
cloud
provider
updates,
they
should
be
the
entire
the
entirety
of
the
update
block
right.
E
D
E
Provider
provider
the
name
of
the
provider
gets
us
there,
because
then
we
can
use
the
cig
labels.
We
can
use
the
the
way
we
use
cig
labels
right
now.
It
can
just
be
provider
slash
whatever
the
provider
name
is
right
and
that
captures
that
we
rename
the
rename
the
the
existing
labels
we
rename
the
slack
channels
to
provider
blah.
It
doesn't
include
cloud
so
there's
less
of
this
feeling
that
it's
just
cloud
specific,
that's
my
suggestion
and
I've
already
put
it
on
the
doc.
So
it's
really
two
other
people
to
discuss
man
yeah.
D
H
Volunteer
to
reach
out
to
Dan
Colin
and
explore,
and
at
least
come
up
with
a
provisional.
This
sums
generally
the
right
direction
around
the
cube,
comm
support
and
maybe
Sarah
Nevada
or
Paris
about
the
infrastructure,
support
for
those
user
groups
and
I.
Think
that
would
make
me
feel
more
comfortable
that
there's
some
concrete
criteria.
D
B
I
would
do
I
want
to
add
one
last
thing
on
to
that
too,
since
we
may
be
talking
with
Harrison
and
Dan
about
this,
is
we
also
might
want
to
separate
the
time
for
developers
and
move
that
more
to
the
developer
track
of
the
conference's
in
time
for
the
users
and
move
that
more
to
the
conference
track?
It's
just
something
to
think
about.
B
You
know,
since
there
is
developer
time
allocated-
and
there
is
you
know
more
conference
time
allocated
might
be-
might
be
useful
to
consider,
but
we
should
also
put
a
put
a
pin
in
this
for
now
and
then
maybe
move
on
to
the
last
two
topics,
since
we
only
have
about
seven
minutes
left.
Is
that
some
good
everybody?
Yes.
D
A
So
I
know
writing
up
time.
So
I'll
be
super
quick.
Let
me
register
nodes
and
volumes
in
kubernetes.
We
label
them
with
an
instance
type
and
zone
and
region
label,
so
these
were
added
like
I
think
three
years
ago
or
something
like
that
and
we
prefix
the
label
names
with
beta
dot
and
because,
at
the
time
we
didn't
know
what
we
wanted
to
do
with
them.
I
don't
think
we're
going
to
remove
these
any
time
soon
so
I'm
proposing
that
we
just
j
them.
A
A
Does
anyone
object
to
seeing
these
labels
or
does
anyone
have
better
ideas?
Well,
if
you
have
better
ideas
for
like
what
the
label
name
should
be
definitely
comment
in
the
PR,
but
as
a
generally
I'd
like
to
get
consensus
on
if
we're
okay,
with
at
least
giing
labels
for
now
naming,
we
could
deal
with
later
as.
E
A
F
A
A
B
B
So
but
a
few
questions,
first
of
all,
you
know
who
can
go.
You
know
we're
wondering
who
might
might
might
be
at
Shanghai.
I
know
that
it's
a
little
bit
of
a
different
event
that
has
a
little
bit
of
less
attendance
from
people
in
North
America
and
in
Europe
I'm
planning
on
being
there
so
I'll
be
able
to
help
facilitate
some
of
the
sig
updates,
Jago
and
Andrew
I.
Don't
know
if
either
of
you
plan
on
being
there
for
the
event
I,
don't.
H
A
B
Fantastic
anyone
else
is
planning
on
going
to
you
and
they
want
to
volunteer
on
that.
Give
me
your
names
and
I'll.
Add
that
to
the
to
the
proposals.
The
other
thing
is:
what
sort
of
updates
do
we
want
to
do?
Typically,
we
have
a
choice
of
one
short
update,
which
is
you
know
either
a
deep
dive
or
a
general
update.
We
can
take
two
short
one
would
be
deep
dive.
E
D
I
think
the
siggy
WS
update
worked
really
well
last
time.
Just
and
you
can
jump
in
here,
but
we
did
the
demos
for
each
of
the
sub
projects
that
we
offered
in
are
going
to
alpha,
and
then
we
took
questions
from
users
and
ever
since
we
did
that
update
and
we
did
release
notes.
There's
been
tremendous
activity
in
the
Sierra
Prius
community,
so
that's
quiet
and
it's
around
the
sub
projects
that
we
demoed
and
work
for
us,
because
it's
basically
talking
about
the.
B
B
Otherwise,
you
know
whatever
Stephen
feels
best
about
will
will
plan
on
doing
since
there's
there's
this
since
yeah,
no
one
aside
from
Stephen
feels
strong
about
it
either
way
and
with
that
I
think
we're
at
the
end
of
there
are
our
there
any
other
final
business
before
we
close
the
meeting.