►
From YouTube: Kubernetes Federation WG sync 20180711
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
C
A
A
We
might
need
to
have
a
package
kind
of
a
thing,
so
we
have
binaries
so
and
anvil
image,
so
we
have
one
binary
and
one
image
and
probably
a
set
of
scripts
which
are
referred
to
as
part
of
the
documentation
that
iPhone
updated.
So
one
option
is
you
just
upload
the
binary
I
mean
and
not
upload
the
binary
creator.
It
means
page
on
the
github
repo
and
there
the
binary
is
published.
A
Location
of
the
image
is
published
and
that's
it
rest.
Everything
people
basically
have
to
clone
the
git
repo
if
they
need
to
run
the
document
through
the
documentation.
That
doesn't
seem
to
be
a
very
nice
option.
So
one
more
task
that
my
domain
is
create
sort
of
a
package
which
includes
those
basic
scripts.
Apart
from
the
binary
and
the
image,
does
it
sound
logical?
Oh
I
think.
B
A
B
It
stands
today.
If
we
get
an
image
published,
we
build,
we
tag,
release,
we
build
cube,
fed
from
that
release
and
that
ugly
release,
and
then
we
link
in
the
release
to
the
docks.
So
people
can
go
through
new
things
manually
and
we
can
also
link
to
you
know:
here's
the
scripts
and
the
repo
and
people
can
you
know,
check
out
the
repo
and
use
the
scripts
that
they
want,
but
I
mean,
to
my
mind,
like
getting
something
awesome
in
the
hands
of
users
is
not
the
goal.
A
In
in
that
case,
the
two
pending
tasks,
which
I
think,
would
be
that
publishing
the
image
and
creating
I
mean
tagging
the
latest.
So
if
you
tagged
the
latest
that
release
page
is
automatically
created
and
they'll,
be,
it
will
automatically
put
in
a
link
to
the
source,
so
users
can
download
that
source
directly
from
that
release
page
rather
than
cloning
the
get
reco.
B
B
B
A
B
C
C
B
C
A
So
I
I
think
in
the
CI
script
a
couple
of
things
like
creating
the
image
for
which
the
dockerfile
is
there
and
then
tagging
it
and
that
kind
of
stuff
are
done.
It's
part
of
another
script.
What
I
did
is
I
did
update
the
make
file,
so
the
make
file
can
build
the
image
using
that
same
doctor
file.
It
can
tag
the
tagging
strategy
that
I
have
used
is
that
whatever
is
your?
If
there
is
no
initial,
the
first
tag
is
not
there
on
the
repo,
which
is
the
current
state.
A
It
will
just
take
the
latest
hash,
and
that
is
what
it'll
put
as
the
tag
of
the
image.
So,
for
example,
the
image
which
is
built
is
which
is
Quay
dot,
IO
kubernetes
foundation,
slash
foundation,
v2
:
they'll
be
a
hash.
If
our
tag
is
put
on
the
image,
then
it
attacked
with
that
latest,
for
example,
V,
zero,
zero,
1
alpha
or
something,
and
that
will
be
pushed
to
this
location.
A
You
can
just
have
a
look
at
that
make
file,
so
it
does
all
that
entity
also,
additionally,
tagged
I
image
with
the
latest.
Whichever
is
the
latest.
It
will
check
if,
whichever
it
is-
and
it
can
panic
using
that
so
how
I
tested
it
is,
are
just
updated.
So
there
is
a
flag
or
there
is
a
variable
which
basically
update,
which
basically
is
the
location
of
the
registry.
A
B
A
Think
they
are
complementary,
so
so,
based
on
eclis,
none
of
us
actually
updated
a
makefile
okay
and
when
it
came
to
like
we
need
to
version
our
binaries
and
all
so
I
did
so.
My
sedition
or
my
scheme
is
that
the
version
is
rigged
up.
It
is
actually
kept
advantage,
and
that
is
that
bag
which
is
available
at
the
get
master
and
that's
the
one
that
should
be
used
for
all
the
binaries
or
images
that
have
been
built
in
this
repo.
A
C
A
A
We
can
have
a
chat
after
this
semester
and,
let's
see
to
check
what
you
are
doing
I,
what
I
did
was
just
an
option
in
the
make
file
where
you
can
do
this
build
and
push
of
the
image
also
and
I'm,
using
the
daka
file,
which
is
already
updated.
There
is
the
docker
file
to
create
the
controller
image
already
in
the
ref.
Oh
okay,
additionally,
I
did
just
update
a
push
option
in
the
make
file
which
can
do
this
pushing
the
image
using
the
tag
which
is
currently
on
the
repo.
A
C
B
Okay,
this
is
fine,
I
mean,
if
you
guys
can
talk
about
this
after
I
mean
I.
Think
that
there's
kind
of
a
bit
of
a
conflict
between
like
automating
this
and
CI
versus
doing
it
locally
and
then
pushing
it
locally.
It
seems,
like
Paul's,
been
fixated
on
being
able
to
do
it
automatically
in
CI.
So
I'm
not
saying
we
may
not.
You
know
you
eat
me
still
want
to
make
tile,
but
I'm
not
sure
that
would
be
the
primary
way
of
publishing
an
image.
A
A
Exactly
exactly
so,
currently,
that's
all
done
as
part
of
a
script.
What
I
was
trying
to
say
is
that
in
place
of
doing
all
that
means
prep
it
could
this
and
open
it
right,
but
I
also
was
not
imposing
that
that
has
to
be
done
now.
I
just
did
put
that
part
of
that
as
part
of
my
PR.
We
can
move
to
that
later.
Let's
focus
on
what
is
already
being
done.
B
Yeah,
that's
a
good
question
kind
of
wanting
to
just
get
the
release
at
the
door,
I
mean
if
anybody
wants
to
start
working
on
whatever
they
want
to
start
working
on,
but
I
mean
part
of
this
is
just
getting
things
in
the
hang
of
the
easier
is
to
start
getting
feedback
like
that's.
That's
kind
of
the
main
reason
to
get
this
release
out
the
door
are
the
things
that
we
think
people
need
regardless.
B
B
B
Would
maybe
suggest
the
next
one
I
mean,
gives
people
an
opportunity
to
go
through
all
the
outstanding
issues
and
fill
in
the
gaps
for
anything,
that's
missing
in
terms
of
you
know
what
our
respective
priorities
are
and
like
I
said,
I.
Think
tagging
I
think
my
suggestion
would
be
is
like
everybody
who
has
an
interest
in
any
given
feature,
make
sure
it's
tagged
as
an
issue,
and
then,
if
you
want
to
see
it,
you
know
I
mean.
B
B
And
being
able
to
start
prioritizing
like
if
we're
gonna
do
say
a
weekly
release
for
the
next
month
or
two
like
having
issues
that
are
small
enough,
we
can
actually
expect
to
have
when
you've
done
in
a
week
or
two
and
other
people
think
I
mean
honestly
a
week
doesn't
leave
a
lot
of
time.
That's
like
any
bug
fixing
we're
talking
features.
Then.
Probably
two
weeks
is
a
more
reasonable
cycle
like
I'm
gonna.
Do
some
work,
I'm,
gonna
post
a
curve
here,
there's
gonna
be
a
review
cycle.
B
C
A
Yeah
so
while
we
have
been
stormy,
so
what
we
can
we
can
missed
out
is
that
what
is
the
priority
or
the
set
of
features
that
you
have
in
mind?
From
your
point
of
view,
the
feature
might
be
big,
but
then
it
will
be
the
stakeholders
responsibility
to
to
create
an
issue
for
the
feature,
and
maybe
some
issues
for
breaking
it
out,
digging
it
down
into
tasks
which
are
completed
within
a
week
or
twos
time
like
that.
That
should
also
be
our
focus.
B
Yeah,
that
makes
sense
so
yeah,
like
I,
said
I.
Think,
while
we
sort
of
wait
for
alpha
to
get
released
just
focusing
on
planning
and
thinking
about
how
we
want
to
sort
of
revise
the
development
process,
I
think
that's
really
helpful.
It
may
be
a
good
idea
to
maybe
have
a
meeting
later
this
week,
like
one
self
is
released
to
sort
of
kick
things
off
and
set.
You
know
come
back
with
the
expectations
that
we've
set
for
ourselves
and
share
it
with
the
group.
Maybe
Friday.