►
From YouTube: Kubernetes Federation WG sync 20180523
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).
B
A
C
D
A
A
A
B
Yeah
we
we
have
a
milestone
in
the
repo
that
were
I,
guess,
informally,
started
tracking
some
of
the
issues
that
we'd
like
to
accomplish
before
releasing
the
first
alpha.
If
you
wanna
I,
think
that's
probably
a
an
okay
place,
we
did
that
for
cluster
registry
as
well.
I
think
you
know.
Similarly,
other
projects
are
doing
the
same.
So
if
you
want
to
create
the
issues
that
you'd
like
to
see
accomplished
before
an
alpha
release,
and
then
we
can
discuss
them
and
and
add
them
to
the
milestones
as
appropriate.
B
A
B
A
Okay,
yeah
yeah,
apart
from
this
I,
had
one
more
point
about
the
review,
worship
and
a
quality
expectation.
What
we
are
thinking
about,
what
kind
of
poor
quality
is
okay
for
the
self
release
like,
for
example,
the
PRS
that
I
have
submitted.
There
are
a
couple
of
teeth
to
dues
in
that
like
it
is,
is
it
necessary
to
complete
or
fix
all
those
tools,
or
we
can,
or
on
what
basis?
A
Should
we
actually
be
deciding
that
this
is
okay
for
this
alpha,
and
it
is
not
okay
for
this
alpha
only
discussion
or
the
cycles
of
the
special
on
issues.
There
might
be
some
expedited
way
for
that
right.
This
is
why
I
have
put.
This
is
because
I
think
some
I
don't
know,
maybe
because
we
need
some
cross
reviewer
ship
also,
so
some
progress
might
be
slow,
especially
for
items
which
we
are.
We
are
working
on.
B
E
B
A
Okay,
yeah,
so
what
I
will
do
so
next
week's
meeting?
We
can
actually
make
up
a
list
of
items
which,
ideally,
we
should
discuss
and
me
by
the
time
I.
We
should
ideally
also
have
gone
one
round
off.
You
know
some
reconciliation
on
the
shoes
that
are
created.
That
means
a
milestone
that
seems
to
be
okay.
B
D
A
A
B
Think
at
some
point
it
doesn't
have
to
be
now,
but
we
should
probably
discuss
kind
of
long-term
testing
strategy
for
some
of
the
capabilities
so
like,
for
example,
the
DNS
stuff
that's
going
in
does
tend
to
require
a
load
balancer
in
order
to
kind
of
fully
test
and
ten
I
believe
in
in
K
Federation.
We
were
using
Google's
cloud
to
do
some
of
that,
but
it
required
Google's
intervention.
B
A
E
I
think
it's
not
faking,
but
it's
one
implementation
of
a
load
balancer.
So
that's
how
double!
But
what
what
is
I
think
a
more
difficult
here
is
I
think
having
a
complete
end-to-end
setup
like
we
had
in
Federation,
and
we
need
to
consistently
do
maintain
it
actually.
So
now
most
of
the
testing
costs
structure
right
now
is
outside
the
test.
E
I
think
automation
is
not
a
difficult
stuff,
mostly
the
decision,
whether
we
continue
testing
and
a
first
second,
because
particularly
multiplexer
was
difficult
because
most
of
the
tests
in
component
is
single
cluster
setups
and
we
need
a
multi
cluster
e
to
e
setups
and
whatever
we
use
in
Federation,
people
was
kind
of
absolute
method
and
there
was
no
stable,
particular
source
test
setups.
Actually
that
was
an
issue
in
women
also.
F
E
Actually,
the
whole
thing
was
built
up
using
the
cluster
scripts
plus
to
bring
up
scripts,
and
that
was
going
to
go
out
and
we
hadn't
for
partially.
We
had
a
using
kubernetes
anywhere,
but
that
project
in
eval
I
think
so
now
we
need
so
most
of
the
guys
are
returning
to
cluster
API
for
suits
to
bring
up
the
cluster,
and
definitely
there
is
no
nothing
which
can
bring
up
multiple
clusters.
As
of
now.
F
E
E
C
I
can
easily
imagine
actual
cloud
provider
clusters
to
be
like
very
flaky
to
test
with,
but
I
also
think
that
we
need
to
have
some
degree
of
CI
that
that
probably
works
using
real
clusters.
I
know
that
Marui
has
been
a
big
proponent
of
using
fake
clusters
as
targets
for
testing
so
I
guess
we
ought
to
think
about.
To
what
extent
can
we
get
away
with
that
versus
if
we
have,
if
we
have
features
that
actually
integrate
with
cloud
providers
that
we
want
to
want
to
test
in
CI.
A
F
Sorry
I
didn't
I
didn't
mean
to
interrupt
you.
I
was
just
going
to
throw
my
two
cents
and
yeah,
so
I
think
I
think
it
is
valuable
to
have
fast
and
reliable,
fake
cluster
tests,
and
particularly
when
it
comes
to
you
know,
doing
large
numbers
of
clusters
and,
as
I
mentioned
in
yesterday's
call,
a
Cisco
have
actually
stepped
up.
They've
got
two
full-time
engineers
and
they're
planned
for
the
next
couple
of
months
is
to
build
fake
cluster
testing
set
up
along
the
lines
of
what
did
we
call
it?
F
In
kubernetes
we
had
the
way
of
creating
fake
clusters
with
fake
nodes
for
building
large
clusters
hollow
hollow
clusters.
Yeah.
That
means
the
words
that
was
used
to
describe
it.
There
was
another
temperate,
but
either
way
those
were
useful
for
scalability
testing
in
particular,
and
I
think
there
also,
if,
assuming
that
we
can
bring
up
these
fake
clusters
much
quicker
than
we
can
bring
up
real
clusters,
I
think
it
has
value
in
being
able
to
do.
F
You
know
I
City
enter
in
tests,
but
I
also
think
I
agree
with
you
pol
I
think
we
need,
and
my
suggestion
would
be,
that
we
pick
a
canonical
public
cloud
provider
and
realistically
it's
you
know,
probably
either
Amazon
Google
or
Microsoft
and
and
choose
one
of
those
as
as
like
the
minimal
set
of
public
clouds,
that
we
want
to
be
able
to
run
regular
intent
tests
on
and
then
invite.
You
know
other
parties
to
to
augment
that
with
additional
cloud
providers.
F
F
F
That
was
all
sponsored
by
Google
and
I
can
mention
the
numbers,
the
actual
dollar
figures,
of
what
that
costs
I'm,
not
sure
if
I
should,
but
it
was
a
pretty
substantial
amount,
but
but
they
they
repay
it
to
be
no
big
problem
with
funding
that
and
yeah
so
I
think
within
you
know
reasonable
limits,
and
it
was
you
know
in
the
many
tens
of
thousands
of
dollars
a
month
range
that
not
seen
as
a
major
obstacle
at
the
time.
I
don't
know.
E
E
F
One
other
comment
on
the
previous
topic:
I
would
hope
that
for
the
most
part,
the
functionality
in
Federation
v2
is
in
the
ended
or
specific
cloud
providers
and
that
the
cloud
providers
specific
code
resides
mostly
in
the
clusters,
and
you
know
that
that
might
be
a
pipe
dream.
But
but
looking
back
to
v1,
there
was
very
little
that
was
cloud
provider
specific.
The
one
exception
would
have
been
the
ingress
better
ed
engross
controller,
but
it
was
very
limited.
Dynamically
yeah.
C
C
A
E
A
C
Did
an
ode,
ATO
dot,
one
like
initial
alpha
release
and
then
just
every
week
released
what
was
in
master,
basically
I.
Think
the
primary
question
to
me
before
we
cut
an
initial
alpha
release
would
be.
What
do
we
want?
The
experience
to
be
like
of
setting
up
a
new,
Federation
and
I
do
think
that
we
should
integrate
with
the
cluster
registry
CRD,
which
is
cluster
rez
registry
version.
0.5
and
Lindsay
is
going
to
be
working
on
that
this
week
that
specific
piece
of
bumping,
the
cluster
registry
depth
so
yeah
on
that.
For
me,.
E
F
A
So
I
actually
did
put
in
one
more
point
to
talk
that
was
about
the
viewership
and
the
code.
Quality
expectations
for
them
sorry
means
so
I
think
you
answered
that
question.
I
only
hope
this
see.
The
main
point
is
that
either
I
or
shashi
do
not
have
any
rights
on
the
v2
records
of
now.
So
we
just
hope
that
we
also
get.
E
C
Yeah
I
I,
so
my
own
predisposition,
temperamentally,
like
especially
when
we're
talking
about
halfa,
is
like
I
I,
do
not
believe
that
alpha
features
should
have
to
be
fully
formed
as
they
go
in
in
the
sense
of
like
I.
Don't
think,
for
example,
that
we
have
to
gate
pulls
on
having
Docs
that
come
with
a
feature.
I
I
also
think
that
it's
probably
a
point
in
this
particular
project,
where
it's
more
important
to
have
like
integration
tests
than
really
thorough
unit
coverage.
C
So
I
I,
like
I,
said
earlier.
I
think
the
bar
is
not
like
extraordinarily
high,
so
we
can.
We
can
play
it
by
ear,
but
in
general,
I
would
kind
of
think
of
just
my
own
personal
opinion.
I
think
Maru
would
probably
want
to
provide
his
opinion
to
next
week,
but
my
own
personal
thing,
it
would
be
like
probably
focus
on
integration
tests.
C
We
don't
need
to
gate
polls
on
being
perfect
and
I'm
personally,
a
big
proponent
of
iterative
development,
so
I'm
all
about
smaller
changes
that
go
in
faster
than
if
you
have
like
a
big
chunk.
That's
a
self-contained
thing
for
a
large
feature
like
that.
That
tends
to
be
very
hard
and
costly
to
review.
F
I
agree
with
you
one
caveat:
there
was
the
the
the
main
purpose
of
Alpha
is
to
get
feedback
from
users,
so
I
think
yeah.
That
should
be
a
goal
that
we're
very
clearly
aware
of
and
explicitly
address.
So
in
particular,
in
order
to
get
feedback
from
users,
they
need
to
be
able
to
go
through
a
getting
started,
guide
and
and
say
right.
F
You
know,
have
a
set
of
and
user
experiences
that
actually
work
at
least
yeah
to
production
quality,
but
I
should
be
bring
up
a
control,
plane
and
I
should
be
able
to
go
through
creating
a
federated
replica
set
or
whatever
I'll
actually
have.
It
behaved
as
its
intended
to
behave
yeah
without
too
much
pain
and
I
think
that
level
of
documentation
is
required.
C
What's
the
experience
of
getting
started
with
it,
what
we
have
in
what
we
have
for
service
catalog
is
a
walkthrough
document
that
has
installation
instructions
and
then,
like
a
sample,
use
case
that
you
can
go
through
step
by
step
and
like
walk
through.
What
do
you?
What
come
in?
Do
you
run
and
like?
What
does
all
this
stuff
mean?
That
kind
of
thing
to
get
you
through
the
basics,
like
of
the
essential
use
case
and
service
catalog?
C
It
sounds
like
what
the
version
of
that
is
for
Federation
would
be
like,
given
that
I
have
a
cluster
or
two
already
started.
I
should
be
able
to
add
those
into
a
Federation
and
create
a
federated
replica
set
and
change
the
replica
counts
and
see
it
updating
in
the
clusters,
or
maybe
something
on
that
level
and
like
as
you,
walk
through
the
Thea.
D
F
B
Yeah
I
we
actually
had
an
issue.
Somebody
was
already
kind
of
requesting
ways
to
get
started
and
while
we
do
have
a
development
guide
as
like
the
readme
and
in
the
root
of
the
repo,
we
do
still
need
to
create
a
user's
guide
and
we
do
have
a
script
that
will
go
through
kind
of
the
end-to-end
setup
and
deployment
of
the
Federation
version
to,
along
with
the
cluster
registry
kind
of
the
necessary
pieces
and
then
I've
kind
of
captured.
B
B
B
Yeah,
there's
there's
definitely
need
to
reorganize
some
of
the
docs
and
create
a
user
documentation
that
that
folks
can
follow
I'll
work
on
creating
an
issue.
So
we
can
track
that
because
that's
okay.
B
E
C
So
I'm
I'm
hearing
that
we
have
seemed
of
like
a
fair
amount
of
consensus
on
that
should
be
part
of
the
first
alpha
release
and
like
I'm
personally
interested
in
having
like
the
first
alpha
release
happen
sometime
soon,
it
sounds
like
that's
what
is
in
other
people's
heads
too
awfully
soon.
It
should
have
walked
through
that
you
can
use
to
get
started
and
work
with
and
understand.
What's
going.
A
B
I
think
the
other
hurdle
is
going
to
be
the
release
strategy
on
this
and
right
now
we're
sort
of
in
a
state
of
flux
where
we're
trying
to
migrate
away
from
API
server
builder
to
queue
builder.
So
it's
potentially
going
to
require
a
different
tool
set
to
actually
deploy
the
v2
stuff.
So
we'll
just
need
to
come
up
with
kind
of
a
release
strategy
to
figure
out
what
we
want.
That
first
initial
experience
to
be.
C
C
Sorry
I
was
just
going
to
say:
yeah,
that's
a
good
point,
but
as
long
as
we
keep
that
like
walkthrough
document
up-to-date
with
what
the
what
the
steps
are
to
install
and
use
Federation
I,
don't
think
that
is
something
that
needs
to
impact
like
the
release
process
and
in
terms
of
actually
so
this.
This
does
make
me
think,
though,
that
we
should
probably
set
up
like
a
Quay
for
other
image
registry
account
for
Federation
and
do
image
builds
starting.
A
Yeah,
that
sounds
logical,
Paul,
I,
think
by
the
time
we
cut
out
a
release.
We
would
need
image
location
like
that.
What
I
was
going
to
say
is
about
the
possible
move
for
to
a
different
conception
of
pupa
I.
Think,
in
my
opinion,
the
functionality
is
what
matters
more
to
me
as
a
user
for
release,
so
that
I
try
out
what
are
the
possible
things
that
I
can
in
the
condition
v2
rather
than
it
is
actually
being
set
up
using
API
server,
build
the
aggregation,
kind
of
a
thing
or
actual
CRV
I.
F
F
F
I
know
Meru
is
not
here,
but
we
can
certainly
tag
the
ones
that
we
didn't
know
the
answers
to
or
MOOC
and
then
go
through
provision
the
triage
list
and
put
his
opinions
in,
but
it
seems
waiting
another
two
weeks
taking
it
from
five
weeks
to
released
until
three
weeks
released.
It's
probably
not
the
right
thing
to
do.
Does
that
make
sense?
No.
A
A
D
A
D
A
E
C
The
cluster
registry,
like
the
CR
DEA
version,
and
we
had
the
walkthrough
document
in
an
image
build
I,
would
be
totally
happy
to
release.
That
is
the
first
alpha
release
like
I
I
personally,
see
no
need
to
block
on
any
features
for
the
first
alpha
release,
because
we
can
push
alpha
recent
releases
like
weekly
if
we
want
to
so
just
just
let
that
let
me
be
explicit
about
that
in
terms
of
what
my
own
opinion
is
yeah.
B
I
was
just
gonna
say
my
that
that
seems
to
make
sense.
My
initial
suggestion
was
just
to
keep
in
mind
that
the
just
to
keep
in
mind
the
release
strategy
that
we
plan
on
setting
for
the
first
release.
It's
not
that
we
necessarily
need
to
wait
and
gay
moving
to
build
or
anything,
but
we
should
keep
in
mind
that
that
user
documentation
will
be
in
a
bit
of
state
of
flux,
for
you
know
the
at
least
a
short
foreseeable
future
and
we'll
just
need
to
keep
that
up
to
date.
A
C
F
Just
gonna
volunteer
to
be
a
guinea
pig
and
I
could
do
once
the
getting
started
guide
has
been
written,
even
if
it's
just
in
draft
form.
I
can't
go
through
that
and
actually
a
guinea
pig
and
do
it
getting
started,
exercise
bringing
up
the
Federation
and
doing
the
basic
tests
manually.
If
that
helps.
F
C
C
A
Just
one
more
item
before
we
I
just
wanted
to
appraise
about
one
of
the
issues:
I
Ivan,
you
might
be
one
of
the
right
guys
to
actually
tell
about
that.
So
I
did
update
that
against
my
peer.
The
issue
basically
is
so
far
we
have
had
in
e2e
and
in
integration.
Also,
we
had
had
only
one
test
fixture
set
up
because
we
probably
are
running
cred
against
a
different
set
of
different
set
of
KPIs
in
a
loop,
so
the
fixture
happens
once
in
case
I
want
to
run
multiple
specs.
A
For
some
reason,
the
Global's
are
persisted
across
the
different
API
server
initialization.
So
it
gets
a
girl
at
some
point,
Crips
saying
that
this
API
or
this
group
for
this
version
already
is
registered.
So
the
best
mechanism
to
do
that
would
be
in
integration
to
set
up
a
suit
kind
of
a
thick
thing
and
all
the
other.
All
the
other
tests
are
individual
specs
against
the
same
integration,
setup,
API
server
or
there
might
be
some
better
mechanical
mechanism
to
do
that.
You
have
any
points
or
comings
for
that.
B
A
B
Yeah
I
think
to
your
point,
though
it
may,
since
everything
is
in
one
binary,
it
may
make
sense
to
have
a
separate
set
up
prior
to
running
like
the
individual
Suites.
It
might
make
sense
to
like
set
up
the
Federation
for
all
of
the
different
individual
tests
and
then
have
a
teardown
afterwards
and
being
able
to
run
them
all
together.
It
would
start
mimicking
more
of
the
end-to-end
setup,
though
yeah.
B
B
So
we
may
eventually
look
at
I,
probably
need
to
consolidate
those
two
and
figure
out
what
long
term
we
want
to
do.
The
antenna
test
does
use
ginkgo,
whereas
the
integration
does
not,
and
it
does
seem
like
there's
a
bit
of
overhead
in
in
speed
and
and
being
able
to
run
tests,
whereas
integrate
integration
runs
it
a
bit
faster
than
then
the
ete
stuff.
B
A
B
F
A
Ya
sorry
I
did
not.
I
did
not
point
that
out.
That
is
something
which
is
supposed
to
be
pointed
out,
so
yeah.
So,
prior
to
this
meeting,
I
had
a
chat
with
Quinton
and
whittles
mentioned
that
we
actually
came
up
with
a
design
document
after
a
couple
of
months
of
brainstorming
and
saying,
and
if
there
is
a
gap
between
that
document
and
what
is
implemented
right
now,
either
the
at
least
the
documentation
should
be
updated
to
reflect
the
correct,
current
state
or
kuden.
B
Yeah
I
think
so.
Do
you
see
I'm
not
sure
that
there's
at
least
it
seems
like
there's
not
a
lot
of
divergence,
it
shouldn't
be
too
large
of
a
task.
Do
you
all
agree
with
that.
A
Yeah
I
sort
of
agree,
I
sort
of
see
the
current
implementation
is,
as
a
little
literally
moved
into
a
layered
kind
of
an
approach,
rather
than
all
API
is
being
augmented
or
supplementing
each
other
in
what
Winton
had
proposed
a
plus
synchronous
document,
the
API
names
and
feel
spec
probably
specified
some
things
which
are
not
necessarily
followed.
Currently,
these
are
the
two
main
points
which
we
differ
as
of
now,
so
we
then
would
would
it
be
okay
if
we
reconcile
the
document
to
update
what
is
being
currently
implemented,
yeah.
F
Yeah,
so
I
would
like
that
to
happen,
the
mechanics
of
it
either.
We
just
put
a
comment,
put
comments
on
the
document
first,
to
just
illustrate
what
exactly
has
diverged
and
then
update
the
document.
Accordingly,
that's
fine
as
long
as
we
can
keep
as
long
as
there's
some
approximation
of
a
diff
somewhere
along
the
line.
So
we
can
see
what
the
difference
is.