►
From YouTube: Kubernetes SIG Cloud Provider 2018-10-31
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
A
E
A
Cool,
so
the
only
agenda
item
I
added
was
to
have
the
discussion
around
providers
sub-projects
of
su
club
provider.
So
we
kicked
off
the
cig.
We
had
kind
of
set
a
long-term
goal
to
consolidate
all
the
provider
SIG's
into
some
cloud
provider:
s
sub
projects
and
I.
Don't
so
we
didn't
have
kind
of
full
consensus
on
what
that
would
look
like.
We
just
said
that
we're
gonna
kind
of
aim
to
get
that
done,
and
so
I
figured
it's
been
a
few
months.
A
Now
that
we've
kind
of
kicked
this
thing
off
and
so
figured,
we
should
have
some
sort
of
discussion
around
around
what
this
would
look
like
and
I
know.
Some
SIG's
have
already
agreed
to
kind
of
fall
under
that
model
of
being
a
sub
project
and
I
know
some
sakes
are
still
undecided,
so
I
think
having
that
discussion.
A
That
would
be
great
so
from
what
I
understand
what
that
would
look
like
if
we
were
to
do
it
today,
would
be
that
we
would
just
kind
of
follow
that
sub
project
model,
where
we
just
added
under
the
thing,
and
then
we
have
tech.
Ideally,
we
have
like
an
owner
style
for
each
sub
project,
but
there
are
discussions
to
be
had
about
if
the
sub-project
model
kind
of
is
flexible
enough
to
do
kind
of,
like
the
providers
of
sub
projects
that
we
wanted
to
come
forward.
D
D
I
think
one
question
might
be
for
PA's
sake,
like
GCP,
who
has
the
number
of
sub
projects
beyond
just
the
GCP
cloud
provider,
whether
it
makes
sense
to
fold
all
of
those
additional
sub
projects
under
sick
cloud
provider
or
whether
or
not
this
is
a
purely
the
cloud
provider
thing.
It's
there.
A
number
of
other
cloud-based
sakes
I
think
that
run
into
the
same
problem,
I'm
curious.
What
other
people's
thoughts
are
out
there
just.
B
I
was
just
gonna.
It
was
just
gonna,
be
that
that
point
of
clarification,
where
that
we're
talking
about
all
the
sub
projects
of
what
are
today,
the
various
accounts
tags
or
whether
we're
just
talking
about
one
of
them
and
essentially
whether
they
like
the
others,
this
the
per
cloud
SIG's
continue
to
exist
or
not.
I
guess.
F
Yeah,
it's
the
I
speaking
on
behalf
of
VMware.
We
do
have
the
VMware
cloud
provider
for
running
on
top
of
East
fare,
but
we've
got
other
things
going
on
with
cluster
API
or
Software
Defined
Networking
staff
stack,
so
the
portion
that
relates
to
cloud
provider
I
think
would
fit
well
in
that
model,
but
I
think
that
there
might
still
be
a
basis
for
a
cig,
independent
of
cloud
provider
focused
on
VMware
infrastructure.
F
D
The
the
prevailing
like
push
back
to
this
would
be
the
it
sounds
like
y'all
are
using
SIG's
as
user
community,
and
you
are
free
and
welcome
to
do
that
as
yourselves
as
a
vendor,
so
like
Amazon,
could
have
their
own
kubernetes
user
community
VMware
to
have
their
kubernetes
user
key.
The
question
is
like
what
does
being
a
cig,
provide
you
above
and
beyond
that
level
of
support.
D
There's
a
lot
of
the
features
you're
talking
about
would
presumably
be
features
that
would
be
enabled
by
way
of
the
cloud
provider
code
right
like
if
you
have
some
super
advanced
networking
or
some
crazy
awesome,
storage,
presumably
you're
a
cloud
provider
project
is
the
thing.
That's
gonna
turn
that
on
I.
E
Think
I
think
there's
some
confusion
around
the
organization
of
the
structure.
Overall
and
initially
the
things
were
a
subset
of
the
overall
kubernetes
project
and
I.
Think
we've
hit
an
inflection
point
where
we
get
into
extensions
of
or
implementations
of
swappable
pieces
and
whether
that
is
still
within
the
same
framework
or
not
has
never
been
clearly
laid
out
for
the
long
term.
E
So
I
think
the
user.
The
user
forum
is
one
aspect.
The
other
is
implementations
of
interfaces,
for
example,
and
I
think
there
is
still
I've
heard
some
feedback
that
there's
some
associated
with
being
a
big
leap
and
you
get
to
be
part
of
this
big
weeds
list
and
you
get
invitations
to
give
deep,
dives
and
intros
at
UConn,
and
there
are
some
benefits
so
I
wonder
if
we
can
figure
out
what
those
benefits
are
and
create
a
new
mechanism
for
certified
providers
of
and
work
with
us
yeah
to
meet
those
needs.
F
Even
going
back
to
your
comment
of
you
know,
you
use
the
example
of
the
networking
integrating
in
with
a
cloud
provider
in
VMware's
case,
our
software-defined
networking
also
supports
OpenStack.
So
this
is
really
not
even
though
it
certainly
is
supported
on
the
VMware
cloud
provider.
It's
on
other
cloud
providers,
so
it
isn't
the
Venn
diagram,
where
these
circles
potentially
overlap
a
hundred
percent
that
actually
may.
D
Like
I
for
my
standpoint,
but
I
would
love
to
see
sick
cloud
provider,
be
the
big
circle
around
the
needs.
The
technological
technological
programs
that
are
under
that
are
specifically
related
to
running
kubernetes
on
top
of
an
infrastructure
provider
and
for
managing
the
concerns.
Questions
of
The,
Associated
user
groups,
I
see
that
this
SIG
should
be
should
be
the
beginning
of
that.
D
Where
we've
gone,
having
sake,
GCP,
cig,
AWS,
SiC,
VMware
sake,
IBM
cloud
Sega,
sure
I
think
is
just
too
much
fragmentation
too
confusing
for
the
community
and
that's
a
bunch
of
overhead
like
Aaron,
was
mentioning
in
terms
of
Charter
Review.
That
does
not
seem
to
add
much
value
to
the
project
itself,
but
none
of
this
is
about
how
to
make
running
kubernetes
on
top
of
an
individual
black
cloud
provider
better
and
well
Frank.
D
Frankly,
I
would
like
to
see
that
that
experience,
moves
and
kind
of
walks
up
across
providers
I
don't
want
to
see
that
the
experience
is
much
much
much
better
while
wearing
my
open-source
hacked
on
GCP
versus
asher
or
verses,
eight
of
us
or
versus
VMware
or
open
sac
and
I
feel
like
this.
If
there's
any
group,
that's
going
to
make
sure
that
that
is
true,
that
it
has
to
be
this
group
and
that
having
a
bunch
of
providers
like
you,
look
at
like
the
documentation
for
the
imageable
from
individual
providers.
D
I
think
he
has
brought
this
up
and
has
tried
to
make
the
situation
better
with
the
documentation
cap
that
allowing
individual
vendors
to
be
the
sole
arbiters
of
what
platform
support
means
on
their
provider
means
that
users,
who
nominally
were
all
here
to
support,
have
a
very
inconsistent
experience
across
providers,
which
is
does
not
seem
to
be
good
for
the
users
or
for
the
project.
I
would
like
to
start.
You
know
rubbing
in
that
sprawl
with
this
group
here
now.
Certainly
AWS
being
I
know
off
the
top
of
my
head.
D
They
have
projects
that
they
have
sponsors
that
maybe
don't
like
suggesting
of
for
VMware.
There
are,
you
know,
tooling,
that
helps
a
lexer
Tiffa
commandment
on
AWS.
Now,
whether
that
should
be
sponsored
by
state
club
provider.
I
would
argue
that,
yes,
it
should
be
because
it's
needed
and
used
by
the
communities,
users
who
are
running
on
AWS
and
I-
think
that's.
D
F
I
just
want
to
make
the
comment
that
optimizing
or
making
the
decision
to
save
refuses.
Some
some
charters
seems
like
the
wrong
evaluation
mechanism
here.
I
mean
if
well
what
if
what
we've
got
now
is
dysfunctional
for
getting
development
activities,
organized
and
done
that's
bad
and
we
should
fix
it.
But
Charter
reviews
I
mean
correct
me
if
I'm
wrong,
but
even
if
there
were
still
working
groups,
aren't
their
charters
associated
with
that
and
reviewer
a
charter
is
an
intermittent
one-time
thing.
Forget.
D
About
charters
for
a
second,
it's
about
six
brawl
of
the
as
a
whole.
It's
about
that
they're,
like
30,
plus
different
groups
that
are
called
sinks
and
as
an
end-user,
contributor
or
developer.
It
might
be
really
confusing
to
know
where,
to
start
not
say
it's
sorry
for
interrupting,
but,
like
I
feel
like
the
point
that
Charter
Review
is
just
an
example
but
considered
okay,.
F
E
I
did
want
to
respond
to
something
that
came
up.
It
said
about
responsibilities
and
figuring
out
what
is
who
is
responsible
for
the
consistent
experience
for
the
end-user
across
providers
and
I
want
to
be
careful
not
to
try
to
take
over
some
of
the
responsibilities
that
the
community
is
put
in
the
conformance
working
group
and
program
and
process.
E
That
is
essentially
what
we
have
that
can
guarantee
the
portability
of
workloads
and
the
consistent
user
experience.
However,
I
think
there
is
responsibility
for
this
group
in
what
is
the
shared
code
that
we
can
centralize
so
that
we
avoid
the
fragmentation
that
would
double
up
in
the
conformance
suite.
And
how
can
we
like?
There
was
a
thread
about
the
tests
shared
tests
that
came
up
and
who
would
have
when
those
tests
I
think
I
didn't
respond
to
the
thread.
E
But
I
think
this
is
a
good
topic
and
I
put
it
on
their
agenda
to
talk
about
next
about
how
this
group
can
hone
those
tests.
And
so
there
is
a
distinction
between
how
to
formulate
what
is
required
of
a
kubernetes
implementation
and
what
the
implementation
details
on
those
providers
are
and
I
want
to
make
sure
we
separate
those
and
we
don't
end
up
testing
the
implementations
we
test
the
API
and
that
that
is
what
is
portable,
so
Walter
had
his
hand
up
and
then.
G
G
So
if
I
denied
to
start
in
one
place,
find
a
small
list
of
things
where
you
can
work
out,
Oh
anything
to
do
with
any
cloud
provider
will
be
under
sick
cloud
provider,
so
I
can
go
there
and
then
I
get
the
next
branch
out.
Factor
and
I
can
see.
Here's
the
30
cloud
providers
well,
I
know
the
thing
I
want
is
under
OpenStack,
so
I'll
go
to
OpenStack.
G
Okay,
now
under
OpenStack,
here's
the
seven
different
projects
that
OpenStack
is
funding
and
that
way,
instead
of
starting
with
a
list
of
400
and
having
no
idea
how
to
find
what
I'm
looking
for
I
have
a
short
list
of
things
and
at
each
step,
I
knew
where
to
go.
If
we
can
find
that
right,
that's
sort
of
correct
hierarchy,
oh.
D
I
think
you
know
that
the
this
group
has
the
role
of
sponsoring
things
like
I
was
saying
about.
The
AWS
like,
maybe
is
a
alb
ingress
controller
or
the
it's
another
good
example.
The
IMF
yeah
I
am
authenticator.
These
are
both
parts.
You
need
they're
beyond
just
the
core
of
kubernetes.
You
can't
run
reasonable
workloads
without
them.
I
think
this
group
needs
to
have
some
responsibility.
Interaction
over
these
additional
batteries
better
beyond
this
is
conformance.
So
even
you
know,
with
conformance
as
a
strong
minimum,
you
know
this
is
what
could
be
these?
D
E
E
E
E
A
D
Totally
agree,
I
think
that's
probably
part
of
one.
The
good
governance
for
this
sake
specifically,
but
also
any
transition
plan
to
fold
a
existing
cig
into
a
sub
project.
Here,
I
think
those
are
required
problems
that
we
needed
to
solve
anyway,
like
I,
think
the
steering
committee
would
be
willing
to
get
creative
if
there
is
concern
around
blockage
when
it
comes
to
the
creation
of
sub
projects.
I
know
that
the
template
that
we've
asked
everybody
to
use
only
has
two
options.
One
tech
leads
choose
to
every
sub
project,
owner
votes
and
it's
a
majority
decision.
D
I
know
I
have
heard
concerns
expressed
that
voting
wouldn't
really
work
well
here,
cuz
like
what
would
happen
if
Amazon
wanted
to
create
the
alb
ingress
controller
and
Microsoft
and
Google
and
VMware
decided
to
gang
up
and
vote
no
to
stop
them
from
doing
that.
Right.
That's
wholly
unrealistic,
but
I
think
it's
more
about
in
empowering
people
to
actually
move
forward,
while
simplifying
the
structure
and
scope
of
the
project
is
ultimately
our.
B
Goal
here,
I
mean
I,
think
I.
Think
that's
in
that
same
problem
could
happen
with
like
the
leads
right.
It
could
be
that
two
leads
become
obstructionists
and
like
it
gets
bubbled
up
to
SiC
architecture.
So
no
I,
don't
really
think
that
would
actually
be
a
problem
practice,
but
I
would
like
to
know
I
think
Caleb.
You
you
mentioned
about
things
going
up
to
cig
architecture,
I,
don't
know
what
that's
referring
to
like
today.
Things
have
bubbled
up
to
say:
architects,
there's
not
no!
No.
B
D
B
D
D
Would
it
be
up
to
you
this
particular
cig,
to
define
like
what
that
profile
looks
like
what
is
a
cloud
conformant
kubernetes,
or
is
that
the
sort
of
question
that
would
get
punted
over
to
cig
architecture,
because
I
feel
like
think
what
decisions
that
get
punted
over
to
city
architecture
or
like?
Is
this
in
the
spirit
of
kubernetes
or
not
and
I
view
this
group
is
trying
to
answer?
Is
this
in
the
spirit
of
making
kubernetes
interoperate
with
the
cloud
more
easily?
E
It
does
help
and
I
think
I
agree
with
your
characterization
of
the
focus
and
scope
of
the
sake
of
this
thing.
I'm
not
sure
it
helps
on
whether
we
sold
all
provider
specific
SIG's
under
Sigma
cloud
provider,
and
it
sounds
like
the
one
sticking
point.
Is
this
hierarchy
and
owners
resolution
and
not
having
to
manually
update
owners
files
for
specific
sub
projects?
Now.
D
That
yeah
and
I
think
that
that
concern
that
maybe
might
be
overblown
like
I.
You
know
it's
my
understanding
that
sub
projects
are
supposed
to
map
to
one
or
any
repositories
so,
like
the
repository
owners
shouldn't
change
that
they
ideally
would
all
map
to
the
AWS
sub
project
under
say
cloud
provider
and
the
owners
for
that
project.
I.
Unless
someone
has
you
know
other
criteria
or
other
plan
which
have
become
the
existing
sig
chairs
as
the
initial
set
of
people
who
are
the
owners
for
that
sub
project.
D
Rather,
not
the
hierarchy
of
sakes
folding
into
other
six,
like
anything
we
can
do
to
make
this
beast
lest
gnarled
than
it
already
is,
would
be
helpful
part
of
me.
I
guess.
I
I
hope
that
if
we
were
to
move
to
like
every
single
sub
project
that
belongs
to
the
existing
cloud,
six
just
becomes
a
sub-project
of
cloud
provider,
and
maybe
some
people
decide
it's
much
easier
to
batch
a
whole
bunch
of
repos
under
one
sub
project.
Maybe
that
works
well
for
them.
D
The
example
I
would
use
is,
is
how
SIG's
storage
has
like
one
massive
kubernetes
CSI
sub
project,
which
encompasses
like
20
or
30
CSI
related
repos.
At
this
point,
so
everybody
who
cares
about
CSI
related
stuff
works
on
like
has
decision
power
for
all
those
repos
and
then
the
decision
process
just
doesn't
become
like
are
we
talking
about
creating
a
brand-new
sub
project
is
doesn't
fall
within
the
scope
of
this
sub
project
because
I
feel
like.
Ultimately,
it's
gonna
be
this
group's
responsibility
to
decide.
E
B
And
I
think
also,
we
should
one
of
things
I
think
works
well,
at
least
in
CGI,
ws
I'm,
less
familiar
with
the
other
six.
Is
the
user
group
aspect
and
fair
enough
a
sake
very
shouldn't,
be
a
user
group,
so
we
would
probably
want
to
set
up
some
form
of
user
group
type
things
so
that
the
people
like
SIG's
tend
to
be
more
engineer.
D
Yeah
I
mean
I'm
unclear
it,
because
I
have
thus
far
whenever
viewed
sake.
Charters
like
Stephen
VMware's
charter
was
great
and
I
thought
it
was
a
it's
an
example.
I
point
to
over
and
over
again
about
how
like
you're
sig
is
the
forum
for
discussion
around
the
best
practices
on
using
kubernetes
on
your
specific
cloud.
That's
that's
something
that
I
wouldn't
necessarily
want
this
community
to
feel
like
they
have
lost
as
part
of
this
transition,
but
I
do
feel
like
fewer
things
would
simplify
things
somehow.
F
Yeah
I
think
you
know
it.
These
eggs
are
developer
focused,
but
really
the
developers
can
get
a
boost
from,
let's
just
say:
well:
educated
and
informed
users
coming
to
the
table,
bringing
their
issues
and
kind
of
serving
as
product
managers
and
giving
them
a
venue
to
come
come
to
the
table,
for
that
I
think
is
valuable
so
far,
at
least
in
the
VMware
Sync.
It
hasn't
been
a
big
issue
where
we've
got
big
crowds
of
users
taking
over
the
agenda.
The
to
the
point
where
we
don't
have
focused
development
and
architecture,
discussions
and.
B
G
Yeah
I
mean
I,
think
I
would
but
I
think
those
two
I
agree
with
what
Justin
just
said,
but
I
think
there's
a
distinguishing.
You
know
we
may
want
to
break
them
out
into
augs
or
whatever
and
have
meetings
for
each
of
the
different
cloud
providers,
but
that
doesn't
mean
that
it
isn't
actually
part
of
the
greater
cloud
provider
and,
in
fact,
I
think
it
would
make
a
lot
of
sense
for
someone
who
wanted
to
find
the
right.
G
D
I,
don't
think,
there's
anything
stopping
this
SIG
from
having
multiple
meetings
like
the
provider
and
I
think
is
that
just
say
questions
about
how
does
this
group
of
folks
get
access
to
kubernetes
community
resources?
So
there's
a
bunch
of
shared
resources,
you
know
geom
account,
don't
create
mailing
lists
or
repositories.
I,
don't
think
the
space
for
users
to
congregate,
to
talk
to
get
information
needs
to
be
significantly
impacted
by
we're.
You
know,
Steven
necessarily
like
logs
and
to
start
the
zoom
meeting
or
how
you
know
he
gets
his
zoom
account
to
run
a
zoom
meeting.
H
E
D
I
can
ping
dims
and
see
if
it's
something
he's
willing
to
do
since
he's
on
the
steering
committee,
we
might
have
a
title
iteration
loop,
but
I
make
no
promises
and
he's
pretty
overtaxed
as
it
is.
Is
there
somebody
from
this
group
that
he
could
collaborate
with
good
for
sure
sign
me
up?
Okay,
I
will
Kirk
DIMMs
connects
with
Caleb.
You
can
put
me
as
the
owner
of
that
AI.
D
The
the
last
thing
I
wanted
to
say
before
I
apologize
for
you
to
try
starting
to
interrupt
you
Caleb
was
that
like
sub
sub
projects
do
so
some
projects
can
have
meetings
and
agendas
and
things
on
the
calendar
and
stuff,
like
that's
totally
what
one
of
their
purposes?
So
again,
if
you
wanted
to
have
like
a
sub
project
for
every
cloud,
then
that's
a
project
could
totally
have
multiple
meetings.
D
D
You
know
what
you're
looking
for
when
you
first
come
to
kubernetes
as
a
project
like
Walter
was
saying:
hierarchy
can
really
help
sort
of
simplify
at
least
the
first
step
in
your
journey,
so
I
yeah,
I've,
said
more
than
enough
here,
I
think
in
information,
hiding
being
the
good.
The
good
thing
that
we
all
like
try
to
do
when
we're
writing
software,
not
information
hiding
as
we're
trying
to
sell
you
a
bridge.
So
we
like
trying
to
make
the
internal
structure
of
the
project
easier
to
grok
to
from
by
new
contributors.
H
A
C
I
proposed
a
request
to
add
some
people
from
my
team,
including
myself,
to
the
AWS
cloud
provider,
just
we're
trying
to
kind
of
take
a
little
bit
deeper
ownership
of
that
make
sure
that
we're
moving
that
forward
cleaning
up
some
bugs
I
know
it's
a
little
bit
out
of
cycle,
since
a
lot
of
us
are
fairly
new
contributors.
So
I
just
wanted
to
bring
it
up
to
the
group.
C
D
D
B
Go
ahead
right,
I
thought
we
had
sort
of
soft
and
soften
that
a
little
bit
I.
D
Have
not
seen
that
softened
for
approvers,
of
course,
maybe
I
haven't
been
paying
the
strictest
of
attention,
and
it
is
something
I
have
asked
if
we
want
to
soften,
because
I
have
run
into
somebody.
Who's
really
active
on
Kubb
ATM
right
now,
like
extraordinarily
active
who's.
Not
yet
an
approver
and
I
kind
of
would
have
no
problems
with
them
being
an
approver,
but
they're
still
concerned
that
that
short
of
a
window,
like
shortening
the
window
beyond
three
months,
might
lead
to
the
potential
for
abuse.
D
I,
don't
have
a
creative
enough
imagination
to
draw
that
line
out,
but
there
is
concern
that
you
want
to
make
sure
you,
you
sort
of
grow
your
contributor
base.
You
know
in
a
measured
fashion,
so
I'd
have
no
ID,
no
problem
with
people
being
reviewers
moving
them
straight
to
having
like
final
say,
is
a
little
a
little
trickier
and
I
wish
I
could
give
you
a
firm,
hard
answer
on
like
who's.
The
final
owner
of
that
decision,
as
well.
I,
maybe
like
maybe
sega
architecture,
would
be
a
good
place
to
ask
that
question.
Yeah.
D
Oh
sorry,
I
just
wanted
the
balances
that
well
there's
narrowly
focused
on
a
single
cloud
provider.
There
are
lots
of
people
who
run
kubernetes
on
AWS
or
GCE,
or
you
know
Asher
who
don't
necessarily
interact
with
the
provider
or
you
could
be
a
company
like
FTO
that
provides
you
know,
solutions
on
top
of
you
know
arbitrary
cloud
providers,
so
balancing
like
the
ability
to
make
changes
there
I
think
is
important.
G
G
D
I
feel,
like
that's
largely
the
answer
you
know
here
at
at
cig
architecture.
I
am
interested
in
being
pragmatic,
but
I'm,
not
the
arbiter
of
the
final
of
this
decision.
I
think
more
people
who
have
more
seniority
and
could
learn
more
lessons
on
how
to
appropriately
grow
and
delegate
approver
Authority
are
gonna,
be
at
sig
architecture.
That's
why
I
feel
like
it's
a
fruitful
place
to
have
that
discussion.
D
B
B
Right
I
just
wanted
role.
There
is
a
distinction,
I
think
between
the
two.
There
are
two
two
repos
in
question
here,
one
of
which
is
like
KK,
and
there
I
would
suggest,
like
I,
think,
there's
some
great
arguments
for
why
it
makes
sense
to
start
as
a
reviewer,
and
you
know,
ping
one
of
the
owners
in
the
approvers
one
of
the
approvers
me
if
you,
if
you
want
to-
and
we
can
get
that
going
faster,
but
there
there
are
a
lot
of
gotchas
in
that
code,
which
we've
learned
through
bitter
experience.
B
Eight
of
us,
the
the
eight
ways
cloud
provider.
People,
on
the
other
hand,
is
not
something
that
end-users
are
buying
large
running
today.
So
I
don't
know
whether
there's
a
difference.
There
I
think
I
think
there's
also
a
separate
discussion
of
whether
we
want
to
do
development
there
or
whether
he
wants
to
development
in
the
main
tree,
and
maybe
that's
tied
in
to
your
requests
here,
because
I
know
that
you
were
talking
about
like
a
sort
of
double
implementation
strategy.
B
I
guess
for
that
got
pride,
which
is
different
from
what
FG
GCP,
but
I
would
I
would
certainly
be
much
more
amenable
if
we
do
the
double
implementation
to
having
you
guys.
Do
it
like
it's,
it's
it's
lower,
lower
risk
to
have
you
be
a
an
approver
on
on
a
repo
which
fewer
people
are
using
right,
yeah.
C
Just
split
my
requests
up
the
the
standalone
cloud
provider,
repo,
their
request
is
almost
entirely
to
help
us
expedite
the
double/double
development
there,
whereas
the
entry
was
more
to
just
kind
of
take
a
little
bit
more
active
maintainer
ship
role
there
and
start
to
push
that
one
forward.
I
think.
H
C
E
Yeah
I
think
one
of
the
main
goal
of
this
whole
effort
to
expect
providers
was
to
enable
cloud
providers
to
iterate
at
an
accelerated
pace
and
get
more
velocity
and
not
wait
for
the
entry
stream
ka
repo
to
come
along
for
the
ride
and
I
want
to
make
sure
that
we
enable
and
empower
those
providers
to
have
that
so
I'm
strongly.
Supportive
of
that
I
am.
D
Too,
but
I,
just
like
your
the
first
case
that
I'm
aware
of
of
asking
to
like
relax
the
rules
for
a
different
repo
I
think
it's
a
necessary
conversation
like
what
about
all
the
repos
and
kubernetes
sakes.
Those
aren't
even
considered
part
of
kubernetes
court
right,
conceivably
I
should
be
holding
you
to
some
kind
of
higher
stand
here,
because
cloud
provider
AWS,
is
inside
of
the
kubernetes
core
organs.
I,
don't
know,
I
think
we
should
have
that
discussion.
D
I
think
another
way
that
we
could
compromise
and
empower
you
right
now
is
there
are
a
couple
I
think
there
are
a
couple
people
in
the
world
of
Amazon
who
are
approvers
in
that
external
repo
right
now,
conceivably,
they
can
just
become
rubber
stamps
if
they
trust
the
LG
TMS
that
come
from
or
healers
that
the
bot
should
be
assigning
because
you've
added
people
as
reviewers.
Like
that's
sort
of
the
way
the
growth
happens
right.
C
D
It
would
be
any
real
pushback
if
you
were
to
collaborate
with
someone
like
Justin
who's
external
to
the
walls
of
Amazon,
but
listed
as
improvers.
Certainly
in
like
other
SIG's,
like
sig
node,
we
work
very
closely
with
Red
Hat
to
ensure
that
you
know
we
all
of
our
you
know.
All
of
our
pull
requests
are
moving
through
the
system
quickly.
D
C
C
Can
add
that
to
the
the
agenda
for
cig
architecture
then,
and
to
to
answer
kind
of
what
you
were
saying,
Caleb
I
do
want
to
be
cognizant
of
the
fact
that
we're
spending
all
me
me
and
my
team
are
spending
all
day
doing.
Aws
development
and
everybody
here
kind
of
is
also
doing
work
and
other
things
and
I
don't
want
to
just
kind
of
shovel.
All
of
my
I
don't
want
to
expect
people
to
kind
of
do
my
reviews
quickly
and
burden
them
with
the
stuff
that
I'm
spending
all
my
day.
D
That
makes
a
lot
of
sense,
I
would
suggest
talking
or
working
with
folks
from
fgo
who
work
very
closely.
On
top
of
you
know,
AWS
who
are
outside
the
walls,
but
have
us
very
you
know
your
your
interests
are
very
well
aligned
and
certainly-
and
some
of
these
other
projects,
like
the
ingress
controller
or
the
I,
am
Authenticator.
You
know
that's
some
real
organic
collaboration
and
so
I.
Would
you
know
imagine
that
you
see
those
kind
of
ties
strengthened
over
time
to
help.
B
You
should
definitely
feel
free
to
email
me.
It
is.
It
is
mostly
that
I
am
just
overwhelmed
with
some
volume
of
notifications.
More
than
I
am
overwhelmed
with
actually
doing
reviews,
because
I
can't
even
get
through
the
notifications
much
less
the
reviews,
but
if
you
send
me
an
email
than
you,
because
they're
go
in
a
different
bucket
yeah
and
you
have
to
commute
only
to
your
house.
So
my
commute
time
has
been
doing
code
review.
Sure.
A
E
Was
about
the
email
thread
about
testing
and
I?
Read
it
on
my
phone
in
in
motion,
so
I
don't
have,
but
I
wanted
to
suggest
that
when
opportunities
come
up
to
you
have
ownership
of
shared
test
infrastructure
where
it
doesn't
fall
into
testing.
We
ought
to
invest
in
that
and
I'm
happy
to
find
some
people
that
help
out.
If
there
are
opportunities
to
pull
test
inspector
together
and
ensure
that
we
are
all
using
the
same
test
to
test
the
implementations.
I
think
that's
one
strategy
we
can
employ
to
avoid
the
fragmentation
talked
about
before.
E
Find
it
in
follow
up
okay,
a
question
about:
should
each
cloud
provider
who
own
their
own
tests
for
this
feature,
which
is
implemented
by
each
cloud
provider
and
that's
to
me
it
seems
like
it
set
up
before.
Yes,
the
tests
demonstrate
that
the
cloud
provider
code
does
what
the
cloud
provider
engineer
intended
it
to
do,
but
is
not
doing
something
that
is
consistent
across
board,
so
Janna
Connect.
That
starts
to
sound
a
lot
more
like
cloud
conformance
or
something
that
word
came
up
at
some
point
about.